When Chrome 1.0 came out in 2008, it only ran on Windows, and it couldn't do basic things like print or export to PDF, didn't have any accessibility, didn't work in RTL languages, and didn't have any graphics acceleration, among other limitations. Don't get me wrong, it was a marvelous piece of engineering - but it was extremely incomplete. By the time it was what we think of as a modern, complete browser, they had many hundreds of engineers working on it.

Also, you're comparing the number of engineers working on one product, to the number of engineers working at Shopify across their entire company today, which includes far more than just one app.

You're entitled to your opinion that Shopify is a poor app or that it's overengineered, but clearly it's not simple. That's just a fact. If it looks like a simple app to you, that's because you're not seeing most of it.

It's like looking at the YouTube mobile app as someone who watches videos and saying that the app frontend looks simple. You're only seeing 5% of the app. The other 95% is for video creators and advertisers, and it is decidedly NOT simple. I think that's the same here.

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 people under you.

A couple years ago, an engineer I know who has always been a very poor performer and lacks initiative, but is friendly and non-confrontational, was hired by GitHub. It would not have been hard for GitHub to find a much better engineer, but this person would be an easy person to keep under a manager on a team who wouldn’t leave or make waves. That can be more important to some managers than skills.

This is wrongheaded in so many ways.

To start -- how many of those 3,000 engineers do you think work on the mobile app? And even among those who work on the app -- do you think they're all working on user quality-of-life and just can't get it right? And it's a $175BB company -- do you think it's worth that much based on the quality of its mobile app?

What are we talking about here - Spotify or Shopify ?

If Shopify - and you are concerned about their engineering teams, please consider that Shopify's revenue grew from roughly $205 million in 2015 to $11.56 billion in 2025, reflecting an explosive compound annual growth rate (CAGR) of over 45% across the past decade. Market validates !

I have nothing to add about Spotify - I use it to listen to music and it works well for me !

People who has not run software at scale have no idea what it takes to run it at scale. Google chrome is 60 engineers at launch but google same company has more than 100k engineers. Building first version was always easy and only gotten easy, scaling software was always hard and it is still hard.

PS - Spotify i can't defend the product sucks.

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

Just so it is said: my understanding is it's really easy to not end up on the credits list for games despite having worked on it. I don't know if contractors end up on there for example, at least beyond some team leads or the like. I don't know R*'s policies though, I've heard stories of people not being in credits because they, for example, changed jobs near the end of the development.

I get your overall point though

You're comparing a company (Shopify) to an application (Google Chrome). A better comparison would be the number of engineers at Google (90,000 [1]) vs Shopify, or the number of developers actually working on the mobile application instead of any other area (website, backend database, internal systems and processes, infrastructure management and maintenance, etc.).

[1] https://www.linkedin.com/posts/rpandey1234_its-mind-bending-...

Video games are much easier than what Shopify do which will be a long tail of business cases and local permutations for all the countries they operate in.

Commercial software is usually a simple core and a long tail of business exceptions

In the corporate software world, especially anything to do with the web both front and back, most people really don’t know what they are doing. The goal is hiring/firing and agile.

Compare that to companies that release actual software products. The goal is product release at high enough quality. There are real performance and security targets to achieve.

Your typical corporate developer, on the other hand, does not have release targets. The actual goal is compatibility with the industry least common denominator expectations and retaining employment. This is why so many people are needed to do the work and why the result is so slow and bloated.

A lot of shopify's engineering probably work on the back-end business logic for payment processing, sales tax, etc. Shopify has to comply with financial norms, rule and laws in so many different jurisdictions.

I know someone who works for Gusto (HR and payroll SaaS for small businesses)... most of their code-base is also business logic and whatnot for all the jurisdictions they support.

Comments like these make me wonder if people don't understand the difference between engineering and business.

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.

They'll be mostly involved with the parts that make money. I worked in a similar situation as one of about 5 people keeping the core infrastructure of the product working, meanwhile about 500 people optimized the ads

I wonder how many of those are there to consult with customers and help them build their stores.

How many of those 3000 engineers are working on the core engine?

That is vs infrastructure, customer support, partner outreach etc? Then you have all the people working on localisation, not just changing the words, but local regulatory issues.

Chrome only has one customer to deal with, Google itself. And since Shopify is saas and hosted for thousands of customers, vs Chrome running on the users pc, the infrastructure complexity does not compare

>what “engineering” Spotify is doing, it’s the worst app I’ve used in my life.

Engineering is app usability. Theres no other possible thing an engineer might do. Chrome ofc has infrastructure to distribute a binary. Spotify of course having a global content delivery network for terabytes of music. Hey GANG CAN WE WOKK OUT WHAT THESE ENGINEERS MIGHT BE DOING?????? WHY HASNT JIM STORAGE ENGINEER IMPLEMENTED A UI REFRESH YET!!!!

Shopify supports multiple countries both as a buyer/seller. I assume there is all kind of customizations needed to comply with each country weird rules. Are all of these software engineers doing core engineering? Probably not. But they are probably tagged as software engineers within the organization.

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

This is so... wow. You think only 150 devs made GTA 5? Despite the fact that rockstar has 10 studios and you think only 150 people in 5 years touch the code of the game? You should learn how those credits work. It doesn't mean what you think it does.

Furthermore, game dev also includes so many artists and other work. It is so insane to claim gta 5 was made by 150 people that I don't think the rest of your comment can be taken seriously.

Shopify as a company works on a lot more products than Chrome developers do.

More relevantly, a lot of their work involves interfacing with hundreds, if not thousands, of external partners, competitors, etc. systems.

When you see seemingly simple products have too many engineers, most are almost always there to cater for enterprise customers.

And how many engineers does Google have? The people working on Chrome are a tiny, numerically insignificant fraction of Google’s employees. A much better comparison would be people working on Google ads and their other commercial products.

3000 engineers or 3000 people on the engineering side of the org ?

Not sure I'd trust Astra in its numbers.

Shopify also seems to be very solid and reliable and I imagine that could require a lot of QA and edge cases (and a lot of support engineers)

Shopify is handling customer payments worldwide, 90% of their work is probably localization issues rather than customer-facing feature development.

GTA V developers don't give a fuck whether the game is running on a computer in North Korea or in Sweden.

Extremely ignorant comment.

Ironically enough, you using "GPT Astra" to query for such simple information is probably in no small way correlated to the state of software engineering (in these large corporations and otherwise) today.

When business is booming, you can do nothing wrong, as with that revenue even big mistakes stop mattering.

All I want from Spotify is API so someone can make better player/plugin to a better player.

Tidal is pretty nice to use. Plus the music isn't compressed.

Comparing Chrome in 2008 to a company in 2026 is a choice.

its actually not that weird if you consider that those shopify engineers are probably not even exceeding 150,000 usd on average salary wise

canadian dollar is very cheap so you'd likely see 40~50% more headcounts for the same burn rates you get in USA

i definitely dont think those shopify engineers are going to be retained long term however

"A simple app" well there's your first mistake, it's not a simple app is it

In a sane society we would be less willing to pass heavy judgement on so many things at passing glance.

Lazily researched comment. Pretty much anyone who isn't in sales can have "engineer" in their title. I'm sure there were plenty of "support engineers" in the Shopify number you cited, and I'm sure there were zero in the GTA and Chrome numbers you cited.

One word: Ottawa. There's a lot of engineers, most of them underemployed.

Shopify has approximately 7,600 employees globally

I don't share your opinion.

With no deeper knowledge to the matter, it is pretty senseless to speculate.

"Numbers from GPT Astra" - well, well...

Currently roughly 1000 engineers are working on Google Chrome.

GTA 6 has around 6000 developers working on GTA 6 since 2019.

So sounds a bit off what you allegedly researched. But, hey, AI slop is real.

We have no idea how many of these engineers work on the mobile app. This comment is somehow both AI slop and human slop.

> Numbers from GPT Astra

Come on.

How are you evaluating the Android build if you don’t use Android and you don’t know Kotlin?

React native is an obstacle compared to what clear Swift/Kotlin code may produce. Swift is very powerful and Kotlin, in all honesty, is the first reasonable and very useful thing to come to the JRE ecosystem (save for Scala, which is, well, quite complex still).

Myself turned some python code to Swift, and keep doing so, without trouble or pressure. Of course, I've been doing fair amount of systems programming for 20 years now, so not sure what to advice newcomers. But this approach to dev DOES work for me very well.

And people say AI isn't taking SWE jobs...

I assume having Kotlin and Jetpack Compose makes it much easier than it was back around 2020?

We did the same with our apps used by a few hundred thousand people a day. We are a slow, boring company, so the port took about 4 weeks of engineering work, and maybe 3 months taking into account release process and change management. But in fairness, we had the first working version after a day as well. This was in February, too, with substantially less capable models, unable to do overnight runs.

I thought the same, but then I build a few complicated apps and thought I could keep the different codebases stable but still was a headache, so switched web, ios, android all back to expo/rn. I love that testing is only (almost) only thing now, instead of 3 platforms.

