· 2 min read
arst
Coupled apps and teams
Our teams are comprised of native mobile specialists. There should be some blending of skills over time, mostly focused around the shared logic. However, a monorepo forces both platforms to immediately consume KMP changes.
That means either the platform specialist needs to complete changes on the “other” platform, or the other app team needs to be involved, before features “land”. You can structure development in this way, but there is a significantly more workflow coordination. There will also be much longer periods where implementations remain unmerged.
If you’ve ever had to work with your team to prioritize PR completions, double that, across teams. Then, of course, changes made during the “other app” implementation bounce back for a follow-up PR. It’s not great.
These workflow problems can be mildly frustrating when development is “calm”. As deadlines approach, workflow problems are magnified.
A common result, is code that should be in KMP is written in the platform-specific language instead, to avoid the overhead.
No Staggered Dev
Staggering platform implementations can be valuable. Not released implementations. Just during dev.
Much of product development is iterative. What the product manager asks for is interpreted by a designer, which is then interpreted by an engineer. For new features with any level of complexity, that is rarely the last step. There are usually iterations. The coupling described above both delays that iteration, and adds extra work that is pure waste. Most feature feedback can be done by looking at one platform.
And again, bad when seas are calm. Horrible when running up on a deadline.
Merging repos is “risky”
The final point. Physically “merging” repos, with CI, PRs workflows, etc, is not trivial. We’ve talked to a number of teams who do plan to do this, but delay “until the next release is out”. There’s always another release coming.
Once merged, “unmerging”, if you decided that was best, is similarly not trivial.
Merging repos, purely to support KMP development, is a big decision. Big decisions are risky.