25 ms·

Shopify is moving from React Native back to Swift and Kotlin

• deleted 1mo ago
  [deleted]
• yusufnb 1mo ago
  Web based mobile made sense pre AI. It is just simpler now to use different languages and have AI implement features across the board.
• xcc3641 1mo ago
  Debugging crashes across JS, C++, and native threads costs more than maintaining two codebases.
• tower-shield 1mo ago
  Finally some common sense. Time to put electron to rest.
• fnthawar2 1mo ago
  We don’t hold on to a decision just because it was successful at the time. When a core assumption changes, we’re willing to go back and ask whether it’s still the right call. LLMs changed one of the core assumptions behind our 2020 decision, so we reevaluated our mobile stack from first principles. What we found led us back to native.
  • ceejayoz 1mo ago
    I suspect we'll see a lot of large orgs doing this in the next year.
    • joshstrange 1mo ago
      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)
      • joenada 1mo ago
        Your assumptions are very outdated. App Store review times are typically < 24 hours and have been for the last couple of years. And KMP makes cross-platform a real thing now, rather than hacking a web view into a native shell, which was always the worst possible user experience.
        • paulryanrogers 1mo ago
          Doesn't KMP assume your team is comfortable working in Kotlin?
          • joenada 1mo ago
            Yes, that's fair. I'd argue, though, that the training required to get your team up and running should be fairly minimal - Kotlin is a very easy language to pick up, especially for people coming from TS - and will pay off dividends in the medium to long term.
          • mike_hearn 1mo ago
            Well, it assumes the model is. KMP can be seen as a token optimization at this point. Business logic is shared and doesn't have to be rewritten in Swift.
          • hn-acct 29d ago
            Plus you’re trading RN problems for gradle and integration problems on iOS.
        • joshstrange 1mo ago
          I'm afraid you are the one out of date here. App Store Review times have ballooned in the last few months. Marco Arment talked about this publically (on the ATP podcast) about how his app was stuck in review for over 2 weeks IIRC and I've seen 2 days as the minimum review time in the last few months with some taking a week or more. Yes, for a while they were doing very well and I even once had an app reviewed in <1hr but the average has been creeping up. LLM/Vibe coding is what is often blamed for this increase though at the end of the day it's Apple's problem/fault for not staffing the review department better.
    • dpark 1mo ago
      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.
    • stephenhuey 1mo ago
      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.
      • 1mo ago
  • fnikacevic 1mo ago
    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.
    • mustafa01ali 1mo ago
      Definitely, we invested in ramping up teams on native before going all in.
  • railka 1mo ago
    Yes, AI have changed the game, and now you can build and maintain two separate projects in Swift & Kotlin instead of one on React
    • deleted 1mo ago
      [deleted]
    • kamaal 29d ago
      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.
      • lysium 29d ago
        Others mention quicker startup of the app, more native-look, less head-ache w/ RN.
      • mcosta 29d ago
        > What you could do with Kotlin/Swift you can do with React Native as well. In theory yes, in practice no. I mean, in theory you can do it in mips ASM and ship QEMU along with the app, in practice it makes no sense.
      • liamgm 29d ago
        Native is fast , no extra layer , the problem is maintaining on every native platform your app available. And AI tooling can handle that efficiently today , not way back then. The problem with xplat is they add extra layer on top of platform native. - React native and similar, add extra js runtime engine. - Flutter and Kotlin MP add extra skia graphics engine. - Skiptools add extra swift runtime - Cordova adn similar add extra browser engine - Etc
    • simondotau 29d ago
      “One React app vs two native apps” is a false comparison. A sufficiently polished React Native app still means two platforms to tune, test, debug, ship, and maintain. It gives you the appearance of efficiency and uniformity, but much of the complexity is just moved elsewhere… including, sometimes, to resource consumption on users’ devices.
  • accumulator 1mo ago
    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?
  • dfabulich 1mo ago
    Did you switch to SwiftUI or UIKit?
  • alexashka 1mo ago
    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.
    • wankerrific 1mo ago
      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
  • nightpool 1mo ago
    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.
    • aprilthird2021 1mo ago
      This is not the author. It's very likely Farhan Thawar, head of eng at Shopify
      • nightpool 29d ago
        Ah, you're right, my mistake—wasn't reading the username carefully enough
• deleted 1mo ago
  [deleted]
• LazyIDE 1mo ago
  [flagged]
• lackoftactics 1mo ago
  I believe this will be overall trend in industry. Dropping React Native and Flutter for native
  • aatd86 1mo ago
    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.
    • organsnyder 1mo ago
      > That would be a huge mistake if we expect many more hardware and OS running them efficiently than just iOS and Android. Is that something we should be engineering for right now?
      • aatd86 1mo ago
        Just like any engineering and business decision, this is a tradeoff. I probably don't see things from the same vantage point. Can't help but notice a trend however. What if this accelerates, especially with AI being an enabler?
    • uncomputation 1mo ago
      How is SwiftUI dated? It uses a declarative model. I don’t see UI framework paradigms shifting that much.
      • aatd86 1mo ago
        It is virtual dom like. We don't have access to a stable underlying element like we would with plain UIKit. You can build declarative models without this virtualdomness. But SwiftUI was created during the react boom so they went with the Zeitgeist, understandably. Now this is somewhat problematic if someone wants to implement better fine grained reactive systems. And I posit that the next paradigm is going to be in that direction given what I've been working on (furthering current reactive systems which only go halfway).
• quotemstr 1mo ago
  The wheel of fashion turns once more.
  • hermitwriter 1mo ago
    srsly
  • nacozarina 1mo ago
    got me spinning like a record baby
  • jmknoll 1mo ago
    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.
• gazarsgo 1mo ago
  Cool story but what's the token spend?
• evilfred 1mo ago
  using React Native you end up having to drop into native code to do anything interesting or optimized, so it feels kind of pointless to not just use the platforms directly
  • bluecheese452 1mo ago
    Most apps don’t do anything interesting.
• asimovDev 1mo ago
  Dropping React and going back to raw JavaScript next? I am still mourning pre-React GitHub. Maybe rose-tinted glasses, but it was so pleasant to use
  • imposter 1mo ago
    [dead]
  • vendiddy 1mo ago
    I would attribute that more to culture. For example https://diffs.com/ https://diffs.com/ is built in React and it's basically instant.
    • bob1029 1mo ago
      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.
      • zelphirkalt 1mo ago
        Which is also, or at least has also been a culture thing, because of the "Oh no, we can't possibly do the computation of all that on our backend! Yikes! Let that run on every single client instead! Let users spend their own compute over and over." culture.
      • vendiddy 29d ago
        But this is way faster than GitHub isn't it: https://diffshub.com/oven-sh/bun/pull/30412 https://diffshub.com/oven-sh/bun/pull/30412 Compare that to this: https://github.com/oven-sh/bun/pull/30412/changes https://github.com/oven-sh/bun/pull/30412/changes I agree there are limitations bc of physics, but I don't think it explains this particular difference.
    • mike_hearn 1mo ago
• kraig911 1mo ago
  A side effect of perceived LLM Generated code is now easier to just make it write native I guess.
