Posted by fnthawar2 19 hours ago
- 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.
Also, you're comparing the number of engineers working on one product, to the number of engineers working at Shopify across their entire company today, which includes far more than just one app.
You're entitled to your opinion that Shopify is a poor app or that it's overengineered, but clearly it's not simple. That's just a fact. If it looks like a simple app to you, that's because you're not seeing most of it.
It's like looking at the YouTube mobile app as someone who watches videos and saying that the app frontend looks simple. You're only seeing 5% of the app. The other 95% is for video creators and advertisers, and it is decidedly NOT simple. I think that's the same here.
Most of the modern software tooling you have today wasn't available back then, from great IDE's to popular libraries, writing software in 2008 was a different beast compared to today.
Exactly!
More seriously, it not just about building a compliant web browser engine, it is about tracking the dominant browser engine which introduces their own "standards" along the way too.
Microsoft could have easily continued to invest in maintaining their browser engine, but it would have to be comparable to what Google is doing, and yet they'd always be perceived as "behind" due to non-dominant position they have.
I'd say strategically they do not want to invest in tech that's not winning (in marketshare), so when they are not dominant, they'll instead adopt and extend (not just web browsers, look at WSL too).
> one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't keep up
Chrome’s original design definitely predates our current rich ecosystem. Plus, V8 and Chrome’s performance profile are demanding enough that there would be a pretty high bar for those dependencies anyway.
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.
Spotify or Shopify?
I think I’ll start a company called Shpoptify.
This is why I’m sceptical of “AI will kill corporate jobs”. A big company has no profit sharing for successful departments. Everyone is trying to get budget to hire because it makes them feel important.
I look back over 15 years and with the exception of increased smart phone usage, everything else still looks mostly familiar. Maybe a bit more slick, but also slower and buggier despite having much better hardware.
There hasn't been a qualitative leap in software (as was in the 90s). Just larger SaaS companies. Without ZIRP would it have been any different?
When a company can run for years, hell, decade+ on the red thanks to investments, that means every competitor now have to compete with company that sells their goods or services below production value. It just kills competition and innovation, which only becomes possible if other company also attracts investors
Spotify had a good app when it came out, p2p and UDP custom networking...
- stay out of it for your sanity
- sell your soul, organically adapt by looking at those who make it to the top fast
I just brought up Spotify since I have more experience using their app and they have also gone fully into “agents have made us 100X more productive”
Perhaps you are the AI slop?
To start -- how many of those 3,000 engineers do you think work on the mobile app? And even among those who work on the app -- do you think they're all working on user quality-of-life and just can't get it right? And it's a $175BB company -- do you think it's worth that much based on the quality of its mobile app?
If Shopify - and you are concerned about their engineering teams, please consider that Shopify's revenue grew from roughly $205 million in 2015 to $11.56 billion in 2025, reflecting an explosive compound annual growth rate (CAGR) of over 45% across the past decade. Market validates !
I have nothing to add about Spotify - I use it to listen to music and it works well for me !
Upon looking just now, seems like they have been relegated to their own tabs now, which is great.
Just so it is said: my understanding is it's really easy to not end up on the credits list for games despite having worked on it. I don't know if contractors end up on there for example, at least beyond some team leads or the like. I don't know R*'s policies though, I've heard stories of people not being in credits because they, for example, changed jobs near the end of the development.
I get your overall point though
They have updated their policies a bit. You may not be in the game credits but you'll show up here.
FWIW the social club team which handled a lot of the online components was small around the time GTA5 released. They built the APIs to handle user generated content, telemetry, accounts, etc. But, there were other team members that made it so the game would call said APIs.
PS - Spotify i can't defend the product sucks.
I wonder what gripes people have.
Also, the website is slow and buggy, and the Electron “desktop” app is even worse. Both gobble up way too many resources and soft-crash constantly. The app does not lock up, but simply stops working. Often it even shows an error like “Spotify cannot play this song right now.”.
"The best minds of my generation are thinking about how to make people click ads." -Jeff Hammerbacher
Commercial software is usually a simple core and a long tail of business exceptions
Like comparing a climb and along run. Sure both require some physical abilities, but in the first case any error and the collapse mean dead end bringing progress to zero, while the second one you can rest on the side any time and still have the miles behind you accomplished.
[1] https://www.linkedin.com/posts/rpandey1234_its-mind-bending-...
Compare that to companies that release actual software products. The goal is product release at high enough quality. There are real performance and security targets to achieve.
Your typical corporate developer, on the other hand, does not have release targets. The actual goal is compatibility with the industry least common denominator expectations and retaining employment. This is why so many people are needed to do the work and why the result is so slow and bloated.
I'm a full stack web developer. I've worked for startups and F500 companies. There is always a push for release targets. The less technical the leadership, the stricter the release targets (its hard to sell a critical refactoring to management when they cant sell a shiny new feature or kpi to their own boss). We've kept our teams pretty lean too.
We still aim for high quality, and performance and security.
I do agree that many people dont really know what theyre doing and are kinda just winging it, especially with AI at the helm, and many companies are likely overstaffed, but I dont think theres a correlation between headcount and slow/bloated software. Any team of any size can make slow and bloated software.
Those other businesses aren’t any less valid, of course. They just aren’t software businesses. They are businesses that (quite sensibly) use software.
There was certainly a ton of bloat to trim, but the haphazard "just pick 80% of the people and fire them" was incredibly stupid. Should have chosen whoever was producing the bloat, at least.
(Maybe that was intended I might have missed some irony here)
Oh you said 500, not 5000, my bad.
P.s.: I find Kotlin "an acceptable typed-Ruby" with an industrial strength VM (the JVM) and two compiles to native stories (KMP and GraalVM-native).
All I want from Spotify is API so someone can make better player/plugin to a better player.
Engineering is app usability. Theres no other possible thing an engineer might do. Chrome ofc has infrastructure to distribute a binary. Spotify of course having a global content delivery network for terabytes of music. Hey GANG CAN WE WOKK OUT WHAT THESE ENGINEERS MIGHT BE DOING?????? WHY HASNT JIM STORAGE ENGINEER IMPLEMENTED A UI REFRESH YET!!!!
canadian dollar is very cheap so you'd likely see 40~50% more headcounts for the same burn rates you get in USA
i definitely dont think those shopify engineers are going to be retained long term however
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.
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.
Most of the time when I review code from AI, there is always something to improve.
It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
The maintenance is not only the burden on the human and LLM. With too many moving parts, it becomes harder and harder to build and verify the correctness of future features. Yes you can write test for this and that, but it didn’t need to exist in the first place.
The second problem is correctness issues. Especially the edge cases. You cannot just manually test out a race condition on a phone! Sometimes it happens! Sometimes it doesn’t! If it leads to a visible signal like a crash, then yes, you can try to reproduce it. But there are a lot of these that are “silent” and would just lead to bad experiences.
We already had a software quality crisis! And I think such views only exacerbate the situation! Quality matters!
And this is not an anti-AI stance. I vibe code personal projects where I don’t even look at the code. But when I use AI as a professional engineer, I act like a professional. Because these products do have an impact on people’s lives.
I think we are over-indexing on speed of delivery. I think this is a mistake. The alpha is in speed and quality.
Currently, my experience is that human + AI can write software faster and with better quality than either party can do alone.
I understand this, but I just can't bring myself to care. I've been doing professional software work for almost two decades. These sorts of improvements/time savers are great without AI. With AI? Whatever. It's fine.
When the underlying lib has an issue, it'll be quicker to debug with the whole thing in context.
It depends on how hard to maintain the code added is, how likely it needs to change in the future, and most importantly on the cost.
If reviewing and manually improving the code takes hours, the cost may already be in the thousands.
That buys you a lot of AI usage, roughly a few months of continuous work.
You have to balance this with the chance that the suboptimal code the AI generated is actually fine and maintainable enough, and also the chance that during further work on that code a model might implement the same optimization on its own.
And more recently its been recommending that i install this new browser called Aside. I did, and it almost felt like I was installing malware so I Uninstalled it fairly quickly (it also was not a great browser)
I feel like theres collusion somewhere.
I don’t see any reason to think the same thing that happens with all tech won’t happen here.
I also used to work full time as a Android developer for five years, and I'm pretty sure I know better than you about the quality of my app that I work on everyday.
Years of experience doesn’t mean much! I will challenge you on ideas. And the idea you are sharing is dangerous and unprofessional.
Especially at scale. e.g., we process more than 3.5 billion orders annually! This is serious business. Edge cases are common.
sounds like your app is nothing serious
Some people on the cybersecurity side are starting to cry....
Last time, when I pointed out that the attack surface for mobile apps is typically very small, some users started to talk about zero day vulnerabilities in the OS's media handling, as if it was a concern for my app implementation.
I found the concerns again wildly overblown.
2. Wild use of webviews/iframes sometimes easily propagates as XSS in phones
3. Incorrect client-side OAuth 2.0 configuration e.g. with schema-based redirect URLs.
4. Not supporting high-enough API versions, which may prevent some OS-related weaknesses
5. The list is actually very long. Just few top of my mind.
Or a login form that gets hidden after login, but clears the username and password only when you click "login back in". (Bonus points if the backend also enforces a 5min session timeout "for security".)
Turn on the secrets scan in GitLab, and put in your release checklist to have the AI audit the usage of secrets in your app, and this is basically guaranteed not to occur.
I doubt current models even make such a mistake in the first place, and particularly so if you use reviews at all.
WebViews are not an inherent problem, it's the system browser embedded in your app.
Where it gets tricky is if your use case involves authentication in the browser. Together with the authentication in your app this is the one area where you need to focus on security.
The case where a SDK update is needed to prevent weaknesses of the OS seems rather unlikely.
OP says they don't have an android phone...
And in the past, I didn't care because when I was manually building the app, I would just do my best with react native. But now that I can actually sweat the details (with the help of agents), I do want to hear from android users and use as many OS-native APIs and features.
I'd order a cheap Android phone to have a device in hand instead of working only with the simulator.
I could only sweat the details on liquid glass, etc because I'm a daily iOS user.
You can write more automation to test it. But that's also how you end up with ever-growing test run times.
There are much better ways that aren't just "throw out the LLM" either. You just need to be more focused on throughput. Requiring manual validation can pretty rapidly require more hours than just sanity-checking code by hand, even (and I'm not advocating that for every use case, either.)
I can't afford manual QA passes if I'm gonna go as quickly as I want to.
Can you share some details of how you work? What models? What harness?
I don't know if Gemini is suitable.
I had few issues with my native iOS app, the results are just decent after a few iterations, the models do what I ask them to do. Where do you see the problem?
The LOC for my app is now at almost 200k + 110k lines of test code.
what the fuck are you talking about
I hate software engineering now.
[yes, this would also get rid of the previous generation of 1000-JS-lego vibers]
That‘s how you check functionality but that’s not how you get the bugs in the code.
That’s like translating a text to another language without knowing the language
What do you think has more training data Python or Kotlin?
If you are blind, you cant see anything wrong, if you are deaf uou cant hear anything is wrong.
It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem, which makes me feel fear in my heart when I imagine the first "production is down" page coming in. I already hated mobile because it's so much harder to maintain than web (and I don't do any spyware or IAP so no benefits for me there); this yolo approach would give me constant dread.
It shows that at least some software development is moving away from code and to product management instead. I'm not passing judgement on that; I actually think that's great for a lot of software. It is interesting to see the shift happening though and will be fun to see if the general quality of software noticeably changes over the next few years.
As much as I dislike it, I think that's the future of _all_ non-critical software (think social media, crms, CI, food delivery etc). Leadership in many companies is explicitly asking employees to have multiple agents running through the day and that will lead to this.
Read this for example: https://www.uber.com/in/en/blog/efficient-software-factory/ . A very useful system, I am sure. But when you have AI at every layer from code to review to triaging, rest assured AI is the only know who knows your system. And you better hope it's not telling you that something is load bearing during an incident.
But yes we are having real Android users test it.
So it’s quite the contrary. I care MORE what real users say. I can only guarantee that the app does things when I tap. So I’m not trusting the agent on UX, only on functionality. But whether it feels native, I am relying on those users in our team.
I still would feel scared operating an established product off a newly changed stack the team isn't familiar with though.
When you’re completely ignorant, there’s nothing to be afraid of.
But I am going to always prioritize the user experience over a developer (like myself)'s need for satisfaction to see code. And a pure native app is _always_ going to behave better than react native.
This gives me a chance to do that.
Maybe iOS is better about consistency, but I've used enough horribly made Android apps that I would not expect one that's vibe coded to behave better than a professionally made react native version.
You are familiar with the React Native code, you are not familiar with the Swift or Kotlin code, and likely nobody on your team is, since the AI wrote all of it for you.
Remember Chinese accounts on US Facebook say data centers are bad.
Myself turned some python code to Swift, and keep doing so, without trouble or pressure. Of course, I've been doing fair amount of systems programming for 20 years now, so not sure what to advice newcomers. But this approach to dev DOES work for me very well.
[1] Epigrams in Programming:
https://engineering.yale.edu/academic-study/departments/comp...
They had previously chosen React Native because it was easier for programmers to keep it updated, since it was really just 1 codebase. With AI, those same programmers can do the more difficult version, keeping the native apps updated separately.
So did it kill a job, or did it make it possible for the existing programmers to do it better?
It's the kind of thing that is really hard to determine in general, but here, it really does sound like they only made the change because it became possible with existing resources. They would not have done it otherwise.
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.
…as long as Claude is still subsidized…
Sounds like you agree
Just like this has made Web devs into Mobile devs, so could Mobile devs leverage AI to work in Web shops.
I'm not an optimist but there could be an increase of available apps being created which would still keep people employed. Theoretically the cost of creating an iOS app for a company without an engineering team dropped from several hundreds of thousand to a few thousand or hundreds, which could be paid out to a freelancer with AI. More people would go into freelancing for industries which were not contemplated before due to cost.
But I'm not an optimist.
I think that rewrite - if AI enabled - owes its thanks to the legion of individuals who put their code up on the internet in the first place.
Weird times.
Seems similar to eminent domain, but without limitations.
We all want super exciting jobs. But plenty have boring jobs like this. Between not having a job or having a boring job that pays well, the choice is obvious for many of us.
I personally never minded doing migrations. I guess I don't really have to anymore though. Weird.
Not anymore.
LLMs made it way worse https://ashishb.net/tech/react-native/
For most app that concept is "gone".
People routinely decompile and recompose existing binaries, and if you use "obfuscation" in your app it's still a small bump.
In today's age, IP is no longer a tangible concept that gives any advantages in software. What differentiates two businesses isn't their IP, it's their relationships and their moat.
Most vendors that had protected proprietary IP are now irrelevant within their vertical. What saves them are the protection provided by patents, which is public.
They don’t care about your code. There’s more and better data on the public web.
Also what's the timing on this setting's effectiveness? What if before you knew to "opt out" you used the agent for a refactor and your entire repo got sucked up in inference? But then you opt out the next day? Is it too late?
And there are solutions around it from other providers and model routers. OpenRouter lets you explicitly say on a per-request basis you don’t want to be routed to a provider that trains on your input, for example.
If a company really believed there’s valuable IP in code, there would at a minimum, ban laptops or ban code on laptops[0], provide and maintain a centrally managed LLM gateway[1] that handles authentication, billing and model choice, have MDM to prevent you from using your own Claude login, etc.
[0]: For example when I worked at Google, the proprietary google3 codebase cannot exist on laptops because there are no tools to download it to your laptop.
[1]: For example Claude code supports having a gateway: https://code.claude.com/docs/en/llm-gateway-connect
Heck, you don't even need to mix up a personal and business AI subscription. For the vast majority of folks one day their IDE "updated" and a bunch of AI features suddenly became available. Free, no sub needed. A dev starts using them (because, why not?) and lo and behold the company's code got shipped out in an inference call and is now scheduled to be in the next training run. Oops.
IDE updated? It’s the company IT’s job to perform testing before distributing those updates. And also their job to use whatever managed settings to disable those unmanaged AI features.
Actions speak louder than words. If the company doesn't even supply and require work devices, they don't effectively consider their code to be valuable IP.
Of course the company can still consider their code to be valuable IP.
Each time I get access to a new model, I do two things on all our active codebases:
- Security review of all the code and vulnerabilities (new models will find new stuff)
- Code review of test suite quality, and idiomatic patterns/code for the language of that codebase.
And in the case of swift and kotlin, it's even more important that an agent helps me with the code quality since I don't know what "idiomatic" swift or kotlin looks like, the way I do with JS, Elixir, C#, Ruby, etc.
What does your app do?
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.
They are like multiple companies in one: Square, Etsy, aspects of Stripe, aspects of Squarespace/Wordpress. Idk I can see why they have a lot of people.
I 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.
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
Now it's a different situation as implementation has become incredibly cheap.
Writing almost anything with javascript sucks ass to begin with. Writing native code with it is even more painful. Most javascript engines don't even have any decent model of parallelism. It takes zero imagination to see the problem here
However, I think it's true that controlling threading in order to perform gnarly work in a separate thread is more ergonomic on mobile than in JS/React.
You'd need to create a Promise that wraps a Web Worker, which would be an unusual thing to use. I don't think most apps need such control over threading in the browser.
yeah because they don't care about a top notch user experience.
But there's a factor few people (that decide on using RN) miss; it adds a layer of indirection, so you're no longer as "in touch" with the underlying platform. While possible, few RN developers would consider adding widgets or smart watch apps to their main app, but (I feel like) if you're a native iOS developer who is all-in on the Apple ecosystem, you're more likely to try and adopt these features (where applicable).
(disclaimer: RN is my current day job, used to do native iOS development and I frequently miss it)
It was a different picture out of the Apple garden, when a company only brings their next major feature to iOS because they couldn't be bothered to hire the same headcount on two development teams and their CEO uses an iPhone anyway.
We had that discussion about a decade ago with a company rep that didn't realize 70% of their EU users were on Android yet their play store app didn't have the feature they were planning to promote.
Basically, better was the enemy of good for most companies.
The android shortfall is a real one but I also pushed for hiring native android developers too.
Agents are happier working on any codebase, but ultimately Shopify and other companies want iOS native app level quality without the huge cost of hiring many native iOS / Android devs.
LLMs and Agents deliver on getting a native app out at lower cost, higher quality, faster all at once.
I think everyone is trying to tell you your skills as an iOS native dev have been commoditised and Shopify and others don't need to hire anymore native devs to find this out.
I don't see how your job being completely commoditised and cannibalised by LLMs replacing your job is some how vindication?
This is just like saying "we won the argument", but what did you actually "win"?
Shopify isn't hiring any mobile engineers.
Probably because the agents were hired first and took the job already.
That is the point of the job being literally commoditized and cannibalised, they hire less or close to 0.
Your quixotic 'vindication' means nothing and has the opposite effect.
Really the whole concept of technology specialization is the thing in jeopardy. It no longer appears to work to make a career out of deeply learning something obscure. Agent-farming generalists appear to be the ones who own the future right now (if, heh, not the agents themselves).
source: ios dev since it was possible -- I am not even pro react native, I am just pro merit based arguments -- you aren't making any
What we found led us back to 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.
Also, any plans to open source Helix?
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)
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.
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.
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.
KMP can be seen as a token optimization at this point. Business logic is shared and doesn't have to be rewritten in Swift.
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.
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.
Edit: was going to update the earlier comment but just hit the 2 hr mark.
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.
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.
So it goes.
any engineering problem is just 'when' and 'how much' at that point
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.
Sure, you need a review to release native code changes, and you should probably get a review if you have big feature changes just for the sake of Apple not banning you. But in practice, it removes one of the biggest annoyances of developing for the App Store.
Changes are cheap and fast, so teams often feel less pressure to test everything thoroughly before a release. Which is a fair tradeoff. That’s part of the reason we can have dozens of releases a day on the web. Not just because we can, but because sometimes we have to.
With native, you know each release is harder to roll back, so you tend to build more tooling around releases, think through changes more carefully, and test more thoroughly before they’re ready to ship. You opt for one bigger, more stable release every few weeks instead.
At the end of the day, both approaches work.
Heh, now that I think about it, maybe web and cross-platform devs were the original vibe coders? Changes are cheap and fast. Just move fast and break stuff.
Native devs are the old-school ones. Shipping is expensive, so you better get it as right as possible.
Exactly this. After close to two decades building for the platform, the mindset is really to be cautious and make sure everything is rock solid before shipping.
This has more to do with building up a quality tool chain and testing process than being slow.
But sometimes there is a need to ship over the air updates, and for that (on Kotlin) there is Zipline [0] from Cashapp. I haven't used it in anger yet, but I know some people who do and trust it.
Also keep in mind Apple might penalize you for dodging the review process and shipping new features, etc.
(btw, one exception to the JIT rule is custom browsers for the EU)
App Review Guidelines §2.5.2 says: "Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps"
Technically Apple can punish you for anything but so far it seems to be accepted for small fixes and tweaks.
I don't see a reason to use it over web stacks plus CapacitorJS (Or Tauri) or directly native for very large teams.
React Native's advantage of having a single source of truth for code hasn't quite gone away yet, imo.
link to project: https://github.com/skiptools/skip
[1] https://news.ycombinator.com/item?id=41384144 [2] https://news.ycombinator.com/item?id=46706906
Also, having agents trace and document every logic path to compare with another codebase works well in my experience. It can certainly do that better than me, i would give up and start taking shortcuts pretty early in a process like that.
Alternatively, point the model at your git repo for platform A, read the diffs since release X and implement the same changes on platform B?
[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.
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.
There's nothing remarkable about the skill set of either party; the appeal here is re-use of code. how the labor markets itself is irrelevant
> But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway.
Are you saying:
- webdevs are now able to write and review native code because of AI (who cares if they don't really understand it); or,
- Because developers are more productive we can cut the number of webdevs and hire native engineers – same no. engineers, same output, but now native apps.
Why not:
Continue using RN but now and just enjoy being more productive? If productivity was the reason to pick RN, then enjoy it. It's not a bug.
I now avoid buying things from anyone who use the dreaded purple "shop" button.