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.
MichiganLabs’ approach to product design: A strategic, problem-solving process
February 12, 2024Product design, or UX design, is a strategic problem-solving process that leads to a valuable digital product. Learn what to expect when working with product designers for your custom software.
Read moreWhy Use Flutter?
January 18, 2023We discuss Flutter, a framework for building Android and iOS apps with a single codebase, created by Google in 2018. Given the increasing popularity of smartphones and mobile-first experiences, it is essential to cover not only Android and iOS platforms but also the mobile-first web.
Read moreA Study of Human-Centered Design Off Screen - Burning Man Festival
February 13, 2023Kourtney examines the Burning Man Festival and its fascinating history of human-centered design
Read more