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.
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!
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!
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.
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!
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.
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]?
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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!!!!!!!!
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!
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.
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.
[+] [-] kylemacomber|6 years ago|reply
If you’re at WWDC stop by the labs and say hi!
[+] [-] dimmke|6 years ago|reply
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
It must be so much fun to work on a project that impacts so many developers. Thanks again!
[+] [-] tekstar|6 years ago|reply
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
[+] [-] vijaybritto|6 years ago|reply
[+] [-] let_var|6 years ago|reply
Edit: Also, thank you!
[+] [-] ghoji|6 years ago|reply
I thought they were crazy strict and would, like, fire people for posting on forums or Twitter
[+] [-] dep_b|6 years ago|reply
[+] [-] sdegutis|6 years ago|reply
[+] [-] trevor-e|6 years ago|reply
[+] [-] tdiggity|6 years ago|reply
[+] [-] seanalltogether|6 years ago|reply
[+] [-] diffset|6 years ago|reply
[+] [-] tigershark|6 years ago|reply
[+] [-] cjf101|6 years ago|reply
[+] [-] yonilevy|6 years ago|reply
[+] [-] pier25|6 years ago|reply
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
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] samskiter|6 years ago|reply
[+] [-] cuddlybacon|6 years ago|reply
[+] [-] jiyinyiyong|6 years ago|reply
[+] [-] zerr|6 years ago|reply
[+] [-] jpochtar|6 years ago|reply
[+] [-] jamanon|6 years ago|reply
[+] [-] telcy|6 years ago|reply
[+] [-] zachgray|6 years ago|reply
[+] [-] archagon|6 years ago|reply
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
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
[1]: https://iosref.com/ios/
[+] [-] PabloSichert|6 years ago|reply
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
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
[+] [-] kennywinker|6 years ago|reply
[+] [-] untog|6 years ago|reply
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
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
[+] [-] thought_alarm|6 years ago|reply
The future of MacOS development is not Marzipan and never was. The future is SwiftUI.
[+] [-] thegayngler|6 years ago|reply
[+] [-] Pym|6 years ago|reply
[+] [-] mmckeen|6 years ago|reply
[+] [-] vedantroy|6 years ago|reply
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
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
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
[+] [-] bilal4hmed|6 years ago|reply
[+] [-] thomasjames|6 years ago|reply
[+] [-] skohan|6 years ago|reply
[+] [-] dvtrn|6 years ago|reply
http://shoesrb.com/