Hacker News new | past | comments | ask | show | jobs | submit login
SwiftUI (developer.apple.com)
765 points by fphilipe on June 3, 2019 | hide | past | favorite | 379 comments

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!

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!

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

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.

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.

Well the oldest ideas are around the notion that code is data and should be manipulated as such (from the 50s).

If you find iOS / macOS views cumbersome to write programmatically you should feel fortunate you didn’t have to write Android views programmatically.

You can always create a layout XML file and inflate it. It saves tons of time. I can't imagine why you would do thing in code instead of inflating and attaching them.

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.

True but who does this? The Android framework isn't built to support that reasonably at all, at least not until Jetpack Compose becomes viable.

Wasn't that the default way of doing things in Android? That is, build your ui's in XML?

By writing views programmatically in Android they mean writing them in Kotlin or Java, not XML. Almost no one does this.

Though Kotlin has an interesting looking DSL for doing that named Anko.

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

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

And the IB approach is a nice one, except that its files (whether NIB or XIB) simply don't diff as nice as the equivalent in code. Checking changes into source control is an opaque experience as the diff is an endless vomit of unintelligible mumbo.

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.

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

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.

So I've been working with SwiftUI for the past day and I am completely blank on how one would implement a collection view, like one with multiple rows. I did succeed to do it myself with a VStack and multiple HStacks, inside which I basically put the cells. Did they show this in the demo or was it a one-dimensional collection view?

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!

Minor bit of pedantry--Yoga is written in C++.

Both are kinda true - Yoga started as a C library, but was ported over to C++ ~a year and a half ago.

If that’s true, maybe they should update the first paragraph of their github page, which clearly says the library is written in C.

Yogas github page clearly says that it is implemented in C in the first paragraph.

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.


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?

I saw somewhere that all this started around 2012.

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.

After 10 years of following wwdc: you may want to temper your expectations as to what this will truely feels like once this runs on your machine, on a real-size project.

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)

New (or kinda new?) Framer X tries to do that for React: https://www.framer.com/development/

This is incredibly awesome! Did you get inspired by the web or by new frameworks like flutter?

This looks very similar to Flutter, I wouldn't be surprised if they took some ideas from that which is all well and good; UI construction needs a facelift.

I think if flutter can provide this kind of editor support and experience it would be indispensable for me! Also I'm pretty sure the web would emulate this one pretty soon!

swift ui to react !

That is exactly what I said when I saw the code on the screen. Now if they released a development environment for Android also.... (wishful thinking)

If you want a Flutter-inspired framework that works on iOS and Android, have you considered, uh, Flutter?

If you mean and official declarative UI library then Google released one of those at Google IO this year:


I am very interested in multi-platform Kotlin. I'm not sure how far it will get but on the surface I think it is more likely for Kotlin to work on iOS than Swift on Android.

Still learning about compose.

> it is more likely for Kotlin to work on iOS than Swift on Android.

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

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!

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

Apple has a set of guidelines for public comments: they don’t restrict employees from commenting publicly entirely, but there are quite a few things they can talk about (such as products that just launched…)

Well, why do you think he only posted one comment and then disappeared...

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

  @State var model = Themes.listModel
I haven't tried it out, but the above looks more like MobX:

  @observable model = new MyListModel();

I think it's a closer analogue to React.useState.

Does that mean that UI will automatically get updated when the model changes, and you no longer need a mess of dependencies, like "if A changed, update X and Y".


useState is for cobbling together state onto what's supposed to be a pure-function. SwiftUI, like MobX (in its normal usage), is class-based and keeps state in a class member.

What's the difference between a class and a function with local state?

(Semantics aside, either way this behavior is implemented in React via useState or setState, MobX has nothing to do with it)

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said “Master, I have heard that objects are a very good thing – is this true?” Qc Na looked pityingly at his student and replied, “Foolish pupil – objects are merely a poor man’s closures.”

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.

