Remix.run Logo
joshstrange 6 hours 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 6 hours ago | parent | next [-]

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.

joshstrange 5 hours ago | parent | next [-]

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.

joenada 5 hours ago | parent [-]

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.

joshstrange 5 hours ago | parent | next [-]

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.

ceejayoz 2 hours ago | parent | prev [-]

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.

ftchd 5 hours ago | parent | prev | next [-]

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.

manmal 4 hours ago | parent [-]

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

ceejayoz 3 hours ago | parent [-]

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

paulryanrogers 5 hours ago | parent | prev [-]

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

joenada 5 hours ago | parent | next [-]

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 5 hours ago | parent | prev [-]

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.

Rohansi 5 hours ago | parent | prev | next [-]

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.

cosmic_cheese 4 hours ago | parent | prev | next [-]

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

schrodinger 6 hours ago | parent | prev [-]

https://www.runway.team/appreviewtimes

joshstrange 5 hours ago | parent [-]

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.

schrodinger 4 hours ago | parent [-]

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.

joshstrange 3 hours ago | parent [-]

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