Glow Test

Internal SDKs

We’re focused here on scaling in the feature area of a particular app, but this is a simplification. If you do happen to have a lot of code that would be described as a “library”, and/or where a lot of regular work is being done, then using KMP there isn’t an “efficiency blocker”. If this code is currently written in both Swift and Kotlin, with multiple developers and potentially conflicting changes, that code will be subject to the same team and workflow issues that “feature dev” is in our discussion. The solutions will be similar as well.

For larger apps, different portions of app logic may “naturally” be split into versioned SDKs purely for organizational purposes.

The same logic might need to be shared between projects. Alternatively, many apps divide into “feature teams”, where different teams focus on different “feature groupings” of a larger app. In general, as an amount of logic and code grows, there’s a “complexity limit”, beyond which formal libraries and publishing make sense.

Within those divisions, similar analysis should apply.

If the module is pure logic, then KMP should probably be treated like any other library. You’re not going to need much platform specialization. A prime example is the work Google is doing with KMP and Workspace. The internals have an enormous amount of complex shared logic. While certainly portions need platform-specific work, the vast majority is “logic”, and largely moving from “Java-oriented” logic.

If an app’s features (screens, data flow, etc) are split into feature teams, each focused on a particular area of the larger app, each of those features and teams would face the same issues presented here. Team coupling, and specialists trying really hard to be generalists. Similar approaches should probably be considered. Just “scaled out” to the feature teams.