Considerations for an effective mobile app development

https://vijayverma.co/

Choosing the right technology for your mobile app development can depend on a variety of things, and since it’s key for any business to utilise their resources effectively considering your options should not be a trivial process.

As a developer here’s how my decision process would look like if I would start a business tomorrow, with a mobile app as its key product. I’ll try to be as objective as possible, but I’m afraid I can’t hide that I’m a big advocate of Kotlin Multiplatform (KMP).

Your 1st question: native or cross-platform?

I’d say this is the traditional question when building mobile apps and it’s a question of efficiency vs quality.

Why cross-platform?

For simplicity I’m going to assume that currently Flutter’s and React Native’s performance on both Android and iOS is equal to a native solution.
Doing an in-depth performance comparison between all platforms, covering multiple use-cases is an effortful task, which will only provide a snapshot of the frameworks, and it’s likely to get quickly outdated. The scope of this article is to provide you with a longer-term outlook on the purpose of the frameworks and the direction of their evolution.

So what are the biggest benefits of using a cross-platform solution:

• You’ll get 1 source code with 2 apps (android & iOS), which generally speaking will result in roughly 2x efficiency or 50% less cost
• No synchronization costs between platforms (I’ll come back to this later)

My biggest concern regarding this approach is the ideology of cross-platform solutions, that you can treat two distinct platforms, which have similarities the same way. This, in my opinion, is the same as thinking that applying the same educational system to two siblings will have the same results.

Now, our cross-platform frameworks with this ideology, will provide the bridge between platforms, so basically they’re making all the platform-specific decisions for you.
Also if one of the platforms has a new feature, you’ll need to wait for the framework to support it too. I know the available frameworks provide a way to write something platform specific, but it’s a last resort wound dressing, when the framework is bleeding somewhere, and it’ll cost you (your team is potentially not a native expert, and in most cases interoperability with this native code isn’t the nicest)

This ideology is why I think even if not at the moment, the project will likely hit some quality roadblocks on its way, because:

• I don’t think Android or iOS have or will have any intention of strictly following each other, this will result in different features, capabilities on the two platforms, and it can become incredibly hard for the framework to keep up with the platforms.
• You don’t have full control over the platform specific parts, you have to rely on the framework. And some UI decisions have to be platform specific (unless you’re a barbarian and don’t mind putting a FAB on iOS devices)

Now with that said, I do like Flutter and I tolerate React Native, since they do a pretty good job given the constraints of their approaches, also I can see why going with two native apps instead of a cross-platform one can seem like you are praying a premium on the quality from a business perspective.

What’s the problem with native solutions?

It’s a bit like shooting sparrows with a cannon. Why? Because let’s say your Android & iOS app are 70–80% similar, now you end up implementing the same thing twice, just so that you could better control that 30–20% difference between the two platforms.
My biggest issue is not even that you implement the same thing twice, but the tremendous effort that is needed to make sure the two platforms are in sync. No matter how good your team is and how efficient they communicate, they’ll still spend time aligning the platforms. People tend to underestimate this aspect I think, mostly because it’s hard to measure, but it can become a monster that drains the efficiency of your team.

So knowing all this, you should make your decision with your two main constraints in mind, efficiency vs quality:

1. If you have an endless budget and you only care about quality, then definitely go full native.
2. If you’re a startup, you have a limited budget and you just want an MVP, then probably cross-platform looks like the best decision so far, but you’re a forward thinking person and you’re thinking about the next step: your MVP brings in the money, and suddenly you do care about quality and you care a lot. At this step there is a risk, that if you hit a cross-platform roadblock you need to rewrite your whole app in native.
3. If you don’t have a preference, you want both and you want the best quality/cost ratio. You’ll have to settle with the thought that with native or cross-platform you’re choosing either efficiency or quality.

Kotlin Multiplatform for the rescue

This beast has the potential to bring you the best quality/cost ratio. Why?

• You get your native code, you can leverage the power of the different platforms, which brings you native quality.
• Is it as efficient as cross-platform? No, but it’s almost. You can share any of your non platform specific code (which generally is up to 80%, and if you want to abuse its purpose, there are methods for sharing UI also).

Kotlin Multiplatform doesn’t want to unify two different platforms, it just gives you the tools to share what you consider common parts of two apps.

And I have to mention here a widely repeated quote (mostly by Kevin though):

Shared UI is a history of pain and failure. Shared logic is the history of computers. -Kevin Galligan

The icing on the cake

With Kotlin Multiplatform you’re not limited to Android & iOS only, you can share code between multiple different platforms like backend, web, windows, linux, mac

What if I’m not starting from scratch?

Then you have probably two scenarios:

1. You’ve chosen cross-platform earlier and you’re unsatisfied with the quality. By switching you’ll definitely increase your short-term costs, because you either have to train your team or get a new team and you definitely need to rewrite your whole app.
2. You’ve chosen native, but you find out that costs are too high for you this way. You take a deep breath, choose to focus on the Android, then you either train your team or hire somebody to migrate the available code to a KMP setup, then finish up the remaining 20–30–40% of the UI or other platform specifics on the iOS.

You need something with enough track record

Makes sense, you want something that’s proven and is not that risky.
First I’d check out the available case-studies and if you’re still not 100% convinced, then I’d consider the following tactic:

Focus on the Android, try to make it in a KMP setup. Worst case scenario (with low probability) you’ll end up with a native Android app and you have to do an iOS app from 0.
On the upside, if you’re successful with the KMP (for which the probabilities are far greater) you can save a lot.

Now I’ve simplified and generalised some parts of my thinking process, because it’s insanely hard to cover all the specifics of a project.
If you have some doubts or feel that some of the things don’t apply on your project I’m always open to have a discussion regarding these topics, just drop a comment or feel free to get in contact with me (LinkedIn, nagyrobi144@gmail.com)