Our typical mobile app actually consists of three different pieces of software. Many times, the most visible portion of a mobile app project is the software you have running on your mobile device. However, that app is often just a piece of a larger ecosystem, which all must work together to provide the necessary functionality. Below we’ll discuss a typical architecture we would implement for a client’s mid-sized project.
Components
Backend
The backend system is the brains of the operation, and it usually lives on self-hosted servers or in the cloud. This is where most of the data the app uses is stored. The backend component itself is made up of multiple pieces such as a data storage system, the application code, or a job runner. In our standard system, the backend talks to the other components using an application programming interface (API).
Common Responsibilities
- Storing data
- Running background tasks
- Sending Push Notifications
Common Technologies We Use
- Firebase
- AWS
- Heroku
- SQL
- Python
- Java
Admin Frontend
Users utilize the web application to manage data and perform administrative functions. Depending on the requirements and how the system will be used, this may sometimes also include all the functionality present in the mobile app. The web admin component interacts with the backend system through the API. In most cases, it never talks directly to the mobile app.
Common Responsibilities
- Managing data
- Administering user accounts and permissions
- Viewing statistics and analytics
Common Technologies We Use
- Angular
- S3
- Javascript/Typescript
- HTML
Mobile App
Finally, we get to the mobile app. After all that work, the mobile app is typically seen as the main user interface in many of our mobile projects. Like the web admin, all communication is done through the backend API, but the app may connect to many other systems (e.g., Apple’s push notification servers, Google Maps, RSS feeds) to provide all the functions a user needs.
Common Responsibilities
- End-user functionality
Common Technologies We Use
- Swift
- Kotlin
- Objective-C
- Java
- React Native
- Xamarin
- Ionic
- Cordova
General Principals We Consider
- We often push as much functionality to the backend as possible. This allows a common platform between all other components (e.g., Android App, iOS App, CMS, etc)
- We pick the best component for each requirement. In some cases, all the system functionality needs to be present through the mobile app, but in many cases, the administrative system work is better suited to a web admin. This allows administrative users to control the app more efficiently and take advantage of the additional screen space a desktop or laptop provides.
Wrapping It All Up
There are many ways to architect a mobile app, and most of the decisions made during that process depend on requirements and budget. The system presented above is a good start for many mobile apps, and it allows the system to grow and scale to meet future needs.
Looking for more like this?
Sign up for our monthly newsletter to receive helpful articles, case studies, and stories from our team.
Chicago Roboto 2022 Retrospective
August 11, 2022Scott Schmitz shares some notes of interest from talks at Chicago Roboto 2022, an Android community conference, that took place August 1-2.
Read moreBetween the brackets: MichiganLabs’ approach to software development
February 12, 2024 Read moreWhat the smartest executive leaders are doing right now
July 25, 2024We are consistently seeing three things right now in terms of how executives are tackling the technological challenges they are facing.
Read more