Shopify is moving from React Native back to Swift and Kotlin (shopify.engineering)

>Spotify has progressively gotten much worse over the last 15 years, all while the size of their engineering team has ballooned.

Spotify or Shopify?

The mythical man-month ;)

> One of the best political moves in a company is to have a lot of people under you.

This is why I’m sceptical of “AI will kill corporate jobs”. A big company has no profit sharing for successful departments. Everyone is trying to get budget to hire because it makes them feel important.

Any book recommendations, that is not satire, about navigating the political landscape?

Spotify had a good app when it came out, p2p and UDP custom networking...

When it comes to number of engineers, always keep in mind that it costs more engineers to maintain (and understand) software than the initial development push.

I have the impression that for hiring this is fundamentally the most important aspect: Finding a prospect that is just skilled enough for the position without being a risk to the person who is hiring them.

Sometimes I wonder what the tech ecosystem would look like without the ZIRP era.

I look back over 15 years and with the exception of increased smart phone usage, everything else still looks mostly familiar. Maybe a bit more slick, but also slower and buggier despite having much better hardware.

There hasn't been a qualitative leap in software (as was in the 90s). Just larger SaaS companies. Without ZIRP would it have been any different?

15 years of extremely well paid engineers and yet we still cannot delete a track from Recently Listened. ಠ _ ಠ

Shopify works well for me but it used to push nonsense like podcasts or audio books that I had no interest in, with no way for me to hide them. I just want to listen to music.

Upon looking just now, seems like they have been relegated to their own tabs now, which is great.

I remember hearing in an old podcast (Dad & Sons), one of the guys there worked at Rockstar in QA in 2012 and he's still listed in the credits for Red Dead Redemption 2 (2018), so the policies are unclear to say the least.

What's an "actual software product" and why don't you think web products count as them?

I'm a full stack web developer. I've worked for startups and F500 companies. There is always a push for release targets. The less technical the leadership, the stricter the release targets (its hard to sell a critical refactoring to management when they cant sell a shiny new feature or kpi to their own boss). We've kept our teams pretty lean too.

We still aim for high quality, and performance and security.

I do agree that many people dont really know what theyre doing and are kinda just winging it, especially with AI at the helm, and many companies are likely overstaffed, but I dont think theres a correlation between headcount and slow/bloated software. Any team of any size can make slow and bloated software.

That’s what they said about Elon firing 80% of Twitter’s staff. But X is doing pretty well.

most people don’t. that’s why they are employees.

i will bet 175 billion dollars people like that guy are bikeshedding types

How is life at Google nowadays?

Oh you said 500, not 5000, my bad.

That’s different difficulties.

Like comparing a climb and along run. Sure both require some physical abilities, but in the first case any error and the collapse mean dead end bringing progress to zero, while the second one you can rest on the side any time and still have the miles behind you accomplished.

I wonder how many of the 100k+ enginners at Google work on that "simple" text box that shows you relevant websites to the input text.

It’s not that much about scalling software, as scalling software on highly concentered nodes. Distribution downstream can be its own hell, admittedly, but otherwise having fully independent copy of software copies that run in local terminal is a no-brainer if all that matter is running software at scale.

I am quite curious about what people hat so much about Spotify. I made some excursions the last few years to competitors like Tidal and Apple Music but I just found myself coming back because the Spotify mobile app experience (and desktop) was just plain better.

I wonder what gripes people have.

And it was a fork.

Rubbish. Most of the stuff you’re listing is handled by OS and frameworks themselves, you don’t need hundreds of SE to handle RTL or a11y. I work in one of those companies, most people just regurgitate existing shit into another form of shit and collect salary (not complaining, as I’m one of them, but let’s be honest).

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).

It ported overnight. I don't think it would create from scratch without a lot of hand holding.

This is a type of project that likely wouldn't have been done before AI

This is an incredibly boring task. Nothing new, just rewrite everything to just see it all rewritten again in 1 year. Perfect for LLMs and something humans shouldn't do.

While I mostly agree with you, this is the kind of thing that might not have been done if the AI couldn't do the heavy lifting.

They had previously chosen React Native because it was easier for programmers to keep it updated, since it was really just 1 codebase. With AI, those same programmers can do the more difficult version, keeping the native apps updated separately.

