Hacker News Reader

Comment by null_object | Hacker News Reader

Where I'm working we're porting the native apps gradually to SwiftUI on iOS and on Android using Kotlin Compose - addressing a lot of the development speed issues mentioned in the article, and shifting to a 'reactive' model while retaining truly native performance and components.

Developing in SwiftUI is lightning-fast - there are a few bumps and bugs that have been extensively discussed, but it's really simple to still use UIKit components in the places that need them (which are becoming fewer all the time).

For me the tone of the article is very 'positive' but the amount of time and effort seem horrendous. And now they're stuck with React. Not sure how many times these articles need to be written and then... [0]

[0] https://www.twopicode.com/articles/this-is-why-we-stopped-us...

View on HN

I think you made the right call here. SwiftUI had a slow start but now closing the gap on UIKit. ReactNative is a dead end.

As a former iOS UIKit dev I actually prefer react native to SwiftUI. If we have to do this declaratively (and I have to re-learn how to do complex layouts) lets also make it platform independent and reusable with Web.

It feels like SwiftUI is being pushed down my throat and I have a strong aversion towards things like that.

Has sharing between the web and RN worked out for you? It seems like it hasn’t for many, or any high profile apps.

Even mobile web and non-web mobile are quite different platforms, even at the UI layer. There are many different expectations, platform norms, and interaction differences that don’t work well in browsers or across platforms. I’d love to seen an example of it working well but I haven’t yet.

Honestly I havent tried much sharing with web but I can at least vouch for sharing between iOS and Android which seems to work mostly. In a few years time I think it will become much more easy and bulletproof than it is now. Making two different apps in SwiftUI and Jetpack Compose seems overkill already.

I remember component sharing being a topic on day 1 with react native. I also remember it coming up a lot about 5 years ago when MS launched a component library that theoretically did this (didn’t seem to take off). I’m skeptical of the approach given that so much time has passed, with so much incentive, and it still hasn’t happened.

Building both SwiftUI and Jetpack Compose apps is definitely a ton of work, but I think the right choice at scale. Before “scale” is “achieved”, I’d advocate for doing one platform well (there’s often an obviously more important one) and packaging the web PWA for the other platform.

True at scale it makes perfect sense to do that. Its just not a very lean (2 different codebases for 2 platforms) and maintainable solution (apple and google keep changing how they do things and kick out apps that dont follow suit)

As a RN developer for over half a decade - I just came to the same conclusion after doing a 1 hour SwiftUI course. Won't be touching RN ever again.

This is the same roadmap of our mobile app too. Migrating to SwiftUI and Jetpack Compose.

The article is very cringe and I’m pretty sure not all the Shopify mobile devs are all in with the RN migration.

Reply on news.ycombinator.com