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

This article includes 1–12 challenges from the book.

Mücahit Eren Özkur
DigiGeek
9 min readAug 25, 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”. It will be consisting of 5 parts.)

  1. State Management

It refers to the management and manipulation of data within an application at a given point in time. In the context of mobile app development, state management becomes crucial due to the unique challenges posed by the nature of mobile devices and the user interactions they involve.

Effective state management in mobile app development is essential for delivering a responsive, user-friendly experience that handles various challenges posed by mobile devices and user interactions. Different frameworks and libraries provide various ways to manage state, and the choice of approach depends on the complexity and requirements of the specific app being developed.

See more for iOS and Android.

2. Mistakes Are Hard to Revert

Resource

Mobile apps are distributed as binaries. Once a user updates to a version with a client-side bug, they are stuck with that bug until a new version is released and the user updates.

We can see a lot of challenges like:

  • Both Apple and Google are strict on allowing executable code to be sent to apps. Apple’s store guidelines prohibit the execution of code that alters the app’s functionality, while Google has the ability to identify unassociated executable code as malicious, in accordance with their program policy. So, you can’t update your apps remotely.
  • The process of releasing a new version of an app on the store lasts from several hours to multiple days. For iOS, each app undergoes a manual review, which typically requires 24 to 48 hours to finalize. On the Android platform, manual reviews are not consistently conducted; however, when they do occur, they can extend beyond a week, often exceeding seven days.
  • Users take days to update to the latest version after a new version is published to the app store.
  • You can not assume that all users will get this updated version, ever.

3. The Long Tail of Old App Versions

Resource

Old versions of the app will stay around for a long time, up to several years. This time frame is only shorter if you are one of the few teams that put strict force app upgrade policies in place. Apps that have a rolling window of force upgrades include Whatsapp and Messenger. Several others use force upgrades frequently, like banking apps Monzo or American Express.

Here’s what you can do to not get harm:

  • Build sturdy network response handling and parsing, using dedicated tooling that solves these problems.
  • Plan well in advance for breaking backend changes.
  • Version your backend endpoints.
  • Track usage stats on an app version level.
  • Put client-side monitoring and alerting in place.
  • Consider doing upgrade testing.

4. Deeplinks

Resource

A deeplink is a hyperlink that directs users to a specific screen or content within a mobile app, enhancing user experience and engagement by enabling seamless navigation from external sources.

Topics that make deeplinks challenging:

  • Backward compatibility: ensuring that existing deeplinks keep working in older versions of the app, even after significant navigation or logic changes.
  • State problems when deeplinking to a running app with existing state.
  • iOS and Android deeplink implementation differences.

The biggest challenge with deeplinks is how neither iOS nor Android provides an opinionated approach on how to design and test deeplinks. As the number of deeplinks grows, the effort and complexity of keeping these deeplinks working snowballs.

See more for iOS.

5. Push and Background Notifications

Resource

App push notifications are a frequently used notification, communication, and marketing tool. The business loves to use push notifications, and as a developer, you will be asked to support this method sooner or later. Here’s the challenges:

  • A similar set of challenges as deeplinks, in terms of implementing what action the notification should trigger. A push notification is a glorified deeplink: a message with an action that links into the app. Thinking about backward compatibility, state problems, and planning ahead all apply to push notifications as well.
  • Push notification delivery is not guaranteed. Especially when sent in bulk, both Apple and Google might throttle push notifications. The rules around this throttling is a black box. However, device connectivity issues, as well as the OS restricting notifications for apps that have not recently been active, might also result in people not seeing push notifications you send.
  • Testing push notifications is a challenge. You can, of course, test this manually. It is more of a workaround, but you can test them on a simulator both on iOS, and on Android. However, for automated testing, you need to write end-to-end UI tests, which are expensive to create and maintain.

See more for iOS and Android.

6. App Crashes

Resource

App crashing is one of the most noticeable bugs in any mobile app, and often ones with high business impact. Users might not complete a key flow, and they might grow frustrated and stop using the app (also known as churning), or leave poor reviews.