I would like to know more about Anton, and the irascible Qc Na.

MobX takes normal data (usually class properties) and makes it observable, via an annotation. That very much appears to be what the @State annotation in the Swift code is doing, though I don't know for sure.

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.

@observable/useState/React.Component.state are all conceptually identical, just with varying implementations of the magic. All of them summon an observable value from the void and provide some method of updating said observable.

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.

> What's the difference between a class and a function with local state?

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.

SwiftUI is protocol-based, not class-based

This looks an awful lot like ReactiveX.

It does. It's kind of disappointing - would rather they build off what the community has in RxSwift, which is pretty feature rich and robust.

Redux and react are two different questions.

When people make alternatives to React, at some point they have to address the concept of state changes and side-effects, building in conveniences for it, or leaving it for third parties to develop this area.

... Or use something like Reagent where there is language level support for reactive state management using atoms.


That looks like exactly what SwiftUI is doing.

This has nothing to do with Redux. Redux is about storing global data, nothing more.

Looking over the references and docs, this is pretty much the builder pattern to generate the view tree and data binding to update it.

Looks very similar to Anko (a Kotlin Android UI DSL). Awesome work, can't wait to try it out.

It is. And I think SwiftUI will only push people toward Anko as this kind of libraries/tools will become popular. Also, some concurrence with make both tools even better. That's great news!

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.

Does this support stylesheet based styling?

Good question, so far it doesn’t seem so

As long as SwiftUI has some support for inheritance and arbitrary variables for all elements like colours, fonts and dimensions, I don't think a stylesheet system would be necessary.

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.

Where does this leave Storyboards? I can't see complex UI being built in SwiftUI

People are using storyboards for complex UI? I was under the impression that people used the more manual processes with larger teams.

Storyboard references made composing complex UI possible, but IMX there's almost always some breakpoint where it's just less complex to do it with code.

you are right, not sure why you are being downvoted

Almost no large scale app uses storyboards for most of their ui....

I do a mix. The "program by painting" is great for some things and sucks for other things. Unfortunately, programming UIs entirely by text is terse for some things and incredibly laborious/tedious/boilerplate for others (e.g. doing autolayout in code sucks).

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.

yes, my team have been using Storyboard/xib for 99% Auto Layout declaration, PaintCode for rendering custom components (which can be shown directly inside IB), RxSwift/RxCocoa for MVVM

This is the exact opposite of how I feel. SwiftUI will be much better for that scenario.

Hi, great work! Is iOS 13 required to use apps made with swift ui?

That would be unlikely, as they probably want to support everyone's old apps for a little while at least

Nope, iOS13 is required, as SwiftUI is a system framework.

So I guess macOS 10.15 too, yes?

According to the documentation the latest OS release is required on all platforms SwiftUI targets.

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.

This looks fantastic, congrats! Any word on whether 3rd party IDEs will be able to integrate the live-preview functionality? (AppCode user)

I assume AppCode will support this the same way it does with InterfaceBuilder and Storyboards - i.e. it won’t do anything but launch XCode to handle it.

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?

What? You develop it using SwiftUI, then you compile it and it will run on whatever you compile it to. So yes, it will run on older OS versions.

Thank you! Looks like your work will impact me (and hundreds of thousands of other developers) every day.

Now you've really given us a dilemma - switch to Flutter or wait and see if SwiftUI goes open source....

This looks fantastic. I work on a little macOS app as a hobby thing, and am excited to try this out!

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.

You could call this hypothetical tool Interface Builder.

Watched several short videos, it seems they are already doing that by dragging component to generate code, by configuring parameters in the code with panels. It's very approaching.

Is an imperative API available as well?

Fantastic work you've done here!

Can I use that in an existing app?

Only if you only support the latest OS versions.

Thanks. Really good job

not all heroes wear capes

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