So did it kill a job, or did it make it possible for the existing programmers to do it better?

It's the kind of thing that is really hard to determine in general, but here, it really does sound like they only made the change because it became possible with existing resources. They would not have done it otherwise.

The optimistic outlook:

Just like this has made Web devs into Mobile devs, so could Mobile devs leverage AI to work in Web shops.

I'm not an optimist but there could be an increase of available apps being created which would still keep people employed. Theoretically the cost of creating an iOS app for a company without an engineering team dropped from several hundreds of thousand to a few thousand or hundreds, which could be paid out to a freelancer with AI. More people would go into freelancing for industries which were not contemplated before due to cost.

But I'm not an optimist.

This app has 15/20 screens, an app this small wouldn't employ many people to begin with. Before there was one guy (op) maintaining it in react native and now he maintains it native. I don't see much change tbh.

Same conclusion here. My current preferred setup is native for iOS and Android with common core in rust exposed through uniffi

The value of most companies/apps are in the relationship with the customers, so it's the database, not the code.

As other have mentioned, the code isn't the valuable part. But also there are alternatives now to these LLM providers.

Are you saying you don’t trust ZDR claims from inference providers?

They don’t care about your code. There’s more and better data on the public web.

> there's no proprietary IP in your company's app

For most app that concept is "gone".

People routinely decompile and recompose existing binaries, and if you use "obfuscation" in your app it's still a small bump.

In today's age, IP is no longer a tangible concept that gives any advantages in software. What differentiates two businesses isn't their IP, it's their relationships and their moat.

Most vendors that had protected proprietary IP are now irrelevant within their vertical. What saves them are the protection provided by patents, which is public.

Frankly there’s more likely to be proprietary IP in the server side code than in mobile apps.

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.

Seriously! What a bonkers thing to claim. "I had codex use maestro so I assume it made Android work well and idiomatically".

It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem, which makes me feel fear in my heart when I imagine the first "production is down" page coming in. I already hated mobile because it's so much harder to maintain than web (and I don't do any spyware or IAP so no benefits for me there); this yolo approach would give me constant dread.

It shows that at least some software development is moving away from code and to product management instead. I'm not passing judgement on that; I actually think that's great for a lot of software. It is interesting to see the shift happening though and will be fun to see if the general quality of software noticeably changes over the next few years.

We have people on the team that are android users. I just meant that I don't want to evaluate whether it feels "native" as I personally am not an Android user.

ITT: people dealing with realities.

Remember Chinese accounts on US Facebook say data centers are bad.

Remember the first step to fixing any problem is admitting you have a problem.

If you are blind, you cant see anything wrong, if you are deaf uou cant hear anything is wrong.

Sounds like the advice to newcomers is to not worry about trying to learn a programming language. There already is an llm to program for you, and do it better than you could, so just learn how to talk.

I hate to break it to you, but we already have it: it's called PHP

I think probably GPT 5.5, or 5.6 Sol - it was ~ 2 months ago.

Each time I get access to a new model, I do two things on all our active codebases:

- Security review of all the code and vulnerabilities (new models will find new stuff)

- Code review of test suite quality, and idiomatic patterns/code for the language of that codebase.

And in the case of swift and kotlin, it's even more important that an agent helps me with the code quality since I don't know what "idiomatic" swift or kotlin looks like, the way I do with JS, Elixir, C#, Ruby, etc.

this is from 2021....

Plus they have an Amazon-scale infrastructure to manage...

probably because every react native app they've used feels like shit

My argument is that platform specific codebases is the right course of action. My point is that consumers can tell, the product is better, and developers are happier working on native codebases.

Not sure why someone would say it was a wrong decision. Why would they even need to do this if LLMs make coding easier. They are likely chasing the things I advocate for: direct access to latest APIs from each platform, platform specific UI, UI that behaves correctly on each platform without chasing down edge case solutions (also said as ui that looks and feels "right"), and a bonus of separate developer pool to hire from that knows the ins and outs of the platform without needing to hire a developer to know all three- react, iOS, and Android.

> worked well for them

yeah because they don't care about a top notch user experience.

