Hacker News Reader

Comment by fnthawar2 | Hacker News Reader

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.

View on HN

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

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.

Others mention quicker startup of the app, more native-look, less head-ache w/ RN.

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

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

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

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

Also, any plans to open source Helix?

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

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

Ah, you're right, my mistake—wasn't reading the username carefully enough

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

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)

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.

Doesn't KMP assume your team is comfortable working in Kotlin?

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.

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.

Plus you’re trading RN problems for gradle and integration problems on iOS.

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.

This is only anecdotal, but I had a review on a brand new app turned around in ~6 hours 2 days ago. A lot of it has always been luck of the draw, though, granted.

I agree it's anecdotal but that's all I have to go off and global averages don't help me at all. The problem it's a complete crap-shoot. You have no way of knowing if you are going to get a quick turnaround or a long one, it has zero bearing on if it's a new app or update or the size of the update, it's completely random. I cannot plan around random which is why I've opted for web-tech-based apps (Capacitor) with OTA updates so I can get fixes out just as quick as I could get webapp updates out.

I just ran an analysis of my apps and the fastest was 8hrs (June 20th) but since then it's been trending upwards with my last 3 updates coming in at 40hrs, 67hrs, and 98hrs. These are all my apps, the company I work for has at least 2 recent updates that took over a week. That's just absurd.

If the App Store can commit to 24hrs being the max time then maybe I'd be interested but for the foreseeable future I'll "Settle" for instant updates when I have a fix ready instead of waiting on Apple. Especially with how random approvals are (not just the time, the approval itself), I'll ship a tiny fix and App Review will kick it back for some native API I've been using since version 1 that they now want more info about. I don't fancy having my businesses at the whim of Apple Review.

It's also dependent on when you file. My reviews seem to come back around 2-3 AM Eastern; I presume they're overseas contractors.

Apple has started automating them a while ago so a lot of them are indeed <24 hrs. I wouldn't say they are wrong though.

Just this week I've had an app stay for 9 days in review and another one for 8 hours. Same dev account, same niche.

When it takes longer than 36h, just revoke and submit again. It's probably just stuck in some queue.

Or https://developer.apple.com/contact/app-store/?topic=expedit... - I've had good results from their expedite tool.

https://www.runway.team/appreviewtimes

I'm sorry but that data does not at all square with my experience. I'm seeing 2 days+ as the average and I haven't seen sub-24hrs in months. I oversee ~20 apps and I can tell you iOS review times have been trending upwards for the last few months.

Apologies, I used to use appreviewtimes .com [dead], which scraped tweets and was pretty accurate, but is dead now. I posted what seemed to be a decent replacement, but will take your word it’s not.

Edit: was going to update the earlier comment but just hit the 2 hr mark.

For all I know it is accurate for them but I encourage you to hover on the bars and see the min/max. That's where the issue is. I wrote more about it here [0] but the TL;DR is that it's wildly inconsistent, sometimes it can take a few hours or <12 hours and sometimes it can take a couple days. It's impossible to plan around and nothing drives me crazier than having a fix written but waiting for Apple to get around to reviewing it.

[0] https://news.ycombinator.com/item?id=49645559

You get all of those, to some extent, if you use React Native. You still need to do reviews for significant changes due to app store rules but you can OTA update most changes without waiting on a review. Even web support is there.

There are cons to targetting web/PWA too. Push notifications work but Safari on iOS only allows them if the user adds your website to their home screen. It also doesn't support prompting the user to install the PWA so you have to instruct your users to tap the Share button, tap View more, and then tap Add to Home Screen. And as soon as they tap the Share button the menu opens on top of your instructions so they need to remember the steps to continue. It's hard to defend this behavior because the user will still need to allow notification permission when they open your PWA from their home screen. It's an unnecessary hurdle.

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

Apple may not trumpet it as loudly, but these freebies are handed out in UIKit too, for cases where declarative UI is cumbersome.

Generally I've found that while SwiftUI is great for little self-contained bits of UI like table/collection view cells and simplistic template-like apps, it tends to become a bear with complex apps, so it's nice to have both options.

The compile and build times on iOS (and Android) are also painfully slow. They claim to have "hot reloading" but only under very specific conditions, and it's not the whole app. When you're working with UI in particular, you can often edit and text your changes 10x faster on React than native. You could argue that the quality "gains" you get from native are partially negated by the reduction in iteration speed. Quality often comes from iteration and it's an order of magnitude faster with React.

Agreed, I’ve never used react native myself but I do use CapacitorJS to run JS (TS) apps and with a dev server I can hit save in my IDE and see it on my phone screen in <1 second on average. It’s so nice for iteration.

Throughout my career, I found that the faster I can go from wanting to try something to seeing it working, the better. Without that quick iteration cycle, I end up, not trying certain things or trying to batch all of my changes which then makes it harder to be sure what actually fixed it.

Exactly. I wouldn’t be surprised if Shopify ended up building some tooling to try to solve this, but Apple in particular is remarkably disinterested in or perhaps inept at improving the developer experience, and agents won’t magically fix that.

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

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

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

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

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

Still loving flutter over here!

The vastly undersold topic to all of these is how many developers do you have?

We have the option of using flutter, or not launching an app at all. The concept of going full native is a non-starter.

I basically could not care what Shopify is doing because they have hundreds or thousands of people.

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.

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

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.

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

Did you switch to SwiftUI or UIKit?

Reply on news.ycombinator.com