• sergiotapia 1mo ago
  Major loss for react native community at large with Skia and Flashlist dying. :(
  • gagabity 1mo ago
    Legend List is the new hotness in RN.
• deleted 1mo ago
  [deleted]
• giebisch 1mo ago
  Their reasoning makes sense. I'd love to read a follow-up and their thoughts in half a year.
  • StrLght 1mo ago
    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 https://shopify.engineering/shop-app-migration It sounds pretty solid, so I wouldn't expect anything to change in just 6 months.
• starlineventure 1mo ago
  Native. Metal. Remove the abatraction layers
  • simonhamp 1mo ago
    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
• 976157424477 1mo ago
  [dead]
• randysalami 1mo ago
  “We debated between gradually migrating to native (brownfield) versus rebuilding them from scratch (greenfield)… However, this time greenfield emerged as a clear winner for the following reasons” “To solve this problem, we built a system called Helix that takes a more gradual approach. It doesn't expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result.” If this is driven by proper engineering then hats off! Supposedly a simpler app has already been migrated and they are working on migrating the main app using this approach. I don’t even know how I can be a cynic here… because the technology is good enough and so are the engineers I don’t know how management or executives could ruin it. “…product quality people expect today. This isn’t just the same apps rewritten in different languages. We’re rebuilding them so both humans and agents can understand, test, and change them quickly.” If this was written using AI and human-edited, you missed a spot.
  • projektfu 1mo ago
    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.
  • codechicago277 1mo ago
    Getting 11% AI on Pangram, which isn’t bad tbh.
• hermitwriter 1mo ago
  I've been around long enough to see this argument come and go under a lot of different names. This time it's AI. Maybe AI really does change the economics. But this post doesn't demonstrate it. Talk to me in a year. The side-by-side comparisons? Whoopty do. It's different code. Of course agents can produce two implementations that look the same today. That's not the hard part. The hard part is keeping them the same. Feature parity isn't an implementation cost. It's a divergence cost. It accrues over years across experiments, analytics, accessibility, edge cases, bug fixes, platform behavior, and a thousand little decisions which current agents aren't great at tracking. Agents can write code fast but they aren't a panacea. The load-bearing sentence in the whole post is this: "Shared specifications, tests, and review checkpoints dramatically reduced the cost of maintaining parity." Okay. For how long? By how much? Got any numbers to share? How will these hold up under contact with customer? You haven't maintained parity yet. You've built prototypes. You're making a claim about a cost that compounds over time based on what it costs at t=0. The other thing missing is the counterfactual. They keep comparing this rewrite to what a rewrite would have cost before coding agents. But what if you point those same agents at the existing RN codebase? If agents make software development cheaper, they make RN development cheaper too. And now you're modifying one implementation instead of generating, testing, reviewing, and reconciling two. The tooling section makes this even stranger. They find that agents are bad at driving simulators, so they pull business logic out of the UI, make it runnable headlessly, and expose a CLI. That's a good idea! Do that! But that's an architecture change, not an argument for native. You can make an RN codebase agent-friendly without rewriting five apps. Then you get to "Preventing slop," which is probably the most important section in the post. Just pointing an LLM at the codebase doesn't work. They had to build Helix, with ordered checkpoints, test proofs, visual diffing, adversarial reviewers, and human gates. So what they've actually demonstrated is that Shopify has enough engineering resources and agent infrastructure to make maintaining two codebases look economically plausible. Maybe it is! For Shopify. That's a much narrower claim than "AI changes the economics of cross-platform development." And where are the numbers? For a post about reevaluating costs from first principles, there's remarkably little cost data. Engineer hours? Review time? Defect rates? Parity failures? Agent spend? Ongoing maintenance? Anything? They even say RN performance isn't the problem. "React Native apps can be fast. Ours are." So there's no product crisis here. No performance crisis. There's an internal cost argument, with no numbers, being used to justify rewriting five apps used by millions of merchants. And in isolation I'd probably just shrug and say: Shopify made a bet. Let's see how it goes. But it's harder to view it entirely in isolation when they brought Tailwind on yesterday too. Shopify used to be one of the great stewards of the broader ecosystem. What worries me about the recent direction isn't any single technology choice. It's the appearance that, following the recent tech leadership changes, we're starting to see decisions driven more by the preferences of the people now making them than by demonstrated technical merit. Maybe that's an unfair read. I hope it is. But posts like this don't help, because if you're going to make a sweeping technical argument for a major change, show the evidence. The part I actually find convincing is much less exciting: Shopify is tired of paying the upstream tax. They've spent years working on RN performance, improving the framework, dealing with dependencies and upgrades, etc. Fair enough. That's a real cost. Being an RN framework developer or dependent is -- or has been -- awful -- it's like trying to fly a kite in a hurricane. The web team has been super disciplined and also ridiculously slow. The RN team changes apis in .. questionable ways with regards to compatibility But it's not new, and it has very little to do with LLMs. And let's not get me started on taking this kind of dependency for your business on companies who still don't have any idea how much to charge for their tools and are all operating (on a per token basis) at a loss. They're swapping some framework dependency for dependency on coding models whose capability, pricing, and terms they don't control. None of this means they're making the wrong decision. Maybe they're right. Maybe in three years this looks obvious. But that's exactly the point. Come back in a year and show me parity bugs, engineering hours per feature, experiment drift, accessibility regressions, review burden, model spend, and how much human work it takes to keep the implementations aligned. Right now they've shown that AI makes rewrites cheaper. Whoopty do.
• yieldcrv 1mo ago
  Perfect, yeah the obvious answer and comment is in the subtitle right at the top. Good way to write an article > Coding agents changed what it costs to build mobile apps twice. Here’s why Shopify is moving from React Native back to Swift and Kotlin.
• deleted 1mo ago
  [deleted]
• Waterluvian 1mo ago
  If you put every company that needs/has an app on a spectrum, there is a line somewhere that roughly divides them into two groups: where Electron/React Native/etc. makes sense or not. It's just a normal engineering decision: solving problems given limited resources. Companies have different problems and different resources. 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. There's some magical thinking borne from ignorance that everyone just ought to go native or that React Native is the best thing ever to be used everywhere or that AI makes this line disappear entirely. I think these takes serve little value and distract from what’s interesting, and what the subtitle to this article says: that this line is moving due to AI. And I think that’s probably right.
  • paxys 1mo ago
    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).
    • embedding-shape 1mo ago
      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.
      • collabs 1mo ago
        In my experience it comes from the business and people who think if we need to touch the same code twice in the same month it is somehow a moral failing of some kind.
• pzo 1mo ago
  Wish they explained more. Even though I'm mostly native iOS its seems react native is better stack for AI and iteration (hot refresh etc) - the main reason pretty much all AI vibecoding app were implemented via expo/react native. I also believed that finally this year react native got mature enough with improved tooling and performance to the point that it started to being 'boring' technology.
  • PKop 1mo ago
    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 https://shopify.engineering/shop-app-migration
• atonse 1mo ago
  We did the same thing - had 90% of it overnight. Then spent a few days in the background tweaking for polish. Our app is smaller, and has about 15-20 screens. I started at about 12:30am by giving codex a goal and it inventoried every screen based on the react native code, then created android and iOS directories, used maestro (I had already set up this tooling for a previous personal app build a few weeks prior), and had the whole thing working in android and iOS in the morning. Took it about 6 hours while I slept. The app is way smaller, launches instantly, and the android app is (supposedly) native looking. I say supposedly because I don't use android phones. But it's using Jetpack Compose and Kotlin. And I don't know Swift or Kotlin. I honestly don't see the point of React Native anymore. I know Expo is doing very cool agentic stuff, but I'm just not sure why I'd need any of it when I can write a native app.
  • greenowl 1mo ago
    And people say AI isn't taking SWE jobs...
    • mattm 1mo ago
      This is a type of project that likely wouldn't have been done before AI
      • eleventen 1mo ago
        Of course it would. Supply and demand. Some companies would decide not to bother. Others would decide it was worthwhile. The limited pool of supply (app developers) would be distributed across demand.
        • enraged_camel 1mo ago
          >> Some companies would decide not to bother. Others would decide it was worthwhile. The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost. So companies that would have shied away from projects like this pre-AI are now pulling the trigger without much hesitation.
• railka 1mo ago
  IMHO, now is a great time to use native Swift/Kotlin code alongside shared Rust code via UniFFI
  • rvz 1mo ago
    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.
    • massel 1mo ago
      It's a lot nicer than having the same logic in 2 languages and trying to keep them in sync – whether doing it by hand or with an LLM. One of the big rules is don't repeat yourself – much of the logic only needs to be written once (except UI)
      • rvz 1mo ago
        In that case, Kotlin makes even more sense especially with Kotlin Native, and Rust is unnecessary. Kotlin is already multi-platform and can be re-used as the business logic in iOS apps with Swift as the UI and the Android app with a Kotlin UI (Jetpack Compose) or both iOS and Android apps can be written entirely in Kotlin. That vastly reduces the maintenance and Kotlin is reused across all apps and keeps it at 2 languages at most. No need to introduce Rust to achieve the same goal.
      • doc_ick 1mo ago
        Well you don’t repeat yourself if the llm repeats it for you at the cost of millions of tokens.
      • mike_hearn 1mo ago
        Rust is uncompetitive for the use case of sharing logic between mobile apps. Kotlin has Swift interop and KMP is a mature tech by this point.
        • 1mo ago
• faangguyindia 1mo ago
  React Native is slow. Hermes VM doesn't even have JIT. If the majority of your app is native code and only a few places are stitched together via JS code that runs in the Hermes VM, then React Native is suitable for you. Look at V8 vs. Hermes performance. We use Flutter; we rarely need to write native code. We have three apps: Symbiote workout app, CalorieCodex, an AI calorie tracker app, and MacroCodex with 17,000+ users, all of them completely free
  • hermitwriter 1mo ago
    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
    • flakiness 1mo ago
      mind sharing a link or two on the native code generation bit? I'm far behind from the scene but still curious.
      • cyberax 1mo ago
        They probably mean that modern RN apps can now use a lot of native widgets. You can look at https://docs.expo.dev/versions/latest/sdk/ui/universal/ https://docs.expo.dev/versions/latest/sdk/ui/universal/ There's also a project to add a static JS compiler, but it's been in development hell for the last 3 years: https://github.com/facebook/hermes/tree/static_h https://github.com/facebook/hermes/tree/static_h
    • cyberax 1mo ago
      It's not. RN has always used native widgets (with a custom renderer) but the JS code itself is purely interpreted. They increased the interpreter performance by quite a bit, but JITs are impossible on iOS, so it can never be fast. We have a RN app that needs to do a lot of geometry processing and things like polyclip are unbearably slow, so we had to add native modules to accelerate them. The web version with a true JIT works just fine.
• roshanabdullah1 1mo ago
  the reason what I believe is that, AI can understand react very well. so It can be beneficial for Shopify
  • hermitwriter 1mo ago
    100%
