top | item 20087168

SwiftUI

765 points| fphilipe | 6 years ago |developer.apple.com | reply

379 comments

order
[+] kylemacomber|6 years ago|reply
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|6 years ago|reply
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!

[+] sjroot|6 years ago|reply
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!

[+] tekstar|6 years ago|reply
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?

[+] vbezhenar|6 years ago|reply
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.
[+] vijaybritto|6 years ago|reply
This is incredibly awesome! Did you get inspired by the web or by new frameworks like flutter?
[+] let_var|6 years ago|reply
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|6 years ago|reply
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

[+] dep_b|6 years ago|reply
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|6 years ago|reply
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]?
[+] trevor-e|6 years ago|reply
Looks very similar to Anko (a Kotlin Android UI DSL). Awesome work, can't wait to try it out.
[+] tdiggity|6 years ago|reply
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|6 years ago|reply
Does this support stylesheet based styling?
[+] diffset|6 years ago|reply
Where does this leave Storyboards? I can't see complex UI being built in SwiftUI
[+] tigershark|6 years ago|reply
Hi, great work! Is iOS 13 required to use apps made with swift ui?
[+] cjf101|6 years ago|reply
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|6 years ago|reply
This looks fantastic, congrats! Any word on whether 3rd party IDEs will be able to integrate the live-preview functionality? (AppCode user)
[+] pier25|6 years ago|reply
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?

[+] oflannabhra|6 years ago|reply
Thank you! Looks like your work will impact me (and hundreds of thousands of other developers) every day.
[+] samskiter|6 years ago|reply
Now you've really given us a dilemma - switch to Flutter or wait and see if SwiftUI goes open source....
[+] cuddlybacon|6 years ago|reply
This looks fantastic. I work on a little macOS app as a hobby thing, and am excited to try this out!
[+] jiyinyiyong|6 years ago|reply
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.
[+] zerr|6 years ago|reply
Is an imperative API available as well?
[+] jpochtar|6 years ago|reply
Fantastic work you've done here!
[+] jamanon|6 years ago|reply
Can I use that in an existing app?
[+] telcy|6 years ago|reply
Thanks. Really good job
[+] archagon|6 years ago|reply
Lots of engineers are suggesting that SwiftUI, plus other declarative frameworks, might be "the future" of app development. However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing. If you're working with highly interactive interfaces, complex animations, or dense, layered documents (DAWs, video editors), it seems that you would need explicit state and imperative code at the center of it all, and that a declarative approach would require hacks and workarounds at every turn. In my humble opinion, some of the most interesting, ground-breaking, and creative software has these properties; whereas this reactive stuff seems tailored to bog-standard utility software.

However: I've never used React or any of its derivatives, so this is mostly inference. Is this take accurate or not? In theory, could you scale SwiftUI to build something like Logic, Blender, or Photoshop (for example)?

Also, have any declarative UI frameworks been released that feature a "platform" layer, where you get to define how your declarative code actually turns into UI, widgets, and behaviors? It seems that SwiftUI relies on (encoded) assumptions of what an ideal UIKit or AppKit app is supposed to look and feel like, and it would be really powerful if we could mess with this foundation or even swap it out entirely.

