No comments from apple guys in this thread;) May be, in some years on WWDC SwiftUI for Android / Windows will be a great surprise.
Well, if nothing else there's always Tokomak.
3 Likes
I think we will see SwiftUI for web first (Tokomak) then see it expanded to other platforms. In fact Tokomak is experimenting with GTK support. I think it will feel like a good option for web apps soon. For Android and Windows where you need to fit in to existing UI design standards this may be years before it feels first class. For web, you can do whatever you want. I think it will feel mature there first. I doubt Apple will do anything directly. This will all be third-party effort. If Apple does do something, it will be for web. I could see Apple wanting to move iCloud web apps to SwiftUI. They already use WASM to implement much of them in C++ and Objective-C.
1 Like
As much as I’d prefer that everything be open-source and available everywhere, I wouldn’t hold my breath on this one. I don’t have any inside info or anything, but I get the sense that Apple views SwiftUI as one of the benefits of writing UI software for their platforms. I’d love to be wrong, though… it’d be a “great surprise”, indeed. 
Still waiting SwiftUI from Apple for other non-Apple platforms. I'm not using Swift/SwiftUI today at all, because today programs it's not only mac os or ios. Today each app that is coming to store, this is crossplatform app. So I'm using c++ and Juce.
therebefore for me Swift, SwiftUI is useless languages (( Apple come on!!!! A few more years and your appstore will be only Flutter and React apps! Please add support! pls!pls!
2 Likes
Apple will never do this, but there are third party efforts including the excellent Tokamak. It will take time for Swift to work well on other platforms. When these options are more mature, you will still need to put effort in to support each platform. SwiftUI was designed to allow more code sharing, but it still requires targeting each platform separately.
Flutter and React Native have already taken over a certain class of apps, but they only work for apps that don't need really tight platform integration. If not in that space, it is still required as always to build native frontends for each platform to get good integration. Writing a productivity app is worth putting the extra effort in to build a native front end.
to really take advantage of swiftui on apple platforms its still good to separate your ui logic from the actual ui code (view model or whatever) which swiftui makes very easy and natural, so i would say (if you could avoid combine in your ui/view model) factoring all you non-ui code out and doing swiftui on apple platforms would still help tremendously on non-apple platforms...
but maybe im not thinking deep enough...
I’d really like to see Combine become part of the language runtime. I’m not holding out much hope, but it would be great if the new concurrency runtime support that will inevitably make it in could also support Combine as a Swift standard library.
2 Likes
+1. Swift support running on all platforms,, swiftUI for all GUI.
3 Likes
it's a cross-platform swift GUI lib,maybe this one can be used .
I'm a new one to learn swift ,I used python before.
(๑><๑）
3 Likes
I have a disappointing perception at this proposal (comparing to other guys in this thread). In my opinion it is not in Apple's manner to distribute some products (even if they are willed by lots of people) for other platfroms just because of additional responsibility for this product's perfomance on the Apple's independent platforms. And we all know and love Apple because of their attention to details, so in my opinion distibuting SwiftUI to other platfroms looks putting in danger Apple's reputation and not giving any profit they could'd take these risks for. One more point is that distibuting UI framework to other platofroms will make Macbooks sellings go down (because you won't need Xcode for development), I guess Apple doesn't want to shoot its knee :)
It took me unreasonable amount of time and effort to reverse-engineer the data flow mechanism of SwiftUI (And I still haven't fully cracked @State yet). SwiftUI, as I've come to realize after cracking it apart, is a treasure trove of very interest and uniquely useful Swift design patterns! I don't care about the OS-level rendering and HID handling, I only care about the front end, which takes an async sequence of view blueprints and produces an async sequence of drawing commands (the HIG handling can't be too hard at that point). Any reference-semantic state machine can be re-architected to be blueprint-driven with amazing ergonomic and robustness gains! I want open-source SwiftUI not to write good UI code for Windows or anything, I want it for its architectural solutions!
8 Likes
I think Apple hasn't open-sourced it yet for two main reasons:
- It hasn't fully matured yet, so any successful project using SwiftUI will inevitably need to use
UIViewRepresentable,NSViewRepresentable, and their other variants at some point. SwiftUI is becoming more and more self-sufficient every year, but until it becomes 100% feature-complete, its API would be quite unstable as an official open-source library. - It's using hidden run-time reflection capabilities that are only accessible through the ABI (here's my attempt at exposing that functionality), so its ABI would also be too unstable.
But that's just my guess. I hope Apple won't take too long to become comfortable with SwiftUI enough to deem it open-source-worthy.
Both of those are reasons for open sourcing, not against. Open development should help accelerate "completion" (is a UI framework ever complete?), it's not something you usually want before open sourcing, otherwise you miss out on the community's dev effort. And having unstable internals is perfectly fine for an open source project.
3 Likes
That makes sense. Honestly, I'm trying not to get my hopes up, because I want it to be open-sourced so badly.
No, there really is no hope unless there's a major change in the relevant leadership at Apple. Electron and other cross platform frameworks will continue to eat away at native marketshare until a crisis point is reached and Apple either embraces the approach or radically shifts their approach to native SDKs. I don't anticipate any change until then.
4 Likes
Electron, react and other web-based UI frameworks are, in my opinion, the bottom feeders of the app world. It's painfully obvious just from looking at an app written using them that this is an app that is written using a web framework and I'd lose all self-respect if I was the author.
The fact that this sort of inexcusable mockery of our industry is the number one way of writing apps for multiple platforms is nothing short of infuriating.
EDIT:
I use VSCode every day and absolutely hate it. I hate that it has no rivals in terms of functionality, yet it's one of those bottom feeder electron apps.
8 Likes
Apple is not a software company; it is and it has always been a hardware company. The things Apple does and sticks with -- as opposed to doing and then ghosting -- are all in service of selling more Apple hardware. Making SwiftUI cross-platform does not actively serve this goal, so I have a very hard time thinking it will ever happen.
4 Likes
True, but the fact that the business interests of apps like 1Password and Spark, which were previously examples of great native design, has overridden design concerns in the name of money should be deeply concerning to Apple. Especially when products like Spark drop Mac App Store support at the same time.
7 Likes
Except Apple has always known that good software drives hardware sales. They've known that since the Apple II and the first version of VisiCalc. The iPhone is a behemoth now, and Apple will continue to fight to keep it that way, but if companies move cross platform and users can get the same experience there as they can here, Apple's left with only their artificial stickiness to keep users long term (much of which is coming under increasing regulatory pressure). Opening SwiftUI serves this goal by ensuring it's Apple driving the framework behind cross platform apps and ensuring it remains high quality on their platforms, rather than being beholden to the scraps left over from Electron's Windows support. They've already largely killed gaming on their platforms, I really hope they don't make the same mistake here.
1 Like