39 Challenges on Building Mobile Apps at Scale — Part 3: Challenges Due to Large Engineering Teams
This article includes 19–24 challenges from the book.
(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 2: Challenges Due to App Complexity
19. Planning and Decision Making
If you work on a small team, you may not worry too much about details and you build new features. But if you work on a larger team that everyone should be aware of what the other developers doing then you need to be consistent for the sustainability of the project.
Formalizing the planning process is vital in this kind of structures. Specification phases should be done until engineering teams get started planning phase. Unclear requirements and scope lost may lead to unwanted delays in the roadmap.
iOS and Android teams working together on planning is a great advantage for being in the same line. By planning features together, you can be sure that both clients will almost build the same functionality.
There is a limited chance for being successful when you have a poor decision and planning. Make sure you are on the right path with everyone and the outcome will be fine.
20. Architecting Ways to Avoid Stepping on Each Other’s Toes
One of the most challenging issues in building mobile apps is connection and conflicts between developers and developments. If you work on a small project with less people, problems rarely bother. Everyone knows what each other does. On the other hand, working with a big project with lots of developers can cause conflicts and sometimes this might be troublesome.
The trouble starts when too many engineers end up modifying the same files. One can’t be certain which part should he include or which shouldn’t and accidentally broke each other’s functionality. The best way to handle is keeping functionalities small and separate.
With a large team, architecture means to control the level of isolation between teams and components. It limits overlaps and complexity of code to some extent. There are some principles engineers must follow:
- Feature isolation.
- Monorepo-like code structure. Click here for more info.
- Strong code and feature ownership.
- Automated tests guarding the app’s features.
21. Shared Architecture Across Several Apps
A company that builds several apps probably will start with different architectures to apply their practices. However, similar or unified architecture means better understanding across projects. It saves remarkable amount of time to get ready for adding new features or anything else.
People need to take steps towards a unified architecture without rewriting. Here are some benefits of shared architecture between iOS and Android apps.
- Shared language → We need to agree on the concepts such as screens, navigations, modals, flows and use these terms everywhere.
- Shared planning → We can start with planning the same feature in the same document for iOS and Android.
- Breaking down silos → Mobile teams in the organization should talk each other even if they work on different projects. Cross-team planning reviews can be a good start point.
- One shared component at a time → What functionality or library can be shared across apps? If something important is built, it might be used in other projects.
- Introduce new architecture concepts in new parts of the app → We don’t need to rewrite the app for new architecture. Being pragmatic is the best possible solution. Starting to build new screens with new approach can turn into a snowball effect. You might want to check this out.
22. Tooling Maturity for Large Engineering Teams
Companies that has apps compiled from millions lines of code might suffer from performance issues.
Constructing projects on a large scale poses a significant challenge, particularly in terms of build time. When you have a team of 50 mobile engineers collaborating on the codebase, reducing the build time by just 30 seconds can translate to gaining several “engineer months” annually. Let’s break it down: if engineers build the application five times a day, multiplied by the number of engineers, it results in two hours of cumulative “idle” time daily across the entire team. This amounts to three months of idle time every year.
Managing the workflow for shipping numerous apps poses its own set of challenges. Each application requires a series of checkpoints, starting from the initial build, progressing through various testing phases including localization tests, manual and smoke tests, performance evaluations, beta user trials, and more.
23. Scaling Build & Merge Times
As the mobile developer team expands, prioritizing build improvements becomes essential, especially at a per-platform level. There are various straightforward optimizations that teams can address, along with more intricate challenges. An instance of a readily achievable improvement is on iOS, where dynamic frameworks can incur costs in terms of both build times and app size, affecting cold launch times. When prioritizing shorter build times and reducing app size, opting for static libraries proves worthwhile. On the other hand, a more resource-intensive approach to bring about change involves transitioning to a monorepo.
Keeping master green — at scale. How difficult is it to keep short the time for merging changes, and to keep the main branch always green? If you have 30–60 minutes to complete build’s unit, integration and UI tests, there will be an efficiency problem. One way to solve this situation is by parallelize both builds.
24. Mobile Platform Libraries and Teams
When building a large app with a large engineering team, what you use and how you use it matters. For example an engineer will implement a functionality about analytics as you see in the picture above. In a small project, he may not look back what others did before but working in a wide team makes this investigation before development compulsory for not inflating the size of the app.
Mobile apps typically develop internal libraries relatively early in the development process. Often, these libraries serve as a simplified interface for a vendor solution, designed to facilitate smooth migration to an alternative solution if necessary.
There is no limit for what can be an internal library. Generally, some features have a tendency to become a wrapper in most of the apps and these are:
- Logging.
- Analytics.
- Data persistence.
- Feature flags, A/B testing & experimentation.
- Networking & authentication.
- Testing: UI testing, unit testing, mock generation.
- Brand UI elements, colors, themes.
- UI elements, frameworks & layouts..
- Message display.
- Animations.
- Image management.
- Navigation frameworks.
- Architecture frameworks.
- Push notifications.
- Shared functionality specific to app domains: calling, PDFs, scanning, location, maps, and others.
In the next part, I will mention about the Languages and Cross-Platform Approaches.
See you soon.
Resources
- The book → Building Mobile Apps at Scale: 39 Engineering Challenges
- Author of the book → Gergely Orosz
- Book link → https://www.mobileatscale.com/
- https://www.lucidchart.com/blog/decision-making-process-steps
- https://medium.com/mobile-app-development-publication/monorepo-for-ios-and-android-project-2fe9eadd9748
- https://www.uber.com/en-TR/blog/android-engineering-code-monorepo/
