What I've noticed is mainly Android and Apple products are the only products that have a modern relatively grounded way of making a UI.
Apple Products: SwiftUI
Android: Jetpack Compose
Windows: ??
Linux: ??
A SwiftUI port for Windows and other platforms like Linux would be amazing but Swift support itself hasn't even been perfected for Windows so getting SwiftUI there if Apple even allowed porting of their closed source software would still have a long ways to go. I feel like our best bet for stuff like this is the use of Kotlin with TornadoFX, I'd say use Kotlin Native but that's currently pretty barren for desktop UIs and TornadoFX depends on JavaFX so that can't be used with Kotlin Native either. So now we got this:
Apple Products: SwiftUI
Android: Jetpack Compose
Windows: TornadoFX
Linux: TornadoFX
What I'm trying to say when I say all this is that I feel like this issue is far more complicated than just porting SwiftUI, maybe it isn't as complicated for porting to Linux because Swift supports Linux and Linux is UNIX like the software that runs on Apple products but Windows support at least is highly unlikely.
@RUSshy Rust isn't hard to learn at all if you know where to look,
It was my first language and I learned it with ease using that course, just because you have trouble learning it doesn't mean it's going anywhere, the world doesn't revolve around you. Also Scala has that bloated syntax and still has null safety issues that's why Kotlin has an edge over Scala and Scala still has a bigger community than Kotlin. Let's put this into perspective for you. Rust is just like Swift but without the data races (and it's more low level while having the same high level capabilities) that's why its syntax is the way it is. It has to be that way to ensure thread safety. Please actually do you research before trashing on a language.
Verona is a research language that may be discontinued or what they learned factored in to another language. Most software out Microsoft Research is exploratory and will likely just be used to guide a new implementation. If it does become a real language it will be many years from now. Microsoft seems to be behind Rust to improve their operating system code and drivers for the near future.
It doesnāt depend on any of these thingsā other then Combine/OpenCombine. Those are just implementation details. I think it is very likely the community will port this to other platforms after the required features make it through Swift evolution. That doesnāt mean write once run anywhere, but it should take less effort to adapt a UI to another platform.
Depends on what you mean by "port." No SwiftUI/Combine source code has been made public. The API definition is "public" as far as it goes as developer documentation, but, it does not necessarily capture all behaviors in the description. You can start from scratch to implement a SwiftUI-like framework (using the required features from Swift that are going through evolution), but, it will most likely not match what Apple is providing as its private framework, unless Apple open-sources either one.
OpenCombine is someone/some group's best guess as to what Apple has implemented in Combine. All of this will be best guess, or take a lot of experimentation on a Mac to tease out all the behaviors, including edge cases, as well as figuring out how to cope with Apple-specific behaviors defined in the API and observed behavior arising from its implementation details.
Not even looking at what licensing/copyright woes one might stumble upon.
There is no magic undocumented behavior in Combine. OpenCombine will be fully compatible when new features make it through Swift evolution. I think there is a chance Combine could become part of the standard library. It may be closed simply because it doesnāt have stable ABI yet. A SwiftUI clone for other platforms will (obviously) be not quite compatible by design. Just like UIKit, AppKit, and watchOS versions are not quite compatible. This is a good thing as it helps to prevent one-size-fits-all design and encourage adoption of platform features. It will still allow extensive sharing of code. SwiftUI is not too complicated to clone well enough to make it as compatible as Appleās various platforms are with each other. SwiftUI is not designed to be write once run anywhere, but it will certainly be ported by someone in the community to allow some level of shared code as Swift gets better support on other platforms. XAML and GTK+ both feel doable. Custom UI could be dropped or implemented differently without losing most of the benefit. A simple generic GUI built on SDL also feels like a reasonable community project.
Apple would not have anything to do with it. The motivation would come from the community. The fact that SwiftUI is closed source isnāt a huge hurdle to overcome since most of the work would be in bridging to the platform specific UI. When Swift is a little further along on other platforms I think there will be a desire for something like Xamarin Forms, but used to port code to Android and Windows. Sure Swift UI is a big complex project, but it is less complex when using it with existing platform UI. In fact much of SwiftUI is piggybacking off UIKit or AppKit to make it less complex. The core features of SwiftUI are not that complex. There are already a few successful companies using Swift for cross iOS/Android apps. I would be highly surprised if one of these companies doesnāt port SwiftUI to Android or Windows.
I donāt think Apple would have a problem with this. Other platforms wouldnāt get the world-class UI features of macOS and iOS since SwiftUI just adds a declarative layer. This would keep more developers on Swift, helping make iOS and macOS apps feel first class.
It would help developers make more money and target more users. Most other languages used for app development have a hard time with interop with system languages and use garbage collection which IMHO is not a good design for 64-bit apps since fragmentation is no longer an issue. A C++ layer is usually used to address some of the interop issues with other languages, but that adds a lot of risk and complexity compared to doing interop with Swift. For many classes of applications this is a big win for developers and a big motivation to help Swift work everywhere. If the interop story were not so much better in Swift, Iām sure the TensorFlow team would have chosen a language that is more mainstream outside the Apple community.
SwiftUI
({ @MainActor ļ£æ in M5.Extreme }(Swift))
114
Since Apple has switched to ļ£æSilicon product, and SwiftUI & Combine are private frameworks, will be built upon arm ļ£æSilicon architecture as time goes. I don't think there's any opportunity to open source or port SwiftUI to non-ļ£æ platforms in future.
There is no architecture dependency, it is definitely possible to port. There are some WIP ports of SwiftUI (like OpenSwiftUI) on GitHub already. You would never run SwiftUI directly since that is part of the operating system.
I would love to see something fitting in the same space as Xamarin Forms. It doesn't need to be 100% compatible, but close enough to get you mostly there for line-of-business apps.
That is an over pessimistic point of view. Apple didn't had to open source Swift and could have kept it private as well. Swift wasnāt open sourced right away, as it wasnāt ready to be open sourced right away. Just because there will be a new family of CPUs & GPUs does not tell us anything about the future of SwiftUI or Combine. That said, only time will tell.
One more thing (pun intended): not so long ago we got SwiftCrypto which will fallback to CryptoKit on darwin platforms. Both SwiftUI and Combine could behave similarly if they were open sourced.
Im about to launch a platform for application development, that is multi-process and multi-os based on a heavily modified Chrome engine.
The primary application SDK is for Swift, that will have direct access to the web layer and even the compositor layers that are gpu accelerated (the ones that the web layer actually uses).
I bet it will be a perfect match for a SwiftUI kind of layer as it can directly draw to the accelerated compositor layers through the Canvas API for instance.
You wont have to worry in binding to many graphics apis because the platform will have this covered for you.
I was trying to keep this to myself until the launch phase (a couple of months from now), but giving i think this will be a perfect target to this, i couldn't hold it.
This platform will be a mix of a browser and a application platform like the ones you see in phones, with the difference that for each app there's an application process running as a service and handler of a RPC service(you can think of it as a application server process) distributed with the application and a application UI process for each UI launched (much like the renderer process in Chrome)
I think it will fit perfectly for this kind of project, and i'm real glad that i've chosen Swift instead of Rust back then as my primary/first application language. (I have a good C layer here that would actually turn it feasible to port it to other languages)
I hope that with things like this, we can fill the gaps that Apple would not be really interested in doing.
Just to chime in, a couple of days ago a new version of Tokamak was released, which implements a subset of the SwiftUI API for WebAssembly/DOM. We don't support forms yet, but had good progress with new additions to SwiftUI this year such as the new App lifecycle. NavigationView and NavigationLink were merged just yesterday. A bunch of Shape APIs are supported too via SVG, you can check the progress of the API coverage in a separate document we maintain. It has a cross-platform architecture, we have a static HTML renderer in progress for server-side rendering, and I plan to start work on the Android renderer as soon as the DOM renderer is usable enough. As soon as the Windows port of Swift is stable and supports SwiftPM, a renderer for Windows will become a priority as well.
Perhaps it is technically possible, but why would Apple every want to do this? Presumably the entire point of SwiftUI is to make it easier to create good apps for Apple platforms, making Apple hardware more attractive.
The point is that if companies use frameworks that allow them to build apps for Apple and non-Apple platforms at the same time and get acceptable results, why would anyone use native frameworks? Open sourcing SwiftUI would show the community that Apple is committed to native development in a way that competes with React Native or Flutter, but using Swift. And it would create a cross platform ecosystem where Apple's OS' are first class citizens, which you can't say about the other frameworks, increasing the amount of quality software available. Plus, like any open source project, it would allow the community to continue building and support the framework even after Apple's interest declines, or fill holes Apple isn't interested in.
I totally second with that! Iām no web developer but how does UI development differ from web compared to application UI development? Honestly, there is no real difference except for the tools you have to use to build it. Iād love to see a dynamic and descriptive way to code web pages in Swift with such a powerful tool like SwiftUI. I love the approach of "learn once, and apply everywhere".
Why did Apple open-source swift? Why don't they open-source UIKit or AppKit? Why did they open-source Darwin? Why don't they certify iPhone clones or MacBook clones the way they certify AirPrint printers? Why does the open-source community hate Apple so much?
Apple understands how to make money their own way. It's unlikely that anyone outside of Apple will understand their decisions completely.
