Collection of thoughts about mobile app development

There are different aspects that anyone can encounter during the development of a mobile app.

I tried to collect a list of criteria, useful to build a possible boilerplate for the implementation of a generic mobile application. Plus I added some criteria and suggestions that could help separating the different layers of the application.

Design System

A design system playground is mandatory in order to share and live test any components together with the product team or a single designer, otherwise testing the app in debug mode will be a cumbersome task (think about just to test the behaviour of a simple button that appears at the end of a flow).

Luckily we are not anymore in the early 2000s when the concept of web components was futuristic and avoided by many developers (well for many backend developers is still difficult to understand nowadays how a component works, but thanks god they have other problems to think about).

We have storybook or playwright that allow us to check design, behaviour and in some case also create complete E2E way before anything will be organized and rendered inside a static page

Unit Tests

While the concept of unit testing is also luckily moving to something more useful like integration testing, having a bare minimum coverage of 70-80% of the code base is not a bad thing. Unit tests are useful to intercept regressions on the business logic of an application. But they are not completely a safe and sound approach for the UI, specially on mobile app. Any unit testing library is trying to mock an environment (browser, mobile device, etc) but in most of the case the developer tends to invest more time in order to tweak this mocks that on the most important implementation.

E2E Tests

I repute the end to end tests the most important tests, in general at the same level of the integration one. Naturally they require more effort to be written and tested (specially on a pipeline). The good part is that they are totally agnostic about the technology behind, as they should reproduce what the user usually or randomly does.

Not only, while in a browser environment we don’t have anymore to waste time* in order to test all the possible rendering engines thanks to frameworks, library and standards on mobile the situation is still not so happy. IOS and Android support differently certain kind of elements in a view, plus certain kind of basic features like push notifications, security and sensors.

*well let’s say most of the time, unfortunately there is still to consider Safari. But Firefox and Opera are disappearing from the scene

At the moment the tools for mobile e2e tests are less available that for browsers, an option is Appium

But let’s go a deep more in the development and in case into the required packages for an app

Routing and navigation

A mobile app presents different small and big views, these can be molecule or complete organism, speaking in an atomic design friendly language.

A full page requires an internal routing with the possibility of passing parameters within different pages. In general the internal routing implementation is straight forward for a mobile app.

State Manager

Sooner or later you will need to pass and edit information between different views but also to store them locally as a respectable mobile application should also work offline.
Being aware that there is no localStorage/sessionStorage mechanism on a smartphone you will need to install and understand how the asynchronous API of your mobile device works (yes, asynchronous, we are in 2023)

Localization

This could be a total custom implementation or could also involve a third party library. There are two main aspects: content and formatting.

While for the content is enough to expand and cover all the possible language in a big and smart dictionary (that could be local or remote), for the formatting there are some more important consideration.

A date should be possibly always stored in timestamp format keeping track also of the localization of the device. This means that if you are considering to allow the user to change manually their settings, in order to avoid the update of all the historical data, keep both information in each model. A similar reasoning can be applied to currency. Never use string format to store datetime information

In the next episode I will dedicate some time to one of the most basic but a the same time most annoying feature of mobile development: the push notifications.