SwiftUI | Hacker News Reader

SwiftUI

developer.apple.com

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

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

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.

https://github.com/reagent-project/reagent

That looks like exactly what SwiftUI is doing.

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

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

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)

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.

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.

SwiftUI is protocol-based, not class-based

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

Yes

https://developer.apple.com/documentation/combine

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.

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

Fantastic work you've done here!

Thanks. Really good job

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.

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

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)

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

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

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 mean and official declarative UI library then Google released one of those at Google IO this year:

https://developer.android.com/jetpack/compose

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

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

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.

you are right, not sure why you are being downvoted

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

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.

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

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.

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

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.

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!

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!

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.

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!

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

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.

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.

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

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

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?

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

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

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

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.

It's wrong.

https://github.com/facebook/yoga/tree/master/yoga

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.

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.

Can I use that in an existing app?

Only if you only support the latest OS versions.

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.

https://github.com/Shopify/FunctionalTableData

Purely for our own vanity - did Apple engineers take any inspiration from FTD? Or just independently set out to solve the same problems we had?

I saw somewhere that all this started around 2012.

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.

https://news.ycombinator.com/item?id=20088593

not all heroes wear capes

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?

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

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

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.

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

"The dirty secret:

We’re all just building CRUD apps."

https://twitter.com/iamdevloper/status/455409190505562112

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.

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)

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:

https://stlab.adobe.com/group__asl__overview.html

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.

http://www.emarcus.org/papers/gpce2009-marcus.pdf

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.

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

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

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.

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.

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.

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/

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

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.

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.

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.

What UI framework are you talking about? Flutter?

Jetpack Compose - https://developer.android.com/jetpack/compose

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

>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

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.

https://mixpanel.com/trends/#report/iphone_models

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.

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

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.

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

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.

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.

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

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.

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.

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.

I love RN, but it's the wrong tool for the job if you only care about one platform.

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.

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.

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

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.

> what are you paying for with Apple?

For me, it's vertically integrated privacy.

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.

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.

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.

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

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

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.

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

https://flutter.dev/docs/development/tools/hot-reload

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

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/

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.

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

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

Which for most companies is 2+ years away

I stand corrected. thanks.

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

Indeed, but (unsurprisingly) Apple-only.

But native, of course.

And proprietary.

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

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.

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?

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

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

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.

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

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.

SwiftUI running through Catalyst, surely?

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.

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…

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

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.

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.

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.

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

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.

https://xkcd.com/927/

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.

https://www.tiobe.com/tiobe-index/

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?

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?

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

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

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

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

Ouch, that’s pretty awful…

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

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

Looks a lot like Flutter

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

Don't forget qml

Yeah, it's a shame people are praising these new frameworks but forget similar ones that have been around and rocking for years.

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.

Both looked kind of like GTK (in a non-verbose language like Python) to me, too. Maybe I am seeing things.

Also have a look at https://fsprojects.github.io/Fabulous/

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

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?

Looks like it shifts the focus toward developing more intelligent components. They mentioned custom SwiftUI components a few times in the demo.

This is one of the things I am eager to get a deep dive on in later session videos.

Well the docs say you can chain an id() property on any view being built in the tree which would hopefully allow you to reference it at runtime and insert/delete children, but I don't see anything obvious for assigning that id to like an outlet so you don't have to traverse the whole tree to find it.

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

http://shoesrb.com/

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.

Here's one comment about inspiration:

https://twitter.com/jckarter/status/1135666944273571840

The nesting makes it look similar but Shoes isn't declarative so it works very differently under the hood

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

Depends on what you mean by "clean". I'd say it's pretty good from what I can see? The examples are also incomparable; the one you link to is nearly 20 lines of code to define nothing more than an embedded triangle image and single text embed with a few colors, while the Swift example hosts an entire modal list with embedded picture components and text (while handling fluid scrolling, right-to-left langs, dark mode theming, etc all implicitly) -- all in the same number of lines or so (and had further mods made during the Keynote by a developer with similar brevity.) Judging from lines only or "cleanliness" I'd say SwiftUI is doing pretty good here, but ultimately the examples are too apples and oranges to draw any real conclusions from.