• ex-aws-dude 1mo ago
  I don’t understand why building an app twice is a big deal in the first place if that’s a core part of your business Like wouldn’t you want to invest in platform specific expertise long term? It’s not like this is a small company or it’s just a dinky side project off of the main business
• pkaler 1mo ago
  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. Teams jump on the latest cross-platform framework assuming that it will reduce headcount cost at the expense of having a lowest-common denominator app on each platform. The latter is true but the former is false. What ends up happening is that teams start as 20 iOS engineers & 20 Android engineers. They adopt something like React Native. Then you end up with a team of 20 product engineers and 20 tooling and framework engineers. I've seen that countless times in the last two decades.
  • lcfcjs6 1mo ago
    [dead]
  • vsviridov 1mo ago
    Pretty sure I've seen you either at B-Sides or Polyglot... Small world...
    • pkaler 1mo ago
      I'll most likely be at Polyglot. I did a very small part to help organize one of the very early ones.
      • vsviridov 1mo ago
        I'm looking forward to the next one in October.
  • woah 1mo ago
    > 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?
    • FLeXMurphy 1mo ago
      We practically heckled and threw rotten tomatoes across it at each other.
• iamgopal 1mo ago
  when you are large enough to allocate sufficient resource, you should go native, if not, go flutter/react native etc. Its very simple decisions I guess.
  • SV_BubbleTime 1mo ago
    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?
• seanhly 1mo ago
  Bragging about "using agents to code pre-GPT" is quite the corporate flex... weren't they notoriously bad back then? Might as well say, "We've been doing spreadsheets with quantum computing since 2016"
  • mike_hearn 1mo ago
    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.
    • Delgan 1mo ago
      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.
      • mike_hearn 1mo ago
        Ah, that makes more sense.
  • keeda 1mo ago
    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-science-and-ml-tasks-ultimate-review-c8bcbefb928a 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.
• mcsniff 1mo ago
  I use Shopify app every day, multiple times a day to run my business and it has always been buggy and inconsistent for me on Android, and I don't expect this will make it any better, especially with more AI in the mix, but we shall see. Who wants to bet there still won't be a dark mode?
• negative10xer 1mo ago
  I remember their blog post claiming how much of a win it was to move over to react native and maintain high performance. They even listed their performance metrics. At that time I was a mobile developer for an e-commerce business and the metrics they were proud to share were unacceptable on our native apps. Here they are coming full circle
  • schrodinger 1mo ago
    Before and after LLMs.
• psadri 1mo ago
  Thanks to coding agents, there is no reason not to
• aurareturn 1mo ago
  How long until LLMs just write machine code?
  • MattDamonSpace 1mo ago
    Direct 1s and 0s
  • _flux 29d ago
    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.
  • desterothx 29d ago
    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.
    • _flux 29d ago
      What actually might could make sense in the future would be super-dense but abstraction-able programming language made for models. Then you'd train the model to work with it and you could have a way to render a human-readable version of the program for introspection. It preferably come with superior guard rails, so strict static typing, borrow checker if not gc, perhaps ability to state proofs, etc.
      • aurareturn 25d ago
        I can see this as the start of some sort of AI take over scenario. If there is no realistic way for a human to 100% verify what the code is doing, how can we 100% trust what the AI tells us the code does?
• rvz 1mo ago
  Agreed, the whole of the Javascript / TypeScript ecosystem has caused a slop hellscape of workarounds, half-backed fixes and have exposed short-comings in the ecosystem. Perhaps these languages do not work well as they are not designed to run efficiently on mobile devices. Now that we have libraries such as SwiftUI and Jetpack Compose, React Native no longer makes sense to use. Now we should also move away from Electron to better alternatives such as Kotlin Multi-Platform or fully native libraries on each platform; because of LLMs.
  • hermitwriter 1mo ago
    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.
    • simonhamp 1mo ago
      Hallelujah! One other person in this place gets it: "fewer tokens, faster progress" Electron, Tauri, React Native/Expo, Flutter (and countless others) are the wrong kind of abstractions, built for a time pre-AI, solving pre-AI problems We need a new post-AI abstraction that embraces this opportunity! That's why we're building SuperNative
• aecorredor 1mo ago
  The most interesting part to me here was the whole helix thing + how they split business logic and UI just so AI agents could drive/test state via a CLI. I hope they do a deeper blog post on just that. I’m surprised they are making “decouple state from UI” sound like something groundbreaking when that’s kind of been the foundation for any sane/testable app for a LONG time.
• running101 1mo ago
  I suspected we would start seeing these types of blog posts. Code is becoming low level, where people do not care what language, it is written in anymore. The cost of moving from one to another is becoming low.
• jasonmp85 1mo ago
  [dead]
• MaoSYJ 1mo ago
  Who could have guessed it!
• philipwhiuk 1mo ago
  I guess expect no new features on mobile until their token budget gets through all the screens?
• BatchJob 1mo ago
  im not a fan of react native per se , but this reasoning does not add up. they are going to "delete an app" because they got some LLM to slop out 2 apps? The architect who wrote that is batshit and will be unemployed after this blows up in his face.
• basepurpose 1mo ago
  if native became easier to tackle with coding agents, react native would have been even more easier to scale. this decision doesn't sit well with me.
• larodi 1mo ago
  Truth is the Shopify app is simple enough to get right by a model. Lots of things hare simpler to get right in native code, so it is to be reiterated - a lot of interpreter code/libs is going down the drain, along with the devs that write it. These are not needed anymore. And, in all honesty, the difficult part with many projects is the bootstrap, the scaffolding, not the continuous dev. Agentic dev. made this a piece of cake.
  • aprilthird2021 29d ago
    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
• philipwhiuk 1mo ago
  > It doesn't expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result. So... local maxima?
• ecshafer 1mo ago
  They don't say anything in the post. But hotwire native supports pushing ui elements to ios and android. I imagine that might be part of the reason. I haven't built anything substantial with hotwire native though so I am not sure on all of the edge cases.
• bearjaws 1mo ago
  We made the same change for our patient app last month, took 2 months to rewrite from react-native to two mobile apps, but we had the PoC in under a week. Interestingly Apple approved it very quickly, which I was afraid of given such a huge rewrite.
• rietta 1mo ago
  The promise of React Native was easing development burden from the web app to the native app. It makes sense if they are just using coding agents to cut out the framework and just go native. That was my thought when I saw the headline and then reading the article confirms this is the inflection point per their own words. Very interesting.
• underdeserver 1mo ago
  And I'm just sitting here looking at the Codex desktop mac app wondering why a list, a chat window and textbox require a 579 MB download (compressed) and 4 GB of RAM.
  • Nathanael_M 1mo ago
    An entire copy of libreoffice, for one.
  • simonhamp 1mo ago
    I'm working to solve this...
• ChiperSoft 1mo ago
  Before I even opened the article I knew the reason was because LLMs don't need abstractions. React Native was always about making app construction easier for people who don't want to learn ObjC or Swift. If you're not writing or even reviewing the code yourself, this is unneeded overhead. For a while I've been wondering why people are even bothering with high level languages if you aren't even gonna read the code.
  • rando0987 1mo ago
    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.
  • thi2 1mo ago
    > 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.
• 1saadcodes 1mo ago
  What I find interesting is how AI has changed the cost of maintaining two native apps enough that a decision that made no sense a few years ago is worth revisiting now
• vanillax 1mo ago
  [flagged]
• nielsbot 1mo ago
  When companies can afford to build a native app but instead use a WOSE (write once suck everywhere) toolkit, it’s because they don’t care about the user experience.
• m_sharma 1mo ago
  As things get more complicated and you need to worry about performance, where every millisecond counts, it makes sense to go to native: React Native and Flutter. These kinds of technologies are really good in terms of building faster and building one app which can work across. Where that deep performance might not be of a bigger concern, or you need to go build components natively and then expose them through React Native. I think, with AI, now building even a native app is faster, so moving back to native can make sense if you have a team which can understand how things work.
• crossroadsguy 1mo ago
  Few of the biggest reasons for "migration" to the likes of React Native, and web-views et cetera, were "lack of talent", and not getting that talent fast, and for cheap, et cetera, while of course terming that as innovation, embracing the future, and "that's where the game is at" et cetera. Now with the LLMs that is mostly sorted. So if anything I'd be able to see the eradication of the Electron infestation in my lifetime. But then I see the very tools these LLMs are accessed with i.e harnesses (and of course mostly made by the LLM houses) are made of Electron or similar things (sometimes a Frankenstein like mix). And even today Claude Code shows up as `2.x.yyy` for process name ffs! So if anything, this is getting worse. Then they say: > We decided to switch from native to React Native in 2020 for three reasons: > Stop building the same features twice > Allow developers to work across the stack > Spend less time chasing feature parity and more time shipping value Totally! Is there some kind of shame in just saying: - we didn't want to hire more people - we didn't want to pay those salaries - we fired a lot of engineers with move to react native/hybrid in mind - we could reuse the frontend devs (aka "full stack" folks) with or without some extra whippings ensuring they grok the bare minimum they'd need to build for mobile and test in on mobile.
