Chris Lattner may be a special case since he started and guided the Swift language formation and development when he as at Apple. Doesn't necessarily negate your point, however.
Also, although there are folks who work on Swift and also SwiftUI, the goals and direction for SwiftUI are made by Apple framework managers, not the Swift core team. Having non-Apple representation on the core team is a good goal for making sure Swift, the language, serves the larger community. However, non-Apple representatives on the core team will most likely not be privy to discussions about the status of closed-source Apple frameworks until Apple management makes the decision to open-source, or otherwise support, non-Apple environments.
Its "SwiftUI" as opposed to "Objective-CUI," i.e., AppKit/UIKit.
It's not clear yet whether Apple considers SwiftUI a piece of the "critical infrastructure of the language." It is a critical piece of the longer-term Apple infrastructure.
SwiftUI does not work the same way that Flutter does. Flutter reimplements every single widget in its toolkit and draws them directly on a canvas using Skia, thus requiring multiple designs and underlying implementations for each platform it supports, in order to feel "more native."
SwiftUI is an interface layer that sits atop a truly native platform implementation, such as UIKit, AppKit, or — in some cases — CoreGraphics/CoreAnimation. If the SwiftUI interface layer were to be open sourced, the community could implement it on top of the native Java Android UI framework on Android, thus getting the native look and feel for free, while still being able to write cross-platform code.
I'm not sure how beneficial Apple views cross-platform code to its interests. Again, until otherwise noted, SwiftUI is an Apple framework designed to ultimately help Apple to sell more hardware. Making it easy for other platforms to build their infrastructure, like making SwiftUI open-source, may not play to Apple's ROI calculations, especially given that the building blocks that are used to build SwiftUI are part of the open-source language, or soon will be (property wrappers, function builders, opaque types, etc.). But, who knows?
It’s not a nitpick, is really important. It’s really frustrating to keep seeing the community so strongly referring to Swift and the Core Team as Apple.
If the Swift community doesn’t believe that this language is bigger than that I don’t see how we expect to convince other communities.
It may not use AppKit/UIKit Objective-C interfaces (remains to be seen), but it sits on top of CoreGraphics, CoreAnimation, CoreData, Foundation (Darwin), Metal, and all the other Apple base-level frameworks that are the basis of macOS/iOS/tvOS/watchOS applications, most likely including some Apple-private interfaces. These are all considered components of AppKit and UIKit.
Which one exactly do I need to check?
I'm interested in to find confirmation to this: "SwiftUI is an interface layer that sits atop a truly native platform implementation".
There is a couple on SwiftUI. I think the introductory video on Monday mentions it. A question though: Why is it important? SwiftUI is an Apple framework whose implementation right now is private to Apple. Simply because it has the word "Swift" in it doesn't mean it is part of the open Swift community.
You didn't get my point. I know how Flutter, React Native and Kotlin/Native work. I'd like to know how SwiftUI works. If it works like it was mentioned by roonieone, that sounds like React Native approach.
Based on the limited playing I've done with the SwiftUI tutorial, I would say that it is very much like React Native in concept. However, SwiftUI code has to co-exist and interoperate with existing UIKit/AppKit architectures. I can use traditional AppKit/UIKit views and view controllers as well as SwiftUI views in the same application. On MacOS, I have to use the traditional window controllers, document controllers, window view, and document models since they are not supported yet with equivalents in SwiftUI. I can use Interface Builder xibs and storyboards with SwiftUI views in the same application.
The best way to understand would be to install MacOS 10.15 beta and Xcode 11 beta and play with the code. Since all of this is still in beta development, I would not expect that extensive documentation will be ready until the fall. Detailed implementation detail on how SwiftUI does its magic will probably not be forthcoming since it's still a Apple-proprietary framework.
Thanks for sharing your experience!
I did a few prototypes with SwiftUI. It's buggy.
I won't use SwiftUI for any client's projects before something equivalent as UICollectionView will be added to it.
It would be completely counter to their interests. Apple's goal is to make more money by making their platforms better, and SwiftUI is a way to make it easier to make great apps for Apple platforms. Apple has absolutely no interest in making it easier to make great apps for Android or Windows.
I really think that point of view is quite wrong:
It wouldn't be easier to make great apps for Android and Windows — it would be easier to write apps (which might or might not be great) for iOS, which could also be deployed to other platforms.
As afaics, Android traditionally does not have the same focus on nice user experience as iOS, portability would be a strong argument to favor SwiftUI over "native" solutions (which might offer slightly better integration).
For end users, the best platform is the one with the most apps, and with the highest quality of those apps.
So in this scenario, Apple would be in a very strong position: SwiftUI would be the dominant toolkit, and iOS would be the platform with the superior user experience for nearly all apps (simply because those all would be iOS apps in the first place).
Well SwiftUI is not Catalyst, it's not about porting apps to various platforms. But in any case, why would Apple want to do anything at all to lessen the gap between iOS apps and apps for other platforms? That's the opposite of what they want. They put in enormous efforts to help developers write the best possible iOS (and Mac) apps, precisely to make them better than Android apps, in the end leading to people preferring iPhones. It is not in their interest to level the playing field.
SwiftUI is a means to an end, they don't really care about SwiftUI per se, only to the extent that it helps iOS and Mac developers make better apps.
I don't think I have really grasped your argument, but let me rephrase mine: Which world do you think Apple prefers:
The world where everyone uses SwiftUI, making apps on all platforms nicer, or
The world where only Apple platforms get better apps, and SwiftUI is used only by Apple developers.
