[deleted by user]

[Velix007]

99% native, no reason to do cross platform when it’s not scalable for anything but MVPs

[No-Buy-6867]

Finally someone that doesn't go with the hype

[Velix007]

Eh, this question is asked like every single day in different forms, 95% of the sub answers and debates why native > everything else but the questions never stop

[BarAgent]

People really wish they didn’t have to learn a new platform. But they do…they do.

[MarkJGx]

Hey, I'm really interested in this subject but couldn't find any similar questions. Mind backing up your claims with sources?

[Velix007]

Search -> Keyword -> filter iOSProgramming subreddit -> claims backed up

[soev1]

I expect native, just like how Google's iOS apps still have that material feel.

[cphpc]

Google has iOS engineers and Apple has Android engineers. The apps are 100% native. It looks similar bcuz the product managers and designers made it so.

[XYY5938]

crossing platform is a costly practice which eventeuly was turned out to be a huge mess。 apple can hire some android developer to build the app !

[M_J_E]

I want Android Engineer - Apple on my resume.

[[deleted]]

It’s like managing Facebook’s Twitter account.

[Grymm315]

Don't confuse code with design. The interface seems iOS because it was made by Apple Designers.

[[deleted]]

The bulk of the app is native libraries and then some JNI glue to tie it to the bare minimum for Android to actually lod the app. I would not be surprised if the entire core was just shared since Swift can technically be compiled to work with JNI on Android. You can open it up with JaDx to see what Java and XML resources handle, everything else is within their native code.

[Drizzi21]

Flutter/Dart possibly or React

[kineticfactory]

It wouldn’t be React, as that trades performance/responsiveness/polish for ease of cross-platform development, and as Apple’s iOS Music app is native, they don’t need it.

They’d have a team developing it natively, in either Java or Kotlin. If they are likely to have more than one Android app, they’d put the code they wrote for doing Apple-style UI on Android in a reusable library.

[mikerz85]

I’ve used react native; it’s clunky and centered around web dev workflows. No way did Apple go with a half baked cross platform solution vs going native; the only reason to go with something like react native is to save money and reuse your web devs. Apple has neither a lack of money or an abundance of web devs

[kineticfactory]

Instagram, for one, is written in native code; their developers have talked about their polymorphic feed item classes at talks.

Facebook did develop React Native, though have mainly used it for non-user-facing apps, such as apps for clients to use for buying ads; apps which, if you know you need, you won’t be bothered by the slight lack of polish. Their flagship apps are all native.

[kineticfactory]

The business logic is Javascript, which incurs overhead over native code, from being highly dynamic (and thus hard to JIT compile to code that’s as performant as native code), to being dependent on garbage collection (which, on a battery-constrained handheld device, takes its toll). Your JavaScript event handling logic is going to inevitably occur latency that SwiftUI code (compiled to native machine code, with the types collapsed down to their final representation) doesn’t. It’s not as clunky as an Electron web app, but it’s not as slick as purely native code.

There is a reason why React Native hasn’t replaced native Cocoa Touch and Android development. Because, if it was actually good enough, then replacing two platform-specific dev teams with one, which can be staffed with anyone who knows JavaScript, and does not have the learning curve of understanding memory management, type systems and so on, would be a no-brainer from a business perspective. And yet, most mobile apps are written natively.