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

I certainly would not say that! Apple has done a lot for the open-source community - most notable probably being their investment in LLVM, but there's a lot more. Their github page has 93 repositories, including FoundationDB, the Darwin XNU kernel, CUPS, etc. Loads of stuff.

Traditionally, platform-specific UI frameworks have not been open-sourced, and it is quite a shift for platform developers to start to do that. Even Apple developing Swift in the open on Github is quite a surprising step (this is Apple remember? Famous for their secrecy).

As I said way earlier in this very long thread, the question of whether companies can assert ownership of proprietary APIs and use that as a competitive advantage is a question currently waiting for the US Supreme Court (Oracle vs Google):

Oracle initiated the suit arguing that the APIs were copyrightable, seeking US$8.8 billion in damages. While two District Court-level jury trials have found in favor of Google, the Federal Circuit court has reversed both decisions, asserting APIs are copyrightable and Google's application of them failed a fair use defense. Google successfully petitioned to the Supreme Court to hear the case in the 2019 term, focusing on the copyrightability of APIs and subsequent fair use. [...]

The case is of significant interest within the tech and software industries, as numerous software programs and libraries, particularly in open source, are developed by recreating the functionality of APIs from commercial or competing products to aid developers in interoperability between different systems or platforms.

Google's fair-use defence was interoperability. As the law stands, duplicating an API to allow your code to work on other platforms is a breach of copyright.

That said: to my knowledge, Apple has only very rarely enforced their ownership over an API (I only know of one time, related to Samsung's copying of a gesture API. IIRC it was actually a patent rather than copyright, and I don't think they succeeded). There are plenty of reimplementations of UIKit floating around, and I've never heard of Apple prosecuting any of them - in fact, one of them is maintained by Microsoft! It includes loads of surrounding system frameworks. You could not have a more blatant violation of Apple's API copyrights, but I don't remember any legal challenges in the press. If this was Oracle, no way that flies. I've never heard of any of these open-source SwiftUI clones being prosecuted, either.

Maybe that's evidence that platform holders don't need to protect their proprietary APIs as tightly as they have in the past? Depending on what the supreme court rules, it may become impossible for them to prevent anybody creating a swift-crypto style wrapper library anyway.

Change is happening, but it takes time. Whenever the Supreme Court makes a ruling (obviously their timetable has slipped a bit), I'd expect Apple to review the situation.

I expected my questions to be rhetorical, because we don't know the answers (And no, "Because they don't want to" isn't an answer) and we probably can't influence the decision makers anyway.

Aside from that, applying the open-source operator isn't a magic wand that makes everything better. I think most of the projects on GitHub are abandoned. At the risk of insulting some people around here: even though it's open-source lldb doesn't work very well. The fact that basic types like Date and URL don't work right with lldb seems to be the direct result of the project being open-source; none of the debugger engineers prioritize Foundation. There's also a ton of compiler bugs that have languished for years while tons of new features are added (Joel would not approve). We get Pitches on here every day that are written by people that have never posted a single thought before on this forum.

At any rate: It is what it is.

The bigger problem is that while formally Apple is the current owner of those copyrights and patents (especially the Swift patent, existence of which is most concerning), we never know where the ownership ends up in the future. Sun was also seen as a benign holder of the Java IP, until it all ended up in Oracle's hands.

This may sound hypothetical, but there's no 100% guarantee this will never happen to Swift and related APIs until these patents and copyrights are granted to the community or some non-profit organization, which would be similar to what Microsoft did with .NET. With the push towards the services revenue, Swift and its ecosystem are much less connected to the business priorities (at least apparently) than it was 5 years ago when hardware sales were much more important.

With the smartphone market fully saturated and hardware sales falling in the economic crisis, who knows what happens next. If Apple's top management and shareholders aren't concerned with Swift's future (it's hard to imagine they are, most sharedholders don't probably know of its existence) and Swift doesn't bring any profit to the table, it could be seen by those people as a liability at some point. That could either justify selling the IP, or suing community members or other companies that would allegedly infringe on patents/copyrights. This may sound crazy right now, but this is what Microsoft have been doing for a while before they finally realized how important the open-source community is. And this is what Oracle is doing right now, but I don't think anyone could have predicted this happening to Java before Sun's downfall.

5 Likes

Hope Apple do NOT be evil!
Open is future, closed was past.

1 Like

Clauses 2 and 3 of the Apache license are grants of copyright and patent licenses, so I'm personally not worried about the Swift compiler, package manager, or any of the other projects released under that license. The issue is proprietary APIs, for which we have no copyright license. Microsoft's moves are further evidence that platform holders have begun rethinking their strategy for the 21st century: they've open-sourced a looot of their platform frameworks.

