This article hints at what I feel is one of the not-yet-realized transformations that LLM coding brings: can we finally drop Electron/React Native and just have LLMs automate the work of transforming Figma/wireframes and behavior specs into truly native apps for each platform?

For CRUD apps, the API spec and UI mockups -- or even a photo of how it looks on the already coded platform -- would go a long way. That's exactly the kind of well defined task work LLMs do well with. It should be possible to automate a lot of the equivalence testing too.

Is there still an excuse for "maybe we'll add Android someday" or "not enough Mac/Linux users"? And is there still a justification for not building those less-used flows like password reset into the iOS app instead of throwing up random WebViews?

For those apps that do have non-trivial logic on device, LLMs have shown a lot of promise at rewriting to cross-compiling-is-easy languages like Go or Rust.

▲

tptacek 4 hours ago | parent [-]

Yes. You can do that. It works right now. It works really well.

My original spicy take is: why learn SwiftUI at all at this point? It's a skill that, for most tasks, falls into the same kind of bucket as "learning Microsoft Word really, really well". I appreciate people who take the time to do that, but the outcomes are within millimeters of each other whether or not we do that.

I don't think that's true of programming generally. But I think there are languages now where the rationale in specializing in them has gotten, hrm, more complicated.

▲

TheNightman 42 minutes ago | parent [-]

I’m a SwiftUI developer at $DAY_JOB so maybe biased but while Claude can make things that look right it’s still not exactly perfect. Especially from designs. I used Claude design to mockup a monitoring app for my talos cluster and Claude code totally freestyled it. What should have been as simple as `List { Section(“title”) { … } }` got morphed into whacky DIY `VStack {}.background(.gray)` nonsense.

It looks off and it’s suboptimal performance-wise. It was, I’d say, 80% of a proper SwiftUI app (which is really fantastic given it was basically a one-shot).

Actually knowing SwiftUI meant it was trivial for me to just close out that remaining 20% by hand and have an actually *nice* cross platform (iOS, iPadOS, macOS) app.

I’m sure I could have prompted it to get it done right but without proper knowledge on the subject I wouldnt even know what was wrong and Claude doesn’t do so hot with “that just feels wrong”. Beyond that it was quicker to do it myself, but maybe I just need to prompt better /:

	▲	tptacek 35 minutes ago \| parent [-]
		I have absolutely no doubt that an experienced SwiftUI macOS developer could easily produce better UI than Claude can today. The thing is, Claude produces better UI than a replacement-level macOS developer can, and, much more importantly --- this is really the core of my argument --- \infty better UI than a typical developer can produce, because most developers don't ever build native UI. If I'm shipping a product where each development/release cycle costs my team $5MM, I am absolutely going to spring for the professional SwiftUI developer. But most things normal developers build in their spare time don't even cost $50 per cycle. Unless they're UI learning projects or projects by UI experts, there is no "budget" for UI. At best, for real labor-of-love projects, you get a TUI where the developer spends 5 hours of their life that they will never get back creating a 70%-functional terminal version of the affordances the native UI toolkit provides out of the box. That's all over now. However competitive Claude-generated SwiftUI user interfaces are with expert SwiftUI projects, they roflstomp the UI options available to most developers. I can't say enough what a smoking gun the flickering Signal app is here!