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 an hour 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 4 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 5 hours ago | parent | prev | next [-]

Android and iphone emulator MCP, model compares screens, flags is theres drift? Something like that I’d guess

▲

professoretc 5 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 5 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