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.

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

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.

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

Tests? Not being flippant, but that strikes me as the new surface to maintain to get what RN used to offer

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

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.

I think the whole native thing is more for better performance, debugging ease and dependency reduction rather than seeking variation in UIs.

It is both. You want the application to look correct on the platform the user is on, i.e. Liquid Glass on iOS and Material on Android.

"GPT-8 Galaxia - figure out where our iOS and Android apps show different doohickeys and fix them"

> 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

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?