Hacker Newsnew | past | comments | ask | show | jobs | submit | _fzslm's commentslogin

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.


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.


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.

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?


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

"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 appreciate the unprecedented load GitHub is currently experiencing, but it's not just the (admittedly extreme) load of commits/pushes that is to blame.

Their Copilot cloud agent offering is suffering with a case of some of the worst corporate ADHD I've seen. We built a cloud agentic development pipeline on it, and it seems like almost every other week they silently change something with zero public announcement that creates real disruption for our team.

Note: that's not bugs in the Copilot platform like the article discusses. That's real, breaking changes to the platform that clearly aren't being tested/reviewed before being pushed to prod, with zero public announcement or documentation.

Support is useless – we're paying customers in the 4-5 figures and our tickets go unanswered.

I love(d) GitHub, but I do think they've lost enough public trust at this point that their time is ticking. With talk of new VCSes designed specifically for agents, I do believe it is just a matter of time. Which pains me somewhat to say.


It's a low power transflective LCD branded as e-paper, not e-ink. So it has none of e-inks downsides (namely low refresh rate and image persistence)


For that you probably want this, lol: https://cssdoom.wtf/


Not only this, but it's like Illustrator, Photoshop and InDesign all mixed up into one super-app. This beats Adobe's cross-app functionality by miles.


I have a gorgeous Surface Pro 11 X1 Elite that can run just enough Linux to tease me with how beautiful it could be, but it's still unstable enough that I can't daily it.

Torture.


It's really that weak?


Anthropic being pissed enough to announce this means that, despite encrypting their reasoning chains, it doesn't matter – distillation lives on.

Sweeeeeeeet.


Cat and mouse measures like this rarely work forever.


Love the graphics, the 8-bit style of the people's portraits is really well done. Are those AI generated?


Yep, those are from "the weights" of GPT-5.4 Image 2 with a little "draw <name>" query and a style reference. More details here https://intheweights.com/about


Why can't it draw Elvis and Hitler?


It is on a 10 minute interval and only does images for the top people, should pick up Elvis shortly. On refusal it shows an X for the person, sometimes the upstream model (gpt-5.4 image 2) will refuse and there are a few names I manually omitted.


Why refuse Adolf Hitler, but allow Vladimir Putin? I mean, it's not a race, but if you're going to draw a line in the sand (labelled 'no admittance to utter cockwombles' or something like that) I know where Putin would end up. Are those models refusing one and allowing the other? Why do they even refuse one?


Really interesting project. Do you have a link to a writeup/paper?


The closest thing would be our showcase poster[0], at some point I might write about the thought/development process (both for my sake and whoever picks up the project in the future)

[0] https://docs.google.com/presentation/d/1jsJ5euZ4VXcwL4fbgJKM...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: