We analyzed it on ourn own and I’d like to summarize our conclusions collected from trying to create a PoC with KMP for Amplitude Analytics.

The scope of our POC was to answer the following questions:

No more misalignments between iOS and Android in terms of attribution, event naming, logic, etc.?

• If we proceed with the planned implementation the misalignment risk is significantly lower than our current implementation. We still need to map the information from the client, but because of hard typing, the risk of messing it up is lower than being able to send any kind of data to the framework directly.

High reliability of Analytics numbers?

• If we would consider implementing a framework agnostic implementation (the ideal case) the reliability would be definitely lower, because we would need to manually implement the logic of each client:

  • Capturing sessions

  • Tracking lifecycle events

• If we implement the blueprint alternative the risk would be low since the framework itself would handle its own session and lifecycle events per platform

Reduced implementation efforts

• With any solution we choose the effort would be high, especially at the beginning.

  • We would have to learn the intricacies of KMP and publish its artifacts to both clients.

  • Increased time for iOS devs to understand Kotlin syntax

  • Modeling the events and properties in the KMP library project

  • Mapping the events from the client models to the KMP accepted types

Reduced testing efforts?
We would need to check how to test sending data to Amplitude works.

• We still need to test the mapping of the information from each platform to KMP, regardless of the solution.

Is it easily feasible for team iOS to integrate a Kotlin-based library into their SWIFT project?

• It is easily feasible.

Can we really write the Analytics Integration only once?

• Not really. The native framework dependencies provide some specific user properties and events, which we would have to expose as interface functions for both iOS and Android. These particular user properties and functions are of high complexity and vital to properly capture the information regarding the app. The effort of properly implementing these functions is high and has to be done in both Android and iOS.

How is debugging going with KMP?

• Because we are implementing a library this feature does not apply. To test the implementations of the KMP project we would have to provide sample apps that we can run and debug against the uncompiled and unobfuscated code

Are there any pitfalls that could cause a misalignment between Android and iOS?

• In the end, the mapping of the events to the KMP will always be done by the clients. There is always a risk that wrong information is sent by either of the clients, but that’s true regardless of the solution that is implemented. The risk of misalignment is less because both platforms would have a centralized and hard-typed source for the events and user properties to send to the tracking framework.

Any other (potential) blockers that could come up?

• The suggested solution that takes into consideration the pros and cons of the framework, requires the library dependencies to be the same between the clients and the KMP project library, this would make release processes longer and more cumbersome for both platforms.

==> So all in all we have decided not to use KMP for Amplitude Integration!