Hacker News Reader

Comment by frabcus | Hacker News Reader

Hmmm, the article doesn't really say what is better about the Swift/Kotlin apps, compared to React Native. All we get is:

"Native keeps us closer to platform capabilities and first-party tooling, with fewer framework and dependency layers between our code and the platform"

What's the user benefit of that? It's not speed, they say "React Native apps can be fast. Ours are."

I'd expect it to be considerably easier for a few people to use the AI to improve React Native with whatever matters, than for every company in the world to permanently maintain two apps.

And those improvements to React Native, would make all mobile apps easier for everyone to build forever more.

Are LLMs going to stop everyone collaborating, making libraries and platforms, and shared language and abstractions, because we can all vibe code our own thing? This seems a loss to cost and quality, even with lots of tokens available.

View on HN

I agree with you. I don't think LLMs magically solve the problem that comes with writing twice.

Even if they were to write for two platforms, they'd likely want to have a whole bunch of business & state management logic that would be shared between the two with the native part being a thin platform layer.

It seems like a mostly shared codebase (reglardless of specific tech choice) would let them get precisely the end user UX they care about. Both for performance and capability.

Not saying they should use React Native but maintaining two large apps and using LLMs to keep them in sync seems far worse than many other options.

Besides API features, it won't require downloading 0.5 GB of web browser in order to run.

Sure, you can make it smaller, but how many companies actually do this?

Sure, you can make it faster, but how many companies actually do this? Accountants and product managers don't care about speed or size -- that's a user problem.

Judging by the app sizes I download (and try to avoid), few companies really care about the user experience as long as the basic feature is checked off.

I worked at a company that provided an unnecessary and heavy FE framework (original devs didn't know what they were doing and "just got it out there"). Most of the target audience used used older PCs, and thus slower and memory limited. Some pages required multiple GB of browser memory. We've had this problem for decades because devs usually have well spec'd computers.

React native does not render in a browser.

I'm on your side regarding this sentiment.

I happen to work on a product that is built for accountants. You would not believe how slow these apps are and all they do is display forms!

I believe customers do care about performance even in these B2B industries.

But it feels like they sink into some form of learned helplessness. We were interviewing our customers to learn how to build a better PDF viewer for them. Their biggest complaint had about Adobe Acrobat? Too slow!

I'd imagine the user benefit is they can tap new operating system APIs and features almost immediately versus having to wait for a React Native package or having to build a React Native bridge. I think everyone would agree that native apps are better in every way, but the thing is, as a small company, you can't justify hiring two different developers - hence why RN is usually a good choice to get off the ground with.

Right, but they could get their AIs to quickly add new features to React Native! It makes no sense.

even in AI terms, the tradeoff is interesting. going native removes the party in the middle, which would be react native here. Sure you can extend core components, but that is notoriously more convoluted than just implementing the feature straight up within the native ecosystem, since it is usually accompanied by official documentation and examples which you can point your LLM towards. Sure you can tweak around things enough with workarounds and hacks (until react native properly supports thing xyz), but at this point the question is why bother with that in the first place. Also keep in mind, you'd have to maintain this own implementation on top of the already existing codebase

Reply on news.ycombinator.com