3 ms·

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 anoth

by _fzslm 24d ago

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.

Dfiesl 24d ago
Android and iphone emulator MCP, model compares screens, flags is theres drift? Something like that I’d guess
- professoretc 24d ago
  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 24d ago
    I think the whole native thing is more for better performance, debugging ease and dependency reduction rather than seeking variation in UIs.
    - myko 23d ago
      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.
akd 24d ago
"GPT-8 Galaxia - figure out where our iOS and Android apps show different doohickeys and fix them"
- otabdeveloper4 24d ago
  > 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
patcon 24d ago
Tests? Not being flippant, but that strikes me as the new surface to maintain to get what RN used to offer
chasd00 24d ago
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.
tiborsaas 24d ago
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.
replygirl 24d ago
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
wsor4035 24d ago
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 https://github.com/skiptools/skip [1] https://news.ycombinator.com/item?id=41384144 https://news.ycombinator.com/item?id=41384144 [2] https://news.ycombinator.com/item?id=46706906 https://news.ycombinator.com/item?id=46706906
nodamage 24d ago
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?

by _fzslm 24d ago

Dfiesl 24d ago

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

professoretc 24d ago
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 24d ago
  I think the whole native thing is more for better performance, debugging ease and dependency reduction rather than seeking variation in UIs.
  - myko 23d ago
    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.

akd 24d ago

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

otabdeveloper4 24d ago
> 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

patcon 24d ago

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

chasd00 24d ago

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.

tiborsaas 24d ago

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.

replygirl 24d ago

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

wsor4035 24d ago

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 https://github.com/skiptools/skip [1] https://news.ycombinator.com/item?id=41384144 https://news.ycombinator.com/item?id=41384144 [2] https://news.ycombinator.com/item?id=46706906 https://news.ycombinator.com/item?id=46706906

nodamage 24d ago

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?