| ▲ | tonic_note 4 hours ago |
| Models have gotten a lot better at generating native iOS apps. The main appeal of RN was being able to leverage your web devs for mobile dev. that's what I did at my last company. And it's fine for a startup, but eventually you want dedicated native engineers bc each platform really deserves its own technical masters who can optimize for it. 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. |
|
| ▲ | spiderice 3 hours ago | parent | next [-] |
| Nobody is talking about the real advantage of RN: Being able to release to the App Store without having to go through a review. That's so massive. Getting a bug fix out to users instantly, sneaking in optimizations, etc.. 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. |
| |
| ▲ | tcoff91 3 hours ago | parent | next [-] | | Over the air updates is SO valuable with react-native. Being able to ship hotfixes instantly to our users has saved our asses multiple times. | |
| ▲ | azuanrb 2 hours ago | parent | prev | next [-] | | I’ve worked with both native and cross-platform. I think the mentality of being able to make changes quickly without much review often comes from cross-platform, especially when the developers come from a web background. 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. | |
| ▲ | sebmellen 3 hours ago | parent | prev [-] | | This is so true, and I'm surprised that Shopify didn't mention it or that they don't use OTA updates. |
|
|
| ▲ | robertlagrant 4 hours ago | parent | prev | next [-] |
| You always still needed a specialist per-platform even if most of the code was RN or KMM[0]. But I agree - a thousand not-great mobile apps sprang from this idea. [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. |
| |
| ▲ | dd8601fn 4 hours ago | parent [-] | | > a thousand not-great mobile apps sprang from this idea. 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. | | |
|
|
| ▲ | _fzslm 4 hours ago | parent | prev | next [-] |
| This is true in a very real sense – models can help you build native apps very quickly, no question. But how do you keep them from drifting apart from one another as you add/change features or design? Right now, there isn't much tooling for this. React Native's advantage of having a single source of truth for code hasn't quite gone away yet, imo. |
| |
| ▲ | nodamage 20 minutes ago | parent | next [-] | | I don't understand the question. If the model built both apps why wouldn't it also be building the new features on both platforms at the same time? 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? | |
| ▲ | tiborsaas 4 hours ago | parent | prev | next [-] | | You create a source of truth which defines all the features and requirements. This can be UI tests, MD files, database, diagrams, whatever that fits your use case. | |
| ▲ | wsor4035 3 hours ago | parent | prev | next [-] | | I've only read about it from it showing up on hn[1][2], but you can use slick to convert your swiftui to jetpack compose for a andriod build from the ios source of truth link to project: https://github.com/skiptools/skip [1] https://news.ycombinator.com/item?id=41384144
[2] https://news.ycombinator.com/item?id=46706906 | |
| ▲ | chasd00 4 hours ago | parent | prev | next [-] | | i think you would have your coding agent work on both code bases at the same time. You could also task with generating identical tests for each platform. It's easier for a model to keep up with that kind of tedium than a human. Plus you can just tell the model to keep re-doing things until you're happy and it won't quit. 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. | |
| ▲ | replygirl 4 hours ago | parent | prev | next [-] | | the problem is that single-source advantage gradually falls away as you develop your software into something that feels good to use on each platform. and once you have a quality product you're left with perfunctory coupling that makes it harder to adopt the latest platform features | |
| ▲ | patcon 4 hours ago | parent | prev | next [-] | | Tests? Not being flippant, but that strikes me as the new surface to maintain to get what RN used to offer | |
| ▲ | Dfiesl 4 hours ago | parent | prev | next [-] | | Android and iphone emulator MCP, model compares screens, flags is theres drift? Something like that I’d guess | | |
| ▲ | professoretc 4 hours ago | parent [-] | | But the screens should look different, right? That's the point of building separate iOS vs. Android versions is to make each version "native" to its platform. The feature-set should be the same, but the interfaces can diverge. | | |
| ▲ | Dfiesl 4 hours ago | parent [-] | | I think the whole native thing is more for better performance, debugging ease and dependency reduction rather than seeking variation in UIs. |
|
| |
| ▲ | akd 4 hours ago | parent | prev [-] | | "GPT-8 Galaxia - figure out where our iOS and Android apps show different doohickeys and fix them" | | |
| ▲ | otabdeveloper4 4 hours ago | parent [-] | | > You're completely right to call me out on this. Here's the real smoking gun: the iDoohickey isn't a real API interface on iPhone |
|
|
|
| ▲ | throwaway27448 an hour ago | parent | prev | next [-] |
| > The main appeal of RN was being able to leverage your web devs for mobile dev. 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 |
|
| ▲ | kypro 2 hours ago | parent | prev [-] |
| > The main appeal of RN was being able to leverage your web devs for mobile dev. > 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. |