Syntax aside, there is a large semantic difference between the two: QML is a separate language/modeling tool that is embedded into the application runtime. SwiftUI is in fact ordinary Swift code and the UI you define with it is also ordinary Swift code too, code that XCode and the Swift compiler understand and analyze and refactor and compile like any other. Just with some special magic to make the UI builder work with it. I think this has a lot of advantages notably from a toolchain perspective, since you don't even need XCode (just the Swift compiler) to do things like xrefs/refactorings across SwiftUI code, nor maintain tooling like that across two languages (XYZ + whatever UI modeling language)

Given that, my first impressions of how far they took it (and how well it came out) are pretty good.

> while the Swift example hosts an entire modal list with embedded picture components and text (while handling fluid scrolling, right-to-left langs, dark mode theming, etc all implicitly)

I think you might check out more of QML / QtQuick 2 before drawing any conclusions.

    import QtQuick 2.12
    import QtQuick.Layouts 1.12

    ListView {
        model: Model.items
        delegate: RowLayout { 
            Image { source: image }
            Column {
                Text { text: title }
                Text {
                    text: subtitle
                    color: "gray"
                }
            }
        }
    }

This should be more or less the same. Fluid scrolling is backed by the underlying Flickable [1]. RTL support is available an can be changed in runtime [2]. Themes / colors can be changed in runtime as well [3].

Lastly, it runs on Windows, Linux and Android as well as OSX and iOS.

[1] https://doc.qt.io/qt-5/qml-qtquick-flickable.html

[2] https://doc.qt.io/qt-5/qtquick-positioning-righttoleft.html

[3] https://doc.qt.io/qt-5/qtquickcontrols2-styles.html

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.

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

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

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

> But it is Swift, which (at the risk of stating the obvious) QML is not.

sure, and I agree that Swift has some better features and a better foundantion than JS on which QML is based upon

> And you can't write an entire app in QML.

This however is not true. I've worked on multiple pure QML apps so far (well, if you don't count the auto-generated main.cpp). Remember that you have access to a complete ES7 JS engine which allows for a lot of stuff.

