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.<p>If you’re at WWDC stop by the labs and say hi!
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 <i>need</i> 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.<p>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)?<p>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.<p>(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.<p>Haven’t had the chance to dig deeper, but the comparison between the UITableViewController and that snippet containing just declarative code looks absolutely promising.<p>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.
I've been working on a very similar framework[1], but wasn't satisfied with the ergonomics enough to release it.<p>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.<p>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.<p>Bottom line - this is very great news for native app development, declarative UI makes it vastly more easy to reason about code.<p>[1] <a href="https://github.com/PabloSichert/Sx/blob/master/Example/Incrementer.swift" rel="nofollow">https://github.com/PabloSichert/Sx/blob/master/Example/Incre...</a><p>[2] <a href="https://facebook.github.io/jsx/" rel="nofollow">https://facebook.github.io/jsx/</a>
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.<p>As an iOS developer, this is by <i>far</i> 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.
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.<p>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.<p>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.<p>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.
I'm laughing at all the handwringing over Marzipan in the lead-up to this year's WWDC.<p>The future of MacOS development is not Marzipan and never was. The future is SwiftUI.
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.<p>Then you would get truly native, cross-platform development.<p>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.<p>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.
there were lots of Swift holdouts. In fact, there has been a resurgence of Objective C<p>Objective C is much higher than Swift: 11 vs 18.<p><a href="https://www.tiobe.com/tiobe-index/" rel="nofollow">https://www.tiobe.com/tiobe-index/</a><p>This should reverse the rankings and might push Swift into a top 10 language.
Does the syntax sort of kind of remind anyone else of Shoes?[1]<p><a href="http://shoesrb.com/" rel="nofollow">http://shoesrb.com/</a>
The syntax example is still not as clean as QML, which is already a ten-year-old language (examples: <a href="http://qmlbook.github.io/ch04-qmlstart/qmlstart.html" rel="nofollow">http://qmlbook.github.io/ch04-qmlstart/qmlstart.html</a>).
Now, will someone be a sweetheart and write a transpiler that will transpile AndroidXML to SwiftyUI and SwiftyUI to AndroidXML. Also, while you're at it, please write a transpiler for Flutter to SwiftyUI and SwiftyUI to Flutter. K. Thx.
So React.js but native and in Swift? I'm hesitant but hopeful.<p>Tutorial: <a href="https://developer.apple.com/tutorials/swiftui/" rel="nofollow">https://developer.apple.com/tutorials/swiftui/</a>
I didn't catch it. Is Xcode 11 (beta) available already? Do I need macOS Catalina (beta) to run it? I seem to have missed the crucial information and cannot find it on apples developers pages...
I’m wondering what this could mean for replacing React Native. Obviously SwiftUI is geared for Apple’s platforms but overall it seems pretty high level and perhaps amenable to being adapted to Android by somebody. Swift is open source after all.<p>This would solve a problem a lot of devs have in deciding how to build a cross platform app. We don’t want to give up first class support for each platform but it’s silly to have completely separate codebases.<p>I hear even Apple has React Native dev groups.
For more information, there's a much more in-depth demo in the "Platforms State of the Union" session, which is now posted at <a href="https://developer.apple.com/videos/play/wwdc2019/103/" rel="nofollow">https://developer.apple.com/videos/play/wwdc2019/103/</a>
This is exactly what we did with Creo a couple of years ago: design, preview and development in a single tool. We rewritten UIKit from scratch in order to be able to preview iOS code on MacOS. Looks like we did it right.
<a href="https://creolabs.com" rel="nofollow">https://creolabs.com</a>
It reminded me of Scaloid <a href="https://github.com/pocorall/scaloid" rel="nofollow">https://github.com/pocorall/scaloid</a>
So frustrating this wont be usable for most apps for at least 2 years.<p>Meanwhile Android, which yeah only 5% of users or something crazy small are on the latest version, will get to use the latest libraries on versions released 5+ years ago.
I was fully expecting something along the lines of "Oh, and SwiftUI will compile to WebAssembly allowing your apps to look just as awesome and run just as fast in Safari."<p>Probably still in alpha...
Other than a few-hour intro seminar on building iOS apps, almost 10 years ago, I've never written anything in Swift. The announcements around it today got the biggest reactions from the crowd. Is is really great, blasé, or too early to tell?
Apple developers will be glad they get to rewrite their entire application with a new UI framework and paradigm or risk their apps looking garbage on the platform (and stop working by next release). This must be the .. fifth entirely new UI framework from Apple?