What market dominance? Afaik, Android has for more users in most parts of the world - Apple just dominates iOS ;-)
But here's why I would not keep SwiftUI an exclusive technology:
Cross platform is definitely desirable for many people - we all may agree that it's crap, but managers love the concept of doing work once and selling it twice ;-)
So if SwiftUI would be a serious alternative for platforms other than iOS (and Mac... although most people seem to forget that most of the time), there would be some pressure to use it - not because it's the best way to build apps for Android, but because it is good enough to do so.
For Apple, I think this would be beneficial, because it would be their platform that has the best integration, whereas the other platforms would have all the apps as well - but the overall experience wouldn't be as good.
On the other hand, what if some alien alternative turns out to be "good enough" to build apps for iOS? I think this would have bad consequences for all of us (Apple as well as Swift developers).
Of course, all this doesn't matter at all, and probably nobody with the power to decide such things will ever read this threat ;-)
Well, wait, SwiftUI is now as "cross-platform" as it can be with support for 5 platforms. tvOS and watchOS differ from each other more than iOS from Android. This argument shouldn't work anymore. Using this same framework for platforms so diverse is now "sanctioned" by Apple.
The big misconception out there seems to be that people think "cross-platform" means sharing 100% of the code. This was never true even for React Native apps. And this is what I expect people are going to do with their SwiftUI apps, only sharing some components between different platforms. Even sharing 60-80% of the code can go a long way, and a lot of time that would be non-UI code. But being able to share some UI structure helps a lot too.
In the context of this thread (and many other on the forums here) cross-platform tends to mean OS library backend/vendor (Generally meaning Apple, Linux, and Microsoft).
Apple-platforms may vary drastically but they are all backed by the Darwin C library and so they really have a more lot in common when it comes to programming for them. It is frequently sufficient to compile frameworks using something like the below code snippet and have it work on all (or at least most) Apple and Linux platforms:
#if os(Linux)
import Glibc
#else
import Darwin
#endif
This definitely indicates that the true difference lies not necessarily in the OS, but in the backend OS C libraries (sometimes it does, but not always). Looking at several cross-platform swift libraries makes it apparent that most compiler flags are used to distinguish between apple and linux platforms and far less frequently between the individual apple platforms.
Each Apple platform may vary drastically but they all use flavors of Darwin as the backing C library while Linux uses Glibc and Windows uses it's own thing (which I can't remember off the top of my head right now). These backend C libraries which are used by swift are what really determine the platform behaviors/capabilities.
No where have people said that it means they should share 100% of the code, but rather 100% of the same functionality and behavior. No one thinks that it would be possible for them to share 100% of the same code. Look at any cross-platform swift framework and see all the #ifs that it takes to get things working on both Apple and Linux. It has even been stated by multiple proponents of making SwiftUI open source and cross platform that it would/should use the platform's UI framework, but would only enable the same functionality for building the UI.
Conclusion:
Yes SwiftUI is "cross-platform" in the sense that it supports all of Apple's various platforms, but it is not in the sense that it doesn't support any platform C library except for Apple's Darwin. This is what people are arguing for and have stated multiple times for various reasons.
You can easily write a framework in pure swift that supports all Darwin-based devices and technically call it "cross-platform". Getting a framework that works on more than just Darwin devices usually takes a bit more work and customization due to the variations in C backends, availability/stability of Foundation, etc.
What I understand that people are really asking for is a common framework for building UIs and not a single UI framework as that would be impossible due to all the variations in how OS's generate graphics.
It seems like there could be a lot that could be shared that is completely unrelated to any of the Darwin platforms: the DSL, the bindings to Combine, the property wrappers that are defined in SwiftUI. Maybe even the diffing engine and the part of the loop that builds view structures when state and bindings change.
With the foundation shared, the community could start implementing various back ends like GTK, Android UI and Windows UIs.
If a big part of the final âvocabularyâ (like HStack, VStack, List, Text, etc could be shared across these implementations then it would already be an amazing way to build cross platform UIs.
I really, really hope that both Combine and SwiftUI will be open sourced in some form eventually.
One guess as to why it hasnât already been open sourced could in fact be iOS and MacOS themselves: if Apple open sourced the platform independent parts of SwiftUI then there would be some confusion about why you might (theoretically) be able to use it on Android while pre-iOS 13 is not an option.
I guess the community could reimplement pre-iOS 13 support, but it would likely be subpar to Appleâs own implementation and give a bad experience to end users.
Could that not explain why they might be holding back?
Edited my post above to note that technically not all appeals have been exhausted in Oracle vs Google. Google are trying to get SCOTUS to rule on it (for the 2nd time, after they declined to hear it the first time). Personally, I don't think they will succeed, but it's at least possible that they will reverse the decision of the appeals court and find that APIs are not copyrightable.
This is an area of active debate in the software industry. So stay tuned.
This. Abstractions over multiple platforms can only go so far and SwiftUI is no different. Most full-fledged applications will end up dealing with each platform individually at some level.
Personally I think the cross platform aspect for a lot of these libraries is overblown. Xamarin became popular because it allowed .net devs to build mobile apps. React Native is the same for web developers. That's exactly what Catalyst is. Allowing iOS developers to make mac Apps. So the question is whether there's enough of a potential market (and business alignment) for someone (Apple or otherwise), to develop the pieces necessary for something like SwiftUI to work on other platforms.
Like Apple said it in one of the SwiftUI talks: SwiftUI isn't about "Write once, run everwhere". That's technically not possible if you wan't to keep having great user experience for each platform. It's more about "Learn once, apply everywhere" and I'm totally happy with that.
I don't need to write code once for macOS and be able to run it 100% as it is on Windows or Linux (even though those are desktop systems as well) or write code for iOS and run that as-is on Android. I have no problem with adding some extra code for platform-specific features and requirements, but as many parts of the UI are actually doing the same thing just with a different look, it would be already great to reuse that code. But the strongest thing for me is Swift and Developer Tools. I'm learning one language alongside it's main developer tools with all their details and can use that knowledge to write code on different platforms. I'm talking about literally years of effort that I can reuse, which is amazing.
This is a game-changer in that it enables single-developers and small teams to write code for everybody and not only those 20% of Apple-developed operating systems. It would enable innovation to an extent currently not possible for someone like me, who wants to keep using a modern language and great developer tools but also reach as many people as possible. As of now, I'm getting stuck with any community-based idea I have due to lack of Android/Web support.
I think many people here are forgetting that SwiftUI is very much dependent on many OS-specific technologies, not present elsewhere. I'm talking about CoreGraphics, CoreAnimation, Metal, etc. That makes SwiftUI very different from projects like SwiftNIO, which depend only on runtime / Foundation functionality. Since Apple already spent years bringing those technologies to each one of their platforms, they were able to develop new UI on top of that in reasonable amount of time. And the best thing is, SwiftUI can fallback to existing UI API in case if certain control is not yet implemented (if I understand correctly this is what happens in current implementation).
SwiftUI cross-platform port if it were to ever happen would be a very complex and expensive project, where each OS version is built around a local stack of graphics technologies, with different graphics capabilities, performance characteristics, supported media formats and so on. The amount of things to port dwarfs Swift language part of SwiftUI.
SwiftUI provides a really nice UI abstraction over many very different types of devices. So while it looks very similar on the surface, it must have taken tremendous amount of plumbing (UIKit, AppKit, CoreGraphics etc) and fine tuning from Apple to get as native experience as it is from watches to TVs. I donât expect to see that plumbing ever as open source. Besides, it should be a moving target, gradually getting rid of the old stuff.
What could possibly be open in some future scenario, is a way to plugin other platforms (Gtk, KDE, Windows Forms, Android UI) into SwiftUI. Most likely as 3rd party plugins. However, it should not be underestimated how big amount of work it would be to get these plugins to same level of quality as Appleâs implementation.
It has been stated by multiple people upthread that open sourcing SwiftUI would/should require platforms to integrate their code to use it. No one is expecting Apple to also open source UIKit, AppKit, CoreGraphics, etc nor for them to build/maintain the underlying code to use SwiftUI on Windows, Android, Gtk, etc... There is no way Apple would have time to do all of that themselves!
I think people are conflating open sourcing SwiftUI with open sourcing the entire stack required for SwiftUI. I certainly hope no one here is asking for that because it would definitely be a non-starter.
I personally, would only like to see the SwiftUI framework generalized and open sourced so it can be used by any platform that supports swift. All the frameworks which use SwiftUI to actually generate the UI can remain private.
This would be a valid option as opposed to open sourcing the framework, but it would require all the SwiftUI backend APIs to be very well documented and Apple would have to vend SwiftUI binaries for each potential platform. I still think it would be easier/better to just make SwiftUI an open source framework, but Apple can decide.
Surely this choice is up to Apple, but open sourcing the "front end" is indeed something that IMO would have such a great impact on Swift, potentially making it much more attractive to both newcomers and experienced devs. This even seems like something that would have such a good impact for Apple platforms.
Also, today, there are so many questions related to UIKit on StackOverflow that I sometimes think this is one of the reasons why so many people keep seeing Swift as "the Apple platforms language" since the majority of questions they find when searching about it are linked to Apple specific stuff.
If SwiftUI became a multi-platform, open source framework, all new questions about it on forums would help fight this image, making people naturally realize that Swift can do so much more.
just my opinion, but i donât think apple would ever let something so business critical as ui to be dictated by the whims or open source... swift the language is different because they want a broad talent pool and to get into edu just like java, but higher level non-infrastructure type stuff... i wouldnât hold my breath (unless apple starts loosing relevancy like microsoft i suppose)
besides, if swift uiâs basic functionalities (dsl) are available in swift itself the isnât there nothing preventing someone from making a functional clone for gtk or windows etc?
But swift isn't dictated by the whims of open source. Sure the code is open source, but the language evolution is dictated by a Core Team at Apple. People are welcome to fork swift and modify it to their heart's content but the main fork is under Apple's complete control. They have the power to reject any PRs or pitches/proposals that would be directly harmful to themselves.
SwiftUI is infrastructure. It's just infrastructure for designing UIs that hooks into infrastructure for generating the UIs on-screen. The infrastructure that SwiftUI hooks into for generating the UIs can remain closed source as that is completely OS dependent. Having a cross platform tool like SwiftUI for designing UIs would be tremendously useful (which is probably a big reason why they've made it closed source).
If it really is Swift UI then it should be open sourced. If it's just going to be Apple UI then it should be rebranded.
When we really want that Apple considers moving SwiftUI to open source, we need some really convincing use cases for that, some that have such a huge benefit for Apple that those outweigh all those reasons not to open source it. What could that be?
One could argue as follows: If Apple open sources SwiftUI, there are good chances that SwiftUI will become a de facto standard for cross platform UI programming. The more projects adopt it, the more the mind share will grow, the more applications which use SwiftUI and therefore Swift will be created. All those apps are instantly available to all Apple platforms too and so will increase the number of available apps for the Apple platforms greatly. Also, Apple keeps full control over SwiftUI, so being able to steer the directions in which all this moves.
I mean, we should come up with benefits for Apple, when they decide to open source SwiftUI.
We'll have to butter them up, it's the only way it could work.
My guess is that they're probably doing it to their platforms only first since they know their own UI kits and they're the only dominant ones on their platforms. I can understand if it takes them a while to figure out how to make SwiftUI work with Linux or even Windows given the plethora of UI kits to choose from on those platforms. Win32 or UWP? What about WPF? And for Linux, GTK or Qt? Or make something up? That's a lot to figure out in and of itself; other parts would have to be making a stable bindings for those UI kits.
I'm curious to see how this develops over time. To get clarifications on what would exactly be involved and if Apple had plans for it at all, I tried to get in touch with Craig. I have yet to hear back, but I'm imagining it's not for discussing at this time, it's taking a while to answer the question, or he just has a lot of emails to process.
Tbh, the decision has probably already been made. Either theyâve been planning to open-source from the start, and just need it to get more stable first (like Swift) or they arenât planning on open-sourcing and they havenât been trying to keep IP separate - in which case I wouldnât expect them to suddenly make the change and but the effort into ripping things apart.
On another note, I am pretty confident that even if they did open source the âtop layerâ, I would be shocked if they put an ounce of effort into making adapters for non-Apple platforms. I believe that would be up to the community
This might seem as a nitpick, but Chris Lattner is a member of the Core Team and works at Google. I wish more people who contributed towards supporting Swift on other platforms were members of the Core Team. Specifically, as it was stated on the community page of the project:
Over time, exceptional community members from a much more diverse background will be appointed based on their record of community involvement and contributions.
In general, some kind of retrospective on how the project evolved over time should preclude any judgement on what will happen to SwiftUI. I'm inclined to think if the Core Team had at least a few more members outside of Apple this all would unfold in at least a slightly different way. And this is what's more realistic near-term: we need to understand how community can have a stronger voice within the Core Team. When that happens, we can hope that the Core Team has more leverage over the critical infrastructure of the language.
