[kylemacomber]

I’m one of the engineers that spearheaded this initiative inside of Apple. I just wanted to thank the HN community—I’ve been reading HN for 10 years now and it’s been formative in my development as a software engineer.

If you’re at WWDC stop by the labs and say hi!

[dimmke]

I just wanted to say thank you - I'm a web developer who has been learning iOS dev in his spare time and made the decision pretty early on to build my views programmatically.

It seemed crazy and old school to me to have the UI stuff that IB generates stored in XML - I definitely thought it should generate the same code that you would write to do it programmatically.

Also, the code for building UIs programmatically has been so unnecessarily complicated. Like building a collection view with all the functions needed and boilerplate code compared to the few lines we saw in the demo.

This seems so simple and declarative. It makes me feel a lot better about my future as an app developer. Thanks again!

[astrange]

> It seemed crazy and old school to me to have the UI stuff that IB generates stored in XML - I definitely thought it should generate the same code that you would write to do it programmatically.

Most good ideas are old school. Data is more powerful than code because it can be analyzed in more ways - for instance, you can extract all the UI and text from an app, localize and re-insert it, then verify the UI won't break, all without having to execute the app.

If it's all in code you may not be able to get to some of the views or even know it's there. This is called the rule of least power - an example of getting it wrong is C++ iostreams.

Of course I'm sure SwiftUI has solved this.

[julius_set]

If you find iOS / macOS views cumbersome to write programmatically you should feel fortunate you didn’t have to write Android views programmatically.

[steve1977]

> It seemed crazy and old school to me to have the UI stuff that IB generates stored in XML - I definitely thought it should generate the same code that you would write to do it programmatically.

Well you know, Cocoa and its predecessor OPENSTEP were built on the idea of using IB to compose interfaces out of actual objects that then got "freezed" into a file. So, no code at all, that was the idea.

Building views programmatically was the old school way even back then. ;)

[vor_]

> It seemed crazy and old school to me to have the UI stuff that IB generates stored in XML - I definitely thought it should generate the same code that you would write to do it programmatically.

The idea behind Interface Builder is that it writes the class instances and their properties using NSCoding, and they're decoded at runtime and assigned to your IBOutlets just as if you had initialized them in code, set their properties, and assigned them to instance variables yourself. XIBs were introduced with OS X Leopard as a text-based way to store the files in source control, but they're still compiled into binary NIBs when the project is built. You're not supposed to hand-edit the XML.

[JannThomas]

So I've been working with SwiftUI for the past day and I am completely blank on how one would implement a collection view, like one with multiple rows. I did succeed to do it myself with a VStack and multiple HStacks, inside which I basically put the cells. Did they show this in the demo or was it a one-dimensional collection view?

[sjroot]