My validation is that platform specific codebases is what is the right course of action. The c-level decision is that they want the cheapest route to consumers. My point is that consumers can tell, the product is better, and developers are happier working on native codebases.

I read it. They chose native over shared. Hence vindicated.

Perhaps. I can absolutely see that being more attractive especially with things like the Duo where, I assume, SwiftUI gives you a number of things "for free".

That said, the massive downsides to native are:

- App Store Review time, this used to be hours to 1-2 days, now it can take a week or more

- In the same vein, you can do updates without waiting on native when using web technologies to build your app. We can go from a bug in the field to a fix in <1hr easy. Try doing that with a native app

- Cross-platform, yes LLMs mean you can create a native iOS and Android app but you have to keep those in sync to say nothing of web (if you want to offer a web app as well)

- Like the point above: Web, if you want to support web, why not get the other platform for cheaper (shared logic)

I’m surprised we aren’t seeing it more already. LLMs suddenly make it reasonable to maintain multiple native apps. I’d love to see this start to supplant Electron and its ilk on the desktop.

Definitely makes sense for a large org with massive resources (such as Shopify) to do this. But for everyone here pondering what to use for their startup or a smaller project, there are still important trade-offs. In the past few years I've launched multiple cross-platform Flutter apps and multiple native iOS and Android apps using Jumpstart iOS and Android (native templates from the GoRails guys which leverage web views from your Jumpstart Rails server). The latter gave me web, iOS and Android out of the box and was vastly less costly to build, even with AI. For entrepreneurs who like Ruby on Rails, Jumpstart is my favorite for launching rapidly, and since the mobile apps are easy-to-modify iOS and Android projects, it's designed so you can either add more custom Hotwire Native Bridge Components or just write Swift and Kotlin to replace functionality with native code. Eventually you could write away all of the Jumpstart webview stuff, but you'd only do that if you had more runway, like if you have plenty of time or you start making lots of money. I've worked for clients whose ideas failed--not because of my code, of course. :)

It's better to find out quickly if you can get traction rather than building something requiring more maintenance. For most bug fixes or enhancements, you make them in the Jumpstart Rails side and they should up instantly in the mobile apps without going through app review again! Most projects are not being built in companies the size of Shopify, so I caution anyone who wants to just get the project out there to use platforms that give them more leverage. And no, I'm still not a fan of low-code or no-code, because I know what it's like to have to maintain apps over many years.

Oh, and I still always warn clients to stay away from native mobile unless they absolutely need it, because even with AI, maintaining just a web app is still light years faster, and far more pleasant. I know from very, very, very recent experience that testing subscriptions is still annoyingly cumbersome in the flaky Apple and Google sandbox environments, and Stripe for web apps is night and day easier to test. Testing on mobile is better than it used to be, but sometimes when I'm waiting for builds onto a physical device or for confusing settings in App Store Connect or Google Play Console to take effect (or just fine where they've been moved to), I think about how a manager 20 years ago was telling me how slowly his development lifecycle was when he used to burn software onto ROM chips. So web is still the way to go, and native mobile only if you absolutely have to. And if you have tons of time or money, sure, start with plain native.

Edit: As a web developer for decades, I still find both Jumpstart iOS/Android and Flutter to be preferable to React Native.

Definitely, we invested in ramping up teams on native before going all in.

If AI can make any language do anything, why move away from React Native ?

What you could do with Kotlin/Swift you can do with React Native as well.

This just feels like internal factions wanting their own teams, and owning their respective politics, than a discussion on Merit.

Yeah. No way we’re getting the full story. It probably goes something like this… we lost native engineers when we switched to React then we lost the engineers that were supporting react recently and won’t be replacing them because stock market. Therefore we’ll switch back to native and go with under skilled engineers using llms. This will work until we have a code base model collapse

This is not the author. It's very likely Farhan Thawar, head of eng at Shopify

Yeah but engineering is still subject to failure modes, AI can't circumvent that short of formal proofing (which nobody really wants to get into)

I'd say that was even a goal of the AI companies. It's not in their interest to generate human-maintainable code

> 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.

Android and iphone emulator MCP, model compares screens, flags is theres drift? Something like that I’d guess

