Everything You Need to Know About Mobile App Architecture

Three-layer architecture in mobile applications

In common mobile app architecture, there will be three layers Presentation, Business and Data layers. Three-layer architecture offers scalability and the opportunity to reconfigure applications when there is a need. It is cheaper to update and at the same time, this type of architecture is reliable and fast. The diagram of the mobile app architecture design is given below.

1. The presentation layer is a part of UI components and UI process components. The presentation layer will decide the visual part of the application, i.e. how the users will see the app.

2. The business layer regulates application performance according to business logic. The business layer includes business components, entities and workflows.

3. The data layer binds together with data access components and service agents and data helpers. The data layer communicates with the device’s local data and also gets access to data sources and services externally as part of mobile support infrastructure.

Android application architecture

Mobile application architecture for Android includes different from web architecture components: activities, fragments, services and content providers, broadcast receivers. Android code will use activities classes that facilitate user holistic interaction with the application. For instance, a user may open the app and in a moment receive an entry call or email notification. So, he quickly shifts from the application screen to email composing and then wants to return to the application.

Fragments are Android components used to build multi-pane or single-pane layouts. Fragments always run within the activity, hold defined functionality and can be easily reused. That’s why they allow building flexible UI across devices (tablets, smartphones) customizing orientation, sizes, etc.

Typically, Android applications will include:

• View layer with activity and fragments as UI-based classes
• Data Layer with API and cacheProvider

One more basic notion of architecture in Android is App manifest – the file in which you declare how a device will interact with an application. An application has to adjust to the user interface of the device and respond to the user’s quickly changing requests. In a minute, a user can open a photo-editing application, take a photo using a certain camera effect, download the picture from the editor and share it with 3 social media accounts. The application triggers the device’s camera that can also send requests to the device’s file storage to save the image. Then the application has to offer seamless posting of the picture on social media accounts not logging the user out. Interaction of applications with social media resources must be fast and smooth in terms of UI/UX.

Some mistakes in building Android app architecture that decrease efficiency:

• Setting activities, services and broadcast receivers as data sources
• Smashing boundaries between app’s modules and their responsibilities
• Forgetting about the module’s testability
• Ignoring offline mode functionality

Putting it shortly, do not assign multiple tasks with data into a single class. It’s advisable to think about the app’s unique functionality and offline mode in advance keeping in mind users would need to access the app without the Internet connection. Structuring Android apps for testability is one more important point to consider: moving logic to a separate module, arranging networking communication and other ways may come useful.

iOS mobile application architecture

iOS app architecture will as well be layered as Android apps and include User Interface, Business Logic and Data Access. However, the iOS mobile development is a level more difficult than Android as there are recommended defined architectural patterns like MVC, MVVM, MVP and others. The biggest difference from Android architecture is an iOS organization of UI which may fall into different patterns such as:

• Model-View-Controller (MVC)

Imagine there is an external event, which is a user request and triggers a system to provide the response back to the user. The pattern is the way of the response through different layers of mobile application architecture. Let’s first go into the MVC pattern.

The iOS MVC pattern is the same as the classic MVC. To remind, a Model is a set of classes responsible for business logic and object validation algorithms. It’s independent of View and Controller which is important for testing. The view is responsible for the visual representation of data. On its side, it receives “tasks” from the Model, but can not independently change the state of the Model. The controller is a class that can change the Model though it does not serve as a communication bridge between the View and the Model. The event firstly goes to the Controller that decides how to process it. As a result, the Controller can change the Model, only then View can read what’s to be updated.

• Model View Presenter (MVP). The MVP pattern is the evolution of MVC. Now Controller is replaced by the Presenter which is responsible for changing the View and handling events of the View.
• Model-View-ViewModel (MVVM). The MVVM separates the View from the Model, so the graphics part from the business and back-end logic. MVVM pattern works great for single-page applications in which view and model communicate quickly.
• VIPER (View, Interactor, Presenter, Entity, and Router) – clean architecture approach for iOS.
• Component-based architecture is a new architecture approach and is promoted mostly with React Native and Flutter.