I was hoping to hear more discussion about performance. At the root of this seems to be a flexbox-esque implementation in Swift. Yoga, one such flexbox implementation written in C, has touted much better performance over UIKit for a while. How do apps built with SwiftUI compare to their UIKit alternatives? How would it compare with some solutions already in the Swift OSS community that utilize flexbox? [Texture](http://texturegroup.org/) comes to mind but I'm sure there are others.

It must be so much fun to work on a project that impacts so many developers. Thanks again!

[weberc2]

Minor bit of pedantry--Yoga is written in C++.

[tekstar]

Back in 2016 we built layer in Swift with a similar goal at Shopify, called FunctionalTableData.

FTD's syntax isn't nearly as nice as SwiftUI, but there's many similarities.

https://github.com/Shopify/FunctionalTableData

Purely for our own vanity - did Apple engineers take any inspiration from FTD? Or just independently set out to solve the same problems we had?

[fontenaut]

I saw somewhere that all this started around 2012.

[vbezhenar]

IDE support is jaw-dropping. I did not see that kind of integration between text and UI anywhere. Framework code looks like React from the first glance, but IDE integration is game-breaker.

[bsaul]

After 10 years of following wwdc: you may want to temper your expectations as to what this will truely feels like once this runs on your machine, on a real-size project.

Apple is famous for making great on-stage demos that collapse once they're faced with the real-world (eg: basically anything related to having a great xcode experience)

[liuliu]

New (or kinda new?) Framer X tries to do that for React: https://www.framer.com/development/

[vijaybritto]

This is incredibly awesome! Did you get inspired by the web or by new frameworks like flutter?

[mooman219]

This looks very similar to Flutter, I wouldn't be surprised if they took some ideas from that which is all well and good; UI construction needs a facelift.

[let_var]

Super. Declarative UI has been one of the differentiator between native UI development vs say React on the browser. ComponentKit and co. are there but having something official from Apple makes it 10x better!

Edit: Also, thank you!

[ghoji]

Does Apple allow employees to post comments like this now? :O

I thought they were crazy strict and would, like, fire people for posting on forums or Twitter

[saagarjha]

Apple has a set of guidelines for public comments: they don’t restrict employees from commenting publicly entirely, but there are quite a few things they can talk about (such as products that just launched…)

[Grustaf]

Well, why do you think he only posted one comment and then disappeared...

[dep_b]

I'll start wearing tin foil hats again as you built exactly what I had in mind when thought what the future of a Swift-based UI should look like. Literally every box checked.

[sdegutis]

How would you compare this to React.js? In particular, how does SwiftUI approach the concepts that Redux solves [EDIT: in other words, state management]?

[_bxg1]

  @State var model = Themes.listModel

I haven't tried it out, but the above looks more like MobX:

  @observable model = new MyListModel();

[baby_wipe]

https://developer.apple.com/documentation/combine

[rat9988]

Redux and react are two different questions.

[seanalltogether]

Looking over the references and docs, this is pretty much the builder pattern to generate the view tree and data binding to update it.

[trevor-e]

Looks very similar to Anko (a Kotlin Android UI DSL). Awesome work, can't wait to try it out.

[Kendos-Kenlen]

It is. And I think SwiftUI will only push people toward Anko as this kind of libraries/tools will become popular. Also, some concurrence with make both tools even better. That's great news!

[tdiggity]

Thank you, this is awesome! I've been hesitant to jump into iOS on my own time. This will push me to build something for fun now.

[seanalltogether]

Does this support stylesheet based styling?

[dep_b]

Good question, so far it doesn’t seem so

[diffset]

Where does this leave Storyboards? I can't see complex UI being built in SwiftUI

[divanvisagie]

People are using storyboards for complex UI? I was under the impression that people used the more manual processes with larger teams.

[myko]

This is the exact opposite of how I feel. SwiftUI will be much better for that scenario.

[tigershark]

Hi, great work! Is iOS 13 required to use apps made with swift ui?

[anchpop]

That would be unlikely, as they probably want to support everyone's old apps for a little while at least

[cjf101]

Thank you to you and your colleagues! I bounce back and forth between web and apple front end dev, and at first glance, this hits a lot of the highlights from both worlds.

[yonilevy]

This looks fantastic, congrats! Any word on whether 3rd party IDEs will be able to integrate the live-preview functionality? (AppCode user)

[snuxoll]

I assume AppCode will support this the same way it does with InterfaceBuilder and Storyboards - i.e. it won’t do anything but launch XCode to handle it.

[pier25]

Nice work!

In the keynote it was mentioned that SwiftUI would work across all Apple products.

Will it work on previous versions or only the latest iOS/macOS/etc?

[megy]

What? You develop it using SwiftUI, then you compile it and it will run on whatever you compile it to. So yes, it will run on older OS versions.

[oflannabhra]

Thank you! Looks like your work will impact me (and hundreds of thousands of other developers) every day.

[samskiter]

Now you've really given us a dilemma - switch to Flutter or wait and see if SwiftUI goes open source....

[cuddlybacon]

This looks fantastic. I work on a little macOS app as a hobby thing, and am excited to try this out!

[jiyinyiyong]

If Apple is willing to create a GUI tool for generating the DSL used in SwiftUI, it's not far from enabling UI designers to generate UI by themselves. We may need a lower-level representation for the DSL though. I think it's not a problem that we go one step further and make it happen in the next few years.

[diroussel]

You could call this hypothetical tool Interface Builder.

[zerr]

Is an imperative API available as well?

[jpochtar]

Fantastic work you've done here!

[jamanon]

Can I use that in an existing app?

[myko]

Only if you only support the latest OS versions.

[telcy]

Thanks. Really good job

[zachgray]

not all heroes wear capes