Shopify is moving from React Native back to Swift and Kotlin

However, I've seen this play out in many a big companies where there's a big mess going on. Answer is always similar pointing to -> "clearly it's not simple" and that's kind of the whole point. They made it not simple. 3k ENGINEERS, my sweet dude. THREE THOUSAND. By any and all account that's half as much as current chrome team or in total if you account for open source contributors as well. If robot is to believed that's also a headcount of windows and macos core teams. What is even going on, I don't even..

It also was reusing the WebKit browser engine, work on which started in the 20th century (as KHTML)

As to Shopify needing zillion of engineers: does their backend query seller APIs? If so, I expect many of their engineers work on keeping that working.

I suspect the vast majority of Shopify engineers never touch the core Shopify experience, but work on the long tail of invisible things that are nevertheless considered important. I'm talking along the lines of "direct integration with bank X for UPI in India to save 0.3% on payment costs in scenario Y."

Most of the modern software tooling you have today wasn't available back then, from great IDE's to popular libraries, writing software in 2008 was a different beast compared to today.

I have insights into the matters, and a lot goes into behind the scene optimization. Some specialists in the pre-AI phase were tasked to do nothing else but optimize build tools but in the sense of tweaking every millisecond out of it. This guy saved Google Billions over the years.

Others work in compiler building etc.

There are a couple of hints in the books by Google engineers but I am regularily blown away during meetings what really highly inspiring things are there to discover as well as presented.

Another factor: Google is spread around the globe. Regulation, law. Believe me, having over a billion users per app is mindblowing.

And it is 24/7/365. And support. And research.

Google is a company I admire. Technical provess at its finest.

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.

Spotify or Shopify?

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?

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

Both. The post is about Shopify, but some of the comments expanded the conversation to include Spotify as well.

> In a sane society, Shopify’s opinion on anything engineering related would be thrown into rubbish [...].

> This is unfortunately not an isolated case, Spotify for one has the same issue, [...]

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

I wonder what gripes people have.

They have updated their policies a bit. You may not be in the game credits but you'll show up here.

FWIW the social club team which handled a lot of the online components was small around the time GTA5 released. They built the APIs to handle user generated content, telemetry, accounts, etc. But, there were other team members that made it so the game would call said APIs.

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

Oh you said 500, not 5000, my bad.

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

And you also have to make sure you're getting the most out of it manually. Here are three steps for those who have Tidal and wan't to make sure that they're getting the most (ish) for their money:

1. Hardware Source: If you're using the soundcard in your computer, make sure to bump up the sample rate: on macOS you go to "Audio MIDI Setup" and change the sample rate to highest possible for your output.

2. Software Source: In Tidal itself you have to go to "Settings" and under "Audio quality" choose "Max". Under "Playback" turn off "Normalize volume". If you're having a dinner party and playing the music through a bluetooth speaker, you might want to leave it on. But otherwise off; the normalization causes distortion.

3. Output Device: You have two options here and you can go with both or invest more in the other one:

  * Option 1: Invest in some decent studio monitors. They don't have to be expensive or be able to play super loud, they just have to not lie to you. I would 100% recommend buying higher quality low power monitors for small spaces and/or spaces that lack acoustic treatment.  

  * Option 2: Buy some actually ok headphones. Bluetooth headphones are not good. I got Sony WH-1000XM6 which I mostly use outside. Inside I can plug them with an audio cable and turn them on and then they double their sample rate from 22kHz to 44kHz. But I also got Sennheizer HD600 which cost about the same and I plug them into a cheap headphone amp, and these headphones are really a world appart.  

- stack A needs lots of tedious, not-quite boilerplate not-quite-copy-paste work whenever you implement something, but reduces cross-OS bugs, UX and accessibility issues down the line. Lots of dev frustration, slows down iteration (when humans actually have to do this).

- stack B has awesome DX and affords smooth operation of the design/UX/dev teams, very fast. More issues down the line, though. May be worth it if unaided humans need to work on it.

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.

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

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.

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

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.

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.

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.

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

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.

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

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.

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)

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.

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.

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?

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.

> working demo especially good trick: force big brain make something to actually work to talk about and code to look at that do thing, will help big brain see reality on ground more quickly

One of the best things about AI is that you can have a working prototype almost instantly, which is great for iterating quickly over ideas. But it means this trick simply doesn’t work anymore.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

I think my point still stands that, if MSFT cared, it would be fast. The issue is not the technology choice in this case.

For example, look at their demo here: https://diffshub.com/oven-sh/bun/pull/30412

It's way faster than GitHub and you check the network tab.

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.

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

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

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

Is that something we should be engineering for right now?

I developed React native app for ios as side project and took breaks often and came back to have to do big updates with expo to make it work again. Maybe there is smoother process, but this was annoying

We have small shims for IOS or Android BLE. But otherwise the discussion of should you go native is really a discussion of how many employees do you have to throw with this?

I work in Rails too, I try to keep them to a minimum, but I definitely try to do at least one happy-path test of any major page (which includes automated accessibility audit), going without them at all seems insane to me.

At work, we use react native, and although the upgrades and stuff are painful, I'd never give up the ability to ship over the air updates.