• nshelia 1mo ago
  The rendering layer and APIs differ significantly between iOS and Android. Agents currently do not know how to test the UI, at least in my experience. I would be scared to do that migration right now.
• theycallmeritik 1mo ago
  Good one
• koeliga 1mo ago
  https://shopify.engineering/shop-app-migration https://shopify.engineering/shop-app-migration follow up with some more technical details and benchmarks
• shawabawa3 1mo ago
  "native" shouldn't be capitalized in the title
• netshade 1mo ago
  I agree w/ advising people to move off React Native, though I think the story that "LLM enabled an otherwise too-expensive migration to consider" is not correct. I say this because I was part of a migration from a mid-size React Native app to a Swift/Kotlin native app redo. I did the majority of the technical work on it. The majority of the work occurred before January 2026 and without LLM code assistance, though later features in the app definitely used some. For anyone considering this, I'd say that the migration is definitely worth considering without even taking LLM assistance into consideration. The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line. It's pretty wonderful to be back in the world of "build, compile, ship, be sure". One thing as a fundamental principle that I think the Shopify article 'gets' at, is the importance of the feedback cycle - investing time in our integration test story very early on both helped w/ my cycle times, and later in providing guardrails for LLM assistance. All to say that this decision is worth considering without even taking LLM assistance into account.
  • zero_shift 1mo ago
    > 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
    • sunaookami 29d ago
      It's still like this and now they release new versions and breaking changes way faster. Not to mention they nudge you to Expo now and outsourced nearly everything to other (outdated) dependencies and companies. Stay far away from RN if you value your sanity, it lead to my burnout.
      • nwienert 29d ago
• gadflyinyoureye 1mo ago
  Out of curiosity why not look at Flutter? I know you don't get native look-and-feel, but most apps are branded who cares?
  • simonhamp 1mo ago
    > you don't get native look-and-feel You answered your own question
• rramon 1mo ago
  Missing out on flawless App Intents integration could be business risk for Shopify once people get used to doing everything from a central chat interface, including shopping. I guess it's the real reason for the switch.
• krttherealest 1mo ago
  this AI stuff is goin crazy
• BringItBack 1mo ago
  Makes sense in the LLM age. With cheap/fast code, it's easy to support multiple software stacks since most of the abstract engineering problems are already solved. Code - especially straightforward low-level code - is so cheap and easy to write now that some people are building their own version control systems, game engines, and other low-level tooling. Thus, some of the most demanding, human-centric work in software dev right now - where we now spend more time than coding - is in technical PM, UI/UX, devops, and overall architecture. The decision-making and design aspects of the job. Exciting times.
• uncle_kostya 1mo ago
  An Android developer since 2010 here. I've always been wary of React Native, because my impression is that it hides nuances of the underlying framework. You may be fine implementing 90% of your app but then need that last 10% and may get stuck. But then I'm also wary of the recent trend by Google to create higher level frameworks on top of native Android APIs. It seems that these days for every Android API family, there is a Google framework that gives you a higher level API. I don't really understand it - is Google admitting that the quality of native Android APIs has eroded? Do they think developers are too inexperienced to deal with native Android APIs? I'm also not sure I understand the how reasonably large companies consider two native apps to be too expensive. A startup may have a hard time funding both and may need to choose, but an established business should consider not only costs but also the better quality of user experience that native apps provide - that has to count for something.
  • tcoff91 1mo ago
    It's incredibly easy nowadays to drop down to native from react native where you need to.
• WhereIsTheTruth 1mo ago
  If you build with electron in the age of LLMs, you should change career
• romanovcode 1mo ago
  It's not surprising. Code is cheap nowadays because of AI. I reckon more companies will follow suit.
• tonymet 1mo ago
  Let’s see their app size (and heap)
• weightedreply 1mo ago
  Isn't it silly that this even needs to be a conversation? Shouldn't we be able to write in any language we want and have the bindings for it to work cross platform? And shouldn't AI aid in building those cross-platform tools? Maybe React Native isn't the right choice - but two tech stacks for virtually identical interfaces is dumb. Three stacks if you include browsers.
• tzone 1mo ago
  With latest AI models, we will most likely see shift back to just fully Native apps even for smaller teams. This is type of stuff that AI models do really well, if you get a particular feature or even a bigger app change done in one platform, you can just tell Opus or Fable to replicate to the other platforms and in almost all cases it will just do it as well as most human teams would have done it.
• jeffrallen 1mo ago
  Too late. My kids called the app Stop-ify because it was so unreliable. Switched to Apple music and won't go back. On Android!
  • SV_BubbleTime 1mo ago
    I think you’re confusing Shopify and Spotify.
• polloRebozado 1mo ago
  I have not coded any mobile apps, I understand the downsides of using react native/electron due to them being web apps but what about things like Kotlin multi platform or flutter? Aren't this frameworks supposed to allow your to have 1 codebase and the apps be truly native instead of web apps?
  • wilsonnb3 1mo ago
    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.
  • zelphirkalt 1mo ago
    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).
• gargs 1mo ago
  What I want to know is if the agents are so good that they can convert React Native code to native with amazing efficiencies along the way, what's stopping them from improving React Native itself?
  • bakugo 1mo ago
    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.
• robofanatic 1mo ago
  this motivates me to rewrite my Flutter app in Swift. I gave up on deploying the app to Android because of their 20 testers requirement at that time (not sure if its still true).
• iBelieve 1mo ago
  It's interesting that they don't mention Kotlin Multiplatform or any sort of shared core logic between their iOS and Android apps. Seems like maybe the apps are fully independent codebases but with shared specifications and tests? They say that agents: > Dramatically reduced the cost of maintaining parity between platforms through shared specifications, tests, and review checkpoints I've used Kotlin Multiplatform on a mobile project built back before AI coding took off, and it was super nice to have shared core logic between the apps and there weren't really any downsides on the Android side, but on the iOS side it was definitely an extra layer that didn't feel fully native.
  • cosmic_cheese 1mo ago
    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.
    • tcoff91 1mo ago
      I work on an open source app that uses a shared swift core for the iOS and android apps and I think it's awesome. I think having all your business logic in swift is great. 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.
• timedude 1mo ago
  This is what happens when you have too much cash on hand. You start wasting it and doing dumb things. Like rewriting entire apps in two different languages.
• parentheses 1mo ago
  The underlying problem is that it's difficult to make a principled decision. So, it's ripe for SEO mining and such fuzzy takes happen. The meta point of the article, I agree with though. The line is moving and AI makes having multiple platforms with code specific to them faster. Getting them right is still difficult.
• Nc67 1mo ago
  [flagged]
• xyst 1mo ago
  Can’t wait for the blog post mentioning move back to react native or other cross platform framework.
• deleted 1mo ago
  [deleted]
• tonic_note 1mo ago
  Models have gotten a lot better at generating native iOS apps. The main appeal of RN was being able to leverage your web devs for mobile dev. that's what I did at my last company. And it's fine for a startup, but eventually you want dedicated native engineers bc each platform really deserves its own technical masters who can optimize for it. 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.
  • robertlagrant 1mo ago
    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.
    • dd8601fn 1mo ago
      > 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.
      • robertlagrant 1mo ago
        Hello! As I'm on Android, thank you for your service.
  • _fzslm 1mo ago
    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.
    • 1mo ago
• ergocoder 1mo ago
  A companies with thousands of engineers should simply go native. Write once, deploy everywhere like React Native mainly benefits small teams and startups who are okay with building 90/10 solutions. At the shopify's scale, they would want to go advance for every corner of the apps and use cases, and only native allows that.
  • SwellJoe 1mo ago
    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.
• mt_ 1mo ago
  The article failed to provide reasons on they why move back to native.
  • mt_ 1mo ago
    Other than LLMs can do it tokenmaxxing exercise.
• bilater 1mo ago
  This is obvious in hindsight. I expect most companies that move fast and care about performance to abandon React Native. Code is cheap now, and the tradeoff of having a single codebase and only hiring React devs basically isn't there anymore.
• m3kw9 1mo ago
  They are admitting React was a shtty choice for a mobile app if they have a choice.
  • SV_BubbleTime 1mo ago
    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.
• jnwatson 1mo ago
  In the history books, this'll be the post indicating the end of writing code as a professional occupation.
• manlymuppet 1mo ago
  This is probably one of the things that excites me most about AI. Companies can now just afford to maintain a hundred different native apps, rather than settle for a write once, run anywhere approach.
• thisismyopinion 1mo ago
  Would be nice if Spotify and Notion did the same.
• jrochkind1 1mo ago
  I'm not totally following the part about the simulator(s), probably because I haven't actually done mobile development before. > When simulator interaction is needed, the CLI can connect to them via a remote mode and drive the UI via commands without having to inspect the layout or the accessibility tree. This enables blazing-fast performance and E2E tests. I think I'm not following. Don't you still need to test the accessibility tree and layout in the actual layer the user will interact with?
  • raspo 1mo ago
    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?!
    • jrochkind1 1mo ago
      indeed it's not totally clear to me if they do or not, my question too! OK, good to know it's not just something I was confused about because of lack of context!
  • azuanrb 1mo ago
    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-system-tests https://guides.rubyonrails.org/testing.html?#when-to-use-sys...
    • jrochkind1 1mo ago
