arst

Screen/Architecture Disconnect

When implementing a feature, say some screens and supporting logic, you write them as a unit. Attempting to first write the logic, then the UI on top of it, without being able to edit the logic, would be very frustrating and inefficient.

Yet that is the basic workflow modeled with library publishing and KMP.

Logically, it’s similar to how back end and front end code are developed. The needs of the app will drive changes to the server, but there’s a lot of extra communication and work involved. Because there needs to be. Adding that kind of bottleneck unnecessarily is what we’re trying to avoid.

Of course, to even attempt to function in this model, a method to locally edit the library code is introduced. That makes this workflow model at least possible. However, once editing is complete, the library must be “published”, then updated in the app code, then reviewed, etc. The workflow’s overhead eats any potential efficiency that KMP might introduce.

We’ve talked to many teams who attempt to scale KMP while continuing with a library model. For the most part, these teams fully understand the issue, and often saw it coming in advance. If you and your team are in this camp, well, we have some good news coming (keep reading).