Comment by atonse
1 day ago
We did the same thing - had 90% of it overnight. Then spent a few days in the background tweaking for polish.
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.
How are you evaluating the Android build if you don’t use Android and you don’t know Kotlin?
We have people on the team that are android users. I just meant that I don't want to evaluate whether it feels "native" as I personally am not an Android user.
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.
I work as a professional app developer. And I find this take to be naive.
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.
16 replies →
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.
2 replies →
> You just install it on your phone and use the app.
Some people on the cybersecurity side are starting to cry....
15 replies →
> You just install it on your phone and use the app.
OP says they don't have an android phone...
5 replies →
I am using Gemini as well as Opus on a somewhat small project in React Native and I can not imagine this thing being able to build the whole thing on its own without it being a dumbpster fire.
Can you share some details of how you work? What models? What harness?
7 replies →
That's a recipe for regressions as the amount of surface you have to cover with "just...use the app" gets bigger and bigger.
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.
Damn, we really gotta get rid of the vibe coders. Bad things are on the horizon if we keep encouraging these naive habits.
4 replies →
> You just install it on your phone and use the app.
That‘s how you check functionality but that’s not how you get the bugs in the code.
4 replies →
Remember the first step to fixing any problem is admitting you have a problem.
If you are blind, you cant see anything wrong, if you are deaf uou cant hear anything is wrong.
Seriously! What a bonkers thing to claim. "I had codex use maestro so I assume it made Android work well and idiomatically".
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.
> It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem,
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.
1 reply →
I answered elsewhere that I don’t personally use Android phones but we have people on our team that do. Which is why I don’t want to personally claim that it feels native.
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.
1 reply →
> this yolo approach would give me constant dread.
When you’re completely ignorant, there’s nothing to be afraid of.
I wrote every single line of the react native app we ported, and maintained it for 9 years. So suffice to say, I'm familiar with the code.
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.
4 replies →
First “production is down” page means you just tell codex production is down and to fix it.
4 replies →
[dead]
ITT: people dealing with realities.
Remember Chinese accounts on US Facebook say data centers are bad.
React native is an obstacle compared to what clear Swift/Kotlin code may produce. Swift is very powerful and Kotlin, in all honesty, is the first reasonable and very useful thing to come to the JRE ecosystem (save for Scala, which is, well, quite complex still).
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.
Sounds like the advice to newcomers is to not worry about trying to learn a programming language. There already is an llm to program for you, and do it better than you could, so just learn how to talk.
Once you understand how to write a program get someone else to write it - Perlis.
[1] Epigrams in Programming:
https://engineering.yale.edu/academic-study/departments/comp...
And people say AI isn't taking SWE jobs...
While I mostly agree with you, this is the kind of thing that might not have been done if the AI couldn't do the heavy lifting.
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.
That's an example of AI growing the sector that can lead to more jobs. Because suddenly a lot of tasks that weren't economically viable are now going to be in demand. Custom software for small businesses, platform specific optimized code instead of cross platform software, etc...
This is a type of project that likely wouldn't have been done before AI
Of course it would. Supply and demand. Some companies would decide not to bother. Others would decide it was worthwhile. The limited pool of supply (app developers) would be distributed across demand.
6 replies →
This app has 15/20 screens, an app this small wouldn't employ many people to begin with. Before there was one guy (op) maintaining it in react native and now he maintains it native. I don't see much change tbh.
The optimistic outlook:
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.
This is an incredibly boring task. Nothing new, just rewrite everything to just see it all rewritten again in 1 year. Perfect for LLMs and something humans shouldn't do.
While I agree with that statement -- that is also a lot of jobs. We have a lot of humans -- not every single developer sits in the innovation seat. The fewer the jobs available the less employable humans.
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.
1 reply →
> This is an incredibly boring task.
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.
2 replies →
This is just not true. In the olden times (pre-claude) devs were constantly asking to do full rewrites of legacy code. This kind of project is exactly the kind of work I've trained for and have loved to do for the last 15 years as a mobile dev.
It ported overnight. I don't think it would create from scratch without a lot of hand holding.
Previous company I worked for would have (and did) hire dedicated swift/java mobile developers to build and maintain ios and android native versions (largely porting functionality from an existing web application)
Not anymore.
3 replies →
This does seem like the kind of task LLM's are ideal for. Just like that port of Bun from one language to another.
I thought the same, but then I build a few complicated apps and thought I could keep the different codebases stable but still was a headache, so switched web, ios, android all back to expo/rn. I love that testing is only (almost) only thing now, instead of 3 platforms.
I assume having Kotlin and Jetpack Compose makes it much easier than it was back around 2020?
React native is broadly an inferior option.
LLMs made it way worse https://ashishb.net/tech/react-native/
this is from 2021....
and still accurate in its conclusion, probably moreso today
Congratulations, you now have 2 codebases to maintain.
So now you have two vibe coded applications you don’t understand. I’m not an advocate of making “job security” decisions but this definitely goes to red flag territory. Was it your job to maintain the RN codebase or do you have other functions there as well? I’m not sure I would keep a native noob on a vibed native codebase. What is your take?
And there's no proprietary IP in your company's app that you don't mind being sucked up into the training data?
> there's no proprietary IP in your company's app
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.
Are you saying you don’t trust ZDR claims from inference providers?
They don’t care about your code. There’s more and better data on the public web.
Isn't ZDR only the case if you "opt out" through a setting? Lots of opportunities to make a mistake here, or for the LLM provider to play games. You could be unaware of the setting. The provider could reset the setting upon subscription lapse/renewal, application update, model release, etc. A developer could accidentally use their personal subscription (w/ setting on) on a work codebase.
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?
8 replies →
The value of most companies/apps are in the relationship with the customers, so it's the database, not the code.
Definitely agree. Most developers could build a basic Twitter or Facebook clone. The hard part is getting the users, content, and relationships that make the product worth coming back to.
1 reply →
As other have mentioned, the code isn't the valuable part. But also there are alternatives now to these LLM providers.
Frankly there’s more likely to be proprietary IP in the server side code than in mobile apps.
True, but shops are exposing everything to Claude or Open AI. It's akin to outsourcing all manufacturing to subcontractors in China. That was cheaper, but extremely short-sighted. Now so many products have cheap Chinese knock-offs that are nearly the same as the originals because the subcontractors made both.
Codex with what model?
I think probably GPT 5.5, or 5.6 Sol - it was ~ 2 months ago.
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.
This has been my conclusion as well. Agentic workflows drops the effort level in keeping two native code bases in sync.
Same conclusion here. My current preferred setup is native for iOS and Android with common core in rust exposed through uniffi
I was surprised by your comments and then you do Rust to be called via Java or Kotlin and Swift?
What does your app do?
2 replies →
Next up, designing an even higher level language which will be used by LLMs to compile to high level languages like kotlin or swift. Just store instructions for LLMs in repos.
I hate to break it to you, but we already have it: it's called PHP
[flagged]