Why did you (or not) choose cross-platform mobile technology?

Egor Tolstoy

@igrekde

@jetbrains In the last couple of months we’ve interviewed dozens of mobile developers. We wanted to understand why they choose (or don’t) to use some cross-platform technology, what are their goals, intentions and pains. And that influenced a lot how we see Mobile Multiplatform today.

13:59 PM - 05 Dec 2019

This is an important discussion, not just for the people making the technology, but the people evaluating them too. Business context matters; team membership, recruiting and retention matter; technology, language, architecture, matters; and the community matters too. What else? And what matters to you?

Comments

[K]

I choose React-Native, a cross-platform technology, because of multiple reasons.

My customers want to save money when porting apps from one platform to another.

I only read bad things about cross-platform technologies like Xamarin and Cordova/PhoneGap.

I know JavaScript in and out, so I'd prefer not to work with Java, Kotlin, Objective-C or Swift.

I already used React for two years, when a customer asked if I could build them a native app, so React-Native was the natural next step for me.

I read that the React-Native approach brings good UI performance, because it uses native UI widgets.

I think, I would use a different technology for complex apps with custom UI interactions etc.

React-Native UIs can look very much the same on different platforms and many component libraries try to get rid of all the platform idiosyncrasies, but when the UI gets really custom (think "expert systems" like Ableton Live, Fruity Loops, Photoshop, Illustrator, etc.) it's better to render your own components that are the same on all platforms.

For such custom UIs I'd use something like Revery or Flutter.

[Justin Mancinelli]

Fantastic explanation, thank you.

[Justin Mancinelli]

cross platform solutions will never prevail over Native solutions

For UI: I agree. For logic: C, Python, Ruby, Java, etc prevail over asm...until you get into very specific performance or system architecture issues (e.g. the linux kernel is cross platform, but there is also some asm for some things)

As @kpgalligan likes to say "Shared UI is a history of pain and failure. Shared logic is the history of computers."

Kotlin Multiplatform took the shared logic approach.

• It is first-class on Android so you already have that platform covered.
• It compiles to a standard ObjectiveC framework on iOS so it's like any other external native iOS library (Swift support in the works).
• It transpiles to JS (kinda like TypeScript) for use on the web so it fits in with "native" web development too
• And besides all the other compilation targets, JetBrains just announced much improved Wasm support for anyone who's interested in Wasm as the next important layer of a cross-platform stack.

apps that have to do with Camera, Audio Support and other hardware support stuff

Definitely, and that's something learned by Kotlin Multiplatform. "Unlike other "cross platform" ecosystems, Kotlin is designed to embrace the native platform it is integrating with."

From UI to hardware, no matter the solution, I totally agree with Ellen Shapiro:

if I client can't wait

Totally agree in this case. If the client can't wait and your core skills are JavaScript or .NET or Dart then it will be faster to make a Cordova, or React Native, or Xamarin Forms, or Flutter app than learn Kotlin and swift and the rest of the native ecosystems. It will then be up to the client to continue with those technologies or to port to a fully native app (and I have seen first hand when clients wait too long before porting to native)

There are increasingly more native mobile developers (those who develop for both iOS and Android). I have worked with a few, met many at conferences, and seen many on Twitter. It will be faster for them to develop fully native apps than learn (and deal with the issues of) a new tool. And, when they learn to architect for common Kotlin code, they'll be even faster.