I think QML is used for Qt Quick and not compatible with desktop-style Qt Widgets. Qt Widgets .ui files are human-unreadable, and when edited in Qt Designer, usually lead to incorrect tab order (see LMMS's settings screen).

All of these seem somewhat conceptually similar to Audacity ShuttleGUI (https://wiki.audacityteam.org/wiki/ShuttleGui)

Or the Python context-manager-based declarative GUI (wrapping PyQt) I wrote for my relatively small program corrscope (https://github.com/corrscope/corrscope/blob/master/corrscope...)

> I think QML is used for Qt Quick and not compatible with desktop-style Qt Widgets.

yes, but it does not prevent you to make desktop apps with it. See e.g. Kirigami UI which is based on QtQuick : https://kde.org/products/kirigami/

(and for "large" desktop apps made with QtQuick, look at the Blizzard launcher, or Substance Designer which is as much a desktop app as one can aspire to be : https://cdn.studiodaily.com/wp-content/uploads/2019/05/subst... )

QML has a fundamental difference with the links you showed : it is able to create bindings according to variables used in expressions / functions / etc.

e.g. if you do

    MyWidget { 
         width: { if(y > 50) 
                    return f(height) + x;  
                  else 
                    return otherItem.height / height;
         }
    }

then whenever any of the properties used in the expression changes, the width is recomputed.

Rectangle calculations. how quaint.

I don't understand why this gets downvoted. It's an entirely valid point and probably SwiftUI took inspiration from it.

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.

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

It certainly gives me a reason to migrate now. Swift alone wasn't enough of a reason.

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.

How is swift a javascript clone?

Objective c is insanely verbose.

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?

I feel you. I understand that Apple tries to cater to the "web developer" crowd as well, but sometimes this feels like a regression compared to what OPENSTEP was about.

Final blow at least for me will be at least some minimal interop with c++ (instead of just c) and sort of reflection mechanism.

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

Tutorial: https://developer.apple.com/tutorials/swiftui/

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

https://developer.apple.com/download/

Thank you, but that's how far I got myself. It is telling me there are no downloads available at this time. I am asking, because I am still on 10.14.5 and I thought the Xcode 11 beta might only be available on the 10.15 beta.

Under Applications now: Xcode 11 beta

Check the “Applications” tab, the Xcode download is there (they redesigned the page, which makes it IMO worse). No idea if it runs on Mojave, but I would think so based on history.

The XCode 11 "whats new" page [0] says:

>To use the SwiftUI design canvas Xcode 11 must running on macOS Catalina.

Please let us know if you find that's incorrect.

[0] https://developer.apple.com/xcode/whats-new/

The direct download is here:

https://developer.apple.com/services-account/download?path=/...

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

https://xcodereleases.com

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

  var body: some View {

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

It's part of generalized existentials, a forthcoming language feature.

It’s part of Swift 5.2: https://github.com/apple/swift-evolution/blob/master/proposa...

It's part of opaque types, which are new in Swift 5.1

https://docs.swift.org/swift-book/LanguageGuide/OpaqueTypes....

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)

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`

Why doesn't a protocol conform to itself?

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.

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.

Can this retroactively support apps targeting iOS 12 and older?

probably not

What do you think

No. One of the engineers said on Twitter it is a system framework.

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.

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.

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

.color(.gray))

What object is .gray acting on?

That syntax is a shortcut for UIColor.gray, so this is really:

.color(UIColor.gray)

I would expect it's the grey static member of SwiftUI's Color struct:

https://developer.apple.com/documentation/swiftui/color/3049...

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)

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

that's shortcut syntax for an enumeration case where the type of the enumeration can be inferred

It's not just for enums. It works for any static variable on a given type. So you can say .gray and have it map to NSColor.gray, etc.

I guess .color() is a method, and .gray is an enum case.

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/

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

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

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

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

It reminded me of Scaloid https://github.com/pocorall/scaloid

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?

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.

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

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

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

https://www.boden.io/

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

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

Looks nice like Flutter.

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

First-call declarative UI support is amazing!

Will there be a similar API for Objective-C?

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

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

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.

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.

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

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

> SwiftUI is iOS only

It's also on macOS

I think it’s on tvOS and watchOS, too.

For the teams that would have gone native if it was easier/faster I imagine it does change the equation quite a bit. Makes me wonder how this changes things internally for mobile teams at Facebook as well.

For JS/web focused teams I don’t think it impacts much, just like I don’t think this impacts Ionic developers that much.

> For the teams that would have gone native if it was easier/faster I imagine it does change the equation quite a bit (Airbnb for ex).

Airbnb have always been native, and their one foray into partially using React Native didn't work out:

https://medium.com/airbnb-engineering/sunsetting-react-nativ...

I think React Native devs still want to be able to deploy to Windows. Unless I'm really missing something here...

> across all Apple platforms

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

How is this like FRP, React, or Elm (each of those things being fairly different themselves). SwiftUI actually reminds me of JavaFX when done with JavaFX Script (ahead of its time by too much), but I haven't been able to dig up a lot of examples from their website yet.

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.

Elm isn't FRP anymore [1], it uses some sort of process and scheduler model behind the msg system. React isn't FRP either, though you can approximate higher order FRP with Redux if you want.

[1] https://elm-lang.org/blog/farewell-to-frp

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

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.

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

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

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.

SwiftUI is not just for iOS, it's for MacOS, tvOS, iPadOS and WatchOS as well. That covers well over a billion devices with all kinds of apps.

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

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.

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?

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?

It’s too early to tell, but it’s certainly very exciting.

It's probably the biggest shakeup to Apple's developer platform since Swift was announced.

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

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.

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?

I don't think that's true. It seems to be higher-level framework based on Cocoa Touch. Existing apps will work just fine. And probably any real world app will have to deal with Cocoa Touch as well, like any real React app have to work with DOM.

That's a lot if pointless FUD.

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

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.

QuickDraw debuted 35 years ago. QuickDraw GX was 24 years ago. Etc.

You're saying that MacOS has been around a long time, which is true.

:) Fair point.

I firmly don't believe they're changing frameworks to "provide platform lockin".

Development philosophies change over time, like the other's said, some of those UI frameworks you mentioned are 20+ years old.

It does suck that we can't use it on other platforms, and I'm sure they don't want to spend resources on doing so, but there's no way the main motivation is to keep people switching frameworks constantly.

That's certainly not why the programmers involved do it, they do it to improve things, but the effect is platform lockin, which is not at all unwelcome for platform vendors and I suspect is why the companies are quite happy with constant churn in languages and tools. I'm not suggesting that is 'why they do it' just that it is a strong incentive to keep doing it.

If they don't control the language and tools for the platform, they don't control the platform.

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.

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?

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

Reply on news.ycombinator.com