• dev_l1x_be 1mo ago
  Native is the new React?! I could never drink the React Native cool aid due to background in performance optimization. Agents gave us the way to go native with less effort. Compilation is a good feedback loop for the agentic workflow as well.
• w10-1 1mo ago
  Most of the costs of switching have yet to be borne: user issues with untested code, maintenance issues with code few understand, and the strategic dependency on coding LLM's, which will change in character after providers go public and need revenue to fit reasonable stock multiples. All only get worse with time unless they're addressed proactively.
• madduci 1mo ago
  The article itself comes from AI ? It says twice why they switched from Native to React Native in two distinct paragraphs at the beginning. The rest sounds also AI slop jargon.
• AJRF 1mo ago
  Most large tech companies are just job programmes, i've seen so much effort, time, cost go into things that are truly unimportant. React Native gives you (with asterisks) - one "source" for things to go wrong (as it sits on top of the native implementations of the UI + Native APIs). You are writing at that source level, and that filters down to the native builds. I am WELL aware to do certain things on each platform you need to get your hands dirty, but most apps are just serialising JSON from a database and displaying it. AI writes very buggy, sloppy code. They've decided - instead of containing that code to 1 surface, they would now have 2 surfaces they throw slop on top of. I look forward to the 2027 version of this where they've gone back
  • tcoff91 1mo ago
    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.
• vmg12 1mo ago
  React native isn't a terrible idea, its fundamental issue is that Apple does not allow for JIT compilation on iOS. So that means your app's js logic will be an order of magnitude slower than what you would get in the browser.
• muddi900 1mo ago
  It is the "why use python" for mobile. The native apps will definitely be better in terms of performance and UX. However, having 2 codebases means twice the tokens.
  • vmsp 1mo ago
    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.
  • vmg12 1mo ago
    The problem isn't tokens but verification that the code works.
    • muddi900 1mo ago
      If you have enough of a budget, you can ask your agent to spawn two subagent to do independent audits of "your" work.
      • vmg12 29d ago
        This just doesn't actually work in my experience.
• Hamuko 1mo ago
  I'm certain that small startup Shopify could not afford to build native applications before AI became a thing. Thank god Sam Altman stole all the information in the world so that small family companies like this can finally have software too.