React native is broadly an inferior option.

LLMs made it way worse https://ashishb.net/tech/react-native/

This has been my conclusion as well. Agentic workflows drops the effort level in keeping two native code bases in sync.

So now you have two vibe coded applications you don’t understand. I’m not an advocate of making “job security” decisions but this definitely goes to red flag territory. Was it your job to maintain the RN codebase or do you have other functions there as well? I’m not sure I would keep a native noob on a vibed native codebase. What is your take?

Congratulations, you now have 2 codebases to maintain.

And there's no proprietary IP in your company's app that you don't mind being sucked up into the training data?

Codex with what model?

Next up, designing an even higher level language which will be used by LLMs to compile to high level languages like kotlin or swift. Just store instructions for LLMs in repos.

[flagged]

Seems a lot like the meme of the new designers pushing a redesign to justify their existence.

To be less dismissive it seems an industry wide problem that big splashy projects get rewarded while the silent “Snow Leopard” mind numbingly obvious just up your quality and fix bugs and UX issues work goes unnoticed.

I don't understand the logic. AI vs Human development still have similar cost profiles. It costs $ per unit of thought (salary or tokens).

If React Native worked well for human programmers, wouldn't it be just as good for AI?

ah yes, the classic full circle

/remind me in 6 years about this thread

Makes perfect sense.

> The continued React Native tax of unnecessarily difficult upgrades,

My very first experience of RN was having to update an app to handle the mandatory change to 64 bit APKs

Which required a massive update not only to several dependencies but also xcode, iOS frameworks, the weird objective C caches that get smuggled into node_modules, _as well as_ all the rigmarole or making the 64 bit APK build work

It was completely miserable

  >  cause your business to really spend a lot of time shepherding the tech over the finish line

> The continued React Native tax of unnecessarily difficult upgrades

I thought I read somewhere that this is what prompted the move. I don't use RN, but apparently the new architecture isn't exactly a drop-in replacement.

I experienced the same issues but went the other way and migrated from React Native to React. Still one codebase but none of the issues. Performance was better too even though half the code stayed the same.

They specifically say in the post how React Native was the correct decision and that it worked well for them.

Now it's a different situation as implementation has become incredibly cheap.

FWIW, the native app specialists are in some sense the most invalidated here. Shopify decided they couldn't afford your skill set and didn't change their mind until you could be replaced with an LLM.

Really the whole concept of technology specialization is the thing in jeopardy. It no longer appears to work to make a career out of deeply learning something obscure. Agent-farming generalists appear to be the ones who own the future right now (if, heh, not the agents themselves).

You should read the article. You'd realize that you're not actually vindicated by its contents.

I don't see why you would, unless your argument for your whole career has been that LLMs make this easy.

I'm inclined to agree on certain points; true native apps are, generally speaking, better when it comes to e.g. customer experience. It comes with risks and costs (but I think the cost vs benefit is exaggerated) - risk being the ability to find good native developers, which aren't as common as e.g. web developers who can switch to RN fairly easily.

But there's a factor few people (that decide on using RN) miss; it adds a layer of indirection, so you're no longer as "in touch" with the underlying platform. While possible, few RN developers would consider adding widgets or smart watch apps to their main app, but (I feel like) if you're a native iOS developer who is all-in on the Apple ecosystem, you're more likely to try and adopt these features (where applicable).

(disclaimer: RN is my current day job, used to do native iOS development and I frequently miss it)

Same here. Glad I stuck with native iOS development. I still haven’t switched to SwiftUI though (except for some small stuff). Still sticking with UIKit here.

If only LLMs had been invented at the beginning of your career, you would have been right all along!

what they should've done is written logic etc.. in rust and use mobile app just for native layers, so they can still share code.

[dead]

[dead]

Yes, AI have changed the game, and now you can build and maintain two separate projects in Swift & Kotlin instead of one on React

Thanks for the write-up. I'm curious if there's a shared core between the iOS and Android apps (e.g. KMP or Rust), and if so, what that looks like.

Also, any plans to open source Helix?

Thanks Mustafa! This was a great article—I'm curious, did you consider the non-technical / organizational costs in keeping the two codebases in sync as a separate factor? Do you foresee more organizational overhead as part of this decision? How are you planning to manage that? E.g. small implementation difference between the iOS and Android app increasing the support burden or bug burden and causing duplicated team effort.

I suspect we'll see a lot of large orgs doing this in the next year.

They created a mess in 2020 and hopped on over to a job at FAANG and now a fresh batch of Waterloo graduates want to do the same - maintaining somebody else's turds is beneath a Waterloo graduate on his way to becoming a manager who never touches code ever again :)