Most iOS applications are defined as thin clients. Thin clients term means that most of the requests made by a client are not performed by the device itself, but rely on the server. Search, editing, mailing – all done in the cloud and results are sent back to the client-side. The data layer in iOS will communicate with external systems. Repository or Gateway are popular design patterns applied on the level. They both encapsulate data sources and define data withdrawing.

Basics of iOS architecture include:

1. Core OS level (Kernel level) – manages low-level features that are often triggered by the application we use e.g. bluetooth or files. It provides a necessary level of security for the whole system.

2. Cocoa Touch (Interface level). It is an Objective-C based UI framework used for building software on iOS devices. It is responsible for basic app infrastructure as in its realm are such key technologies as AirDrop, Auto Layout, TextKit, Apple Push Notifications, Local Notifications, Gesture Recognizers. Thus, it provides support for documents, multitasking, notifications, touch-based input.

3. Media level serves for audio, video, graphic, text, animation implementation. This layer is responsible for UIKit graphics, Media Players, TextKit and Core Text, AV-Foundation as examples.

4. Core Service layer – serves for providing data access and allows file controlling. Features that pertain to the Core Service layer are: iCloud storage, data protection, in-app purchase, file-sharing, user accounts management, etc.

The repository handles actions with data. Repositories are intermediaries between different data resources. The repository is a pattern for the data layer which serves for data layer optimization.

Entities are part of the Business logic layer and these are business rules that go with the data for certain business operations. Business logic is perfectly described with use cases, helpful scenarios that define behavior of the system and user interaction with it. However, not all entities can describe all of the business operations. That service layer is the one to fulfill the rest of business logic operations, CRUD functions (create-read-update-delete), manage networking and validations. Interfaces control operations on the side of the data access level.

What is CLEAN architecture?

Clean architecture states that dependencies come from the outer levels inward. Some imagining of architecture according to CLEAN is circle-shaped. Some of the key characteristics of CLEAN architecture:

• It is effective for testing
• It makes the UI independent. UI can be easily updated without changing the whole system
• It separates databases, frameworks, libraries from UI
• It puts core business logic into entities and use cases
• It isolates frameworks in individual models
• It is less bug-prone as modules

Clean architecture works according to the Separation of concerns principle of building software that helps to handle hopping activities during the user’s interaction with the application.

Entities represent domain object and hold business logic Use cases represent business actions (one use case for one particular business action)

Interfaces/Adapters take control of MVC and retrieve data from databases, 3rd party tools, file systems, etc. They trigger use cases and prepare results into an appropriate delivery format.

External interfaces is the last layer where to use a framework to implement the REST functionality.

Component-based architecture

Components are independent reusable elements of an application that encapsulate certain functionality and behavior. Component-based mobile app architecture design offers a lot of advantages:

• Fast development time and improved time-to-market capabilities
• Reliability of the solution achieved with reuse of elements
• Ease in upgrading software functionality via extensible elements
• Modification of complexity in parts of the application without updating the whole system

Tips to remember

Designing mobile application architecture is an obligatory step to get a successful application delivered. Poor software architecture is error-prone, not reliable and restrains from developing scalability. There are some tips that software engineers use to build effective software applications.

• Decide the type of device you build for. Primarily, the development team should know screen size, resolution, characteristics of CPU-bound performance, memory space, access to specific hardware (camera, GPS, etc.)
• Think of different bandwidth scenarios. Designing appropriate solutions in case of bad connectivity raises a question of caching, state management, data access and speed.
• Take into account platform specifics. UI constraints can happen in building applications for certain platforms. These are usually adjusting to screen sizes, memory usage, battery life, security and network connectivity.
• Use best practices for application scalability. When building scalable mobile apps, you’ll need to accommodate more resources not changing the core structure. The choice of framework and tech stack is critical in developing and improving the app’s scalability, but also reduction in dependencies, code reusability, components separation, data flows, use of global and local services impact how well the application will perform multiple users’ requests.
• Mobile enterprise development should carefully choose mobile application architecture and consider all the variants before shifting to the development stage. Native approach, the enterprise can request a cross-platform application. Thus, there is a possibility to see a reduction in costs, faster time-to-market and other benefits.