(It's very possible I'm mixing up reactive/declarative/reactive-UI concepts since I'm not too familiar with the territory.)

[+] fphilipe|6 years ago|reply
Personally, as an iOS developer, this is by far the biggest announcement.

Haven’t had the chance to dig deeper, but the comparison between the UITableViewController and that snippet containing just declarative code looks absolutely promising.

The only downside is that we’ll have to wait one or two years before we can use it if older iOS versions still need to be supported. Let’s hope for extra quick adoption of iOS 13.

[+] eugeniub|6 years ago|reply
Unfortunately, iOS 13 drops support for iPhone 5s and iPhone 6.[1] Last year, iOS 12 didn't drop support for any devices. The iPhone 6 is a very popular device, and was still sold by Apple less than two years ago.

[1]: https://iosref.com/ios/

[+] PabloSichert|6 years ago|reply
I've been working on a very similar framework[1], but wasn't satisfied with the ergonomics enough to release it.

My plans were to extend the Swift compiler with JSX-like syntax[2] that makes use of the declarative framework. Of course that's still possible, especially now with a canonical "Apple" way of building declarative interfaces in Swift.

I'm a bit sad that with the announcement of SwiftUI my implementation will not stand a chance anymore, but I definitely learned a lot along the way how declarative rendering and reconcilation works in detail.

Bottom line - this is very great news for native app development, declarative UI makes it vastly more easy to reason about code.

[1] https://github.com/PabloSichert/Sx/blob/master/Example/Incre...

[2] https://facebook.github.io/jsx/

[+] oflannabhra|6 years ago|reply
This is fantastic, and I am almost upset by how little info the keynote address included. Obviously there will be a ton of detail coming out this week with the labs and documentation being released, looking forward to that.

As an iOS developer, this is by far the biggest announcement. This has huge potential to provide value to me and my team. I'm looking forward to ripping out programmatic NSLayoutConstraint and Interface Builder from my projects ASAP. This seems like it includes much more than that, however.

[+] Jerry2|6 years ago|reply
The "real" developer keynote is "Platforms State of the Union" which will surely cover a lot more of it. The morning keynote is for the press and executives to highlight latest releases with some dev stuff thrown in.
[+] kennywinker|6 years ago|reply
Details will be in the Platform State of The Union later today. Keynotes are always press/casual-fan focused
[+] untog|6 years ago|reply
I'd be curious to know how many React Native devs work on cross-platform apps. In casual conversation I've had it actually isn't that high, despite it being one of the central promises of RN.

Given that SwiftUI has live reloading and a sensible template interface I could absolutely see it winning over some RN devs. There's something to be said (particularly with Apple) for using the native toolset rather than RN, Flutter and the like.

[+] zapzupnz|6 years ago|reply
I'm sure SwiftUI has been in development for a long time, but it seems to me to be Apple's response to frameworks like React Native and Electron.

We get a simple way to make UIs for multiple platforms, we get a nice batteries-included language, and Swift 5.1's dynamic method offers a similar functionality to hot reloading.

Of course, it can't answer everybody's needs (no Windows, Linux, or Android support) but combine SwiftUI with Project Catalyst, and I'm really hoping to see plenty of high-quality cross-platform apps that don't have a whole instance of Chrome underlying them.

[+] sz4kerto|6 years ago|reply
To me this looks very similar to what Google is doing with Flutter.
[+] thought_alarm|6 years ago|reply
I'm laughing at all the handwringing over Marzipan in the lead-up to this year's WWDC.

The future of MacOS development is not Marzipan and never was. The future is SwiftUI.

[+] thegayngler|6 years ago|reply
Thank you so much for this. I was learning iOS again for the fourth time. This time is different. I learned about programmatic UI from Brian LBTA guy which has been so much easier than IB. Now this update just makes my learning iOS a whole lot easier for me. I'm so thrilled. Thank you thank you thank you Apple!!!!!!!!
[+] Pym|6 years ago|reply
This reminds me Visual Studio back in 2001 when I discovered programming. Everything was so easy to prototype. I'm so happy to see Apple is taking this direction. Thank you guys!
[+] mmckeen|6 years ago|reply
Reminds me a bit of QML, though less declarative. Qt creator also has some pretty good IDE support.
[+] vedantroy|6 years ago|reply
This is definitely an overly ambitious project idea, but now that Google has Jetpack Compose and Apple has SwiftUI, and the web has React, I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively.

Then you would get truly native, cross-platform development.

Now, the probability this would ever work is 1%, but it's something that has lingered in my mind anyway.

[+] childintime|6 years ago|reply
I was waiting for Apple to react to Flutter. It was a threat. They couldn't bluntly forbid Flutter apps. Now it seems this is their answer.

Soon you'll be able to compile SwiftUI to Flutter and reach all platforms it reaches. Their play: to get the best experience, you'd still need to buy an iPhone.

[+] melling|6 years ago|reply
there were lots of Swift holdouts. In fact, there has been a resurgence of Objective C

Objective C is much higher than Swift: 11 vs 18.

https://www.tiobe.com/tiobe-index/

This should reverse the rankings and might push Swift into a top 10 language.

[+] laszlokorte|6 years ago|reply
Do the trailing closures implicitly return arrays of child elements? Or what kind of syntax is that?
[+] thomasjames|6 years ago|reply
Interesting move we see from the big players to more declarative UI toolkits. First Flutter, now this.
[+] skohan|6 years ago|reply
I hope it still supports low-level control when you need it.