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.
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.
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.
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.
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!
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)
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!
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.
> 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!
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…)
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]?
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.
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.
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.
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.
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!
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.
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.
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?
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
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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 .
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.
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].
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.
Think highly of yourself much? But I'll be continuing to provide links as I see it's relevant and informative, my comments are not just for your benefit, readers can make their own mind whose opinions are more informed - "no need" to tell others how to comment.
> Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities".
Am I meant to be impressed by this list of languages? I'm not. Are the number of languages meant to give your inexperienced opinion on Flutter's development environment some credence or is this washy strawman meant to downplay anyone else's opinion who wasn't a developer in the 90's when these languages were more relevant?
What matters is what's relevant now and Flutter lets you build modern x-plat Mobile, Web, Desktop and Embedded Apps with productive Live Hot Reload environment that's both fast at development and runtime which can be run in a JIT VM, as AOT compiled or transpiled to tree-shaken JS. Which of these above languages provides a more productive and "technically impressive" environment to develop iOS/Android, Web and Embedded Apps than Dart/Flutter?
> Flutter is a way to rescue Dart, plain and simple.
Adding "plain and simple" to an baseless opinion doesn't re-enforce it, including links that backs up this wild speculation will. What information have you used to be able present this opinion as fact so staunchly? Do you really believe Google invented and funded the Flutter project out of thin air to give Dart a popularity boost?
> And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART.
How can Android have more political power for Fuchsia than Dart which is what most of its UI is written in? You can also develop Flutter Apps on Chrome OS so that's no different. Chrome OS is still primarily a Web OS, allowing running Android Apps doesn't make it an OS for running Android Apps and devs aren't going to be lining up to develop Chrome OS Apps using Android.
Flutter's strength's is that you can develop x-plat App's that looks, behaves and runs natively on all its supported platforms - feel free to wait until Kotlin reaches the same maturity on iOS before declaring it a Flutter killer. Kotlin still suffers from Android's complicated and fragile tooling and from what I've seen with JetPack compose it's highly coupled to Android - it's going to take a long time before they'll let you build iOS/Android Apps from a single code base.
Besides Dart v1.0, Dartium, Angular Dart when they were still relevant to Chrome and Angular teams, and following up on Flutter?
I usually only criticize stuff that I actually have some level of experience with.
AdWords team rescued Flutter, after Chrome and Angular teams stop caring, which even caused Dart designers like Gilad to leave in disagreement.
I believe that they found out some internal management support that is willing to give them a time frame, of lets say 5 years to prove themselves worthy of such support.
Android has more political power ChromeOS has adopted Android and not the other way around, the two commercial OSes from Google.
While their experimental OS, Fuchsia is now adding support to run ART, while at the same time via Scenic, decoupling themselves from the UI framework.
You want to believe in Dart/Flutter, go for it.
Me, I am betting it will be joining the list of abandoned Google projects in a couple of years.
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'.
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.
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.
"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]
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!!!!!!!!
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" :)
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.
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.
> 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.
> 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.
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.
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?
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.
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.
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.
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.
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).
QML has a fundamental difference with the links you showed : it is able to create bindings according to variables used in expressions / functions / etc.
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.
> 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.
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.
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.
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.
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:
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 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...
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.
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.
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 "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:
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.
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)
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
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...
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.
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.
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.
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."
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.
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.
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?
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.
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 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?
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.
If you’re at WWDC stop by the labs and say hi!