Models have gotten a lot better at generating native iOS apps. The main appeal of RN was being able to leverage your web devs for mobile dev. that's what I did at my last company. And it's fine for a startup, but eventually you want dedicated native engineers bc each platform really deserves its own technical masters who can optimize for it.
But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway.
Nobody is talking about the real advantage of RN: Being able to release to the App Store without having to go through a review. That's so massive. Getting a bug fix out to users instantly, sneaking in optimizations, etc..
Sure, you need a review to release native code changes, and you should probably get a review if you have big feature changes just for the sake of Apple not banning you. But in practice, it removes one of the biggest annoyances of developing for the App Store.
Over the air updates is SO valuable with react-native. Being able to ship hotfixes instantly to our users has saved our asses multiple times.
I’ve worked with both native and cross-platform. I think the mentality of being able to make changes quickly without much review often comes from cross-platform, especially when the developers come from a web background.
Changes are cheap and fast, so teams often feel less pressure to test everything thoroughly before a release. Which is a fair tradeoff. That’s part of the reason we can have dozens of releases a day on the web. Not just because we can, but because sometimes we have to.
With native, you know each release is harder to roll back, so you tend to build more tooling around releases, think through changes more carefully, and test more thoroughly before they’re ready to ship. You opt for one bigger, more stable release every few weeks instead.
At the end of the day, both approaches work.
Heh, now that I think about it, maybe web and cross-platform devs were the original vibe coders? Changes are cheap and fast. Just move fast and break stuff.
Native devs are the old-school ones. Shipping is expensive, so you better get it as right as possible.
> "Native devs are the old-school ones. Shipping is expensive, so you better get it as right as possible."
Exactly this. After close to two decades building for the platform, the mindset is really to be cautious and make sure everything is rock solid before shipping.
This has more to do with building up a quality tool chain and testing process than being slow.
But sometimes there is a need to ship over the air updates, and for that (on Kotlin) there is Zipline [0] from Cashapp. I haven't used it in anger yet, but I know some people who do and trust it.
[0]: https://github.com/cashapp/zipline
Totally depends on your business model too. We have clients that often require quick changes for compliance reasons, and they need to ensure all users of our apps are congruently updated. That’s not easy without OTA.
This is so true, and I'm surprised that Shopify didn't mention it or that they don't use OTA updates.
Are you saying a native app can't make an http request and update the code they JIT?
It can download Javascript (or other interpreted language, or config data), but you generally can't download and execute new compiled native code on iOS, due to iOS code-signing/executable-memory restrictions.
Also keep in mind Apple might penalize you for dodging the review process and shipping new features, etc.
(btw, one exception to the JIT rule is custom browsers for the EU)
Pardon my ignorance but can't an iOS app host a WASM runtime without being a browser? And if so it doesn't need to be an interpreted language necessarily.
I am fairly certain this is against Apple's policies. In principle you're not supposed to change the functionality of your app without review.
i don't see any difference between wasm and js? If react native apps can be updated with js, wasm should be allowed.
I think updating js without review is also against policy.
It's a grey area.
App Review Guidelines §2.5.2 says: "Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps"
Technically Apple can punish you for anything but so far it seems to be accepted for small fixes and tweaks.
Doesn't seem like a grey area at all, pretty clear it is against the policy. Just a ridiculous policy and hard to enforce.
Yes, it could, but then you would have re-invented React Native. But in WASM.
Yeah, but to my understanding that’s not what Shopify is doing.
Precisely. That has always been prohibited both by technical measures and by the App Store review guidelines. Especially on Apple, but also on Google Play / Android as well.
Doing so would require the app to have the business logic written in JavaScript. Apple only allows JIT’ing JavaScript using JSC.
This seems to be a weaker claim than "RN is needed to do this", but practically speaking it might amount to that.
Sure you can choose not to adopt React’s reactive paradigm and manage state directly but using JavaScript. My understanding was that in RN, JavaScript code manipulates C++ objects in the C++ part of RN, which then calls host platform code to create views and render.
This is true in a very real sense – models can help you build native apps very quickly, no question. But how do you keep them from drifting apart from one another as you add/change features or design? Right now, there isn't much tooling for this.
React Native's advantage of having a single source of truth for code hasn't quite gone away yet, imo.
You create a source of truth which defines all the features and requirements. This can be UI tests, MD files, database, diagrams, whatever that fits your use case.
I've only read about it from it showing up on hn[1][2], but you can use slick to convert your swiftui to jetpack compose for a andriod build from the ios source of truth
link to project: https://github.com/skiptools/skip
[1] https://news.ycombinator.com/item?id=41384144 [2] https://news.ycombinator.com/item?id=46706906
i think you would have your coding agent work on both code bases at the same time. You could also task with generating identical tests for each platform. It's easier for a model to keep up with that kind of tedium than a human. Plus you can just tell the model to keep re-doing things until you're happy and it won't quit.
Also, having agents trace and document every logic path to compare with another codebase works well in my experience. It can certainly do that better than me, i would give up and start taking shortcuts pretty early in a process like that.
I don't understand the question. If the model built both apps why wouldn't it also be building the new features on both platforms at the same time?
Alternatively, point the model at your git repo for platform A, read the diffs since release X and implement the same changes on platform B?
the problem is that single-source advantage gradually falls away as you develop your software into something that feels good to use on each platform. and once you have a quality product you're left with perfunctory coupling that makes it harder to adopt the latest platform features
Android and iphone emulator MCP, model compares screens, flags is theres drift? Something like that I’d guess
But the screens should look different, right? That's the point of building separate iOS vs. Android versions is to make each version "native" to its platform. The feature-set should be the same, but the interfaces can diverge.
I think the whole native thing is more for better performance, debugging ease and dependency reduction rather than seeking variation in UIs.
It is both. You want the application to look correct on the platform the user is on, i.e. Liquid Glass on iOS and Material on Android.
Tests? Not being flippant, but that strikes me as the new surface to maintain to get what RN used to offer
"GPT-8 Galaxia - figure out where our iOS and Android apps show different doohickeys and fix them"
> You're completely right to call me out on this. Here's the real smoking gun: the iDoohickey isn't a real API interface on iPhone
You always still needed a specialist per-platform even if most of the code was RN or KMM[0]. But I agree - a thousand not-great mobile apps sprang from this idea.
[0] I always thought the best answer was something like KMM to do all the backend comms and local data model in a shared way, and then a bespoke UI building on what that shared code exposed.
> a thousand not-great mobile apps sprang from this idea.
Hi. That’s me… not-great mobile app maker. And yes, I’m grateful that RN exists.
Mostly what it does is make sure that an Android version of things exist at all.
Hello! As I'm on Android, thank you for your service.
I think there are many reasons why React Native would be unappealing, my experience with it wasn't that positive.
I don't see a reason to use it over web stacks plus CapacitorJS (Or Tauri) or directly native for very large teams.
> The main appeal of RN was being able to leverage your web devs for mobile dev.
There's nothing remarkable about the skill set of either party; the appeal here is re-use of code. how the labor markets itself is irrelevant
> The main appeal of RN was being able to leverage your web devs for mobile dev.
> But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway.
Are you saying:
- webdevs are now able to write and review native code because of AI (who cares if they don't really understand it); or,
- Because developers are more productive we can cut the number of webdevs and hire native engineers – same no. engineers, same output, but now native apps.
Why not:
Continue using RN but now and just enjoy being more productive? If productivity was the reason to pick RN, then enjoy it. It's not a bug.