"GPT-8 Galaxia - figure out where our iOS and Android apps show different doohickeys and fix them"

Tests? Not being flippant, but that strikes me as the new surface to maintain to get what RN used to offer

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.

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.

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

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 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?

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.

This is so true, and I'm surprised that Shopify didn't mention it or that they don't use OTA updates.

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.

Are you saying a native app can't make an http request and update the code they JIT?

Yeah, massive parts of our community and ecosystem miss that something can be right today, and wrong tomorrow, and having to change along with your users and needs is OK. You'll never be able to anticipate what the business needs in the future, so stop pretending your software design can be done once and then just coast on that, because that's typically not how a software project should be run long-term or even medium-term.

The main cost of two engineering teams shipping identical products in my opinion isn't the cost of those extra engineers, it is in the product and organizational challenges of keeping those two products that need to be identical in sync. I am very bullish on coding agents but would be wary of this turning into a mess.

  For the Shop App, this coincided with our next major React Native investment: adopting the New Architecture. That work would have required us to revisit native module integrations, rendering, and the boundaries between shared and platform-specific code. Before committing to this investment, we tested whether coding agents could help us build directly in SwiftUI and Jetpack Compose while keeping product behavior aligned across platforms.

Another factor is design.

A lot of companies go to React Native, etc, because they want one single non-native design on both platforms.

Which IMO can be a mistake most of the time, especially from the POV of a user.

There’s risk to doing anything. There’s risk to doing nothing. A bit off topic but my perception is that organizations bias towards doing something more often than they should.

Is everyone wrong, or is there more to it than you can see from where you stand?

I don't want to spend much time on this comment so I risk not making a sufficient point, but something I notice is that you're appraising the situation from a purely technical point of view. The technical component is just one piece of what makes a whole product. I think Apple is probably a good example: they regularly make decisions that bother the hell out of tech-centered minds.

That decision is easy: do users leave bad reviews for bundling a few hundred MB of Chromium?

Do they leave bad reviews if your app malfunctions due to the system webview behaving differently than the Chromium version you tested with?

Forget about saving websites as apps, no one does that. Not sure if it works on Desktop Safari, it certainly doesn't on iOS Safari. Not even persistent storage is offered for PWAs. Apple likes the billions in AppStore fees they rake in every quarter.