My expectation is that the Supreme Court will rule in Google's favour, and if they don't, copyright law will quickly change to allow interoperability as a fair-use exemption. I remember when I was learning electronics and taking things apart that had weird, proprietary screws you could never open; there was a kind of trick that involved melting the end of biro and pressing it against the screw-head so the plastic moulded in to a makeshift screwdriver. It was a bit rough, but it worked to quickly duplicate a proprietary (physical) interface. IMO, it's absurd to think that the same idea, applied to a programmatic interface, would be illegal.

But that's enough ranting.

As far as I understand, these are only applicable if a patent holder and a copyright holder are the same entity, but not applicable to any clean-room implementation of Swift created by the community. At least no one to my knowledge was able to claim that such reimplementation does not infringe on the patent in the relevant thread: "Apple is indeed patenting Swift features - #11 by Max_Desiatov". Ironically enough, if the same patent existed for C or C++ (and Apple didn't own it or license it) this would prevent Apple itself from participating in the LLVM/Clang project, as it would infringe on such patent.

I think the problem with the lack of contribution with lldb and the compiler is due to the knowledge needed in order to contribute (C++, compilers, etc), and since in the Swift community there are far more apps developers rather than compilers developers, is more difficult to see more contributions from the community itself. I think with a UI framework, like SwiftUI it could be different, since it will be focused in UI development, where there are more people from the community that have more experience and knowledge and will be able to contribute.

4 Likes

Was GitHub - SwiftWebUI/SwiftWebUI: A demo implementation of SwiftUI for the Web mentioned before?

It looks pretty awesome:)

In addition to SwiftUI, I’d want a non-Apple implementation of Combine first. It may works like the corelibs-foundation project that tries to keep with the behavior of Apple platforms. I believe that will work well, and Combine itself is not only fundamental but also useful. OpenCombine has done some work, but an official one is exactly what we want (and maybe the Swift
community can continue the work on the basis of their codes if they would like to contribute).

3 Likes

Yes, Combine seems like a far easier library to open source and would be immensely useful to the community, especially server side Swift, as it's likely the only stream library likely to be adopted by Apple's libraries.

9 Likes

I think swift really needs an open-source GUI framework. But swift is really like a language for apple's products only.
what else swift can do? server side?
swift is really lack of attraction to adopt unless for apple's products.
as a swift programmer, I really feel like out of apple's environment, I can't really use swift.
but an open-source GUI framework, can really help to gain popularity.

1 Like

When you say you are a Swift programmer, what are you are actually building? I'm looking to use Swift as part of build environment to build complex simulations that may or may not have a GUI interface. These are not iOS/iPadOS applications. Some run from the command line, some can be started from a GUI. There is on-line and off-line plotting. All are written in Swift (as well as C. C++, Fortran).

Do you mean something like OpenSwiftUI, which is a reverse-engineered open source version of SwiftUI for Darwin, Linux, soon to be Windows, open-source versions of UIKit/AppKit which exist (probably need Swift interfaces)? Or something else?

Swift is not a development platform, its a language, No other language that I know of has a GUI framework as part of the language. There are bindings for languages to GUI frameworks.

Even SwiftUI is not part of Swift, it's an Apple-private GUI development framework that has been engineered to be used with Swift. It's really no different that AppKit having originally been developed to require using Objective-C. AppKit is not part of Objective-C, but, you needed to use Objective-C (until Swift came along) to write programs that took advantage of the AppKit framework. However there are other GUI frameworks that work with Objective-C as well (any C/C++ GUI binding, actually).

What the Swift community needs is for GUI frameworks to provide Swift bindings, which many are.

2 Likes

With the recent developments in the WASM area, Swift can run to a limited extent on the front-end, and things are looking better everyday. All thanks to @Max_Desiatov

2 Likes

You are right.
But why would this thread still growing? People still discuss here?
Because people want it.
As you said that, If everyone thinks like you, This discussion won’t be still growing.
Without promoting the language, the language can’t go anyway.

This thread continues to grow because there are a large number of developer, Darwin and non-Darwin developers, that would like to get their hands on the SwiftUI and Combine frameworks and they are hopeful that pressure from the developers will cause Apple to change the status of the frameworks.

If you also see a large number, so why you said that?

β€œ What the Swift community needs is for GUI frameworks to provide Swift bindings, which many are.”

I think anyone can do it otherwise..

Does any git repo that transplant swiftUI by skia engine works on Android exist?

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