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.
...