SwiftUI for non-Apple platforms (like Android, Web, Windows)

That really doesn't have anything to do with it, given that macOS, iOS, tvOS, and watchOS all have different UI/UX and SwiftUI is designed for them all. Apple even did a session at WWDC about supporting all platforms from the same codebase. So it seems entirely likely that SwiftUI could be made to work on Windows and the Linux UI frameworks, Apple just chooses not to do so. Personally, I recognize that abstracting the SwiftUI runtime away from the underlying platforms enough to make it available to other platforms would be more work than they'd otherwise need to do, but I think the benefits would outweigh the costs, as Swift and SwiftUI would suddenly become a viable cross platform app framework.

6 Likes

What Apple doesn't get is that they are losing the battle for developers. A lot of education institutions simply won't teach software development for Apple platforms because:

(1) students would have to purchase an expensive computer (my 15" MBP costs more than the tuition for three years at our university, even if you don't have a scholarship).
(2) it uses programming languages and frameworks that are specific to the platform and aren't used in other courses.

If students have to choose between developing for Android using a language/platform they already know (Java), or spending $$$ to develop using a language/platform they know nothing about (and may not even like), what do you think they'll do?

Investing more in Swift on other platforms, and open sourcing more frameworks so they'll work on those platforms will mean Swift can be adopted for general programming courses, and the barrier of entry into Apple platforms will be much lower. This is definitely in Apple's best interest as it will increase hardware sales.

7 Likes

Wouldn‘t Swift remain closed sourced by that logic. You could argue „oh you want to develop with a cool modern type safe language, build for apple platforms in Swift“. Yet it‘s here, and it‘s availability grows with the recent support for Windows. :slight_smile:

If people start building apps for Android in Swift(if that was possible), they may just port their code to Apple platforms and everyone benefits.

So my fingers are crossed for the good outcome of the initiated signal from this discussion.

4 Likes

Ideally I'd love to see low-level UI implementations on other platforms with SwiftUI as a front-end, a la Flutter.

However, I don't see it being open sourced anytime soon. Its currently being positioned as a meaningful competitive advantage for Apple, so it would be a pretty big departure from the status quo.

There could also be some significant technical hurdles. The amount of integration SwiftUI has with Apple's localization and accessibility features, as well as possible future directions like AR (which will definitely remain proprietary), may make it difficult to fully abstract it in an accessible way for OSS development.

Although I can't see a future where Apple provides an Android implementation, I can definitely see them making a Web version at some point, (though maybe just internally...also possibly via WASM?), and maybe a linux version (although, who uses linux for it's GUI? :wink:). As for Windows...I doubt it, but with the way Microsoft has been changing it's not nearly as clear cut as it used to be.

Regardless, as most/all the required language features should be in Swift, there's nothing stopping someone from building their own version for other platforms. Even if there are potential copyright issues, I'm sure there are ways around that via code conversion or something similar.

2 Likes

What about a $330 iPad with Xcode for iPad in iOS 14/15? :wink:

What are you basing this on? It seems to be continually gaining popularity, And even if that's mainly cannibalizing Objective-C, that's still a win. Swift is still VERY new. 5 years since it's announcement is meaningfully more recent than any popular competitor I'm aware of.

As far as academia, my perception of most (U.S.) universities is their Computer Science programs aren't really interested in following trends. I think this has changed somewhat, but for a long time many programs used Academic languages for much of the intro/theoretical classes.

IMO the more compelling story for Swift+Education is at the primary/secondary level with something like Playgrounds on an iPad. I can't see a University using Swift as it's primary teaching language for another decade or so when the language features have stabilized, full Memory Management has been added, and it has meaningful usage among professors.

1 Like

Well, firstly, Apple didn't have anything to do with Windows support (neither did Microsoft AFAIK).

Secondly, I don't think Apple considers the language itself to be a part of their "special sauce". There are lots of reasons why it makes sense to open the language itself up, so that it can be more widely supported on server platforms, for example. I doubt even Apple uses macOS as a server.

Of course, it may still happen. Anything might happen. I'm just saying that this is pretty wishful thinking. Not only is there no evidence to support it, but there is arguably evidence against it. Lots of people have been wishing for years that they'd open-source UIKit. And did they?

I don't think Apple just forgot to mention they'd be open-sourcing SwiftUI. If there were any such plans, they would have said that.

"everyone benefits" except Apple and their customers. Suddenly they're just getting ports of Android Apps instead of the bespoke experiences they've been used to.

At the same time, "bespoke experiences" shouldn't mean "difficult to create" or "requires expert knowledge". The goal has always been to make it as easy as possible to create great Apps which behave in a way that is natural to the platform.

3 Likes

Let me clarify: That's mean that SwiftUI should understand that app is running on Android and it needs to use Material Design instead of Cupertino. Therefore as I understand SwiftUI should implement all these Material Design components at the core. Flutter works in that way.

if winning the battle for developers won the war, linux would rule the world. winning users is what matters, and the developers will follow the market. as long as you need an iphone to send a blue text, i don't see Apple's market dominance going away anytime soon.

4 Likes

Yes, developers will develop for iOS because they have the users, but that doesn't mean they'll use native Apple technologies. Where I live, cross-platform tools such as React Native, Flutter and the sorts are way more popular with students, and this year's students are next year's developers ...

If Apple wants developers to build native apps, so their users have a better experience, and a reason to buy an iPhone over an Android device, they need to open up their development platform so more students can be exposed to it.

3 Likes

Personally, I don’t care that much whether the SwiftUI will be open source or not. It would be useful for me when trying to understand or optimize an app. However imo, SwiftUI won’t be SwiftUI without all the Core libraries supporting it. I am far more interested in having all the tools needed to create SwiftUI-like wrappers around other (C) libraries like GTK+. Then people would be able to write some small wrappers that would just pick correct method for a platform.

I hope property wrappers and dsl would be sufficient, however, having Combine open source would be great. (I hope it would since it is listed under the Foundation framework in the documentation.)

3 Likes

I definitely want students to adopt Swift and there's no doubt Apple could do more in that realm. I also think the comparison should be with Objective-C, and not things like React. I'm unsure where I would find a statistic, but I think It's fair to assume there are more students (at all levels) using Swift now than there were using Objective-C prior to Swift's launch.

My question though is why they're popular. Three reasons I see are ease-of-use, compatibility, and relation to existing platforms. The only platforms Apple cares to integrate with is their own which Swift does quite well, and SwiftUI massively improves ease-of-use to be on par with (or better than) Flutter, and compatibility went from 1 or 2 platforms to 5.

Flutter is becoming trendy now just like ReactNative has been (and is now starting to fall off), just like Xamarin was for a while and Cordova before that. These platforms tend to spike in popularity and then settle into a particular niche. They're still great for plenty of use cases, but there are always drawback. E.g. they're usually developed by a single company with no real guarantee it will still be supported in 5 years time if/when their business model changes. Whereas I doubt Apple will sunset SwiftUI in the next decade.

I think that sums it up well. These tools are available everywhere and you don't need to buy a new computer to use them.

1 Like

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

3 Likes

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

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.

3 Likes

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.

1 Like

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?

10 Likes

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.

7 Likes

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.