In the age of LLMs, I get why you would dump portablity in favour of close-to-the-metal Swift and Javascript codebases. However I don't really understand the need for Kotlin- surely thats just an unnecessary complication and performance hit?
Kotlin compiles to the same JVM bytecode that Java itself does. There is no performance hit. And from a developer's perspective, no it is not a "complication", Kotlin is a much more pleasant and efficient language to program in than Java (in my opinion, and that of many others).
I'll put it this way, my argument was pro native. And in the context of the article, if a large company had unlimited resources, they would choose native. I'm not discussing the business case for it, but the end result of it being the better option. It can be seen as "Shopify tried Reactive Native and left it behind the second they could after sinking resources into it for 6 years".
Everyone always knew native was better if dev cost weren't a factor
Go back in time and read the react-native vs native debates. Many react advocates claimed otherwise
You just install it on your phone and use the app. Maintainability concerns are entirely overblown by people who don't use agentic AI to develop large mobile apps, but anyway give their opinion as if they had that experience. I put in a few hundred hours, and I reached the same conclusion as Shopify. With reviews from other models and then a manual QA pass the result is fully usable.
I work as a professional app developer. And I find this take to be naive. Most of the time when I review code from AI, there is always something to improve. It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed…
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.
Numbers from GPT Astra - Shopify has 3000 engineers as of 2026 - Google Chrome when released in 2008 conservatively had ~ 60 engineers. - GTA 5 in its credits had 150 software engineers. Surprising even to me who has had many an experience of being in a bloated FAANG team, this 150 includes GTA Online! In a sane society, Shopify’s opinion on anything engineering related would be thrown into rubbish because they seem…
Add to it that they need a compiler team for a Ruby JIT, due to the language choice to run an heavy load server infrastructure.
And now we learn they use Swift and Kotlin to replace React with. So they are not replacing it with Ruby. I think they've hit the limits on Ruby (like twitter had on Scala).
P.s.: I find Kotlin "an acceptable typed-Ruby" with an industrial strength VM (the JVM) and two compiles to native stories (KMP and GraalVM-native).
You just install it on your phone and use the app. Maintainability concerns are entirely overblown by people who don't use agentic AI to develop large mobile apps, but anyway give their opinion as if they had that experience. I put in a few hundred hours, and I reached the same conclusion as Shopify. With reviews from other models and then a manual QA pass the result is fully usable.
I am using Gemini as well as Opus on a somewhat small project in React Native and I can not imagine this thing being able to build the whole thing on its own without it being a dumbpster fire. Can you share some details of how you work? What models? What harness?
We use CC with Fable(Opus before that) continuously on a rather large project, everything is tested, we maintain high verified test coverage, we ship features x10 faster than when we started(pre Claude-everything era 2-3 years ago). I never worked with RN before and I ship features now. LLMs allowed us to find issues within RN itself, that thanks to some patches, improved lower end Android experience by a lot. We just use all the Claude defaults with claude.md that evolved over last year.
> Not sure why someone would say it was a wrong decision. Writing almost anything with javascript sucks ass to begin with. Writing native code with it is even more painful. Most javascript engines don't even have any decent model of parallelism. It takes zero imagination to see the problem here
how much parallelism are you writing in your frontends?
The problem with everything being single threaded isn't so much that you want to do a lot of parallel processing, but that you don't want to have the occasional fat loop cause the whole engine to start stuttering. If you want butter smooth scrolling while there's (for example) a lot of dynamic content moving around, you want very precise control of the threading so you can get the gnarly stuff done without causing hitches that don't feel right.
Spotify has progressively gotten much worse over the last 15 years, all while the size of their engineering team has ballooned. I am very unsurprised by this outcome. People wonder why good software becomes bad, and it’s because the people who were good at engineering are often outmaneuvered by corporate-politics savvy people in a growing company. One of the best political moves in a company is to have a lot of peopl…
>Spotify has progressively gotten much worse over the last 15 years, all while the size of their engineering team has ballooned. Spotify or Shopify?