If a new mobile project starts and you have to talk via HTTP to other devices (could be anything, like a server, a IoT device or even another smartphone) you may have a similar problem like me and my team had.
The API isn't ready to use but you also don't want to block yourself. Maybe even the customer complains already and wants to finally test and see how the app behaves etc.
There are many solutions how to "fix" this "problem". One solution is to kinda "mock" the API inside your application. This is obvious from my point of view and I did it in the past quite often and it worked pretty well.
Oh, and if you design the architecture of the app well you could also implement a "demo modus" where users (and the customer) are able to play with the app without the requirement of having (or connecting) with the other device.
So it's a win-win situation, right?
Sure, it is. At least for your users. But this brings of course other (coding) challenges for you and your team. Because even if this mock API consists of only some static JSON files you have to think how to keep them in sync with at least the other app team (iOS or Android). Or maybe even with the backend team.
In the past I always hardcoded the JSON files in one Gradle module (from the JVM side) and hoped that someone will inform me if there will be an API change or I inform the others if I think an API change makes sense. But yeah, as I said, then each other team has to be informed and even worse they have to apply these changes quickly because otherwise things are going to break.
As you probably already spotted by the headline of this blog we tried this time another solution
Kotlin Multiplatform
I mean, our mock API consists only of static files and there are no other dependencies to the Android or iOS world. Isn't this the perfect example of using Kotlin Mutliplatform?
Because we had no experiences with MPP yet (beside of an awesome example of my valued colleague Tom Seifert) and we don't wanted to jump directly on the monorepo train, which is somehow suggested by the MPP documentation, we decided to see this as an experiment and created a repository outside of our current ones. Yes, we have one git repository for Android and one for iOS.
With this approach we are able to start with Kotlin Multiplatform and gain some knowledge about the new technology without making big changes in our existing code bases. Importing the generated JAR and Framework from the project in our Apps were done over our internal Artifactory. We have set it up that the iOS side can consume the Framework via Carthage and the Android side via Gradle.
If we would find out that this approach doesn't work for whatever reasons we could simply copy the Kotlin code into our Android project and go back to the old approach — where each platform has its own implementation. This way we are having no real risk because what we write is already written in Kotlin and can be natively consumed by our Android project.
We are still in the early development with this project but so far everything went really smoothly. Of course we ran into some pitfalls like dealing with frozen singletons on the Kotlin/Native (iOS) side or thinking about the version names twice because Carthage is very strict with it.
But all of the problems are quite easy to solve and we are not in a state where we think it was a wrong decision going this way.
Anyway. This is our story how we are trying to use Kotlin Multiplatform.
I plan another post were I will go a little bit deeper into the technical stuff — showing you some source code and how to set this up in your project.
