It’s time to stop complaining about “shitty code” written by AI. If there are problems in functionality sure, but I personally don’t care about a good directory structure or short, single-purpose functions or short files or whatever else we have been taught about good engineering practices. Why? Because if the code was generated by AI then it will be maintained by AI. I’m not reading it, and I don’t care about it.
This sounds great until you've seen an AI generated & maintained repo go wildly off the rails and need to step in afterwards to fix it. Turns out some of those things still matter.
The code generated by AI is often not maintainable by AI. It's mostly trained on one-shot tasks still, not on growing a small system into a large one. AI is not immune to tech debt.
No, they said they don't use android so don't know the native UX. You can test your app on the platform and confirm that the functionality all works, but how well it adheres to the platform's design language is subjective and hard to say if you aren't used to the platform.
That plan only works if they manage to drive Google et al out of business, and there’s zero evidence of that happening at this point. There’s no more ad $ coming to the table, just a battle for the same $.
If anything, things like Google putting really good AI right in search is making OpenAI’s efforts increasingly a hopelessly uphill battle.
Well, even payment is no guarantee that ads won't be injected into service. even these fucking movie theaters sho like 20-30 min of ads before showing movie people paid for.
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).
The main cost of two engineering teams shipping identical products in my opinion isn't the cost of those extra engineers, it is in the product and organizational challenges of keeping those two products that need to be identical in sync. I am very bullish on coding agents but would be wary of this turning into a mess.
But here's the thing, across operating systems the products should not be identical.
When you get to the point that your have a significant enough number of users across multiple platforms, generalizing everything into a shared UX doesn't make sense; giving those classes of users the best experience requires embracing their platform.
A simple example: Android has a system-wide convention for a `back` button. iOS has no such standard. Users on each platform have different expectations for how to navigate an app fundamentally, and holding tightly onto the concept of identical gives both camps a compromised experience.
I took "identical" as in feature wise. The user should be able to accomplish the same things, no matter what platform they're using.
I do think that the way the features are implemented should be platform dependent, i.e. use common UX pattern on each platform, fit in with the UI, and be good platform citizens.
The solution is to make the common features a part of a statically-linked library that you can pull into your apps. A web app is, IMO, never the answer when you want to address multiple audiences. It is bad for accessibility (because 99.999 percent of web app developers never consider accessibility) and it doesn't solve the problem that web apps are trying to solve (having 8 code bases all that have to remain in sync) because you will inevitably need your code to handle platform-specific differences, standards/conventions and whatnot.
I don't know iOS so I can't say, but a good UX does depend in part on platform expectations and every system historically been different. The compromises mean the each have good reason for what they do (sometimes anyway), but switching is hard.
It shows the sad state of user experience that applications completely ignore how different platforms function. For websites, I would expect them to follow the web conventions of UX. However, as soon as you're in a "native" application, you need to function like the device you're running on wants to function. Otherwise, it's going to be a jarring user experience for everyone in there. The whole system becomes harder to use.
There is an implication here that the back button is a microcosm that represents the differences holistically but it's not. It's a small one-off exception that doesn't even affect the design choices made for the various apps. As I open up app over app on my Android (Audible, Spotify, ChatGPT, etc.), they all have clear in-app "back" functionality where needed. No apps I have installed rely on the Android back button exclusively. Also, none of these apps have any design elements that follow Android's design language.
The back button works at its best when it closes an app and it restores the one that opened the previous one. There could be no in app back button to do that. However the back button used to be an always available hardware button or a touch one on the bottom bezel. It's optionally visible now (I'm on an old Android phone so I'm not up to date with the latest OS) or a gesture, right? So app designers must design as if it does not exist.
It's literally still a back button, doesn't matter if it's a gesture, physical button or button on a bottom of the screen. The result is always the same action in the same place no matter the app used.
> keeping those two products that need to be identical in sync
I agree that most companies do that, but in my opinion that's not really all that important. Some drift between the iOS and Android apps should be expected and accepted.
> it is in the product and organizational challenges of keeping those two products that need to be identical in sync.
They're two different platforms where the capabilities and UI patterns differs, so I don't see why they should be in sync. The web platform is not in sync with them. And using native features can give you a nice boost in maintenance and speed, unlike React Native where you always needs to align library semantics.
The capabilities of Android and iOS don't meaningfully differ for the purposes of Shopify; Shopify doesn't need LIDAR. Most large brands throw the UI design patterns of the platforms out the window in favor of their own UI guidelines.
Saying the web platform is not in sync with mobile is not a relevant metaphor to justify why Android and iOS should be considered separately.
They vary in terms of architectural patterns and ui widgets. RN tries to prevent a single interface, but you quickly reach the point where it becomes a pain. You can use Expo to help, but their libraries are unstable.
So if Shopify had to do major refactors of all their React Native apps, maybe they could look at what it would take to go back to native Platform APIs.
For the Shop App, this coincided with our next major React Native investment: adopting the New Architecture. That work would have required us to revisit native module integrations, rendering, and the boundaries between shared and platform-specific code. Before committing to this investment, we tested whether coding agents could help us build directly in SwiftUI and Jetpack Compose while keeping product behavior aligned across platforms.
The result of that native platform APIs side project involving six devs converting the app's major user workflows?
- startup time reduced: iOS by 23%, Android by 50%
- crashes - 10x reduction
- app size - iOS increased by 1MB (67MB -> 68MB), Android reduced by 109MB (37.2%)
- build time - Android release build time fell ~75%.
- runtime perf - Android builds could draw at 120fps while scrolling feed and switching screens
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.
The problem with tomorrow is sunk costs. There are many places I wish we had made a difference decision in the past - but we need to balance that with cost to make changes when what we have works okay.
There's also a recency bias, where you ignore how valuable some decision was in the past and ignore the fact that you maybe wouldn't even get to the place you are if "you made a different decision in the past".
I can't count how many times I've said "this is really bad, I it is worth rewriting to fix all the issues", only to discover that there were good reasons for all the past decisions and so we end up with the same mess as before - except that now I know what it must be that way.
Not always, but very often people in the past had good reason for what they did.
Those are the comments that should persist in the code. I hate when the AI edits and removes my "why" comments. I want the refactor to make it less messy but keep why it's that kind of mess.
I just put a comment in yesterday for this very reason - there was a flag I had set to false, and then looking at the library docs for something else thought maybe it should be true but that doesn't work how I would have implemented it if I had created the library and written the docs how I did.
It is a very capable library, and when I first started using it the docs were more Oracle docs looking - but I could find what I wanted easily. Now, it is much more annoying to delve through but looks more modern.
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.
it is always the nerds (i’m a nerd, but also run a company and led teams before at a unicorn that IPOd) who obsess over things that normal people would probably not even come to given 100 years
case in point: even some of apples own apps don’t follow their design language.
also some of the most popular apps in the world like tiktok or x don’t use ios glass.
my bank app doesn’t use it and opts for a single theme across platforms.
and you know what? i don’t give a fuck. i just want my money transferred properly, my memes consumed on demand, and that’s about it.
Heard of POSSE? They could post on their websites and syndicate elsewhere. That way, I can access their content thru their website or RSS since I don’t have an Instagram.
LLMs are equalizing this. They use curl and Instagram has dark patterns to stop this. So if you ask a question in a specific niche, LLMs will prefer and refer to users who have their own website.
It’s the same reason popular YouTubers move to Patreon and Nebula once they get established. You never want to solely depend on a platform that can demonetize, or in this situation, take your handle.
Muse might’ve just sold it to them, TBH. I don’t see FB stripping them of it outright. This is not a small band afterall.
I'm old enough to remember when bands did everything on their own sites, complete with message boards. I _really_ miss that. Twitter is just a middle-man nobody wants when you're talking about artists.