So it goes.

Any education required for engineers to switch to native or the agents are handling the details on their own? Wondering if architecture or the new languages require ramp up.

Did you switch to SwiftUI or UIKit?

Why is it astounding? They have one of the biggest e-commerce applications in the world. A mobile app for shoppers. A payment system and mobile wallet app. A shipment tracking system. Tax and small business software. They have their own lending arm with its own software. They have multiple frameworks for other development teams to make super customizable e-commerce sites. They support Remix and Tailwind among other software. They have brick and mortar POS systems.

They are like multiple companies in one: Square, Etsy, aspects of Stripe, aspects of Squarespace/Wordpress. Idk I can see why they have a lot of people.

>I asked for feedback

Even if they gave you feedback I think you would have to take it with a pinch of salt.

Hiring decisions are more emotional than most people would admit.

I had an eerily similar experience interviewing at a similar public SaaS co recently.

Nobody is talking about the real advantage of RN: Being able to release to the App Store without having to go through a review. That's so massive. Getting a bug fix out to users instantly, sneaking in optimizations, etc..

Sure, you need a review to release native code changes, and you should probably get a review if you have big feature changes just for the sake of Apple not banning you. But in practice, it removes one of the biggest annoyances of developing for the App Store.

This is true in a very real sense – models can help you build native apps very quickly, no question. But how do you keep them from drifting apart from one another as you add/change features or design? Right now, there isn't much tooling for this.

React Native's advantage of having a single source of truth for code hasn't quite gone away yet, imo.

You always still needed a specialist per-platform even if most of the code was RN or KMM[0]. But I agree - a thousand not-great mobile apps sprang from this idea.

[0] I always thought the best answer was something like KMM to do all the backend comms and local data model in a shared way, and then a bespoke UI building on what that shared code exposed.

> The main appeal of RN was being able to leverage your web devs for mobile dev.

> But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway.

Are you saying:

