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'.
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.
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.
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 .
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.
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.
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.
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.
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.
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.
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.
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.
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’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.
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]?
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.
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.
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.
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.
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".
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).
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?
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!
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.
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!
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.
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.
> 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.
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 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!
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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:
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.
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 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.
> 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.
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" :)
393 comments
[ 3.7 ms ] story [ 365 ms ] threadTutorial: https://developer.apple.com/tutorials/swiftui/
I bet by next IO, Flutter will get replaced by it, specially after the #KotlinEverywhere announcement and Kotlin/Native effort for iOS.
https://flutter.dev/docs/development/tools/hot-reload
Trying to sell Dart a 2nd time was a mistake.
Given Flutter enables the nicest native x-plat dev experience today I'd say it has a very bright future, which they've also recently announced Flutter for Desktop and Embedded devices.
Jetpack compose is years away from the same kind of x-plat support that Flutter's providing for Mobile, Web, Desktop and Embedded [2].
[1] https://flutter.dev/docs/resources/faq#why-did-flutter-choos...
[2] https://developers.googleblog.com/2019/05/Flutter-io19.html
Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities".
Flutter is a way to rescue Dart, plain and simple.
Yes, Jetpack Compose might be doing its baby steps, but I am betting most developers are more keen in having Kotlin than Dart on their CV, specially after Dart v 1.0's demise.
And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART.
Think highly of yourself much? But I'll be continuing to provide links as I see it's relevant and informative, my comments are not just for your benefit, readers can make their own mind whose opinions are more informed - "no need" to tell others how to comment.
> Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities".
Am I meant to be impressed by this list of languages? I'm not. Are the number of languages meant to give your inexperienced opinion on Flutter's development environment some credence or is this washy strawman meant to downplay anyone else's opinion who wasn't a developer in the 90's when these languages were more relevant?
What matters is what's relevant now and Flutter lets you build modern x-plat Mobile, Web, Desktop and Embedded Apps with productive Live Hot Reload environment that's both fast at development and runtime which can be run in a JIT VM, as AOT compiled or transpiled to tree-shaken JS. Which of these above languages provides a more productive and "technically impressive" environment to develop iOS/Android, Web and Embedded Apps than Dart/Flutter?
> Flutter is a way to rescue Dart, plain and simple.
Adding "plain and simple" to an baseless opinion doesn't re-enforce it, including links that backs up this wild speculation will. What information have you used to be able present this opinion as fact so staunchly? Do you really believe Google invented and funded the Flutter project out of thin air to give Dart a popularity boost?
> And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART.
How can Android have more political power for Fuchsia than Dart which is what most of its UI is written in? You can also develop Flutter Apps on Chrome OS so that's no different. Chrome OS is still primarily a Web OS, allowing running Android Apps doesn't make it an OS for running Android Apps and devs aren't going to be lining up to develop Chrome OS Apps using Android.
Flutter's strength's is that you can develop x-plat App's that looks, behaves and runs natively on all its supported platforms - feel free to wait until Kotlin reaches the same maturity on iOS before declaring it a Flutter killer. Kotlin still suffers from Android's complicated and fragile tooling and from what I've seen with JetPack compose it's highly coupled to Android - it's going to take a long time before they'll let you build iOS/Android Apps from a single code base.
Besides Dart v1.0, Dartium, Angular Dart when they were still relevant to Chrome and Angular teams, and following up on Flutter?
I usually only criticize stuff that I actually have some level of experience with.
AdWords team rescued Flutter, after Chrome and Angular teams stop caring, which even caused Dart designers like Gilad to leave in disagreement.
I believe that they found out some internal management support that is willing to give them a time frame, of lets say 5 years to prove themselves worthy of such support.
Android has more political power ChromeOS has adopted Android and not the other way around, the two commercial OSes from Google.
While their experimental OS, Fuchsia is now adding support to run ART, while at the same time via Scenic, decoupling themselves from the UI framework.
You want to believe in Dart/Flutter, go for it.
Me, I am betting it will be joining the list of abandoned Google projects in a couple of years.
Secondly, and the most immediate reason, I think it's a very clever and clear move from Google to lock-in devs into using Google Cloud services like Firebase and Cloud ML services by leveraging Flutter. If you have observed, Microsoft has given a rebirth to their Xamarin developers YouTube channel and have been hosting 'The Xamarin Show', which is, hmm, quite similar to 'The Boring Flutter Development Show'.
I may be missing something, but SwiftUI seems to be pretty much ready to go today.
Which for most companies is 2+ years away
Flutter specifically or cross-platform UI frameworks in general?
I don't mind it being different, but does the app feel unpolished?
There isn’t much of a difference between Flutter controls and native controls, other than being a reimplementation in some cases.
Hmm...that's pretty much the entire difference between native and non-native controls.
A previous commenter implied that there somehow native controls were technically different than Flutter controls.
Obviously the rendering stack is different but Skia is as native as Quartz is.
Native widgets are those of the native widget toolkit. I can use the underlying drawing libraries to draw widgets that look vastly different and implement behaviours that behave vastly differently from the native widget toolkit.
The point of native widgets is that they are the same, not that they are drawn using the same underlying technology.
So the fact that you are using platform libraries to draw those non-native widgets is not at all relevant. After all, what else are you going to be using?
Except that they behave quite differently…
by contrast, with a native android app, the look and feel of the widget can change on an end user's device when the end user updates android on their particular device.
Except they're not actually native controls. They're reimplementations of them. It is a very important distinction.
It seems as though they are viewing SwiftUI as a successor to UIKit/AppKit on all their platforms, not just a higher level wrapper.
iOS users update pretty rapidly.
It's also on macOS
For JS/web focused teams I don’t think it impacts much, just like I don’t think this impacts Ionic developers that much.
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...
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.
The livestream hasn't been uploaded yet but I'm sure you could find it in one of the live blogs.
[1]: https://iosref.com/ios/
Google also announced a declarative UI framework. It's in the early stages and is open source. Android is on 9.x but that framework will run on much older versions of Android.
Meanwhile iOS 12 might be on 85% of iOS devices but it wont ever see SwiftUI.
Edit: On Apple developer forums I've read that the library is annotated with iOS13 requirement.
Not enough to convince my stakeholders that we don't need to support at least one major version back.
I'll probably fight that harder this year than in previous years - SwiftUI looks incredible and any AutoLayout code already feels like legacy.
I understand why, I just wish they could release this open source like Jetpack Compose. Would've been a great way to introduce SPM to Xcode and iOS as well.
I'm not even an Android developer and I already know that tons of Android libraries get back ported to older Android versions. They have to. Nobody runs the latest Android.
It's a bit shocking to get downvoted for a statement that's undeniably true.
That really is a bummer, I have an iPhone 6 and it's still alive and kicking.
https://mixpanel.com/trends/#report/iphone_models
If anything, users of really old iPhones are likely to be less spendy so you're losing less than 10%.
…have you taken a look at development for Apple’s platforms lately? Nobody has been able to do this yet.
If you’re at WWDC stop by the labs and say hi!
https://github.com/reagent-project/reagent
(Semantics aside, either way this behavior is implemented in React via useState or setState, MobX has nothing to do with it)
setState is a totally special container for data; while it technically lives in a class member (this.state), it can only be modified via setState. It isn't observable, so much as setState just internally triggers a render directly.
useState is different because your state lives out somewhere in React's core framework, associated with your function only through a value and a callback. It doesn't live in your function's local scope itself, because it would get lost if it did. It's very weird and funky because the whole point of non-class components is for them to be pure functions which have no state. useState is this shortsighted workaround for that self-imposed limitation.
Redux, finally, is different because its new states are determined as a pure function of the current state and some change. It's the polar opposite of MobX's mutable-observables pattern. Neither is strictly better, but they're as different as can be.
That said, @State seems most identical to useState -- it provides an observed value which you use $/.binding to update.
> It's very weird and funky because the whole point of non-class components is for them to be pure functions which have no state.
That's a false assumption, that's not the "point" of functional components. Functional components were always pure simply because there was no way to make them stateful. There are distinct benefits for using stateful functional components over classes -- mainly less boilerplate and abstractable/re-usable state functions.
Practically nothing, especially since it is stored in objects and the code uses a lookup table to figure out which ones are part of your function's "this" (essentially), IIRC from reading the code. The similarity to how one implements objects/classes has been good for some laughs.
[EDIT] in "React Hooks" specifically, I mean.
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.
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)
https://developer.android.com/jetpack/compose
Still learning about compose.
Who knows... With Chris Lattner at Google and Google adopting Swift for TensorFlow, I could well imagine Swift eventually working on Android (or something newer).
Almost no large scale app uses storyboards for most of their ui....
So I end up doing both. The problem (and I've seen this for many years with other similar systems), is that you have to become relatively comfortable with both approaches, so you can make informed decisions about when to flip back and forth. When can I do this with IB even though it's a teensy hacky vs when should I just subclass UIView and take over layoutSubviews and friends?
That's been my experience at least. YMMV.
Edit: Also, thank you!
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.
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!
Though Kotlin has an interesting looking DSL for doing that named Anko.
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.
Most good ideas are old school. Data is more powerful than code because it can be analyzed in more ways - for instance, you can extract all the UI and text from an app, localize and re-insert it, then verify the UI won't break, all without having to execute the app.
If it's all in code you may not be able to get to some of the views or even know it's there. This is called the rule of least power - an example of getting it wrong is C++ iostreams.
Of course I'm sure SwiftUI has solved this.
It's no surprise that XML seemed more attractive when your alternatives were Java or, even worse, Objective C. But really both options are absolutely terrible.
Thankfully we are very slowly making some steps forward again with Swift.
SwiftUI is using new Swift features sort of similar to Haskell's "do" notation, which isn't actually itself monads.
Well you know, Cocoa and its predecessor OPENSTEP were built on the idea of using IB to compose interfaces out of actual objects that then got "freezed" into a file. So, no code at all, that was the idea.
Building views programmatically was the old school way even back then. ;)
What is so astonishing about SwiftUI is that it's simultaneously the most impressive looking visual GUI builder I've ever seen... and the most terse, diff-able syntax I've ever seen. I can't think of anything that has combined these two properties quite so successfully.
The idea behind Interface Builder is that it writes the class instances and their properties using NSCoding, and they're decoded at runtime and assigned to your IBOutlets just as if you had initialized them in code, set their properties, and assigned them to instance variables yourself. XIBs were introduced with OS X Leopard as a text-based way to store the files in source control, but they're still compiled into binary NIBs when the project is built. You're not supposed to hand-edit the XML.
I thought they were crazy strict and would, like, fire people for posting on forums or Twitter
It must be so much fun to work on a project that impacts so many developers. Thanks again!
https://github.com/facebook/yoga/tree/master/yoga
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?
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?
This is one of the things I am eager to get a deep dive on in later session videos.
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.
You're saying that MacOS has been around a long time, which is true.
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.
If they don't control the language and tools for the platform, they don't control the platform.
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?
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.
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.
[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
There's something to be said for being able to use one language for all things.
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
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.
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/jimbo1qaz/corrscope/blob/master/corrscope...)
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
then whenever any of the properties used in the expression changes, the width is recomputed.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.
What object is .gray acting on?
.color(UIColor.gray)
https://developer.apple.com/documentation/swiftui/color/3049...
Given that SwiftUI has live reloading and a sensible template interface I could absolutely see it winning over some RN devs. There's something to be said (particularly with Apple) for using the native toolset rather than RN, Flutter and the like.
But applications written in React Native aren't cross platform, are they? You have different components depending on the platform. My understanding is that they claimed you wouldn't have to learn a different framework when switching to a new platform, not that your apps would be portable.
It works by supplying me with native modules and native components for every platform and I write my domain logic in portable JavaScript.
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
React Native is for cross-platform. SwiftUI is for cross-device.
Does that work?
Even some of the built-in components are platform specific though, such as the segmented control for iOS and view pager for Android. But the nice thing is you don't need to create a separate project to use these, you can just chose the appropriate one at runtime based on the platform.
Probably still in alpha...
I'm interested in your take on that though. I'm self taught and I've got some weird ideas about things.
[1] https://elm-lang.org/blog/farewell-to-frp
>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/
https://developer.apple.com/services-account/download?path=/...
for some reason my account only shows "There’s currently no beta software available for download."
Best-kept secret with direct download links (from apple.com)
https://docs.swift.org/swift-book/LanguageGuide/OpaqueTypes....
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:
And I try to call this: I will get an error, because the protocol Button does not conform to itself. However If I use opaque types: this works just fine because the compiler is able to determine the concrete type returned by `createPlayButton`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.
Objective c is insanely verbose.
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?[1]: https://developer.apple.com/documentation/swiftui/viewbuilde...
> 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