Apart from the hassle that OSes put in the way of PWAs (intentionally, but that's another topic), a local Node app simply has a different kind of system access compared to a web app.

Most apps won't need these capabilities to function, but they are there, for all purposes good and bad:

- background activities with fewer restrictions

- less restricted file system and sensor access etc

- ...

sure, many app use this for nefarious things.

But real use cases don't need to be sophisticated rendering algorithms or what not.

I think good streaming apps also use these capabilities, for example, for performance.

Sure, cross-platform frameworks were great. I do think LLMs are changing the game, however. If you have a robust set of tests, it's much easier to maintain native versions of an app, compared to the past.

I think you contradicted yourself. If a tool provides better value for the time spent for a company, I don’t understand how you can call it objectively bad.

You can say it’s objectively bad from a technical perspective, but clearly that’s only one part of the equation.

None of this matters anymore.

We have LLMs.

It's easy to build native everything now without much resource expenditure.

Android will be Kotlin. iOS will be Swift. Desktop and server will be Rust. Web will be TypeScript / React for now, but maybe one day WASM.

LLMs are the target now.

I don't have any actual experience with React Native and Electron, but with that caveat out of the way I personally think tools get far too much blame that should be on developers.

For an example that I actually have experience with, React very frequently gets criticized for being slow, heavy etc. React is not slow. I can make (have made) fast and snappy websites in react. React can render at more than 60fps if necessary, and if the code isn't shit. The fact that someone else has made a slow buggy mess with React does not prove that react is bad, it simply proves that the developers are bad. At this point, someone will typically interject with something along the lines of "but react makes it hard to make fast websites" and to that I simply say no it doesn't. I've seen what makes react apps slow, and it's generally just bad code. The developers who make shitty react apps would make equally shitty apps with any tool because they're the problem not the tool. They don't know how to build good software and literally no tool can help them because it's simply a matter of understanding programming and the sad fact is most developers suck at programming.

I graduated university with about 200 others and out of those people who have the same degree as I do, very few were even decent at programming. I know that because I was the guy who helped them complete their assignments and I was a TA in several different classes, and I'm telling you the overwhelming majority of students sucked at programming even after 2-3 years of studying it.

After graduating I've worked on many different web apps and other stuff, and I've seen an overwhelming trend of trash code and bad developers. The people who actually care about writing good software and have the mental facilities to do so are few and far between. And that's why most software sucks. A good developer can write good software using pretty much any of the popular tools. The tools are just different ways to do the same stuff. Sure there's some overhead with react etc but it's really not that significant, the significant part is all the trash code people put on top of it.

Nuance is always a thing. Native apps are faster and better most of the time. Electron and React Native wouldn't annoy me so much if they were used with small apps where it's not worth over-optimizing.

However, it's now the default for Multiplatform apps that are used constantly, including IDEs, chat apps, etc. They gobble up memory and cpu cycles and are constantly getting updates due to the shitshow that is the javascript dependancy ecosystem.

A well built native app can still serve as a vector for harvesting personal data in ways you cannot control. A web app is inherently superior because of its security envelope.

> These tools are bad, objectively! They give inferior user experiences, and waste resources (ever more important now with RAM prices what they are).

They can be "bad" in some dimensions (as you mentioned) while being "good" in others (dev productivity).

These frameworks didn't become popular for no reason. They have value. The parts that are "good" can easily outweigh the parts that are "objectively bad" when they enable a smaller team to get things out the door they would have had trouble shipping otherwise.

A badly made native app is worse than a well built react-native app. There are plenty of anti-patterns that will ruin your native app.

In stories like this its much more likely that they just got sick of refactoring a big ugly code base so got buy in to throw it all away and starting over and the justification is native. Wait like 5 years and there will be a new react-native corss platform app because the native apps have too much cruft. Assuming we still have human in the loop then.

> For a while it seemed that having deeply held, nuance-free opinions about technologies was a sign of being wise and experienced

this was every DBA in the late 90's and early 2000s when talking about their pet RDBMS. To me, it was a signal to avoid that person unless absolutely necessary.

It's worrying to say the least. Today it's "get this working", tomorrow it's "can it also do XYZ?", next week it's "we have a 40% spike in crashes, you MUST resolve this IMMEDIATELY!"

Meanwhile the devs are furiously asking AI how to fix it, every flavor of every model will give you a different diagnosis, GH Copilot will throw a million high/critical at you, and you still have no idea if it's fixed or not.

It's the exact reason why you still need to know the languages you're using despite what leadership/product teams demand.

I would attribute it to physics.

If the entire page is rendered on the server, the information required to do so is presumably reasonably approximate (same datacenter). If most of the page is rendered on the client, the information needs to be pulled in from arbitrary physical distances.

At some point the engineering really is this simple.

Is it? I looked at the source but it doesn't appear to be react. It has a React API but also a "vanilla js" API and when I looked at the code it seems to be doing everything by hand:

https://github.com/pierrecomputer/pierre/blob/main/packages/...

... albeit using React inspired terminology like props and hydration.

You'd be wrong, diffs is vanilla js with a react wrapper.

It's the cost of water processing and delivery, infra (plumbing) maintenance, chemical treatment...

I'll most likely be at Polyglot. I did a very small part to help organize one of the very early ones.

We practically heckled and threw rotten tomatoes across it at each other.

How do you stay motivated to do this?! I've tried to start my app in React Native multiple times, but it always sucks, so I finally started learning Swift. I'm already not sure how I'll stay motivated to learn Kotlin too, and rebuild the whole app again.

A Rust implementation of this idea is Crux: https://redbadger.github.io/crux/

Yes, native .NET without MAUI is great for that. I have my app running with MvvmCross and two native UIs on iOS and Android since 2018, with hundreds of thousands of installs.

We're doing it with PHP... we call it SuperNative (https://nativephp.com/blog/supernative)

The GP misquoted the article. They actually wrote:

> Shopify has been using LLMs to build software since 2021

GitHub Copilot integrated into VS Code started becoming available that year. It’s definitely not a coding agent, but it was certainly LLM-assisted programming.