39 Challenges on Building Mobile Apps at Scale — Part 2: Challenges Due to App Complexity

This article includes 13–18 challenges from the book.

Mücahit Eren Özkur

Follow

Published in

DigiGeek

7 min readOct 23, 2023

--

(This series is a summary of what I understood and considered as important from the book “Building Mobile Apps at Scale: 39 Engineering Challenges”.)

Previous article → 39 Challenges on Building Mobile Apps at Scale — Part 1: Challenges Due to the Nature of Mobile Apps

13. Navigation Architecture Within Large Apps

The issue of navigating within mobile applications is often overlooked, much like the challenges posed by deeplinks. We may not give it much consideration when the app is in its infancy. However, as the app expands, we come to recognize that the navigation structure has evolved into a complex problem that requires careful management, particularly as the quantity of screens and transitions increases.

Having a well-defined app navigation strategy with good separation of app state is key for any decent-sized app. We need to know what navigation happens between screens? What triggers this animation between taps or gestures? Is navigation independent of app state?

Inconsistent navigation can lead to duplication of code on instructing the app to navigate. It violates DRY principle.

Asynchronous navigation is another key term in this subject. We can define as when something needs to finish before navigation can continue. Logging into the application is a common example. Have you ever thought what happens if the user tries to navigate during this phase? We as engineers must plan test scenarios to avoid this problem.

On iOS, there is no native navigation component. Some open source projects can help. On Android, The Jetpack Navigation Architecture Component is the one mostly used for navigation.

14. Application State & Event-Driven Changes

As the app becomes more complicated, the potential number of states it can have also increases. Certain state changes can lead to additional state modifications. For instance, when a component modifies its state following a user’s tap, it could result in a change in the state of the entire page or application.

As the app grows in size and complexity, the likelihood of bugs arising from unusual combinations of events increases. The challenge with these uncommon events is that they are hard to anticipate or assess in testing. For instance, a background push notification that triggers a state change in a component might arrive just after the user locks the app screen, resulting in a different state change.

Record invalid states with information to replay or debug, so you have details on what went wrong and how to reproduce the issue. A convenient approach to initiate this process is by utilizing a bug reporting tool provided by various vendors, offering a wide array of options to select from.

We need to keep up with the state management best practices to keep the number of bugs low that happen because of state change issues.

15. Localization

Both iOS and Android offer some ways to implement localization on your project. There are many challenges about localization while building app.

Deciding what to localize in the app versus doing so on the backend is one of the first challenges any growing app will confront.

When supporting a large number of locales, you need to ensure that all localization translations are complete before shipping to the app store.

Ensuring iOS and Android use the same language and localization is yet another challenge.

Localized custom fonts is a frequently overlooked area and attention should be paid.

Currencies formatted differently on iOS and Android on certain locales is another pain point that multi-language, multi-platform apps displaying monetary values encounter.

Supporting right-to-left (RTL) languages can often go beyond just translations.

Testing localization is no small effort. In an ideal world, a native speaker would go through every flow of your app after each localization change. In reality, this rarely happens because it is too expensive to do.

16. Modular Architecture & Dependency Injection

As apps become large, it often makes sense to build parts of the application as reusable components or modules.

A modular approach in the design and development of mobile applications involves breaking down the app into various functional units, components, and subsystems. This allows for the seamless replacement or addition of any module without causing disruptions to the overall system, ensuring adaptability to evolving business needs and customer expectations.

It has many advantages as follows:

Greater adaptability
Easy testing.
Ease developers’ productivity.
Reducing the infrastructure cost.
Avoiding reliability related problems.

Modular architecture is such an enormous subject that I can’t simply go into details in a short paragraph. You can find more details from here. Also, you can check this website.

17. Automated Testing

Automated testing is a must for large apps. By applying automated tests, we can be sure for the parts that is tested are working fine. Let’s have a closer look on automated test types for mobile.

Unit test: It is the easiest one of all automated tests. We test just a component, also called the ‘unit’. These tests are simple to write and understand. They are fast to run. Writing unit test reduces bug rate, keeps the code cleaner and increases knowledge sharing within developers.
Integration test: It is more complex than unit tests. It’s behaviour is to test multiple units that interacts with each other. Integration tests take longer to run. It’s developer’s choice to work with mock data. If you want to know more about integration tests, you can visit here.
Snapshot test: One method involves the comparison of the layout of a UI element or page to a reference image. This is a cost-effective and swifty approach to verify that code modifications do not lead to unanticipated alterations in the UI.
UI test: A test that actively engages with the user interface and checks for specific behaviors in its operation. It utilizes UI automation to input commands and assesses the UI to confirm expected outcomes. These tests are typically the most hard to create and have the longest execution times.

18. Manual Testing

If you have a small app, manual testing can be a life saver. As the app grows, you notice that it is a headache for everyone.

The goal at scale is to always have a shippable master with zero, or as close to zero, dependency upon manual testing.

There are several challenges and questions about manual testing:

Who does manual testing? Big projects should not rely on only developers to test the product. Developer can write conditions that must be match to a google form and then he/she marks the conditions as passed or failed but that’s not sufficient. We have to include release and test team in the game.
How do you keep testing instructions up-to-date? It is vital to keep the instructions updated frequently. In this way, there is no suspicion about the app.
To keep manual testing in-house, outsource, or to mix? Testing is a time consuming process and someone has to do it. Some choose to do it insource or some choose outsource way. Also companies use third parties in order to make it easy to carry this burden.
How do you integrate manual testing in your build train and release process? You need to be certain about the issues. What kind of problem should block the release and what are things that will not?

You can use the book “Hands-On Mobile App Testing by Daniel Knott” to learn more.

In the next part, I will mention about the challenges due to large engineering teams.

See you soon.

Next Article → 39 Challenges on Building Mobile Apps at Scale — Part 3: Challenges Due to Large Engineering Teams

Resources