- webdevs are now able to write and review native code because of AI (who cares if they don't really understand it); or,

- Because developers are more productive we can cut the number of webdevs and hire native engineers – same no. engineers, same output, but now native apps.

Why not:

Continue using RN but now and just enjoy being more productive? If productivity was the reason to pick RN, then enjoy it. It's not a bug.

I think there are many reasons why React Native would be unappealing, my experience with it wasn't that positive.

I don't see a reason to use it over web stacks plus CapacitorJS (Or Tauri) or directly native for very large teams.

> The main appeal of RN was being able to leverage your web devs for mobile dev.

There's nothing remarkable about the skill set of either party; the appeal here is re-use of code. how the labor markets itself is irrelevant

Another scary thing is with AI it's easy to let complexity get out of hand to the point where a human manually writing code is basically impossible. Even though AI might seem capable of handling the complexity, you'll start noticing all these weird bugs pop up all over your codebase.

Armchair / gut feeling opinion: using AI makes a developer feel like they can manage more code than they normally would. But it's a risk, if an agent can no longer make sense of the code, or the developer can no longer make sense of what the AI is saying, you're in trouble.

Not a new problem, of course - developers wrangling large amounts of code (more than they should or can) is a recurring challenge in the industry.

Always relevant - https://grugbrain.dev/

Yeah the problem is AI would improve exponentially and can do work 24/7

any engineering problem is just 'when' and 'how much' at that point

We should understand the complexity we are adding but having LLMs as a tool does also make managing the complexity easier.

An entire copy of libreoffice, for one.

I'm working to solve this...

And the “makes sense or not” part can change based on a bunch of factors.

It’s actually pretty common for a new company to start fully native (only iOS, few features, limited scope), then switch ro react native/electron (need to support more surfaces, features are being developed too quickly), then back to fully native (can afford individual dev teams for each platform).

> I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools.

I don't think that's necessarily true. Nuance is a thing.

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

But that doesn't mean I can't understand or even agree with a company for using them. Building the same native application for more than one platform is expensive and time-consuming. Most of the time I'm happy to prefer an app built with a cross-platform framework vs. not having one at all.

(To be fair, though, if there's a webapp, 90% of the time I'll prefer that over an Electron app. But nothing meets a well-built native app.)

> I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools.

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

The slightly lighter version of this was having near-absolute convictions but leaving a tiny exception for extreme cases to try to demonstrate that you weren’t being unreasonable.

These would usually follow trends when something would spread like a meme. Recent examples include “Everyone should use SQLite for everything” and the ironically closely related “Just use PostgreSQL for everything”. The typical pseudo-nuance would be “unless you have FAANG scale” to imply that there is no nuance until your user base includes most of the developed world.

Using cross-platform web technology is absolutely a nuanced engineering decision that is the right one for many businesses. What is categorically bad is bundling a standalone browser runtime for every single service, wasting user’s storage and memory when you could just have a website in a browser.

Is there any major browser now that doesn’t support saving websites as apps? Electron is simply a suboptimal and incorrect way of producing web apps.

its sad that the only reason warranting this switch is AI.

I would have loved to see some performance benchmarks on some critical app flow.

These takes are also a bit premature. Wait until the new apps have rolled out and users are happy.

Most likely this will work out fine, but big rewrites like this have a big enough chance of going off the rails that I wouldn't shout success from the rooftops just yet. I'm sure Digg engineering was proud of their rewrite too.

Agreed. I felt the same way when a long time ago when Airbnb made a big deal of going back to native.

For companies the size of Shopify and Airbnb that makes sense. But that doesn’t mean a small ten person startup should do the same thing.

Absolute opinions are simple and travel better on media.

"The right tool for the job" is too complicated for a lot of people to understand. Tradeoffs? Tradeoffs require understanding.

"XYZ is the best, just use it" is much easier, especially if you don't know how to make decisions and don't really care. Then you defend your non-decision by parroting what you read.

I remember a product manager talking crap about Kafka years ago, and I started digging in as to why he didn't like it, and all of his reasons were marketing FUD from competitors. It was odd, his understanding of it was a Potemkin village.

All tools presumably solve a problem. If you understand that envelope you can figure out if it works for you and your envelope.

It is funny how the experience of finding a tool/platform that you love can be a little bit like joining a cult. You probably have experience using other things that were frustrating and this one seems like the answer. Each platform has its own tradeoffs and philosophies and embracing one can make the others seem backwards.

Its also funny how reality sometimes validates or punishes these loyalties, and that is reaching a fever pitch in the era of LLMs. Platforms that offer familiarity at the expense of complex or inefficient framework will naturally lose ground when familiarity is no longer at a premium. It is a good thing, all of the hard parts are a little easier and it is less tempting to take the shortcut that you know has a dead end somewhere.

Well written and good perspective

I think this is something we’ll see AI very meaningfully impact — the threshold needed for “Get this thing working on a tech stack we might not be familiar with” has gone waaaaaaay down.

[dead]

I've been trying to minimise the number of apps I have. Every app needs to be justified in that I actually need it, and there is simply no way it could have been provided as a website.

true absolute cancerous bs

Never bought anything that used Shopify and never will. As a Canadian, Lutke is just a pathetic individual and I simply refuse to use anything he touches if I can avoid it.

[flagged]

I would attribute that more to culture.

For example https://diffs.com/ is built in React and it's basically instant.

I don't think UI frameworks will go away any time soon. They solve a very different problem from React Native.

Dropping Javascript and going back to native yea

it was also terrible, but in a different way

[dead]

Before and after LLMs.

We believed that the craft was typing the code while the real skill is to create something solving someone's problem. Whether that's done by punching holes in cards, writing esoteric letter combinations decided back in the 80s or using any natural language I so wish, to me it's the same. I just like getting there faster and while I'm grabbing a cup of tea.

psychosis

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.

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.

I never understood how that flies by Apple's review. Aren't all code changes supposed to go through their review and thus OTA is effectively illegal?

> The performance gains in native compared to RN (new architecture) are minimal for normal UIs (except games)

And yet most apps feels distinctly different than native.

> The most valuable feature which RN have is OTA updates, this has been a game changer for us and many fast moving companies. Ability to release and iterate at light speed. On native you are on the mercy of the app stores for review

That's the real killer feature

> Silos of bugs on native - When you go native you might encounter bugs which appear only on either platform.

This still very much happens with RN on anything bigger than a toy app

> The project management of native teams is not always in sync - The teams often drift apart bevy iOS team might need 2 weeks just to make the app compatible with the new iPhone Fold (Duo) or Android team might encountered a blocker. Keeping them in sync for new features is really hard.

Speaking of which, what is the iPhone Duo support situation of RN right now?

> I'm sitting here at my desk overlooking Cordova Street. The street that Apache Cordova is named after. I've seen this debate for almost two decades now.

The debate has been taking place on the actual street?

Yes, though its worth noting the goal of Cordova was to not exist. In the eyes of the project the web itself is the cross-platform solution but at the time Browser progress was stagnant and Cordova helped move things forward by offering device functionality using open web standards. Cordova was never intended to be a "cross-platform productivity multiplier". The north star of the Cordova project was for browsers to get the device functionality that native platforms offered, such as geo-location, accelerometer, contacts, camera, etc.

I just want to correct this, because I agree with you but the framing is a misinterpretation of the goals of the Cordova project - goals which were ultimately met.

I've dumped all cross-platform frameworks as well. I tried many of them but they just weren't good enough, even for simple stuff. There were always glitches and teething problems that marred the overall quality compared to the native version.

I'm currently maintaining versions for both iOS and Android.

That wasn't the starting point for the webview app DX.

Companies (or their consulting agencies) had tons of webdevs - working on their company public and internal websites, but not many native smartphone devs. Those were the days when people who completed the Stanford iPhone programming course were snapped up lickety-split.

But everyone was clamouring to have their own smartphone app for all the smartphone platforms (well, iPhone, Android, maybe Blackberry)

Hiring enough smartphone devs to fill multiple smartphone-specific dev teams would be like trying to build multiple AI development workstation on the cheap these days.

In the late 2000s, people realized they could write an HTML/JS/CSS website and compile to an app for each J2ME/Blackberry/iPhone/Android platform that would "serve" the website. So their webdevs could be converted to smartphone app developers.

Hey, if you planned your website well, you could use the same business logic for your website AND your smartphone apps.

That was the elevator pitch.

You'd need an actual (maybe two) native smartphone devs for each platform to handle any areas where the marketing didn't meet reality 100%.

But that was doable versus hiring multiple native smartphone devs for each platform.

And in the late 2000s, there seemed to be a lot of potentially viable smartphone platforms - iPhone, Android, Blackberry, J2ME, Windows Phone, Palm's webOS. But we know now that in a few years, all but two would wither away.

Even with native APIs exposed via JavaScript, there were obvious problems with these webview apps. The apps were passable if the app didn't require much user interaction or computation.

Projects like React Native and others tried to reduce the amount of webview usage and increase the amount of native UI controls used.

The mobile platforms themselves aren't going to improve their platform-specific webview to make it easier for webdevs to mimic the "native" experience. Why would they?

I can see the case for shared core libraries and then platform native views. This is best done in one programming language. Can Swift, Rust or .NET work here?

Pretty sure I've seen you either at B-Sides or Polyglot... Small world...

[dead]

This is probably the end now. People don't debate anymore whether they should write only in assembly vs. in C. Sometimes new abstractions emerge and they replace something completely. This time the abstraction was LLM.

> React Native was always about making app construction easier for people who don't want to learn ObjC or Swift.

There are more OS than just iOS, depending on the app a lot of shared logic has to be written only once with RN.

I agree as well. To the point i have a feeling that maybe after some time people will just start writing bigger programs which were in these high level languages like swift, java etc in Rust or C++(except for the potential memory risks).

I mean maybe there is some substance to the point that llm's have read substantially much more code and projects made in python and JS instead of rust or C++, but as they generalise and improve more and more, there is a case to go back to these languages for the pure speed and close to the metal ideology they have.

Most likely many wont do it because shipping faster and capturing market value makes more sense than optimization for a company like shopify(user probably wont appreciate going from 175ms to 20ms as much as new feature), and for those features the higher level lanugages have more training data in the models, but still interesting to think about.

I would not say they were bad, mostly just primitive compared to what we have today. I can only presume they are talking about GitHub Copilot which was released before ChatGPT. I believe at the time it was little more than “spicy autocomplete.” Yet it could be surprisingly capable, e.g. I recall this blog, also pre-ChatGPT: https://medium.com/data-science/github-copilot-crushes-data-...

That said I did happen to work with a team in ‘21 - ‘22 that got access to an older coding model from OpenAI, also called Codex, through a corporate partnership. We also tested it out in an autocomplete UX. Our experience was rather hit-or-miss and I was a bit skeptical of AI-based coding at the time. That blog post above and others like it were an eye-opener and made me wonder if we were just “holding it wrong.”

Then ChatGPT was released. It was nowhere as good as the models today but it could write reams and reams of correct code and I realized the world had changed forever.

I'm skeptical. Pre-ChatGPT the models didn't understand tool calls or file editing so you couldn't really do targeted edits. So I really am not sure what they mean by this.

I mean, it's not impossible - I wrote a "coding agent" with GPT-3. It sucked balls. The idea was you write a Markdown spec file and the tool then compiled it to an equivalent source code one shotting it every time, but it hardly worked at all. The file changed too much every time and instruction following wasn't good enough, so it'd keep changing the interface exported by the file, and there were lots of bugs etc.

That would be a huge mistake if we expect many more hardware and OS running them efficiently than just iOS and Android. Best is to have an IR. Now maybe that IR can be turnt into native code. But we shouldn't be constrained. As an incoming framework author, SwiftUI is problematic for instance because it has a programming model which is dated. And I don't particularly enjoy the language either. Looked fine at first and then got more complex than I feel is needed.

oh yeah, disclaimer: I write UI frameworks and dabble in PLs.

I think it'll become a trend at larger, well-capitalized companies and startups, but not universally. The article mentions hundreds of engineers have worked on Shopify's RN apps, so they're well positioned to maintain two native codebases with agents and practically infinite token spend. Migration will be a harder sell for resource-constrained businesses.

It also depends on features. Many apps don't rely on platform features (widgets, watch apps) and are essentially webviews, and those will continue to do just fine on RN.

Can React Native become a sort of Compiler which compiles to natives (Android/Apple) now that AI can help in that direction as well? I don't know much about mobile ecosystem though.

Yep. Flutter has been dead-end for a while. RN won't last through 2027.

What if you could have both great performance and UX for each platform AND a single codebase?

I have done some iOS development and still couldn't follow what the article was saying about the simulator. I'm actually quite interested in it, because (in my experience at least) verifying that the UI works as expected is quite painful with current LLMs and the developer tools available. They talk about building a CLI and keeping business logic isolated, ok fine, but do they still run the simulator and take screenshots to verify their work?!

It’s a reasonable tradeoff. Shopify uses Rails, and there’s been a long history of discussion around E2E testing in the Rails community.

In recent Rails releases, system tests, or E2E tests, are no longer enabled by default. The short version is that they’re significantly slower and more brittle. Basecamp also removed most of their E2E tests.

I don’t know what Shopify does internally, but my guess is that they’ve taken some of those lessons and are trying to apply the same thinking to mobile development too.

https://guides.rubyonrails.org/testing.html?#when-to-use-sys...

There's a section linking to a more in depth article:

"The Shop app, which is regularly at the top of the list in the shopping category in the app stores, is the first to be migrated. Assisted by AI, the team was able to go from a proof of concept to a fully rebuilt native app published in the app stores in just 12 weeks. We’ve written about this migration in depth here [0].

The migration of the Shopify app (our biggest with 300+ screens, home & lockscreen widgets, Apple Watch app, complications, Siri Shortcuts, etc.), is also underway and will ship later this year. The rest of our apps will be migrated soon."

[0] Migrating Shop app from React Native to native https://shopify.engineering/shop-app-migration

Speaking personally, JVM toolchain bits like Gradle being involved is a turnoff and has kept me away from KMP. Last I checked support wasn't really there yet, but I'd much rather go the other direction and use Swift Package Manager and the associated toolchain on Android.

1. AI will read the code

2. AI will manually test code

> Just because. There's no tech reason to do it.

They made a separate article on why, which they linked to. Performance is significantly better. The native Android app launches twice as fast for example

Ridiculous, the amount of energy saved from a faster native application over how ever many million users will be far greater than the amount spent to generate the tokens to do so

Can someone explain the waste water thing to me, because unless they’re separating it into H2 and O2 how is it possible for water to be wasted?

quality ragebait

This article is about the Shop app (which is a consumer shopping app, kinda like Etsy or Amazon). The Shopify app is a lot more complex actually

If the argument, which seems to be "code is cheap; let's write implementations for multiple platforms", remains true, what do you think will continue turning the wheel?

I think what they’re actually admitting is if they have more resources to throw at native.

This is non-starter math for small companies.

Your data is out of date. React Native performs within spitting distance of raw native now because in the last 2 years... it basically became native - it's now false dichotomy

It's incredibly easy nowadays to drop down to native from react native where you need to.

You don't have to ditch cross-platform building entirely just to escape dependency hell

I don't think its purely fashion here. React Native always incurred a bit of a performance & UX penalty, but many people decided that this tradeoff was worth it for the increase in product development velocity.

LLMs change the tradeoff and organizations would be remiss to not reconsider previous decisions.

got me spinning like a record baby

srsly

Not enough community around it. Shopify would have to pioneer a lot more than they would like to get it working for their use case.

I've been out of the app world for ages, always liked kotlin. Can you speak more about multiplatform?

The problem isn't tokens but verification that the code works.

I came here to say this. I also prefer fully native apps but this is the elephant in the room. If most of your web code can be re-used on native, that's a ton of tokens you won't have to pay for.

Which is why the topic about what Shopify does should apply to absolutely almost no one.

Who has more people/resources to justifiably throw at their native app than Shopify? Maybe a dozen companies?

So disagree. The benefits you get from leveraging a framework as as important today as they have ever been -- strong frameworks, fewer tokens, faster progress.

100% with you. I'm fed up of having my M3 36GB run out of memory because I have Chrome, Slack, Discord and Claude all open at the same time

That's why I'm building SuperNative

IMO it doesn't make sense for LLMs to write machine code, because abstraction allows them to have more information density. As context size is a big limitation right now, cluttering it with less dense information seems like a bad idea.

Probably a long time, as machine code is verbose and thus destroys the context both when reading and writing, as well as making it more expensive.

Direct 1s and 0s

React Native apps are not webview based like Electron, they use native components. Arguably it is more native than flutter, which uses its own components designed to mirror native ones on Android and iOS.

I think any framework that aims to support desktop and mobile frome the same code per view/screen is doomed to either make one of those two awkward to use, or alternatively become itself very complex to use.

The most advanced in this area may well be websites and into those decades of work of thousands of engineers went (HTML, CSS and JS standards).

Even a single person can now build/maintain native apps. It's literally a day of effort for an experienced dev working with the best current models to port an app to a new native platform. Maybe another day or two to walk through wiring up all the test harnesses needed to prove the app is working well without a human having to click everything. Until recently you'd still have to spend a bunch of time on making sure the UI looked and felt right, but models now have good enough vision capabilities to where even that can mostly be automated.

And, honestly, the cost of tracking React over time has always been higher than the cost of tracking native deployment options, which move more slowly and usually with more care than React, where breaking backward compatibility is just another Tuesday. I don't think the promise of React Native being an almost-free "native" app actually pans out in reality. I've never maintained a large React Native app, but from following some apps that are, it seems like it introduces a sizable amount of technical debt that you pay over time. So, in exchange for worse software you also get worse maintenance costs.

https://github.com/vlang/ui2 does just that

wxWidgets carries too much legacy. A GTK3 fork maybe? Or a functional clone of QML with some improvements.

Working on this problem for the next version of NativePHP Desktop. Have dropped Electron entirely

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

That's for the Android version, I would assume

Even at MVP startups that's not true anymore. It's now easier to build native than to deal with RN quirks.

If you expect a story about how this migration to native went from technical PoV, they've already shared this: https://shopify.engineering/shop-app-migration

It sounds pretty solid, so I wouldn't expect anything to change in just 6 months.

Translating code from one language/framework to another is easy for AI to do, as it does not involve solving any novel problems. Making improvements to existing complex codebases is much harder.

I think its more like 2024/5 is the year that existing frameworks were locked in place. At least it feels like that for react.

React popular -> llms get good at react -> llm generated apps default to react

Most apps don’t do anything interesting.

There's also "Helix rebuilding a screen in the Shopify mobile app using Swift and Kotlin" which sounds like a caption but there is no video or image.

Getting 11% AI on Pangram, which isn’t bad tbh.

> they're basically going to be spending a ton more than they have to by switching back to multiple apps

A ton more what? Money? AI costs are insignificant to a company like Spotify. Hell I've been using Astra fairly extensively at work and I've only racked up like $500 in the last month. Peanuts.

There's quite a bit of research out there showing that application performance has a material impact on checkout conversion rate, so a single platform optimization potentially improves checkout for millions(?) of storefronts.

Seems like you've never had to worry about accessibility in hybrid apps...

And on top of that, they're losing the ability to ship hotfixes over the air and will always be at the mercy of apple & google to deliver their updates.

React is still king.

Legend List is the new hotness in RN.

Other than LLMs can do it tokenmaxxing exercise.

We're only where we are in the world of computing because of abstraction layers

It's not the layers that are the problem; they're the point.

It's the quality of those layers. React is just a poor abstraction layer

https://medium.com/airbnb-engineering/sunsetting-react-nativ...

Article is too long to summarise but basically they outgrew it tech- and org-wise.

Lack of a sane desktop app framework from Microsoft.

Heck Microsoft wrote their own damn start menu in React native, and VS Code in Electron.

See the first post, they have 6000 engineers.

Their reasoning’s and opinions on anything are useless to compare to almost anyone.

We’re using Flutter successfully and love it. I don’t have 6 engineers to throw at Native, let alone 6000.

We've been doing this for a while and it works great. Logic and network stuff goes in Rust, UI goes in Swift/Kotlin.

So you want to review and maintain code in 3 separate languages?

Sounds like a complete waste of tokens with the worst case of just quickly building more technical debt, three times.