If you’re at WWDC stop by the labs and say hi!
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!
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.
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.
SwiftUI is using new Swift features sort of similar to Haskell's "do" notation, which isn't actually itself monads.
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.
Though Kotlin has an interesting looking DSL for doing that named Anko.
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. ;)
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.
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.
It must be so much fun to work on a project that impacts so many developers. Thanks again!
FTD's syntax isn't nearly as nice as SwiftUI, but there's many similarities.
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?
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)
Still learning about compose.
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).
Edit: Also, thank you!
I thought they were crazy strict and would, like, fire people for posting on forums or Twitter
@State var model = Themes.listModel
@observable model = new MyListModel();
(Semantics aside, either way this behavior is implemented in React via useState or setState, MobX has nothing to do with it)
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.
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.
That said, @State seems most identical to useState -- it provides an observed value which you use $/.binding to update.
> 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.
That's a false assumption, that's not the "point" of functional components. Functional components were always pure simply because there was no way to make them stateful. There are distinct benefits for using stateful functional components over classes -- mainly less boilerplate and abstractable/re-usable state functions.
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.
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.
Almost no large scale app uses storyboards for most of their ui....
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.
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?
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.
If anything, users of really old iPhones are likely to be less spendy so you're losing less than 10%.
That really is a bummer, I have an iPhone 6 and it's still alive and kicking.
was rocking the 6
look ma, shiny new xr lol
Google also announced a declarative UI framework. It's in the early stages and is open source. Android is on 9.x but that framework will run on much older versions of Android.
Meanwhile iOS 12 might be on 85% of iOS devices but it wont ever see SwiftUI.
Edit: On Apple developer forums I've read that the library is annotated with iOS13 requirement.
Not enough to convince my stakeholders that we don't need to support at least one major version back.
I'll probably fight that harder this year than in previous years - SwiftUI looks incredible and any AutoLayout code already feels like legacy.
I understand why, I just wish they could release this open source like Jetpack Compose. Would've been a great way to introduce SPM to Xcode and iOS as well.
I'm not even an Android developer and I already know that tons of Android libraries get back ported to older Android versions. They have to. Nobody runs the latest Android.
It's a bit shocking to get downvoted for a statement that's undeniably true.
The livestream hasn't been uploaded yet but I'm sure you could find it in one of the live blogs.
…have you taken a look at development for Apple’s platforms lately? Nobody has been able to do this yet.
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.)
Honestly, this is something I've been struggling with coming to terms to for a while.
Really, what mobile app isn't just a CRUD thing? Literally every 3rd party app I can think of on my phone talks to some REST service in some way. Even the video games, photo editors, notes apps, etc. They all use the cloud where the cloud contains most of the business logic and the app is a thin visual client proxying the data.
You could argue that, for example, a first person shooter is not CRUD heavy. But after the match, when you're looking at leaderboards or sending friend requests or chatting with your friends in the lobby...guess where that UI is updating from?
Yep, another CRUD API. It's everywhere. I really want someone to prove me wrong because I want to expand my horizons - what the hell isn't a CRUD thing these days, other than completely offline apps?
We’re all just building CRUD apps."
There's nothing stopping you from writing imperative, side-effect heavy code. But it's something you deliberately opt into, usually on the edges of the program, rather than something you have to deal with by default. Absolutely nothing about React discourages this.
SwiftUI tries to do clever stuff under the hood to only update the portions of the view hierarchy affected by the state change for performance.
My plans were to extend the Swift compiler with JSX-like syntax 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.
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.
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.
But applications written in React Native aren't cross platform, are they? You have different components depending on the platform. My understanding is that they claimed you wouldn't have to learn a different framework when switching to a new platform, not that your apps would be portable.
At its base React Native provides a common set of native components with the same API on both iOS and Android such as View, Image & Text which can all be styled and laid out through common APIs. These APIs pretty much give you most of what you need to make an entire APP. Sometimes you may want to have different behavior per platfrom and for that you can use the Platform API (provided by React Native) to switch for each platform. This would allow you to do things like change the styling on each platform or the native components you use.
Wile Swift Layout is not cross-platform, it may soon be and I think it does a lot for promoting declarative UI & maybe they did take some inspiration from React!
View docs: https://facebook.github.io/react-native/docs/view.html
React Native is for cross-platform.
SwiftUI is for cross-device.
Does that work?
Even some of the built-in components are platform specific though, such as the segmented control for iOS and view pager for Android. But the nice thing is you don't need to create a separate project to use these, you can just chose the appropriate one at runtime based on the platform.
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.
Even with other cross-platform offerings like Flutter, React, Electron and so on, getting one codebase to work out of the box on just two platforms can be a challenge. On mobile, there tends to be a need to drop down from the cross-platform stuff to something native for performance reasons — Discord does this for its chat buffer on iOS, Facebook does this for practically everything.
So while people take to their ideological high horses, there'll be people out there who can really benefit from being able to develop for Macs, iPhones, iPads, Apple Watches, and Apple TVs with a single, familiar, and easy yet powerful API to provide a glass of ice water in cross-platform hell.
Did you mean "cross form-factor" or something?
This is not some far flung usage of the term 'cross-platform'.
Nobody would doubt that Windows 10 and Windows Mobile/Windows Phone are/were different platforms. Nobody would imagine a modern Linux distribution and Android were remotely the same thing, despite their shared heritage and the fact that Android can very happily run optimised for pretty much any form factor that an OEM decides.
It's merely because all of these different platforms are made by the same company that even the slightest bit of skepticism creeps into peoples' minds but make no mistake, they are different beasts with different needs. If they were as similar as people think they are, iOS developers wouldn't need something like Project Catalyst to bring their apps to the Mac, they'd already be doing it.
I don't understand how my fellow developers could ever tolerate Apple doing this.
This goes one way, and its been like this for decades.
For a lot of developers, targeting just the Apple platforms is still a worthwhile investment in itself: Apple's customers tend to pay higher prices for quality Mac software — yes, outside the Mac App Store, too — and they will very often be happy to pay for the accompanying iOS app if it's worth doing so.
There have been Apple-only development houses since the year dot and this won't change just because Apple decided to release a platform to make it a little easier for its developers; they're not beholden to the rest of the world and it's ridiculous to believe so.
The direct comparison one might make is to Microsoft, who recently opened up .NET to have official Linux and macOS compatibility. The result is that enterprise and small businesses can deploy Microsoft technology on their Linux servers, possibly moving towards deploying on Azure. The cloud is Microsoft's big money maker — providing cross-platform tooling is one way to support that business.
Apple makes their money from selling devices, not from offering a cloud infrastructure. Therefore, it makes no sense for Apple to offer their high-quality tooling and frameworks for other operating systems — the aim is to have developers selling their software for Apple platforms, eventually having people pay for services like iCloud storage, Apple Music, Apple TV — and then stay with using Apple's hardware. Maybe a person tries an iPad. Then they get an iPhone. Then they get a Mac.
Apple recognised this about two decades ago when they officially cancelled development on the Windows version of Yellow Box (later to be named Cocoa, the base frameworks for Mac and the ancestor to UIKit, the base frameworks for iOS). It has worked well for them.
Is it right or wrong? That depends on one's perspective about lock-in. However, I don't see a problem with it in the sense that nobody is being duped — unlike Microsoft in the 90s practically forcing Internet Explorer on practically every PC available, Apple doesn't have a market monopoly.
Apple's strategy has remained consistent since the early days of OS X: you don't trap users, you make simply make sure they never want to leave. That's the pitch they make to developers, too.
So if everyone can spend 3,000 dollars and get best in class computing, what are you paying for with Apple?
They have lots of marketing that psychologically makes you feel good?
Treating other people like that is, to my mind, a shallow dismissal of an opinion you did not have the good patience to discover in the first place.
For me, it's vertically integrated privacy.
Not everyone has this urge to create FOSS software, available as free beer in every possible OS out there.
It seems as though they are viewing SwiftUI as a successor to UIKit/AppKit on all their platforms, not just a higher level wrapper.
There isn’t much of a difference between Flutter controls and native controls, other than being a reimplementation in some cases.
Hmm...that's pretty much the entire difference between native and non-native controls.
A previous commenter implied that there somehow native controls were technically different than Flutter controls.
Obviously the rendering stack is different but Skia is as native as Quartz is.
Native widgets are those of the native widget toolkit. I can use the underlying drawing libraries to draw widgets that look vastly different and implement behaviours that behave vastly differently from the native widget toolkit.
The point of native widgets is that they are the same, not that they are drawn using the same underlying technology.
So the fact that you are using platform libraries to draw those non-native widgets is not at all relevant. After all, what else are you going to be using?
Except they're not actually native controls. They're reimplementations of them. It is a very important distinction.
by contrast, with a native android app, the look and feel of the widget can change on an end user's device when the end user updates android on their particular device.
Except that they behave quite differently…
Flutter specifically or cross-platform UI frameworks in general?
I don't mind it being different, but does the app feel unpolished?
I bet by next IO, Flutter will get replaced by it, specially after the #KotlinEverywhere announcement and Kotlin/Native effort for iOS.
Trying to sell Dart a 2nd time was a mistake.
Given Flutter enables the nicest native x-plat dev experience today I'd say it has a very bright future, which they've also recently announced Flutter for Desktop and Embedded devices.
Jetpack compose is years away from the same kind of x-plat support that Flutter's providing for Mobile, Web, Desktop and Embedded .
Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities".
Flutter is a way to rescue Dart, plain and simple.
Yes, Jetpack Compose might be doing its baby steps, but I am betting most developers are more keen in having Kotlin than Dart on their CV, specially after Dart v 1.0's demise.
And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART.
Think highly of yourself much? But I'll be continuing to provide links as I see it's relevant and informative, my comments are not just for your benefit, readers can make their own mind whose opinions are more informed - "no need" to tell others how to comment.
> Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities".
Am I meant to be impressed by this list of languages? I'm not. Are the number of languages meant to give your inexperienced opinion on Flutter's development environment some credence or is this washy strawman meant to downplay anyone else's opinion who wasn't a developer in the 90's when these languages were more relevant?
What matters is what's relevant now and Flutter lets you build modern x-plat Mobile, Web, Desktop and Embedded Apps with productive Live Hot Reload environment that's both fast at development and runtime which can be run in a JIT VM, as AOT compiled or transpiled to tree-shaken JS. Which of these above languages provides a more productive and "technically impressive" environment to develop iOS/Android, Web and Embedded Apps than Dart/Flutter?
> Flutter is a way to rescue Dart, plain and simple.
Adding "plain and simple" to an baseless opinion doesn't re-enforce it, including links that backs up this wild speculation will. What information have you used to be able present this opinion as fact so staunchly? Do you really believe Google invented and funded the Flutter project out of thin air to give Dart a popularity boost?
> And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART.
How can Android have more political power for Fuchsia than Dart which is what most of its UI is written in? You can also develop Flutter Apps on Chrome OS so that's no different. Chrome OS is still primarily a Web OS, allowing running Android Apps doesn't make it an OS for running Android Apps and devs aren't going to be lining up to develop Chrome OS Apps using Android.
Flutter's strength's is that you can develop x-plat App's that looks, behaves and runs natively on all its supported platforms - feel free to wait until Kotlin reaches the same maturity on iOS before declaring it a Flutter killer. Kotlin still suffers from Android's complicated and fragile tooling and from what I've seen with JetPack compose it's highly coupled to Android - it's going to take a long time before they'll let you build iOS/Android Apps from a single code base.
Besides Dart v1.0, Dartium, Angular Dart when they were still relevant to Chrome and Angular teams, and following up on Flutter?
I usually only criticize stuff that I actually have some level of experience with.
AdWords team rescued Flutter, after Chrome and Angular teams stop caring, which even caused Dart designers like Gilad to leave in disagreement.
I believe that they found out some internal management support that is willing to give them a time frame, of lets say 5 years to prove themselves worthy of such support.
Android has more political power ChromeOS has adopted Android and not the other way around, the two commercial OSes from Google.
While their experimental OS, Fuchsia is now adding support to run ART, while at the same time via Scenic, decoupling themselves from the UI framework.
You want to believe in Dart/Flutter, go for it.
Me, I am betting it will be joining the list of abandoned Google projects in a couple of years.
Secondly, and the most immediate reason, I think it's a very clever and clear move from Google to lock-in devs into using Google Cloud services like Firebase and Cloud ML services by leveraging Flutter. If you have observed, Microsoft has given a rebirth to their Xamarin developers YouTube channel and have been hosting 'The Xamarin Show', which is, hmm, quite similar to 'The Boring Flutter Development Show'.
I may be missing something, but SwiftUI seems to be pretty much ready to go today.
Which for most companies is 2+ years away
The future of MacOS development is not Marzipan and never was. The future is SwiftUI.
But I think you're right. Catalyst (née Marzipan) is being pitched by Apple as a brilliant way to get a head start on porting iPad apps to the Mac, and should become the best way to write an app that you want both an iPad and Mac version of. But "Mac apps as we know them are dead" always struck me as histrionic, and today's presentation doesn't make me think that any less.
(At least it appears that way, going by the WWDC session descriptions. We'll know more in a couple of hours)
@kylemacomber - can you provide some context here? I'm sure many of us would love to get a high-level understanding of this.
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.
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.
Just no. As an Apple user, just use whatever the tools they give you when you're developing for Apple platforms.
Objective C is much higher than Swift: 11 vs 18.
This should reverse the rankings and might push Swift into a top 10 language.
And Apache Groovy rose from number 91 to number 17 in the past 12 months also according to that same Tiobe page (May 2019). Quoting Tiobe for anything only discredits what you're trying to prove.
> the basic idea is that we take the "ignored" expression results of a block of statements — including in nested positions like the bodies of if and switch statements — and build them into a single result value that becomes the return value of the current function.