
SwiftUI - fphilipe
https://developer.apple.com/xcode/swiftui/
======
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.

------
archagon
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.)

~~~
nexuist
"However, I can't help but feel that this paradigm would work best when your
app is a fairly basic CRUD thing"

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?

~~~
untog
I feel like CRUD can be a simplistic categorisation at times. Take a look at
the Slack app, for example. It's got chat messages. Also rich media. And
threading. And user profiles. And notifications. But each of those is "just"
CRUD. That doesn't mean it's a walk in the park. By broad definition just
about every piece of software ever created is CRUD.

------
fphilipe
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
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/](https://iosref.com/ios/)

~~~
BrandonSmith
I smell a low-cost iPhone offering late Summer.

~~~
eugeniub
Frankly I think they'll just keep selling iPhone 8 for another year but drop
the price down by $50 or so to $549. Or maybe if we're lucky $499. Either way
they won't release a serious budget phone like the iPhone SE for $399 like
they did in 2016. That year, Apple's flagship phone was $649. This year the
flagship is $999.

------
PabloSichert
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...](https://github.com/PabloSichert/Sx/blob/master/Example/Incrementer.swift)

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

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

~~~
ehsankia
Yeah, it's similar to I/O where there's a separate developer keynote, and
specific "State of the Union" talks for each platform/framework.

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

~~~
wtetzner
> In casual conversation I've had it actually isn't that high, despite it
> being one of the central promises of RN.

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.

~~~
joshjhargreaves
Applications written in React Native typically _are_ cross-platform; saying
that they are not is a pretty large misrepresentation of the framework.

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.

React Native makes it pretty easy to expose native components to JavaScript.
It is also up to the native component author if they want to create a common
API for all platforms that they support. In the case of Views & styling it
makes a lot of sense to have the same API on iOS and Android, but sometimes
they are some platform features that are only available on one platform.

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](https://facebook.github.io/react-native/docs/view.html)
Styling: [https://facebook.github.io/react-
native/docs/style](https://facebook.github.io/react-native/docs/style) Layout:
[https://facebook.github.io/react-
native/docs/flexbox](https://facebook.github.io/react-native/docs/flexbox)

~~~
pvinis
Maybe we need to coin a new term.

React Native is for cross-platform. SwiftUI is for cross-device.

Does that work?

~~~
Razengan
Cross-ecosystem vs. cross-platform maybe.

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

~~~
robertAngst
>Of course, it can't answer everybody's needs (no Windows, Linux, or Android
support)

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.

~~~
zapzupnz
Because not all of your "fellow developers" have the same priorities as you.

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.

~~~
robertAngst
Given the high cost, high cost options exist on other platforms that are also
fantastic.

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?

~~~
zapzupnz
The notion that all of Apple's users are just fools for good PR is not one to
which I bother to respond because I choose not to be called a pawn.

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.

------
sz4kerto
To me this looks very similar to what Google is doing with Flutter.

~~~
pjmlp
Jetpack Composer you mean.

I bet by next IO, Flutter will get replaced by it, specially after the
#KotlinEverywhere announcement and Kotlin/Native effort for iOS.

~~~
HillaryBriss
It looks like Jetpack Compose is not really done yet. It's pre-alpha and the
Jetpack Compose doc page says don't use it for production.
[https://developer.android.com/jetpack/compose/](https://developer.android.com/jetpack/compose/)

I may be missing something, but SwiftUI seems to be pretty much ready to go
today.

~~~
myko
Ready to go today if you're only supporting iOS 13+

Which for most companies is 2+ years away

~~~
HillaryBriss
To add a bit more detail: the required level for other Apple OSs are macOS
15+, tvOS 13+ and watchOS 6+.

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

~~~
saagarjha
SwiftUI running through Catalyst, surely?

~~~
thought_alarm
SwiftUI isn't confined to Catalyst. It's available to native Mac AppKit apps
as well as UIKit apps.

(At least it appears that way, going by the WWDC session descriptions. We'll
know more in a couple of hours)

~~~
saagarjha
Yeah, or once I can finish unarchiving Xcode…

------
thegayngler
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!!!!!!!!

~~~
thegayngler
Why am I being downvoted simply for being happy about this update and that it
brings down the learning curve for other engineers?

~~~
kartickv
Unfortunately, many geek forums accept cynicism, negativity, sarcasm and
snark, and downvote a happy post, usually with some excuse like "doesn't
contribute to the discussion".

------
Pym
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!

~~~
pplante
I assume you mean Visual Basic, since Visual Studio was geared towards C/C++.
Unless you actually used the MFC designer in VS5/6, which never really worked
that well for me.

~~~
Pym
Actually I had VB6 in mind yes, but after a few months playing with it I made
the switch to .NET (which was still in beta I believe at the time) so I was
using Visual Studio ".NET" :)

------
mmckeen
Reminds me a bit of QML, though less declarative. Qt creator also has some
pretty good IDE support.

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

~~~
munificent
_> 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._

Flutter targets native code on Android and iOS and JavaScript for the web. It
has very mature compilers for all three.

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

~~~
mleonhard
Who said anything about compiling SwiftUI to Flutter?

------
melling
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/](https://www.tiobe.com/tiobe-index/)

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

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

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.

------
laszlokorte
Do the trailing closures implicitly return arrays of child elements? Or what
kind of syntax is that?

~~~
saagarjha
Single-expression functions can now return a value without the “return”
keyword: [https://github.com/apple/swift-
evolution/blob/master/proposa...](https://github.com/apple/swift-
evolution/blob/master/proposals/0255-omit-return.md)

~~~
laszlokorte
Yeah but the example code looks like multiple expressions?

~~~
saagarjha
Those might be functions that alter context of the closure rather than being
returned. Or it might be some Swift compiler magic?

~~~
laszlokorte
So far I found out it's implemented via parameter attribute [1]

[1]:
[https://developer.apple.com/documentation/swiftui/viewbuilde...](https://developer.apple.com/documentation/swiftui/viewbuilder)

~~~
laszlokorte
More details in the proposal [1]:

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

[1]: [https://forums.swift.org/t/pitch-function-
builders/25167](https://forums.swift.org/t/pitch-function-builders/25167)

------
bilal4hmed
Looks a lot like Flutter

------
thomasjames
Interesting move we see from the big players to more declarative UI toolkits.
First Flutter, now this.

~~~
pzo
You have to give credit to react time which seems that started this paradigm
of declarative _and_ reactive ui frameworks. After that you got react native,
flutter, jetpack compose and now swift ui. As for declarative (but not
reactive) ui prior art is also Qt qml.

~~~
sandeepc24
Also have a look at
[https://fsprojects.github.io/Fabulous/](https://fsprojects.github.io/Fabulous/)

------
skohan
I hope it still supports low-level control when you need it.

~~~
bendixso
Yeah, I have the same concern. This is great for those situations where
declarative works but sometimes you really want to get low-level and do some
custom stuff with imperative code. I suppose we can use the old frameworks for
that?

------
dvtrn
Does the syntax sort of kind of remind anyone else of Shoes?[1]

[http://shoesrb.com/](http://shoesrb.com/)

~~~
ksec
Yes, I wonder what framework Apple engineers looked at for inspiration, and if
they looked at shoes. Although I doubt they are allowed to answer this
question.

~~~
jurip
Here's one comment about inspiration:

[https://twitter.com/jckarter/status/1135666944273571840](https://twitter.com/jckarter/status/1135666944273571840)

------
jcelerier
The syntax example is still not as clean as QML, which is already a ten-year-
old language (examples:
[http://qmlbook.github.io/ch04-qmlstart/qmlstart.html](http://qmlbook.github.io/ch04-qmlstart/qmlstart.html)).

~~~
untog
But it is Swift, which (at the risk of stating the obvious) QML is not. And
you can't write an entire app in QML.

There's something to be said for being able to use one language for all
things.

~~~
stabbles
Well, you can almost surely write entire apps in QML if you take the C++
entrypoint for granted.

Just a couple examples: you can do Bluetooth discovery scans in QML without
writing any C++ [1], you can read from ~20 sensors without writing any C++
[2], you can write complete 3D scenes declaratively in QML [3], and the list
goes on.

[1] [https://doc.qt.io/qt-5/qml-qtbluetooth-
bluetoothdiscoverymod...](https://doc.qt.io/qt-5/qml-qtbluetooth-
bluetoothdiscoverymodel.html)

[2] [https://doc.qt.io/qt-5/qtsensors-
qmlmodule.html](https://doc.qt.io/qt-5/qtsensors-qmlmodule.html)

[3] [https://doc.qt.io/qt-5/qt3d-wireframe-
example.html](https://doc.qt.io/qt-5/qt3d-wireframe-example.html)

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

------
checker659
One more blow to the head for objective-c. Wonder if this the final nail in
the coffin.

~~~
protomyth
Given that Craig Federighi basically said this type of migration only comes
around every 20 years, I would imagine Objective-C is dead. I do hope they
actually take the time and fix the Swift examples so they are updated.

This does hurt. I've been programming Objective-C since NeXTSTEP and love it.
Swift is still like Perl for me. Something I will use for programming for
money, but not enjoy for one minute. I loved the clarity of selector syntax,
but Javascript clones rule the world. I still don't understand the love of
commas or why they are needed.

~~~
adamnemecek
How is swift a javascript clone?

Objective c is insanely verbose.

~~~
protomyth
_How is swift a javascript clone?_

They ditched the selector syntax and went to a Javascript / C++ like syntax.
There were so many ways to keep the selector syntax, but they went conformist.

 _Objective c is insanely verbose._

well, no - Swift's call syntax actually results in the same or more
characters:

    
    
      somePoint.moveBy(x: 2.0, y: 3.0)
    
      [somePoint moveByX: 2.0 y: 3.0];
    
      somePoint.moveBy(x: 2.0, y: 3.0, z: 4.0)
    
      [somePoint moveByX: 2.0 y: 3.0 z: 4.0];
    

Swift benefited from some shortening of the method names that can be equally
applied to Objective-C. Plus, why the whole split by a left parentheses and
comma thing?

------
sdegutis
So React.js but native and in Swift? I'm hesitant but hopeful.

Tutorial:
[https://developer.apple.com/tutorials/swiftui/](https://developer.apple.com/tutorials/swiftui/)

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

~~~
gschrader
The direct download is here:

[https://developer.apple.com/services-
account/download?path=/...](https://developer.apple.com/services-
account/download?path=/WWDC_2019/Xcode_11_Beta/Xcode_11_Beta.xip)

for some reason my account only shows "There’s currently no beta software
available for download."

~~~
weiming
[https://xcodereleases.com](https://xcodereleases.com)

Best-kept secret with direct download links (from apple.com)

------
Redoubts

      var body: some View {
    

Wait, what? When was `some` a keyword?

~~~
ardit33
I am still scratching my head why the 'some' keyword is needed/required for
opaque types.

Eg. SquareButton and RoundButton are implementations of the Button (protocol).

You want to create a function that returns the button, but you don't want to
specify to the user exactly what type of button is it (as it doesn't matter).
Your function could just declare the top level protocol as the return type
without needed to specify the word "some"

createPlayButton -> Button

instead of createPlayButton -> some Button

Am I missing something? It feels like the 'some' keyword is just there to help
the compiler and not the users necessary

it seems like the equivalent of id <MyProtocol> in Objective-C. Basically just
a surface re-arranging of names, but keeping the same concepts as in
Objective-C

I feel Golang did better in this regards... (eg. not necessary distinguishing
between protocols and super class-es, it is quacks like a duck, it is a duck)

~~~
skohan
The difference is subtle but it's there.

The "some" keyword indicates that the function returns a specific type, even
if that type isn't known to the caller.

One place where this is meaningful is if you have to _use_ the result of that
function in a generic function. For instance if my functions are defined like
this:

    
    
        func createPlayButton() -> Button { ... }
    
        func doSomething<T: Button>(_ button: T) { ... }
    

And I try to call this:

    
    
        doSomething(createPlayButton())
    

I will get an error, because the protocol Button does not conform to itself.
However If I use opaque types:

    
    
        func createPlayButton() -> some Button { ... }
    

this works just fine because the compiler is able to determine the concrete
type returned by `createPlayButton`

~~~
nicky0
Why doesn't a protocol conform to itself?

~~~
skohan
In many cases it doesn't make sense. For instance, what if your protocol
contains a static member?

    
    
        protocol P {
            static var x: Int { get }
        }
    

Here `let x = P.x` doesn't make any sense, because it's only the type
implementing the protocol which has that member. However this would be
possible:

    
    
        func f() -> some P { ... }
        let p = f()
        let x = type(of:p).x
    

because in this case p has a concrete type, we just don't know what it is.

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

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.

I hear even Apple has React Native dev groups.

------
Apocryphon
Can this retroactively support apps targeting iOS 12 and older?

~~~
scarface74
The only devices you lose by supporting iOS 13 and not iOS 12 are the iPhone
5s from 2013 and the 6th generation iPod Touch from 2014.

iOS users update pretty rapidly.

~~~
saagarjha
iPhone 6 does not have an iOS 13 IPSW on the developer downloads site. iPad
Air and the second and third generation iPad Mini were dropped as well.

~~~
scarface74
Didn't realize that they dropped the 6 and 6 Plus.

------
azhenley
.color(.gray))

What object is .gray acting on?

~~~
kennywinker
That’d be standard swift type inference. The .color function takes a single
unnammed parameter of type Color (or similar, idk exactly). Color.gray is a
static constant value. So .color(Color.gray) can be simplified to
.color(.gray)

~~~
steve_adams_86
Huh, that's actually a great way to do type inference. Swift seems like an
excellent language.

------
OkGoDoIt
For more information, there's a much more in-depth demo in the "Platforms
State of the Union" session, which is now posted at
[https://developer.apple.com/videos/play/wwdc2019/103/](https://developer.apple.com/videos/play/wwdc2019/103/)

------
DelightOne
Where does this leave View Controllers? Is this available for those too? How
does composition of multiple custom views work?

------
creolabs
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.
[https://creolabs.com](https://creolabs.com)

------
DanGarthwaite
It doesn't matter that it looks like flutter. It matters that flutter will be
able take advantage of it.

~~~
saagarjha
Flutter draws its own controls, so no, it cannot take advantage of SwiftUI.

------
machinesbuddy
It reminded me of Scaloid
[https://github.com/pocorall/scaloid](https://github.com/pocorall/scaloid)

------
artemiszx
Thinking about starting a new project over the summer. But seeing the demos it
seems just starting something in UIKit now is a bad idea?

------
hokkos
So it look like react but it doesn't seems to be immediate mode GUI, still
retained ? The body is a property not a function.

~~~
Hemospectrum
That's a "computed property," ie. a getter method pretending to be an instance
variable.

------
dgellow
Something like this available in C++ would be so great for cross platform
applications!

~~~
zaiste
There is Boden (native apps from a single C++17 codebase)

[https://www.boden.io/](https://www.boden.io/)

~~~
dgellow
As far as I understand Boden is still a work in progress, far from being ready
for prime time.

------
jpochtar
fmr founder of Pagedraw here... this looks amazing. I wish we'd built it! :)

------
atilkan
Looks nice like Flutter.

------
adamspb
Am I the only one thinking "SwiftUI compile to WASM"?

------
let_var
First-call declarative UI support is amazing!

------
binthere
Will there be a similar API for Objective-C?

------
kensai
OMG, has anyone noticed the device icons on the bottom of the SwiftUI page?
Steve will be turning in his grave...

------
chadlavi
The question the whole web asks now: what does this mean for React Native devs

~~~
gmemstr
I bet it's going to stay relatively the same, for now. React Native still
works across iOS and Android, which is one of the key features. SwiftUI is iOS
only.

~~~
chadlavi
It's my understanding that a lot of the appeal of RN is also that it allows
web devs who are fluent in JS to make mobile apps, so I guess that's not
really comparable in SwiftUI either.

~~~
nicoburns
I'm not sure about that. SwiftUI code looks an awful lot like React code. And
IMO (as a web dev), it was always learning the UI framework that seemed like
it would be the difficult part of learning iOS dev. Data manipulation APIs are
pretty similar in most languages, but learning a new UI paradigm is a pain...

~~~
lghh
Yes, but alongside learning SwiftUI they will also have to learn whatever is
going on in Android land because it's not cross platform.

------
lostmsu
> across all Apple platforms

------
lisardo
It’s nice to finally see a FRP framework for iOS like React/Elm. MVC must die
already.

~~~
steve_adams_86
FRP and MVC seem like different types of patterns to me. Functional reactive
is about how you manage state and flow while MVC is largely about separation
of concerns. In my (possibly poor) understanding, you could actually use them
together.

I'm interested in your take on that though. I'm self taught and I've got some
weird ideas about things.

------
croxx5f
It smells a little like dart UI as code(flutterish may i say)

------
myko
So frustrating this wont be usable for most apps for at least 2 years.

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.

------
mikece
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."

Probably still in alpha...

~~~
saagarjha
Why would Apple want these apps to run in Safari? They have a platform to run
these already.

~~~
mikece
Safari isn't the point -- running on other platforms is. Market share for iOS
globally is nowhere close to Android; in India iOS is only about 10% so if
your SwiftUI app could run in Chrome on Android and is installable as a PWA,
you open up the rest of the handset market.

~~~
saagarjha
Apple doesn’t really care about you being able to run your UI code on those
platforms.

~~~
mmargerum
True. in fact they have a vested interest in not making this happen, but
someone will. This looks really impressive and i've grown to like swift quite
a bit.

------
RantyDave
Ahhh, I don't get it. XCode already does all of this, and has done for very
many years. Y'all are excited because you can see the code?

------
TheRealDunkirk
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?

~~~
teilo
You were not using Swift 10 years ago, or even almost 10 years ago. It was
released in 2014.

~~~
TheRealDunkirk
Ah, now I see the reason for the downvotes. I just meant "Apple's language for
doing iPhone apps," and, of course, that was Obj-C back then. I haven't
thought about it since.

------
stefan_
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?

~~~
jaegerpicker
This isn't true at all. Since iOS launched there has been UIKit and then this
SwiftUI.

~~~
grey-area
_This must be the .. fifth entirely new UI framework from Apple?_

 _This isn 't true at all. Since iOS launched there has been UIKit and then
this SwiftUI._

They didn't say anything about iOS. There have been lots of UI frameworks from
Apple, some abandoned before they were even finished:

QuickDraw, Quickdraw GX, HIToolbox, AppKit, Cocoa Touch/UIKit, Playgrounds/IB,
SwiftUI

The constantly changing frameworks and languages are a useful strategy from
platform vendors - they _do_ help provide platform lockin, and make it very
very difficult to provide cross platform apps. That is a real threat to Apple
with offerings like flutter from Google. Of course there are other reasons to
make a clean break with the past, but there is a lot of work just to stand
still in developing for a platform like Mac OS or IOS - they don't highly
value backwards compatibility and often introduce sweeping changes. Constant
change is in the platform vendor's financial interest, and I don't think it's
unfair to point that out.

Just to take one example - apps built for the original iOS are now almost
entirely obsolete, and it's not worth reusing any of their code in a modern
swift app.

~~~
AprilArcus
QuickDraw and Quickdraw GX aren't UI frameworks (like PowerPlant, AppKit or
UIKit), and they aren't a widget library (like HIToolbox). They're much more
lower-level than that; drawing libraries on the level of Quartz, Cairo, Skia,
or GDI.

~~~
grey-area
Ooh, that mention of PowerPlant that takes me back, I remember CodeWarrior too
back in the day.

Yes you're right there are various levels here - sometimes it's hard to
distinguish them. There have definitely been at least 5 UI toolkits though,
and probably more, though of course over the life of Mac OS that is not
terribly unexpected. For those who lived through the transition to OS X, this
sort of churn is not unusual, and I do think it does benefit platform vendors
- they have zero incentive to keep supporting their technologies over decades
and every incentive to increase churn.

Quickdraw GX I remember particularly because there was such fan-fair about it
as a replacement for all your graphical needs (such as drawing text), and yet
it was dropped before it could even really be used (same with Quickdraw 3D). I
can't remember what apple called their UI toolkit at the time, which was based
on Quickdraw, then GX, but I don't think it was Carbon, that came later didn't
it? I think I've found it now, was it MacApp?

~~~
DerekL
MacApp was a framework that ran on top of HIToolkit, similar to PowerPlant.
Originally it was written for Object Pascal, but later it moved to C++.

