Recently listened is an automatic list like a log, not user curated. I would never expect to be able to delete things from that list.
I don't need an audit log for my audio. What I do need however is to remove something so it doesn't influence the algorithm. I may not remember every time I play music for a kid to turn on the right mode.
That would also then require them to invalidate caches and rerun scripts to rebuild those lists and recommendations, which costs extra compute.
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…
I'd imagine the user benefit is they can tap new operating system APIs and features almost immediately versus having to wait for a React Native package or having to build a React Native bridge. I think everyone would agree that native apps are better in every way, but the thing is, as a small company, you can't justify hiring two different developers - hence why RN is usually a good choice to get off the ground with.
I 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…
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.
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…
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. Quali…
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 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.
You just install it on your phone and use the app. Maintainability concerns are entirely overblown by people who don't use agentic AI to develop large mobile apps, but anyway give their opinion as if they had that experience. I put in a few hundred hours, and I reached the same conclusion as Shopify. With reviews from other models and then a manual QA pass the result is fully usable.
Same result here just using plain Opus 4.8+. I had a web ap with a PWA approach. Now I have an iOS app written in Swift/SwiftUI and an Android app in Kotlin in the appstores. I do not know how to code a single line of Swift or Kotlin. You just test the app and iterate with the AI over it until it is stable and does what it should.
My main agentic coding side project is something that I can't justify paying the apple developer license for. If I was an Android person or I didn't have to pay the developer license, maybe I'd just go for it.
I agree with what you're saying that it's not exactly what we're seeing which makes it not as simple. However, I've seen this play out in many a big companies where there's a big mess going on. Answer is always similar pointing to -> "clearly it's not simple" and that's kind of the whole point. They made it not simple. 3k ENGINEERS, my sweet dude. THREE THOUSAND. By any and all account that's half as much as current…
Taxes, compliance, regulatory bodies, logistics multiplied by X countries X products has an amazing way to bog you down. If you have money and problems money solves (eg you could hire more people to do something) you do not have a problem (except for people on the internet making arguments from personal inexperience)
I get that, I truly do since I see it all and every day. We're talking engineering hands here though. Presumably programmers and infrastructure and SRE.
2020-01-29: 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-powere... ("The future of commerce is dynamic, contextual, and personalized. Hydrogen is a React-based framework for building custom and cr…
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 e…
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
Pardon my ignorance but can't an iOS app host a WASM runtime without being a browser? And if so it doesn't need to be an interpreted language necessarily.
Could you reinvent OTA updates in another non-native language? Of course. But then you still wouldn't have a native app. You'd just be doing React Native but worse.
My point is that it isn't that RN "removes one of the biggest annoyances of developing for the App Store", it's that a specific technical feature of RN does that, and it's not only available to RN