loading...

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

twitter logo github logo ・1 min read

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?

twitter logo DISCUSS (4)
markdown guide
 

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.

 
 

We must also note that the cross platform solutions will never prevail over Native solutions. And I'm not talking about apps that have some CRUDs to do in specific servers but apps that have to do with Camera, Audio Support and other hardware support stuff (and for some platforms even maps).
However, if I client can't wait and the logic behind an app is not hard and complicated (even in architecture), the cross-platform solution server pretty well.

 

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:
Cross-platform is not an excuse to ignore the platform

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.

Classic DEV Post from Aug 22 '18

Notes on ECMAScript 6 (ES6)

Introduction This is not meant to replace the official documentation...

Justin Mancinelli profile image
Justin helps dev and product teams navigate the waters of mobile app development and is an expert at integrating them into larger technical, customer, and business ecosystems.

Sore eyes?

dev.to now has dark mode.

Go to the "misc" section of your settings and select night theme ❀️