arst

Why we changed our recommendation

The lack of source visibility has long been an issue. However, for much of KMP’s history, the tech was “pre-stable”. It was easy to assume that KMP would ultimately be abandoned. There is more friction for iOS devs using KMP source. They need to install a JVM and properly configure their build system, as well as wait for a longer initial build.

These issues were often sufficient to push back on the KMP effort, and arguably, that wasn’t unreasonable pushback. To get KMP “in the door”, binary packages were an easy starting point. No friction. KMP needed to “prove” itself, and since it caused essentially zero friction for iOS developers to consume binaries, there was much less to push back about.

Times have changed. KMP is stable, is now endorsed by Google, etc. The tech “works”. Proving that it “works” doesn’t accomplish much. The goal of the piloting phase is to evaluate if KMP works for your team. Starting with binaries does not move you significantly towards that goal.

The “friction” of installing some tooling, now that KMP is “stable”, is no longer really “reasonable” pushback. It’s simply not that difficult to do. If, for your team, that is enough pushback, I’d argue your overall chances of success aren’t very high.