• synergy20 1mo ago
  wow, what about electron.js the bloated cross-desktop GUI, can LLM either totally modernize wxWidgets(to avoid Qt's license mess), or create some light-weight cross platform GUI widgets to make GUI easy on windows/macos/linux that is not resource heavy?
  • mike_ivanov 1mo ago
    wxWidgets carries too much legacy. A GTK3 fork maybe? Or a functional clone of QML with some improvements.
    • synergy20 1mo ago
      maybe gtk4 gui first then ask llm to recreate them natively on windows and macos
      • mike_ivanov 1mo ago
        no, not gtk4 - they lost their way after v3
  • simonhamp 1mo ago
    Working on this problem for the next version of NativePHP Desktop. Have dropped Electron entirely
  • amedvednikov 1mo ago
    https://github.com/vlang/ui2 https://github.com/vlang/ui2 does just that
• jgwil2 1mo ago
  I wish more companies would just focus on webapps. It's infuriating how many services try to push an app on you when it's completely unnecessary. The other day I went to a restaurant that had an app. Not a fast food chain, a nice full-service place. No, I'm not going to download an app to order dinner.
• AtNightWeCode 1mo ago
  Why on earth is Shopify not just a web wrapped in an app like most apps? I mean, they implement most of that stuff for the desktop anyway.
  • CodingJeebus 1mo ago
    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.
    • AtNightWeCode 1mo ago
      Google research from a decade ago that might as well been that their bot did not want to wait for pages to load. The performance difference between React native and a web wrapped in an app is pretty much zero today.
  • simonhamp 1mo ago
    Seems like you've never had to worry about accessibility in hybrid apps...
    • AtNightWeCode 29d ago
      We booted react native like 10 years ago and there is not much a web does not solve. We even did solve it for the desktop users anyway even before. A simple app as Shopify with mostly static content should not be any problem to build as a web.
• maltyxxx 1mo ago
  [dead]
• simonhamp 1mo ago
  As the builder of a post-AI, cross-platform native app building framework like React Native, I 100% believe this to be a backwards move. I've written up a load of thoughts about that here[1], but in summary for the Shopify case, they're basically going to be spending a ton more than they have to by switching back to multiple apps and I'd predict another swing back to better cross-platform tooling in the coming years. [1]: https://nativephp.com/blog/why-not-write-it-twice https://nativephp.com/blog/why-not-write-it-twice
  • IshKebab 1mo ago
    > 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.
    • simonhamp 1mo ago
      More code means more people. That's not peanuts
      • IshKebab 1mo ago
        The whole point of this article is that it doesn't. Or at least for the same number of people you can now have way more code.
        • simonhamp 1mo ago
          Is more code the right goal?
          • IshKebab 29d ago
            No. The point is that the goal (slick native apps) isn't blocked by the fact that it needs more code.
• trynotsober 1mo ago
  The shared specs and tests seem like a big part of making this work. I'd be interested in a follow-up after a few months of shipping new features on both platforms. Does keeping behaviour consistent still take much coordination, or have the agents reduced that work too?
• canto 1mo ago
  So, instead of paying humans twice for the same thing, Shopify will pay corporations to burn the planet a little bit more, waste water and energy - to build the same thing twice. Just because. There's no tech reason to do it. "LLMS are better now". There's no low level optimisations, no blockers, no app shortcomings, it's a shopping app for Christ sake. Instead of optimising, creating more with less, they will create the same with more. Yeah, that's smart. Super smart.
  • shawabawa3 1mo ago
    > 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
    • throwaway613746 1mo ago
      [dead]
    • canto 29d ago
      and only 23% on iOS. Now while those can initially seems significant, it's still a web app, doh, a web page, that loads non deterministic stuff. Even in their tests, the page that loads native vs RN is simply... different. Different things take different time to load, yeah, who would have though. Not even mentioning that this "performance" is only app startup, lol. Ah, sorry, my bad, 120fps when browsing items on the web. Don't get me wrong I don't have anything against AI, I'm a heavy user myself, but refactoring everything just for the sake of it and bragging on HN with little to no tangible effects - that's a whole different story.
  • gvv 1mo ago
    quality ragebait
    • canto 29d ago
      yeah, apologies, i shouldn't be doing that but it's just... doh
• firemelt 1mo ago
  expected
• LelouBil 1mo ago
  There's Kotlin Multiplatform too, you can either have the UI for IOS also done in Kotlin, or just have the logic shared in Kotlin and make the IOS UI in Swift.
• moomoo11 1mo ago
  i think many ppl don't understand this news IMHO... if you have a large org, a large app, lots of revenue and $$$ and resources... it makes sense to do fully native now. if you're a startup, you don't have the resources and $$$, you stick to RN you can obviously have AI maintain both, but that is a cost. double maintenance = more $$$ on tokens so many people are being doomer about this, but most people are also not Shopify
• lmf4lol 1mo ago
  Yesterday, just before bedtime, I pointed Astra at our Electron Desktop app, and asked it to write me a native Swift app for iOS. The electron app has 750 unit tests and 50 something integration tests. It also had access to the electron app via mcp and could click around and inspect it. I also gave Astra read only access to the backend code. It worked for 3 hours and delivered a nearly feature complete port. Today, I found in manual testing 3 bugs and 1 performance issue, all of which it fixed afterwards. To fix the performance issue , it made several different builds and profiled them with Xcode. At around 12:30 I had a full native app port of our product on my iPhone and iPad and could show it to my crew. It even did portrait and landscape correctl! Needless to say, that I was flabbergasted. On one hand, I love it , I can build now all those cool stuff, but on the other hand, its a complete devaluation of my craft. I kinda tell myself that I was still the one setting up a proper env for it and that not everyone can do it. but thats coping. Freaking coping… and I know it
  • hollowturtle 1mo ago
    psychosis
    • lmf4lol 1mo ago
      what? why? Do you say I made this up?
  • xandrius 28d ago
    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.
• trencedamp 1mo ago
  In my limited experience, in h2 this year, LLMs were kind of shit at building Mobile apps. I had to switch TO react native because the flutter app it built me was a horrible buggy mess and I couldn't debug it myself because I don't speak dart. At least with react native I can kind of get in the weeds if needed
• shevy-java 1mo ago
  That also means that ruby becomes less important in their (rails) stack since they move to Swift and Kotlin specifically. Quite interesting considering problem-man DHH ("why are people upset at me shooting at wolves and comparing this it to Roma and Sinti" - and even aside from the connection on his blog to humans, I don't think everyone agrees at gunning down wolves in the first place) is part of the Shopify bromance team. In hindsight that also explains why they laid off so many ruby devs in the last two years. Now if only someone could have told the ruby core team that companies pursue their own interests ... perhaps then they would not have led to the fiasco about a year or so ago. (And prior to that, the silly 100k downloads restriction at rubygems, aka "after that point we no longer allow you to remove your own code", whereas Microsoft github has no such restrictions in place. What are these people smoking?)
• mkhalil 1mo ago
  A multi-billon dollar company dropping quarters (performance/ux) to pick up pennies (development savings from not maintaining a native app) never made mathematical sense to me. [ aside: Meta founded the development of RN and they don't even strictly use it; plus, any troubles/hacks they need, they can make to the Framework itself ]
  • simonhamp 1mo ago
    What if you could have both great performance and UX for each platform AND a single codebase?
• vyftec_wpsec 1mo ago
  [flagged]
• BatchJob 1mo ago
  This article makes more sense if you remove the self congratulatory verbiage from it, and the cost rationale which I believe is zero. Most orgs used REACT native becuase they simply didnt have the interest or talent to build mobile apps using native tech. Many many companies outsource the entire thing for the same reason. So NOW that its been many years, and LLMs are there to help them they arent simply AFRAID to build a native mobile app anymore. Thats the entire article. The rest is utter nonsense and bullshit.
• j45 1mo ago
  Its interesting that the move is back to native and not towards a technology better suited to delivering the same experience on multiple devices from one codebase.
• hollowturtle 1mo ago
  Does that mean no more react native skia sponsoring?
• cdnsteve 1mo ago
  I've been out of FE dev from awhile, is React still leading? I feel like Vue might be taking over?
  • mplewis 1mo ago
    React is still king.
• ICHx 1mo ago
  While Meta's Whatsapp just dropped native Windows client for Electron Lack of vision?
  • seabrookmx 1mo ago
    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.
• vladkens 1mo ago
  Lol, they bought Tailwind CSS, freaked out, and decided not to touch it at all.
• yes1would 1mo ago
  Reminder that Shopify's CEO and COO are both literally Nazis and they host websites for literal Nazis.
  • profdevloper 1mo ago
    What, exactly, is a "literal Nazi" -- I think Tobi is German, but he seems more like a capitalist than a national socialist. /shrug
    • yes1would 1mo ago
      https://drewdevault.com/weird-guys/#lutke https://drewdevault.com/weird-guys/#lutke Literally a Nazi. His best friend and the COO is the founder of the Canadian equivalent of Breitbart, and also, they hosted the store for Breitbart...
      • SV_BubbleTime 29d ago
        So literally not Nazis… but you have been programmed to go to extremes in any political disagreement. I suspect they are both better informed and likely better members of society than you giving evidence of.
        • yes1would 28d ago
          Did you read the article? Or like, even google it? Because yes, they are 100% literally Nazis.
          • SV_BubbleTime 28d ago
            Did I read some loser’s blog about how some not-Nazis are totally-Nazis? Nah, miss me with that clownshoes moron shit. Grow up and join the real world anytime.
            • yes1would 28d ago
• keithnz 1mo ago
  This is exactly the decision we have made (though we didn't start with native). It just makes a lot more sense to make native apps and customize to take advantage of different native capabilities. AI essentially makes this a lot easier, and the end result just feels a lot nicer.
• blendergeek 1mo ago
  I first learned about the shopify app when I saw a purple "shop" checkout button. Next, I got an email saying that if I wanted to track my package I needed to download an app. No thank you. I don't want your app on my phone. I don't want to browse other stores in the shop app. I want to see my package and its status without enjoying a new "social shopping experience" or whatever. I now avoid buying things from anyone who use the dreaded purple "shop" button.
  • fHr 1mo ago
    true absolute cancerous bs
  • throwaway613746 1mo ago
    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.
  • Gigachad 1mo ago
    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.
  • profdevloper 1mo ago
    [flagged]
• jadar 1mo ago
  I forsook RN years ago. I am not a huge fan of the JavaScript ecosystem in the first place, and the UX of RN apps is not the best. Instead, I adopted Kotlin Multiplatform (shortly after their memory management overhaul). I haven't been disappointed. As coding agents have come along, they are really good at writing both Swift and Kotlin, and I get to write all the business logic once. UI can either be shared with CMP, which is quite good, or platform-specific.
• MoE2 1mo ago
  [dead]
• petegleeson 1mo ago
  Surely the decision comes down to whether they have the expertise to build native apps. I know JS and I know models still write a lot of garbage JS. I don’t know Swift so a model writing Swift all LTGM. Garbage is still there, I just can’t see it. The solve isn’t another agentic harness. I need to learn more. Lots of faster/cheaper justifications. I believe that part. If the quality bar is “web devs prompt models” then that’s a worry.
• ernsheong 1mo ago
  It seems like Shopify has fallen into a trap thinking that more complexity costs nothing because of AI. In the age of AI we have to embrace the same principle as before that complexity needs to be tamed, not multiplied. Even as humans struggled with complexity, from what I see now AI struggles very much the same. Hence I don't think this will age well.
  • tonyhart7 1mo ago
    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
    • ernsheong 1mo ago
      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)
  • meowtimemania 1mo ago
    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.
    • gib444 29d ago
      I'd say that was even a goal of the AI companies. It's not in their interest to generate human-maintainable code
      • bcjdjsndon 29d ago
        Aren't there open models you can get for free? What are their intentions?
        • 29d ago
• fhub 1mo ago
  I had one feature in RN and the rest properly native. The day I realized agents were good, I ported that RN to native. Monkey-off-back moment.
• hectdev 1mo ago
  As an iOS Engineer that has been fighting the battle against every C-level type who brings up the subject of a shared codebase my whole career, I feel very validated.
  • dshprobe1111594 1mo ago
    [dead]
  • oofbey 1mo ago
    If only LLMs had been invented at the beginning of your career, you would have been right all along!
  • hackernud3s 1mo ago
    I don't see why you would, unless your argument for your whole career has been that LLMs make this easy.
    • winrid 1mo ago
      probably because every react native app they've used feels like shit
    • hectdev 1mo ago
      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.
      • ronsor 1mo ago
        They're right when it makes business sense, which is also about cost and why Shopify didn't do it before.
        • hectdev 1mo ago
          I'm not arguing the business sense. Two sides can be right which is why I advocated for native development. Which is vindicated here.
• Quarrelsome 1mo ago
  oh fuck my life, we're back to this circa 2000 default of having incompatible binary UIs frameworks across various different platforms, with different OEMs shitting the bed at various different times and Apple free to arbitrarily force its hardware and OS into CI. I felt we were so close to unification in 2011. And that's not even discussing the heresy of app stores. Curse smartphones for ever happening.
• animanoir 1mo ago
  [dead]
• dools 1mo ago
  I wonder why not Kotlin Multiplatform. I’ve been using LLMs to build with KMP for about 10 months and it’s a delight and you can use native Swift UI when you want to. It seems to be the best of all worlds.
  • willsmith72 1mo ago
    I've been out of the app world for ages, always liked kotlin. Can you speak more about multiplatform?
    • dools 1mo ago
      Well the thing is that the server code is basically Java, and the only bad thing about Java is writing it but since I don’t have to write it, it’s actually a really solid option. Then you have shared UI (don’t use WASM for web though it’s terrible, I use React for the web frontend) but you can switch to some or all native components when you need to on any platform. So for example I needed native components for secure storage and passkeys and did that by mixing in some swift on iOS and using a JNI native bridge on macOS and Windows. I created a standardised bootstrap for all our projects here starting from the KMP wizard: https://bitbucket.org/workingsoftware/kmpbootstrap/src/main/ https://bitbucket.org/workingsoftware/kmpbootstrap/src/main/ The reason it the bootstrap has all platforms included is that adding in iOS, android and desktop after you have already created the project is a bit of a hassle compared with just always having the same structure even if you only want to use web. Then you can easily add on native apps later if you like.
  • mrr7337 1mo ago
    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.
• KPGv2 1mo ago
  "Native is now the future of mobile at Shopify" is a rather unfortunate title for a writeup of why you're leaving a product with "Native" in the name.
• roger_maddux_iv 1mo ago
  [dead]
• zhyder 1mo ago
  AI dramatically reduces the cost of writing code (especially when you have a reference), so the scale between native and cross-platform is going to tilt more towards native now compared to before. But I'm curious what their update will be in a year or two. Because these costs don't reduce as dramatically with AI (unless you fully give up control and vibe code it): 1. Reading code 2. Manually testing code
  • bdangubic 1mo ago
    1. AI will read the code 2. AI will manually test code
• socalgal2 1mo ago
  I agree with this but not just React, React-Native. There's many libraries I no longer have a need for. I've made several JS 3d apps just asking the LLM to write the 3D code from scratch. AFAICT they usually shed 2meg of library and run 1.5x to 3x faster as the LLM will do the optimal thing for the situation.
• jan_m_savage 1mo ago
  The move to native makes sense. Also, human developers and AI make different types of mistakes, and take different approaches to debugging. I'm not saying they shouldn't have done that, it's just that a more human-involved approach with AI filling the gaps would probably be a saner bet than 90% AI with some human interference. Here's an example of why: https://blog.coredump.cx/p/recursion-into-madness https://blog.coredump.cx/p/recursion-into-madness
• inopinatus 1mo ago
  Technology historians will pin 2026 as the year frameworks died.
  • gh0st_hunt3r 1mo ago
    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
• busymom0 1mo ago
  I develop iOS and Android apps and all the apps I have in App/Play Store are native. I did try React Native a few years ago but I just didn’t like how much extra bloat I had to include as third party dependencies. Plus now with iPhone Duo which has so much variation in layout, I don’t think React Native would work well for it.
• kashnote 1mo ago
  I mean it sounds nice but they never say _why_. "AI removes a lot of the burden" is not a _why_. I was hoping to read about some of the shortcomings of React Native, but it seems like they're doing it just because they can. I remember Airbnb had a post about switching off of React Native years ago that actually had some solid reasoning behind it.
  • SenHeng 1mo ago
    https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a https://medium.com/airbnb-engineering/sunsetting-react-nativ... Article is too long to summarise but basically they outgrew it tech- and org-wise.
• ramshanker 1mo ago
  Yea, I have started using c++ for some of the stuffs previously used python for. When agents is doing the grunt work, better to go even closer to machine.
• alanning 1mo ago
  I think the most interesting part of this story is actually the Playwright-style “driver” that they built into their new apps to support faster verification by the agents. Hopefully they will write more about that in the future.
• Javantea_ 1mo ago
  I was excited to hear some details about how LLMs are changing big companies' workflows. This is a fairly straightforward problem and good on them for discussing it. My first gut reaction is that there is no way I would let LLMs write a significant amount of my codebase. And then I remembered that not invented here (NIH) is a problem I have. If I let it decide what code I ship, I am making the same mistake as writing all my code from scratch. When I find myself worrying about alignment, that is what rigorous computer security policy is for. If it's not catching serious bugs written by LLMs it's not catching bugs written by people. Treating my own code as if it was written by someone else is just another part of computer programming.
• hn993302 1mo ago
  Yep. First time I "wrote" a native iPhone or Mac app in about 9 years was recently. I've written plenty of C, C++, Rust, etc code but always found Swift and ObjC to be uniquely bad, and Apple's UI frameworks and tooling are terrible. So one way or another wanted it to mostly not be my problem. First that was RN's job, now it's Claude's job.
• snknew 1mo ago
  May be a good decision.
• karmasimida 1mo ago
  I think in the end, we should just be writing some prototyping language, then let AI translate into target/native development language of the said platform. Code and optimization is going to be a niche moving forward
• eviks 1mo ago
  Vibe-based architectural changes undoubtedly destined for "extreme" success until the next turn of the churn
• sombragris 1mo ago
  I'm an user; I have zero or near zero development and programming knowledge, so this take of mine might be complete nonsense. But I think this is perhaps one of the first AI developments I actually like. Transitioning an app from React Native or any web technology to native code has the distinct advantage that the native version should be much more economical in its use of resources. I'm tired of hearing about RAM and other components hiking their prices while at the same time RAM sizes of ~8 GB are considered too small because things like Electron apps are wasteful in their consumption of resources. Now, with more native apps, we might get full circle: leaner apps thanks to agentic development. Maybe someday 8 GB of RAM could be considered enough once again. Truly interesting.
  • simonhamp 1mo ago
    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
• sashank_1509 1mo ago
  Numbers from GPT Astra - Shopify has 3000 engineers as of 2026 - Google Chrome when released in 2008 conservatively had ~ 60 engineers. - GTA 5 in its credits had 150 software engineers. Surprising even to me who has had many an experience of being in a bloated FAANG team, this 150 includes GTA Online! In a sane society, Shopify’s opinion on anything engineering related would be thrown into rubbish because they seem to have managed to complicate a simple app into requiring thousands of engineers and now maybe millions in cloud spending to Frontier labs. This is unfortunately not an isolated case, Spotify for one has the same issue, idk what “engineering” Spotify is doing, it’s the worst app I’ve used in my life.
  • Vegenoid 1mo ago
    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.
    • vantassell 1mo ago
      >Spotify has progressively gotten much worse over the last 15 years, all while the size of their engineering team has ballooned. Spotify or Shopify?
      • aetch 1mo ago
        Probably both
        • 29d ago
• ropable 1mo ago
  And so the mobile app development wheel turns. All of this has happened before, and all of this will happen again.
  • azangru 29d ago
    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?
• coderonline0 1mo ago
  [dead]
• madrox 1mo ago
  I made this argument at my previous company a year ago and was shouted down by most of the mobile engineers. I have since departed, but knowing how much Shopify's engineering blog is worshipped there they will now say this is the future.
• voidash 1mo ago
  If they play this right, they can do much more than just ecom and move into agentic templates and start selling slack and jira templates
• deleted 1mo ago
  [deleted]
• keithcarolus 1mo ago
  That Shopify employs 3,000 engineers is astounding. I was rejected after a fairly basic ML interview at Shopify and when I asked for feedback I was told someday I could become a machine learning engineer. I don’t think the interviewer read my resume or understood my responses as this was after working for several years in ML roles - staff applied ML and scientist. So maybe that tells you something.
  • aprilthird2021 29d ago
    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.
    • harrouet 29d ago
      Plus they have an Amazon-scale infrastructure to manage...
      • stingraycharles 29d ago
        I think Amazon is very much on another level in terms of scale. Not trying to be negative about Shopify — they have a very large system to maintain - but Amazon is just on another level.
        • tomnipotent 29d ago
          Shopify is not far behind Amazon (the e-com business). It's network sees as many unique visitors as Amazon, though I imagine Amazon has more sessions per visitor, but the GMV across Shopify is just shy of half of Amazon. It's still in the same ball park.
• felizuno 1mo ago
  Sorry not sorry RN was always the wrong choice, and I've made my money shipping React since 2013. Every RN project I've had to join has been a junk show and there is no way they operate more efficiently than 2 native teams. Don't even start me on Expo. Kotlin and Swift are nice, and ObjC/Java are still approachable IDK why people act like native is a big ask. I see people are in their feels already but I'm so glad so see Shopify stop carrying the RN banner, this makes giving the right advice to my clients easier.
• akmarinov 1mo ago
  Not mentioned but this also gets them away from what now seems monthly npm supply chain attacks. Big win for security
  • simonhamp 1mo ago
    You don't have to ditch cross-platform building entirely just to escape dependency hell
    • akmarinov 1mo ago
      No, but it’s a nice bonus
    • hn993302 1mo ago
      Do you even escape dependency hell this way?
      • msephton 29d ago
        It's a developer decision. But I'd say it's easier to not use dependencies on native because there are more capable system API. I don't use any in my iOS apps, and only one dependency in 20 macOS apps.
      • akmarinov 29d ago
        Yeah, with iOS for example, you typically need very little third party dependencies for functionality. The main ones are things like analytics, crash reports, etc I’m not aware of any attacks on native package managers in the past 5 years. The closest would be a poisoned Xcode build in China that wasn’t downloaded from Apple a while back. Also getting an attack on one of the platforms means at least ~half your users are safe on the other one.
        • hn993302 29d ago
          I remember there being a lot of hijacked CocoaPods more recently than that Xcode attack. But supposedly Swift Package Manager is actually replacing CocoaPods now, which tbh I didn't even know until now because I've been out of that loop. So that's good. One of my larger gripes with native Mac/iPhone dev was always needing to rely on a third-party package manager with all its quirks.
• seydor 1mo ago
  Hey what about Flutter
• perarneng 29d ago
  Why not flutter?
  • SV_BubbleTime 29d ago
    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.
• timzaak 29d ago
  Maybe cross platform devkits would not be choosed only becauseof development cost.
• gardenhedge 29d ago
  Shopify always comes up but I do t know much about it. Do I interact with Shopify sites without knowing they are Shopify?
• fergie 29d ago
  In the age of LLMs, I get why you would dump portablity in favour of close-to-the-metal Swift and Javascript codebases. However I don't really understand the need for Kotlin- surely thats just an unnecessary complication and performance hit?
  • sgt 29d ago
    That's for the Android version, I would assume
    • fergie 29d ago
      Right- but why not let the LLM program directly in Java?
      • m11c 29d ago
        Because Kotlin is the primary language for Android.
      • sgt 29d ago
        Java can still be used but it's no longer the recommended choice for Android apps. For any new Android apps nowadays you start with Kotlin and Jetpack compose (made by Google). In fact, I think Google's been saying this for 6-7 years already.
  • listenallyall 29d ago
    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).
• deleted 29d ago
  [deleted]
• harrouet 29d ago
  The one topic that is almost not addressed in this post is: what happens to the React Native developer team? Technologies are never the issue. The people is.
• Krisso 29d ago
  I'm still laughing.
• pranshuchittora 29d ago
  My 2 cents on this as a fellow RN dev & contributor. - The performance gains in native compared to RN (new architecture) are minimal for normal UIs (except games) - 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. - Silos of bugs on native > When you go native you might encounter bugs which appear only on either platform. - 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.
  • agos 29d ago
    > 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?
    • pranshuchittora 29d ago
      I think the Duo support is not there, it will be there at the end of the year.
  • gr__or 29d ago
    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?
• danangtalkin 29d ago
  [flagged]
• yanis_t 29d ago
  I was just recently thinking about how we have built a lot of abstractions that makes it easier for a human to do useful stuff but they usually come with their own set of trade-offs. And now in the LLM era, there's is less and less justification for using those very high level abstractions, and we'll see many of them die out in the upcoming years. React (native or not) is not exception.
• bsaul 29d ago
  is there still no way to compile / execute ios apps on a linux machine ?
• epolanski 29d ago
  > Shopify has been using LLMs to build software since 2021 Odd banter. So did anybody using GitHub copilot which was in technical preview back then?
• joenada 29d ago
  This thread is very depressing. Web dev bootcamps and product managers have done untold damage to the field of software engineering. And it's our own faults. We had it so good for so long. There was a period of time when programmers were the new "rockstars" (for better or worse). We should have used that respect and those resources to unionise and build some kind of institution responsible for teaching, mentoring, standards, etc - a software engineering guild of some sorts. Quality is, was and always will be job one. There's obviously a place for AI tools (providing the economy doesn't melt), but can we please just slow down for a second and think about what we're actually doing?
• faceless3 29d ago
  And they still has zero job openings for Android/iOS devs
• msalihb 29d ago
  React Native and Flutter as cross platform frameworks are best for Startups which can't handle 2 mobile developers. They can create MVPs in short time then start to looking for investors. After the app mature enough company should decide to move native.
  • josefrichter 29d ago
    Even at MVP startups that's not true anymore. It's now easier to build native than to deal with RN quirks.
• fad_fusion_law 29d ago
  Thanks for sharing this. The methodology is solid and the results are informative.
• frabcus 29d ago
  Hmmm, the article doesn't really say what is better about the Swift/Kotlin apps, compared to React Native. All we get is: "Native keeps us closer to platform capabilities and first-party tooling, with fewer framework and dependency layers between our code and the platform" What's the user benefit of that? It's not speed, they say "React Native apps can be fast. Ours are." I'd expect it to be considerably easier for a few people to use the AI to improve React Native with whatever matters, than for every company in the world to permanently maintain two apps. And those improvements to React Native, would make all mobile apps easier for everyone to build forever more. Are LLMs going to stop everyone collaborating, making libraries and platforms, and shared language and abstractions, because we can all vibe code our own thing? This seems a loss to cost and quality, even with lots of tokens available.
  • vendiddy 29d ago
    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.
    • jkmcf 29d ago
      Besides API features, it won't require downloading 0.5 GB of web browser in order to run. Sure, you can make it smaller, but how many companies actually do this? Sure, you can make it faster, but how many companies actually do this? Accountants and product managers don't care about speed or size -- that's a user problem. Judging by the app sizes I download (and try to avoid), few companies really care about the user experience as long as the basic feature is checked off. I worked at a company that provided an unnecessary and heavy FE framework (original devs didn't know what they were doing and "just got it out there"). Most of the target audience used used older PCs, and thus slower and memory limited. Some pages required multiple GB of browser memory. We've had this problem for decades because devs usually have well spec'd computers.
• wangxin199 29d ago
  [dead]
• devenquan 29d ago
  [flagged]
• ngcazz 29d ago
  the end of Electron would be a nice silver lining to the new era of coding
• Zigurd 29d ago
  The answer depends on scale, and appropriateness. If you've got enough engineers, you can do platform native code. The results will look better. Appropriateness often comes down to is the code doing deep platform API things, with sensors for example, or anything else that's not part of user interface, but has an API that's going to require you to write platform native code. Shopify clearly meets the first criterion, but are the commerce and security parts enough to drive the second criterion? Anyway they're big enough to make a slightly less than optimal solution and still get a better result than sticking to a cross platform SDK.
• boutell 29d ago
  When so many people talk about companies going with React "because AI knows React," it's interesting to see Shopify draw the opposite conclusion: AI "knows" all major platforms and frameworks, so at a certain scale it makes sense to let AI handle cross-platform development as a translation problem. Modern LLMs evolved from translation models, and they still seem to work best at translation-shaped problems. Even if you are asking them to translate specs to code, or code for system A to code for system B. In my case, I added SQLite and Postgres adapters to a formerly MongoDB-specific CMS, including support for a largely compatible API, "in one wild weekend..." followed by lots of verification. That was only practical because we already had a large test suite. But it was still a task that would have been out of the question for our team size before Opus 4.6 or so. Again, it was very much a translation-shaped problem.
• andfinally 29d ago
  Sounds like they have problematic management. https://x.com/ErfanEbrahimnia/status/2098145097334379001?s=20 https://x.com/ErfanEbrahimnia/status/2098145097334379001?s=2...
• torutofu 29d ago
  Curious how much of this was React Native limits vs just wanting one UI toolkit the iOS/Android platform teams already know cold.
• vietthan 29d ago
  2020-01-29: https://shopify.engineering/react-native-future-mobile-shopify https://shopify.engineering/react-native-future-mobile-shopi... ("After years of native mobile development, we’ve decided to go full steam ahead building all of our new mobile apps using React Native.") 2021-11-08: https://shopify.engineering/high-performance-hydrogen-powered-storefronts https://shopify.engineering/high-performance-hydrogen-powere... ("The future of commerce is dynamic, contextual, and personalized. Hydrogen is a React-based framework for building custom and creative storefronts powered by Shopify’s platform and APIs.") 2025-01-13: https://shopify.engineering/five-years-of-react-native-at-shopify https://shopify.engineering/five-years-of-react-native-at-sh... ("React Native has come a long way in the last 5 years and a lot of limitations that led people to not adopt it simply don’t exist anymore. If you haven’t tried using RN in a while, now would be a good time to revisit it.") 2025-09-05: https://shopify.engineering/react-native-new-architecture https://shopify.engineering/react-native-new-architecture ("We successfully migrated two of our largest apps, Shopify Mobile and Shopify Point of Sale (POS) to React Native's New Architecture") 2026-09-10: https://shopify.engineering/back-to-native https://shopify.engineering/back-to-native ("React Native was working well for us, and it remains an excellent framework. But since then, coding models have gotten dramatically better, and for our apps and our team, building the same feature in Swift and Kotlin no longer carries the cost it used to.") ^ to show the timeline of things.
  • nish__ 29d ago
    Makes perfect sense.
  • _rwo 29d ago
    ah yes, the classic full circle /remind me in 6 years about this thread
  • mrbombastic 29d ago
    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.
• kudokatz 29d ago
  > Agents can make code changes in seconds, but it takes them several minutes to test the output. This makes iterating extremely slow and manual ... We’re fixing this by designing our app architecture to work for both humans and agents. The core principle here is that business logic should be completely decoupled from the UI and be able to run headlessly on desktop. Looks like we're back to Uncle Bob! [1] [1] https://youtu.be/o_TH-Y78tt4?t=2203 https://youtu.be/o_TH-Y78tt4?t=2203
• albatrossjr 29d ago
  I've been a mobile developer for 15 years and being able to develop two codebases in parallel is by far the best productivity gain LLMs have to offer in this space. These cross-platform SDKs try too hard to solve a very difficult problem and never last (looking at you Xamarin). My first job was actually working on a Lua framework that was shared between an Android and iOS codebase. It's far better to tell claude to port your swift+core data implementation to kotlin+room then fix whatever it did then it is to try to debug a complicated view hierarchy that renders incorrectly on a specific Android version because you're framework decided to nest a list in a scroll view.
• de6u99er 29d ago
  LOL, good luck keeping feature parity for both code bases. I moved to Flutter which has been a great experience so far.
• lellow 29d ago
  [dead]
• blehn 29d ago
  The true test here, which I don’t see much discussion around, isn’t how fast or how well agents can convert the existing apps to native; it’s how fast and how well the team can build entirely new features across platforms with native vs react. The existing app code is an unambiguous spec — perfect for agents to build from. Typical design specs, PRDs, and prompts have a lot more ambiguity. There’s a lot of iteration that needs to happen to get a feature from concept to launch and I’d wager that will not be as fast with the fully native approach.
• byward 29d ago
  It's nice storytelling, but hard to take completely seriously. As others have commented, there's a lot that's not being said. We may also look back on a (now-deleted?) tweet in which this company's CEO meme-trolled another engineering org. for their mobile decision-making. The overall tone here and over the past years comes off as holier-than-thou.
• grommet_kit 29d ago
  The 3000 vs 60 comparison ignores what the products do. Chrome 1.0 couldn't print; a complete browser took hundreds more engineers.
• diebillionaires 29d ago
  Who respects shopify's engineering practices?
• Vishal_Max 28d ago
  What is really going on, why suddenly every single company is just saying we going to go native? I mean they are working fine as it is
• p32929 26d ago
  [flagged]
• fami-hn 19d ago
  [dead]