Crashes are not a mobile-only concern. They are a major focus area on the backend, where monitoring uncaught exceptions or 5XX status codes is common practice. On the web, due to its nature (single-threaded execution within a sandbox) crashes are rarer than on mobile apps.

The first rule of crashes is you need to track when they happen and have sufficient debug information. Once you track crashes, you want to report on what percentage of sessions end up crashing and reduce this number as much as you can.

See more from here.

7. Offline Support

Resource

Offline support is another challenging subject and here’s why:

  • Reliably detecting when the phone is offline. The OS could report the user being online; however, this might not be the case.
  • Detecting connection speed and latency and changing the app’s behaviour accordingly if it is necessary.
  • Persisting local state when the device is offline, and synchronizing back when the connection recovers.
  • Decide which features should work offline and which ones should not.
  • Decide how to handle offline edge cases. What do you want to do with extremely slow connections, where the phone is still online, but the data connection is overly slow? A robust solution is to treat this as offline and perhaps notify the user of this fact. What about timeouts? Will you retry?

8. Accessibility

Resource

Accessibility is a big deal for popular applications, a few reasons:

  1. If you have a large number of users, many of them will have various accessibility needs, finding it difficult or impossible to interact with your app without adequate support.
  2. If the app is not accessible, there is an inherent legal risk for the app’s publisher; several accessibility lawsuits targeting native mobile apps are already happening in the US.

Accessibility goes deeper than ensuring sighted people can use the app. Allowing accessibility preferences to work with the app, such as supporting the user’s font size of choice via Dynamic Type support on iOS and using scale-independent pixels as measurement on Android are both practices you should follow.

See more about accessibility that I’ve written before from here.

9. CI/CD

Resource

Continuous Integration and Continuous Deployment (CI/CD) are crucial in mobile development for streamlining the process of building, testing, and releasing mobile apps. Here are some challenges to mention:

  • Diverse Ecosystems.
  • Long Testing Times.
  • App Store Approval Process.
  • Complexity of Mobile Platforms.
  • Network Conditions.
  • Security Concerns.
  • Automated UI Testing.

CI/CD is such a big topic to work on. You can find more details from here.

10. Third-Party Libraries and SDKs

Resource

As your app begins to grow and integrate with many third-party libraries, the build process becomes complex. Those libraries will have new versions, some of which are breaking changes that will require your source code to be updated correctly, and re-tested.

Third-party libraries can be a security liability. You need to monitor for third-party library vulnerabilities on an ongoing basis. An option is to hire a third-party security provider to notify you when this happens.

Stability and reliability is another issue with third-party libraries. For example, in April 2020, the Google Maps SDK team pushed code to their backend that caused the apps embedding it to crash.

Making third-party library updates reversible is difficult, and sometimes impossible to do. Major library updates can be risky.

It is a healthy approach to treat all third-party dependencies as risks, keep track of them, and re-evaluate the need to use them on a regular basis.

11. Device and OS Fragmentation

Resource

Device model and OS fragmentation is an everyday problem on both iOS and Android. Device fragmentation and weird, hardware-related bugs have always been familiar pain points on Android. OS fragmentation is less of an issue on iOS, while it keeps getting worse on Android.

Keeping on top of new OS releases and the accompanying API changes requires focus from mobile engineers. Both iOS and Android keep innovating; features and APIs keep being added, changed, and deprecated.

Making sure the app keeps working without issues on older OS and devices is more of a challenge.

Deciding how and when to stop supporting old OS versions is a process your mobile team should put in, early on. The cost of supporting old iOS and Android versions is high and the payoff can be low. When revenue or profit from the old version is less than the cost to maintain, the pragmatic solution is to drop support for old OSes.

12. In-App Purchases

Resource

In-app purchases (IAPs) offer a way for users to make purchases within mobile applications, unlocking additional content, features, or services. However, there are several obstacles and limitations associated with in-app purchases:

  • App Store/Google Play Store policies.
  • Platform fees.
  • Complexity.
  • User trust.
  • Platform lock-in.
  • Limited revenue models.
  • User experience.
  • Refund requests.
  • Regulations.
  • Testing and quality assurance.
  • Fraud prevention.

In the next part, I will mention about the challenges due to app complexity.

See you soon.

--

--