HN Explorer

Ask HN: Native App Development Stack

9 points by edimoldovan ↗ HN
Both Google and Apple have been making strides in their composable UI framework development -- JetPack Compose and SwiftUI, with Apple seemingly rewriting already part of their apps in SwiftUI.

Also, the overall frameworks available on both platform are evolving well in the direction of Swift and Kotlin, with some being available only there.

The question I would like to get the feedback of the community in is this: given the start of the implementation of a native app right now, would you comfortably go for the SwiftUI/Swift and Jetpack Compose/Kotlin or you would look at other options like React Native or Flutter with the customer experience and developer experience as the two main KPIs to deliver on. Would also be curious on why you would choose what you would choose.

8 comments

[ 3.4 ms ] story [ 34.2 ms ] thread
surfskatr
SwiftUI/Swift and Jetpack Compose/Kotlin for us - despite using react for other stuff, we find these native languages to be very nice to use and productive. Also, if you’re targeting a featured by Apple badge using their native technology is a huge plus vs react native.
jamil7
This is hard to answer without knowing what kind of business you're building. A rough rule of thumb which I've said before is, if your business is highly or entirely dependant on mobile (often B2C apps) then go native and build for whichever platform is dominant in your region/industry first. The reason is to remove a dependency between your dev team and the target platform. The project I'm on right now went with SwiftUI/Jetpack Compose, I would use SwiftUI only if you can target the latest OS and stay far away from it on macOS. I haven't used it for a while but I've heard React Native has also gotten a lot better lately.
edimoldovan
Can you elaborate on the "The reason is to remove a dependency between your dev team and the target platform."? I think I might not understand your point here.
jamil7
If you're heavily or entirely dependent on mobile, then you don't want to be waiting for the React Native/Flutter team to fix critical issues or introduce functionality. You want to remove as many dependencies/parties between your product and your customers.
K0nserv
You have to introduce ordering in your KPIs. If developer experience is more important, then you can get better results with cross platform. If user experience is more important, then you are virtually guaranteed to get better results with native. Personally I’m of the opinion that user experience should never be subordinate to developer experience, so at least for me the choice is clear: native.

Also consider whether you will benefit from a broad install base, i.e. when building a social app, or if you can go for one platform first. Lastly, I’d consider the stage your in, i.e, are you trying to find product market fit or not.

If native stills feels like a lot of extra work, I’d suggest building a common core, in e.g. Rust, to share non-UI code between the platforms.

edimoldovan
Really good points.

I think the order in my case will definitely be customer experience first. And for the the rest of the points, we are looking at something similar already, limited user access initially, only one platform perhaps.

On your last point, reusing code among platforms, I was looking into Rust, it seems there isn't yet a good way to share Rust code. I have found https://kotlinlang.org/lp/mobile/ which looks interesting.

K0nserv
Yeah, Kotlin multiplatform is the most promising cross platform solution because it explicit leaves the UI fully native. With Rust you'd leverage C based FFI(with a layer to communicate with Swift and Kotlin), it's not the most streamlined experience. One big benefit of building a Rust core with C FFI is that it can be used virtually everywhere.