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.
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.
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.
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)
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.
React Native's advantage of having a single source of truth for code hasn't quite gone away yet, imo.
link to project: https://github.com/skiptools/skip
[1] https://news.ycombinator.com/item?id=41384144 [2] https://news.ycombinator.com/item?id=46706906
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.
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?
[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.
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.
I don't see a reason to use it over web stacks plus CapacitorJS (Or Tauri) or directly native for very large teams.
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
> 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.