I can only speak for React, but the declarative component model doesn't eliminate state or imperative code, it just nudges you towards separating your stateful code from your layout/rendering code. In the React/Redux convention, your application is one big state machine with transitions encoded in reducers, and your state -> view data transformations in "selectors". View components are composed into one big pure function of state. Putting barriers between those classes of functionality makes it much easier to compose complex behavior from small, focused functions. Obviously you can write code with those properties in any context, but conventional React/Redux architecture makes the lines more explicit, which is why I like it. Lots of people hate it.

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

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.

I’m working on a realtime video conferencing service. Lots of long running connections with state updated by streamed events. React works pretty well for this use case imho. Not a lot of CRUD there.

"The dirty secret:

We’re all just building CRUD apps."


Adobe uses a declarative UI system, and what they call a 'property model', which apparently successfully reduced their UI code by a factor of over 500. The system is available here:


Fascinating! (And on reflection, Blender probably does something similar, since it's super modular and practically every field is in perfect sync with the view and the data.)

It's very interesting! The 'property model' was apparently a real research project, which adds an additional ingredient over and above most systems in common use:

> The combination of procedural and declarative program code has found success in, for example, GUI element layout. The most familiar example is perhaps HTML, CSS, and DOM combined with JavaScript. The QTk library [12] in Mozart/Oz, Glade [7],XUL [16], XAML [34], and XForms [5] serve as further examples. Some of these systems, along with rule-based systems such as Drools [27], Jess [11], and R++ [14], also support concisely specifying declarative rules for maintaining consistency across values in user interfaces. Property models are distinguished from these systems by not only providing the ability to create rules that assist introducing a valid result but also by providing an explicit model of the dependencies these rules create. Inspecting the state of the model enables generic algorithms (e.g., for widget enablement) for user interface.


Every software needs explicit state. If React is any indication, it tells us that the management of this explicit state can be made much more pleasant when written in a declarative way.

I disagree. I'd argue React is most useful when doing something highly interactive.

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.

Take most of the Adobe creative suite as an example. Different paradigms will fit different aspects of the UI design. Nobody wants to expend the same effort to build CRUDs as they would when they're working on "groundbreaking" stuff. Reality is a bit more nuanced: you want to abstract as much as possible and make it trivial, so that you can focus most energy where it matters. Patterns/Language/Frameworks all come into play here, and SwiftUI is a beautiful addition.

SwiftUI has state. The idea is that all layout code is defined as a pure function of the state. Basically you can annotate properties with `@State` and each time one of those properties is updated, your view `body` function is re-run to produce an updated view.

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.

If you combine a declarative UI like SwiftUI and a reactive logic like RxSwift, you can get very far, while keeping things separated and simple. Not only for CRUD apps, but for big complex apps too.

Don’t use it with RxSwift, use it with Swift Combine! https://developer.apple.com/documentation/combine

Agreed... especially in React Native. You quickly run into a wall for some more advanced things because of how it's designed. (Mostly imperative actions/animations, etc)

Xcode Previews are written in SwiftUI; you can definitely write real apps with it.

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.

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

According to Mixpanel, the 5S / 6 / 6 Plus together account for a bit less than 10% of iOS devices they see. So it's not as big of a drop as one might expect.


That is way more than most companies will part with. If support drops substantially below 1% we can talk again.

Yep, if your margins are 20% and you lose 10% of your user base and revenue, you just lost half your profit.

I must be missing something here. Assuming on a napkin that all users roughly generate the same amount of revenue, losing 10% of them will lose you 10% of your profit, no?

If anything, users of really old iPhones are likely to be less spendy so you're losing less than 10%.

It depends on how you're calculating it: if you have fixed costs, then yes, your profit drops 50%; if your costs scale with number of users then you go down 10%.

Profit is revenue minus expenses. Supporting more versions of iOS essentually means greater expenses. So the decision to drop support of older iOS versions is basically the questions of whether or not the additional expense of supporting it is greater than the additional revenue those users generate. For a company like Facebook, the revenue is much greater than expense, while for a smaller company, it's probably smaller.

>Unfortunately, iOS 13 drops support for iPhone 5s and iPhone 6.

That really is a bummer, I have an iPhone 6 and it's still alive and kicking.

day before WWDC:

   was rocking the 6
day after WWDC SwiftUI announcement:

   look ma, shiny new xr lol

Does this include 6 Plus? I grabbed one second hand recently and it's been working great for an iOS side project, would be sad if I couldn't use any of this.

It includes 6 Plus. 6 and 6 Plus are essentially identical devices internally, they have the same A8 chip and 1 GB of RAM.

I smell a low-cost iPhone offering late Summer.

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.

Lower than the $0 they're already offering the Xr at? :)

One thing that Google does right with Android is back porting to older versions.

I'm having a hard time figuring out how this statement can be even remotely accurate.

Whenever new frameworks or pieces of android come out, they are often accompanied by a compatibility library that you can ship in your app to use the new API and target older platform versions.

Ok, that's a fair point.

Do you develop Android apps?

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.

Vast majority of the people with iOS12 will update. Also, at least on the announcement page, there seems to be no mention of iOS13 required for running apps using SwiftUI. Up until Swift 5 the whole runtime library needed to be shipped with the app and it is quite possible that a SwiftUI library could be shipped and run on iOS12.

Edit: On Apple developer forums I've read that the library is annotated with iOS13 requirement.

The vast majority of folks will update right away.

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.

Yeah, I agree that Apple should have added at least one version worth of backwards compatibility if they want to see quick adoption. I suppose one could hide the whole view in defines and lug two implementations but that is not much better than waiting for one year.

What UI framework are you talking about? Flutter?

It will not be on 85% of iOS devices once iOS 13 is available.

Sure, but my company (and I assume most) will maintain support for at least the last two major versions of iOS. We wont be able to be minimum iOS 13 until ~September 2020 at the earliest, probably not until early 2021.

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 having a hard time figuring out how this statement can be even remotely accurate.

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.

Of course, that’s because most manufacturers don’t push updates to their devices and many users are using versions from years ago.

True. But supporting iOS 12 would mean I could start working on SwiftUI apps today.

Do you have a link to the comparison?

It was during the event, they just displayed an overly dramatic LOC comparison on the screen between a few page-downs on a longer Swift file, then the next screen showed a ~10 line block of code which does the same thing. Followed by the standard audience applause.

The livestream hasn't been uploaded yet but I'm sure you could find it in one of the live blogs.

Part of that comparison (on the "before" side) was a bunch of Cocoa autolayout code. It's verbose and annoying, only mitigated if you're using Interface Builder, which has its own significant downsides. If the declarative form in SwiftUI supports a saner approach to managing and adjusting layout, then there's absolutely nothing overdramatic about that comparision. It's a potential game changer.

Thanks! Indeed it's impressive.

Nah, do what we do on the web: Polyfill. It wouldn't be perfect and have all the interactive tools, but a API-compatible lib that abstracts over AppKit / UIKit seems doable, then just switch imports when the future arrives.

> but a API-compatible lib that abstracts over AppKit / UIKit seems doable

…have you taken a look at development for Apple’s platforms lately? Nobody has been able to do this yet.

People have (many companies have their own frankenstein version), but maintaining them is hell and I'm not sure I'd trust the OSS community to do a great job of it.

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/

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.

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.

Details will be in the Platform State of The Union later today. Keynotes are always press/casual-fan focused

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 love RN, but it's the wrong tool for the job if you only care about one platform.

Even if you only develop for iOS at the start, the nice part of RN is the promise of simplified porting. So while the number of people targeting multiple platforms at the start may be low, the number who would consider it "on the roadmap" (or possibly on the roadmap depending on the app's success) is pretty high in my experience.

Google announced jetpack compose in last i/o. But it seems like it was not discussed here at all. And from other comments seems like developers don't know about it.

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

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 Styling: https://facebook.github.io/react-native/docs/style Layout: https://facebook.github.io/react-native/docs/flexbox

Maybe we need to coin a new term.

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

Does that work?

Cross-ecosystem vs. cross-platform maybe.

They are. If you make a react native project using the official boilerplate generator, the resulting project will be able to run on both Android and iOS out of the box, with no modifications. It's true that you might need to use native APIs and components for specific features, but the everyday UI building blocks of RN are cross platform. These are(in my mind): the flexbox layout engine, styleable box/image/text components, animation system, and a touch and gesture interaction system. In addition many of the other parts are cross platform too: geolocation, device dimensions, activity indicators, alerts etc.

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.

You can share components but have to carefully handle any platform-specific code.

I built cross-platform apps with it.

It works by supplying me with native modules and native components for every platform and I write my domain logic in portable JavaScript.

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.

I wouldn't call anything close to cross-platform if it only works on Apple's products and devices.

You're welcome to your definition, but if you think developing for desktops, notebooks, smartphones, and tablets, with all the differences they encompass is trivial, you're in for a shock.

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.

You are literally the only person I have ever heard to use "cross-platform" in the sense you just described.

Did you mean "cross form-factor" or something?

No. Macs run macOS, iOS devices run iOS (and now, iPadOS), Apple Watches run watchOS, and Apple TVs run tvOS. They might have shared heritage but they are decidedly not the same platforms; these are not different form factors for the same thing (aside from iPhone/iPod touch and iPad), these are different platforms with different use cases, different capabilities, different sets of available frameworks including what languages are supported both in terms of compiled code and what can run as an interpreter on-device, different kinds of considerations for interaction, different userbases with different expectations.

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.

Bit like Microsoft in 2005. "Cross platform" meaning Windows, Windows Server, Windows Mobile, Windows CE...

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

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.

There sure are a lot of developers only interested in developing for Apple platforms. But wouldn't it be beneficial for Apple to extend the framework outside their ecosystem? I doubt the reason they haven't is to limit expending resources.

It wouldn't be beneficial to Apple.

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.

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?

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.

Perhaps they like the things that they're paying for, and no one's tricking them into anything, and maybe they even looked at those alternatives and still decided that they liked what they had. Crazy, I know. Something to consider though.

> what are you paying for with Apple?

For me, it's vertically integrated privacy.

Some other fellow developers are happy to target just Windows, just PS4, just XBox, just Wii, just Switch, just Android, just Arm mbed, just Tizen, just whatever OS.

Not everyone has this urge to create FOSS software, available as free beer in every possible OS out there.

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

Flutter doesn't use native controls . It draws everything. Just pointing out that difference.

FWIW, the Apple developers discussing SwiftUI on Twitter are careful to point out that SwiftUI is not designed to be a wrapper around UIKit. Much of the implementation currently uses UIKit under the hood, but that's an implementation detail that is subject to change and there are already significant parts of SwiftUI that don't use it.

It seems as though they are viewing SwiftUI as a successor to UIKit/AppKit on all their platforms, not just a higher level wrapper.

Native controls aren't drawn too?

yes, they're drawn too. but, i think what the above comment is pointing out is that Flutter itself does the drawing, instead of delegating the drawing to iOS or Android native widgets.

Actually no, Flutter doesn’t do the drawing. It’s done by Skia, much like Cocoa native controls are drawn by Quartz.

There isn’t much of a difference between Flutter controls and native controls, other than being a reimplementation in some cases.

> other than being a reimplementation in some cases.

Hmm...that's pretty much the entire difference between native and non-native controls.

Yes, and that is precisely my point.

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.

That was the exact opposite of my point.

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?

> There isn’t much of a difference between Flutter controls and native controls

Except they're not actually native controls. They're reimplementations of them. It is a very important distinction.

> There isn’t much of a difference between Flutter controls and native controls

Except that they behave quite differently…

I meant technically speaking. Obviously the implementation or the user experience are a different matter.

another noteworthy difference is that the look and feel of a widget is locked down at compile time in a Flutter app.

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.

More than just drawing. They have to reimplement all of the behaviors of the built in controls. I'm sure google is up to the task, but my experience has been there's always things missing and and lag behind native .

> there's always things missing and and lag behind native

Flutter specifically or cross-platform UI frameworks in general?

I don't mind it being different, but does the app feel unpolished?

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.

Flutter is cross platform. I looked for it but didn't see where jetpack has this capability. Please post me a link if I’m wrong, I would follow this project if it does support cross platform development.

Jetpack Compose was announced at IO: https://blog.karumi.com/android-jetpack-compose-review/

No he means Flutter which has been around a lot longer, it's immediately what I've thought of being inspired by as well:


I know pretty much what he/she meant, was just making a point that I don't believe in Flutter's long term success.

Trying to sell Dart a 2nd time was a mistake.

Flutter's not a PR campaign for Dart, they're a separate project that chose Dart based on its technical capabilities [1].

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 [2].

[1] https://flutter.dev/docs/resources/faq#why-did-flutter-choos...

[2] https://developers.googleblog.com/2019/05/Flutter-io19.html

That after-the-fact reasoning link that gets posted every time someone questions Dart is well known, no need to give it to me.

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.

> no need to give it to me.

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.

What information have I used?

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.

I think dart/flutter serves primarily two purposes, as I see it. First the obvious one, Google is trying to get devs used to flutter as when the time comes to switch to Fuchsia/Zircon, it would be relatively a breeze.

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

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/

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

You are missing the fact that Android team doesn't want to have anything to do with Dart, and started a Kotlin everywhere initiative, including iOS via Kotlin/Native.

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

Which for most companies is 2+ years away

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

I stand corrected. thanks.

Except it’s not ready to go because it’s not backwards compatible it seems.

Indeed, but (unsurprisingly) Apple-only.

It does, in a good way. I really liked Flutter's UI approach.

But native, of course.

And proprietary.

Jetpack Compose is more like it

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.

The future of macOS development may be SwiftUI, but that's also the future of iOS, iPadOS, watchOS, and tvOS development.

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.

I also see it as a fairly nice way to develop iPad apps.

SwiftUI running through Catalyst, surely?

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)

Yeah, or once I can finish unarchiving Xcode…

Or maybe Catalyst runs on (in?) SwiftUI?

@kylemacomber - can you provide some context here? I'm sure many of us would love to get a high-level understanding of this.

"A rose by any other name would smell as Marzipan". Even if it's called SwiftUI and not Marzipan, it still has all the same future problems as when it was called Marzipan [1]

[1] https://blog.iconfactory.com/2019/05/what-to-expect-from-mar...

SwiftUI is totally unrelated to Marzipan.

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

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

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

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!

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.

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" :)

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

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

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

Just no. As an Apple user, just use whatever the tools they give you when you're developing for Apple platforms.

It would be great until you need to debug something. Then it would be a nightmare.

All meta-platforms are themselves platforms; meta-ness is in the implementation. So you could always do this no matter what you started from, but it's not actually a good idea.


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.

Who said anything about compiling SwiftUI to Flutter?

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.


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

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

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

It appears to be https://github.com/apple/swift/pull/25221, which doesn't yet have a public proposal.

Single-expression functions can now return a value without the “return” keyword: https://github.com/apple/swift-evolution/blob/master/proposa...

Yeah but the example code looks like multiple expressions?

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

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

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

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

Ouch, that’s pretty awful…

They look like initializers. Functions are lower-case by convention in Swift.

That is convention, but there’s no need to follow it ;)

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact