Hacker News Reader

Comment by mexicocitinluez | Hacker News Reader

There's been some discussion around Shopify (and others) move from React Native to purely native and that leading some people to conclude that LLMs have effectively killed RN. Which has always seemed silly to me for 2 reasons: First, Shopify almost certainly has on staff (or access to) actual native devs to steer that ship that a small/medium-sized company may not have. But more importantly, it's not the "Translate this RN app into native" that's the trouble. It's the hundreds and thousands of additional iterations you'll have to do on top to maintain and build out that product.

It's hard keeping separate code bases with separate languages in tandem, and while LLMs definitely aid in that area, I can't imagine it's a free lunch.

View on HN

We moved one of our apps away from RN to SwiftUI and Android (Jetpack Compose). The binaries are way smaller, and the apps work beautifully.

So I don't see any reason to stick to RN, when we can just use any OS native APIs to our heart's content and our apps automatically feel more native.

> So I don't see any reason to stick to RN

For the exact same reasons you chose in it the first place: experience with React to build a single codebase for different platforms.

If AI allows you to build your native apps and keep 2 different, growing code bases in parity without needing native dev experience, then use AI. But my point of the original comment is that those decisions are different at smaller companies than Shopify. There is no free lunch.

You're still stuck in this loop of humans reviewing and maintaining code. It's over. They will go native and abstractions like RN will die.

This is it. Most people (including myself occasionally) are having trouble letting go of the old world. It's not about writing code that's easy for you, the engineer, to maintain anymore. Our context window is small. Things need to be easy to read and well organized for us to work with. LLMs will write the code in a way that's efficient for them. If it's easy for an agent to jump in and make a change without doing a ton of investigation first, it's maintainable code.

Abstractions are for humans.

> Abstractions are for humans.

I disagree with this. The mistake rate goes up rapidly as context grows. Current frontier models get noticeably more stupid at context sizes of only 100k tokens or so, and inference becomes slower as the context grows, leading to more rework and more token usage.

I foresee a trend of having _smaller_ code units, more modularity, more abstraction, because agent work on smaller units leads to smaller contexts and a better chance of the agent getting the change right first time. Or a higher likelihood of a lower skill, lower cost model getting the change right.

I agree completely. That doesn't require abstractions though. All that can be done with native code. In fact, the abstractions often grow the context window if you need to debug any mildly complex issue.

> Current frontier models get noticeably more stupid at context sizes of only 100k tokens or so

It may be domain/task/prompting dependent etc, but my experience is different. I haven't subjectively felt any degradation up to like 500-600k tokens with current Opus/Fable models. After which I usually do a manual hand-off to a fresh session anyway. I don't use context compaction though.

[delayed]

That's called reality, anyone that throws their product to LLMs to design, code and review will end up with a pile of slop garbage pretty quickly

They also seem to be ignoring the realities of modern app store reviews. Apple and Google are only getting slower as vibe-coded apps flood their marketplaces with submissions. Maybe Shopify has a special relationship that gets them faster reviews, I don't know. But if not, the ability to put out updates, rollbacks, and hotfixes without being gatekept is a critical feature. Especially with today's security landscape. React Native now seems more compelling than ever before.

From what I heard, updates for many established developers, even individuals, go through within a few hours.

I'd also love the ability to take back control over my rollouts, but with Apple's recent crackdown on remote controlled feature flags in response to fraudulent nudification apps, I'd be very careful about this.

Rumors say Apple now uses heuristics to detect feature flags in the binary. While that's not directly relevant to remotely delivered JS, I fear that bypassing App Review in this way could become a quick ticket to account termination.

It’s probably only a year or two out that Apple will inform us that “for security reasons,” they’ll only accept App Store submissions in the form of an XCode project, i.e. as source only. (What are developers going to do? NOT be on the iPhone?)

I'd have original Slopus 5 rename my variables and replace all comments with inline 'docs' for my existing 500k LOC code base.

Good luck with parsing that one, Apple.

I'm joking, but in seriousness, I'm not sure they would gain much from that which they couldn't already analyze from the binary.

Yeah, I have an app with ~150 users, and Play Store updates slowed down to about a week for a moment, but lately they have been going out within the hour.

I've heard those reports, but it's absolutely insane. Having feature flags is table stakes on mobile. And being able to put out security or bugfix updates rapidly is the killer feature of React Native. The current ToS say you need store review for feature changes, and that's fine. But OTA updates and feature flag changes for bugfixes, phased rollouts, A/B testing, and security patches are critical.

Just last week we saw a critical CVE in BetterAuth integrations for mobile app sessions. Being able to put out a patch without being gatekept on review is just so important in a world where crazy security vulnerabilities are being disclosed daily.

What makes you think you can circumvent the App Store to update React Native apps?

How is RN speeding up your app store review time?

You can set up your app to do over-the-air updates. This can be as simple as shipping an updated JS bundle or delivering just patch diffs for it to apply. So long as your code changes are JS-only and don't involve any native code, you can push an update.

People are already used to being able to do things like phased rollouts, automatic rollbacks, and hotfix deployments for webapps and API services. OTA updates let you do something similar for mobile.

It's against the ToS from the stores to do this for notable feature changes that impact what the user sees, but for things like fixing crashes, bugs, or applying security updates, it's a game-changer.

Reply on news.ycombinator.com