Download the sample PDF for Building Mobile Apps at Scale here, or read draft chapters - before they were peer reviewed and edited - as individual articles on this site.
In 2015, few apps had force upgrading mechanisms in place. Nearing 2021, most mature apps have put this approach in place, recognizing the need to force retire old versions of the app. Old app versions might stop working when a backend API is retired, and they might be expensive to test, support and keep backwards compatible. The catch with force upgrade is you need to build it much earlier than when you plan to use it. ...
There’s a high likelihood that your app and your development process needs to adhere to certain compliance and privacy guidelines. PII - Personally Identifiable Information - should not be accessible to anyone but people who should access these details. No mobile engineer, customer support folks, or people working at the company should be able to access this information. GDPR (General Data Protection Regulation) - an official EU regulation - has further expanded the scope of PII. ...
The shorter the feedback cycle between detecting issues with your code, the more productive both engineers and teams will be. While getting feedback on your code at code review is great - would it not be even better to get instant feedback, even before you submit your code to code review? Productive teams put advanced code checking infrastructure in place early on: exactly to help with rapid feedback on “easy to spot” code quality issues. ...
Mobile app performance is something you rarely need to worry about with small apps - and something that becomes increasingly important, as your app - and mobile team working on the app - grows. Users will eventually abandon problematic apps, according to a 2015 Techbeacon study. Since the study, expectations for “snappy” apps have likely only increased. perf.dev is an industry-leading mobile performance platform from the creators of Nanoscope. The platform enables a proactive workflow for managing mobile performance. ...
Kotlin Multiplatform is one of several approaches to build cross-platform features, or apps, by sharing common code with the Kotlin language. We discuss this approach separately from other cross-platform feature development and app development approaches, thanks to its rapid rise in adoption among large apps and developer teams. Kotlin Multiplatform was announced in 2017. With it, you can write Kotlin and build: JVM libraries for Android, or backend services Native framework for iOS and desktop JavaScript artifacts for frontend web or backend services Kotlin Multiplatform The idea behind Kotlin Multiplatform: share business logic code, keep view code as native. ...
When should we onboard to a new language? Should we start to use a new and promising framework? Unfortunately, there are no simple answers and even when you do your research, you might regret the decision you take. In 2016, Swift was at version 2.2. The engineering team at Uber decided to go 100% with Swift when rewriting Uber’s Rider app. The decision turned out to be an almost disaster - mainly because the team did not expect the binary size for Swift to be multiple times that of Objective C. ...
The more you build native mobile apps, the more you realize the pain that supporting client-side business logic brings, due to the nature of mobile app versions having a long life. The idea of building apps that are mostly backend driven will likely come around sooner or later. Sending executable logic to the mobile app is treading on thin ice. Apple has prohibited all forms of executable code up until 2017, when they softened this policy for developer tools. ...
Companies whose apps are compiled from millions of lines of code usually also set up a mobile platform team. At this scale, the company will have dozens of native engineers or more. They’ll run into the problem of native development tools starting to have performance or process issues at this scale, with no good off-the-shelf solutions. This was the case at Uber, and I hear the same of companies like Facebook, Spotify and similar places. ...
Native mobile app build times become an issue very quickly. iOS engineers are very familiar with how seemingly slow Xcode builds projects, and Android engineers with a project beyond “Hello, World” will also start to count the seconds - then the minutes on a build. Neither Apple, nor Google have prioritized build time improvements for large projects. This is especially true for large projects, with hundreds of thousands, or millions of lines of code, and dozens of dependencies. ...
If your company builds several apps, they will all start with different architecture. Different teams will be building each of the apps, moving fast in the early days. However, the idea of having a more “unified” architecture will come up, over time. The sooner there are mobile platform teams owning shared components such as experimentation, feature flags, performance, and others, the sooner this idea is likely to surface. While a unified architecture will no doubt have clear benefits at this point, it will mean a lot of work such as possibly rewriting a good part of the app. ...
When you work on a small mobile team with a handful or engineers, or less, you just go and build the new features. You’ll probably discuss decisions with each other, and comment on code reviews, but that’s about it. With a larger team, this process will have to change - both to avoid stepping on each others’ toes, and to keep the code and architecture choices consistent. Formalizing the planning process is a practice worth introducing above a certain team size. ...
When starting off with a small app, manual testing each release is a viable path. As the app grows, this effort gets more tedious. At scale - an app that’s releases weekly, with a large number of engineers working on it - this approach will break down. The goal at scale is to always have a shippable master with zero - or as close to zero - dependency on manual testing. ...
Both iOS and Android offer opinionated ways to implement localization. iOS supports exporting localizations for translation, while Android builds on top of resource strings. The tooling is slightly different, but the concept is similar. To localize your app and define the strings, you want to localize and ship the localized strings as a separate resource in the binary. Still, with large apps and many locales, you quickly run into challenges with this workflow. ...
Navigation within mobile apps is an underrated problem, similar to deeplinking. This is an area that engineers tend not to pay attention to with a small app - only to realize it’s a beast that needs to be tamed, as the number of screens and transitions grow. Both iOS and Android provide basic navigation concepts and leave putting navigation architecture up to developers. In turn, we tend to reinvent the wheel on navigation, both out of necessity, as well as due to the not invented here syndrome. ...
In-app purchases (IAP) are unique to iOS and Android in the amount of revenue they can drive, and the challenge of testing these on large and complex apps. IAP is unique to mobile platforms and when you sell digital products, not implementing it is rarely an option. You have to pay a hefty fee of 15% on revenue up to $1 million annually (both for iOS and for Android), and 30% above this. ...
CI/CD for simple backend services and small web applications is straightforward. Yet, even for simple mobile applications, it is less so: mostly because of the manual submission step for the app store. Doing a fully automated continuous deployment pipeline is impossible to do so for iOS App Store apps due to the manual review gate. On Android, you can automate this process, as you can with enterprise iOS apps. You can’t have a fully automated continuous deployment to the App Store on iOS, thanks to the manual App Store Review process. ...
Though offline support is becoming more of a feature with rich web applications, it has always been a core use case with native apps. People expect native apps to be usable when connectivity drops. And they certainly expect state to not get lost, when the signal drops or gets weaker for a short period of time. Proper offline mode support adds a lot of complexity and interesting edge cases to an app. ...
An 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 referred to 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. ...
Old versions of the app will stay around for a long time - this can be measured in years. This is unless you’re one of the few teams that have a strict force app upgrade policy 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. While the majority of users will update to new app versions in a matter of days, there will be a long tail of users being on several versions behind. ...
The second most common pain point is caused by mobile apps being 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 users update to this version. There are a few challenges here: Apple does not allow updating native code on the fly. Interestingly enough, they do allow this with non-native code like JavaScript: and this is why solutions where business logic is written using JavaScript, bug fixes are pushed to the client are gaining popularity. ...
State management is the root of most headaches for native mobile development - as well as single page app web development. Mobile applications are almost always stateful. On top of keeping track of the current state in business flows, you need to make sure you handle app lifecycle transitions (iOS, Android). Examples of the app-level lifecycle changes are the app pause and going to the background, coming back to the foreground or being suspended. ...