We built our iOS and Android apps in Java & Kotlin — one year later

Monday morning, first cappuccino, first lines of a new feature we’re adding to our mobile apps. I look at the calendar and realize that over a year ago we’ve decided to build our mobile apps using Multi-OS Engine. Was it a good decision? Here is what we have learned.

What Multi-OS Engine is?

Multi-OS Engine is the closest-to-native solution that allows you to create cross-platform mobile applications. I wrote a story about it here, but here is the TL;DR:

Take your Android app, add iOS views and run common Java/Kotlin code on your iPhone.

That’s correct — build the Android part in your cozy Android Studio, then just add iOS views in Xcode and bind them to Java/Kotlin presenters.

How does the development process look like?

New endpoints, written in Go, are already running on Google Cloud, awaiting requests. I quickly modify the Model data classes and REST interface.

Time for the Presenter. I prepare mocked observers, which will be connected to the real buttons in a moment, and begin designing a RxJava flow. Here comes the complicated logic that will correctly handle all input data from views, asynchronously verify it, autosave it in the background and finally feed the backend with it, handling any error that may occur. All of it is covered with a unit tests. The presenter is not using any Android classes, so JUnit runs the tests in a blink of an eye. After the presenter is ready and tested it’s time for the views.

I like to start with Android — a new fragment, a few inputs, and other views. All I have to do is connect them to the exposed Observers and Observables from the Presenter. Next comes the iOS part — I switch from Android Studio to Xcode and create new UIViewController, UITextFields, and UIButtons. All connected to the powerful RxJava waiting for the data.

I’m working with Android Studio and XCode, so I can easily debug the app using physical Android and iOS devices.

Questions we heard

What if Multi-OS Engine disappears one day?

Worst case scenario: Android app is not influenced at all. iOS app already has the views and requires only rewriting the Java logic to Swift.

Why did you choose Multi-OS Engine instead of Xamarin or React Native?

It’s the closest-to-native solution that exists. We didn’t choose Xamarin, because we prefer to write Android app in Java/Kotlin with Android Studio instead of C# and Visual Studio. React Native was a plan B — it seems very promising although we have seen a trend in big apps to drop React Native (https://proandroiddev.com/the-truth-about-cross-platform-mobile-development-8b4f2de942e2).

What is currently the biggest issue with Multi-OS Engine?

Unpopularity. I’ve heard that some developers would love to try it with production apps but are waiting until MOE will gain more popularity. There are no fancy code camps, which allows you to learn it while you listen to a soothing voice of a teacher. You have to learn it from articles, tutorials and posts.It is also a good idea to reach out to developers experienced with MOE to get additional consulting.

Will I stuck with some weird error without any solution online?

I don’t think that you will be able to find some copypaste solution on the stackoverflow.com. During the year we had a couple of weird issues, but we always received a quick solution from the creators of MOE. Place your question on http://discuss.multi-os-engine.org and I’m sure someone will find a solution over the night.

Summary

Multi-OS Engine delivers what it promises, but remains unknown.

We are successfully iterating our mobile applications, incorporating new features and external services. Using platform-specific methods is not a problem, we can easily use any native library both for Android and iOS.

However, Multi-OS Engine is still not widely known. During this year there were no breaking updates, the userbase is slowly growing. While developers are deciding if they should use Xamarin, Flutter or React Native — the MOE remains hidden.

Kotlin/Native has been announced with a promise of Kotlin-based iOS apps without using JVM. It’s a distant future and a completely separate topic, but I think that the quote below quickly explains the difference.

With JVM AOT approach they could write most of their code in Java and start to write some of the code in Kotlin (and fall in love with it). With current approach these people either refuse to port their app to iOS at all or discover and use MOE.

In the following weeks, I’m planning to release more posts allowing you to create a basic Multi-OS Engine app connected to Firebase. If you are interested, make to sure to follow my profile!