[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.

[tsss]

Bullshit, any language with a macro system can do this. LISPs in particular are known for being code and data at the same time and this idea is way more old school than XML. You could also make a DSL that builds something like an AST of your UI in a similar fashion to free monads.

It's no surprise that XML seemed more attractive when your alternatives were Java or, even worse, Objective C. But really both options are absolutely terrible.

Thankfully we are very slowly making some steps forward again with Swift.

[astrange]

But we don't want the data and code to be the same, we want the data to be less dynamic than the code. You can't find out what the UI of a Lisp program would be without executing the program. It has everything available all the time, which is bad and turns you into a Lisp weenie.

SwiftUI is using new Swift features sort of similar to Haskell's "do" notation, which isn't actually itself monads.

[infinite8s]

Well the oldest ideas are around the notion that code is data and should be manipulated as such (from the 50s).

[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.

[lanjoe9]

You can always create a layout XML file and inflate it. It saves tons of time. I can't imagine why you would do thing in code instead of inflating and attaching them.

Honestly, if not for SwiftUI, I find developing interfaces in Android to be infintely faster than either fighting Apple's Interface Builder or building things by code in Swift.

[myko]

True but who does this? The Android framework isn't built to support that reasonably at all, at least not until Jetpack Compose becomes viable.

[Cthulhu_]

Wasn't that the default way of doing things in Android? That is, build your ui's in XML?

[myko]

By writing views programmatically in Android they mean writing them in Kotlin or Java, not XML. Almost no one does this.

Though Kotlin has an interesting looking DSL for doing that named Anko.

[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. ;)

[sjwright]

And the IB approach is a nice one, except that its files (whether NIB or XIB) simply don't diff as nice as the equivalent in code. Checking changes into source control is an opaque experience as the diff is an endless vomit of unintelligible mumbo.

What is so astonishing about SwiftUI is that it's simultaneously the most impressive looking visual GUI builder I've ever seen... and the most terse, diff-able syntax I've ever seen. I can't think of anything that has combined these two properties quite so successfully.

[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++.

[arcatek]

Both are kinda true - Yoga started as a C library, but was ported over to C++ ~a year and a half ago.

[hellofunk]

If that’s true, maybe they should update the first paragraph of their github page, which clearly says the library is written in C.

[hellofunk]

Yogas github page clearly says that it is implemented in C in the first paragraph.

[weberc2]

It's wrong.

https://github.com/facebook/yoga/tree/master/yoga

[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.

[vijaybritto]

I think if flutter can provide this kind of editor support and experience it would be indispensable for me! Also I'm pretty sure the web would emulate this one pretty soon!

[lucasverra]

swift ui to react !

[gwright]

That is exactly what I said when I saw the code on the screen. Now if they released a development environment for Android also.... (wishful thinking)

[munificent]

If you want a Flutter-inspired framework that works on iOS and Android, have you considered, uh, Flutter?

[oakesm9]

If you mean and official declarative UI library then Google released one of those at Google IO this year:

https://developer.android.com/jetpack/compose

[gwright]

I am very interested in multi-platform Kotlin. I'm not sure how far it will get but on the surface I think it is more likely for Kotlin to work on iOS than Swift on Android.

Still learning about compose.

[fphilipe]

> it is more likely for Kotlin to work on iOS than Swift on Android.

Who knows... With Chris Lattner at Google and Google adopting Swift for TensorFlow, I could well imagine Swift eventually working on Android (or something newer).

[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();

[ng12]

I think it's a closer analogue to React.useState.

[kartickv]

Does that mean that UI will automatically get updated when the model changes, and you no longer need a mess of dependencies, like "if A changed, update X and Y".

[aaronbrager]

Yes

[_bxg1]

useState is for cobbling together state onto what's supposed to be a pure-function. SwiftUI, like MobX (in its normal usage), is class-based and keeps state in a class member.

[ng12]

What's the difference between a class and a function with local state?

(Semantics aside, either way this behavior is implemented in React via useState or setState, MobX has nothing to do with it)

[tsomctl]

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said “Master, I have heard that objects are a very good thing – is this true?” Qc Na looked pityingly at his student and replied, “Foolish pupil – objects are merely a poor man’s closures.”

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire “Lambda: The Ultimate…” series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying “Master, I have diligently studied the matter, and now understand that objects are truly a poor man’s closures.” Qc Na responded by hitting Anton with his stick, saying “When will you learn? Closures are a poor man’s object.” At that moment, Anton became enlightened.

[_bxg1]

MobX takes normal data (usually class properties) and makes it observable, via an annotation. That very much appears to be what the @State annotation in the Swift code is doing, though I don't know for sure.

setState is a totally special container for data; while it technically lives in a class member (this.state), it can only be modified via setState. It isn't observable, so much as setState just internally triggers a render directly.

useState is different because your state lives out somewhere in React's core framework, associated with your function only through a value and a callback. It doesn't live in your function's local scope itself, because it would get lost if it did. It's very weird and funky because the whole point of non-class components is for them to be pure functions which have no state. useState is this shortsighted workaround for that self-imposed limitation.

Redux, finally, is different because its new states are determined as a pure function of the current state and some change. It's the polar opposite of MobX's mutable-observables pattern. Neither is strictly better, but they're as different as can be.

[asark]

> What's the difference between a class and a function with local state?

Practically nothing, especially since it is stored in objects and the code uses a lookup table to figure out which ones are part of your function's "this" (essentially), IIRC from reading the code. The similarity to how one implements objects/classes has been good for some laughs.

[EDIT] in "React Hooks" specifically, I mean.

[aaronbrager]

SwiftUI is protocol-based, not class-based

[baby_wipe]

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

[sdegutis]

This looks an awful lot like ReactiveX.

[myko]

It does. It's kind of disappointing - would rather they build off what the community has in RxSwift, which is pretty feature rich and robust.

[rat9988]

Redux and react are two different questions.

[sdegutis]

When people make alternatives to React, at some point they have to address the concept of state changes and side-effects, building in conveniences for it, or leaving it for third parties to develop this area.

[nickbauman]

... Or use something like Reagent where there is language level support for reactive state management using atoms.

https://github.com/reagent-project/reagent

[sdegutis]

That looks like exactly what SwiftUI is doing.

[ng12]

This has nothing to do with Redux. Redux is about storing global data, nothing more.

[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

[sjwright]

As long as SwiftUI has some support for inheritance and arbitrary variables for all elements like colours, fonts and dimensions, I don't think a stylesheet system would be necessary.

This is the sort of thing that will become clearer as real developers start using it. And I'm sure Apple will learn a lot as people start building bigger apps with it.

[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.

[cjf101]

Storyboard references made composing complex UI possible, but IMX there's almost always some breakpoint where it's just less complex to do it with code.

[ardit33]

you are right, not sure why you are being downvoted

Almost no large scale app uses storyboards for most of their ui....

[travisgriggs]

I do a mix. The "program by painting" is great for some things and sucks for other things. Unfortunately, programming UIs entirely by text is terse for some things and incredibly laborious/tedious/boilerplate for others (e.g. doing autolayout in code sucks).

So I end up doing both. The problem (and I've seen this for many years with other similar systems), is that you have to become relatively comfortable with both approaches, so you can make informed decisions about when to flip back and forth. When can I do this with IB even though it's a teensy hacky vs when should I just subclass UIView and take over layoutSubviews and friends?

That's been my experience at least. YMMV.

[EdwXD]

yes, my team have been using Storyboard/xib for 99% Auto Layout declaration, PaintCode for rendering custom components (which can be shown directly inside IB), RxSwift/RxCocoa for MVVM

[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

[Klonoar]

Nope, iOS13 is required, as SwiftUI is a system framework.

[pier25]

So I guess macOS 10.15 too, yes?

[snuxoll]

According to the documentation the latest OS release is required on all platforms SwiftUI targets.

[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.

[awinder]

https://news.ycombinator.com/item?id=20088593

[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.

[jiyinyiyong]

Watched several short videos, it seems they are already doing that by dragging component to generate code, by configuring parameters in the code with panels. It's very approaching.

[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