Yes, but this is directly affecting hardware sales. If the most important apps running on macOS look and behave in the exact same way as they do on Windows (which is to say, their UX is the lowest common denominator), then all the benefits of macOS are completely lost and the laptop becomes essentially an unreasonably expensive Windows laptop with a picture of a bitten-off apple on it. Why waste money on a MacBook if you can get the exact same garbage software running for much cheaper using a Windows laptop?
I hate Windows 8+, but I'd at least consider a Windows laptop for media consumption if any of them had a trackpad as good as any MacBook made in the past 10 years.
Apple is losing on the software front, but they still have some hardware tricks the other manufacturers don't. The M1 series is also amazing.
In the interest of luring customers, I think the best course of action for Apple would be to just provide a web-targeting variant of SwiftUI with the front-end and web back-end open-sourced and the Apple back-end proprietary. That way companies that need to support non-Apple platforms would not inadvertently give Apple customers (both current and potential) a reason to switch away from Apple. This solution would allow Apple to grow its customer base (especially for mac, which desperately needs it) by saying something like "all your favorite apps are ugly garbage on other platforms, but on a mac, they are slick eye candies! It's well-worth your money".
No doubt, Apple hardware is leaps and bounds superior to the competition (the M-series SoCs doubly so). The problem is that it won't matter if the app they're forced to use never makes use of the (as an example) haptic feedback of that mazing trackpad and effectively reduce it to a run-of-the-mill trackpad. Or never make use of the neural engine that they paid so much for, because the app is a JavaScript garbage that can never make use of it.
I doubt Apple will ever open-source SwiftUI. Apple always keeps platform APIs proprietary.
I would love to see a cross-platform Swift counter to Electron and Flutter apps aimed at branded apps where SwiftUI isn't as important. Maybe something like Flutter that uses Swift instead of Dart.
As long as they'd yield platform-native appearance and behavior, that'd be perfect!
If a project like this were started, I think it would be similar to Flutter with optional skinning that looks close to a platform, but might not be pixel perfect. That might be fine for some apps. Branded apps usually just want to look the same on every platform which SwiftUI wasn't designed for. I think there is a place for a complementary UI toolkit to SwiftUI.
In that case, that would be essentially the same as electron and flutter: lowest common denominator garbage that will never be as good as a native app.
3 Likes
I think most of the problem is Electron, not the idea. Flutter performs very close to native on Apple platforms. Electron is just a pig. A productivity app should always use SwiftUI to fit in perfectly to the system, but I think other line of business apps would be fine on a different UI system as long as they are close enough to Apple look and feel, lightweight, and performant. Branded apps often just want to look the same everywhere where Flutter/Electron tend to work better. I think Flutter is on to something interesting giving a lot of upsides to the approach without a lot of the downsides. Flutter even has full support for scribble and accessibility. I just don't like the Dart language it is built around.
It could be such a UI would be designed to work really well with SwiftUI on Apple Platforms. Other non-Apple platforms really don't have a very cohesive UI paradigm anyway.
2 Likes
Yeah, it would be cool to see something similar to this state-threading stuff and type erasure in an open source package. I have found myself wanting to use similar state management in other contexts or DSLs.
Not a full solution, but if you're trying to build a SwiftUI-style environment, you might find my IntrospectionKit and AttributeKit useful. They're the products of my efforts to reverse-engineer SwiftUI's environment.
1 Like
I'd argue that instead of necessarily looking the same, branded apps want to preserve their brand identity and provide the same capabilities of their app across different platforms. Having an android-style UI on iOS is not their goal in general, they just end up accepting the fact that their iOS app will look ugly and out of place (looking at you, YouTube) just to save money. If instead of a cross-platform framework they could use a good multi-platform framework, they would. The key difference being that cross-platform is providing the lowest common denominator, while multi-platform is providing separate functionality per platform with some possible overlap. With sufficient API overlap, it would largely feel like a cross-platform framework, but with native per-platform customizablility and without settling for inferior UI for the sake of uniformity.
That downside is that those apps end up looking like a lazy and incompetent attempt at putting a website into an app (no matter if it's Dart or JavaScript), because "that's cool nowadays", instead of stopping to think about what the user of that specific platform wants and expects. The effort it would take to build an app with a good multi-platform UI framework would be the same as building an app with a cross-platform UI framework. My argument is that cross-platform UI frameworks do not deserve to exist and are nothing but an artifact of laziness and carelessness on the part of the developers of those frameworks.
That's so true. Windows is a complete mess with a dozen "official" UI frameworks, where all of them are incompatible with each other, different ones are for different versions of the OS and all but the last one are deprecated and not being actively supported any more. This is where a multi-platform UI framework would be a life saver, because the app developer wouldn't need to deal with that mess and would get an app that looks and behaves appropriate for not just the platform, but different versions of it, as necessary.
EDIT:
To be clear, SwiftUI is definitely not cross-platform, it's multi-platform.
1 Like
There have been some experiments with bringing a SwiftUI layer to GTK, but I think GTK is problematic to create something that might get used in place of Electron for various reasons. I'd rather see a modern cross-platform rendering stack (similar to Flutter, but primarily for non-Apple platforms) that is mostly implemented in Swift. For Apple platforms it should be either compatible with or layered on-top-off SwiftUI. It would be a huge project, but I've thought about putting together something exploratory.
It is a bit amusing to see claims of "Apple will never..." or "Apple always..." when discussing aspects of a programming language that Apple has open sourced. Have we so soon forgotten how unusual that is?
I found a post from ~7 years ago regarding how to compile Objective-C on Linux. One person opined that Apple was smart to keep objective-C proprietary. They said that Apple knows what they are doing, if they were to release Objective-C then Google would soon let you build build Andriod apps with Objective-C and an open source UIKit framework. Within a year of that post Apple open sourced Swift and not only has it not taken over Andriod, but the open source UI framework has failed to appear. Maybe I am misunderstanding him and he was referring to an Apple provided open source framework rather than a new one. If that is the case then keeping the SwiftUI proprietary would still align with his reasoning of keeping Google from profiting from it.
I think if we can better understand the motivation (make more money) behind the open sourcing of Swift, then we might better understand why they have not released SwiftUI. How did open sourcing Swift help Apple make more money? In my mind they profited by improving their corporate image with the tech world. Also, this whole forum and all of the collaboration and discussion of Apple and Swift would not exist otherwise. If they see that this effort has indeed benefited them and Swift is gaining traction then releasing the UI might follow.
1 Like
I don't think this was about money. I doubt you could have a successful computer programming language without it being open source. It needs a strong community to be successful. Recruiting developers in this space is difficult if they can't keep some level of ownership of their own work.
I think if Apple were to release an open source version of SwiftUI it would have to align with their services goals, but desire to have Swift reach diverse domains might also motivate them. I'd love it if the fact it is named SwiftUI is foreshadowing for an eventual semi-open UI goal... Maybe the non-platform specific parts of SwiftUI with ability to create platform specific backends. It does appear that it could abstract away from platform specific things like Core Graphics, AppKit, UIKit, etc. I was certainly hoping Apple would at least open source Combine.
3 Likes
From a marketing perspective I think that Apple must open source SwiftUI because of competition. Right now the native UI frameworks have competition from C# MAUI, Qt among others. If you are a company that makes a mobile app for several platforms, you will certainly choose cross platform frameworks in order to save money and time. Unless you make a top teer mobile app where you need to use the native framework for each platform, many will choose a cross platform framework and accept that there will be some "non native look and feel" in an app.
If many choose a framework that is not provided by Apple, the quality will be perhaps worse and this will hurt the eco system. In order ensure that Apple gets as many high quality apps as possible, making SwiftUI cross platform will make more companies choose it. This doesn't necessarily mean that Apple develop SwiftUI for other platforms but open source makes it possible for other to do it.
I personally would never learn an additional non cross platform GUI framework because of time spent versus market. C# MAUI has such an appeal here for me and if SwiftUI becomes cross platform it would have the same appeal.
1 Like
how does open sourcing something that is tied to internal apple apis and only works on apple platforms an advantage from apples perspective?
i think what you are really saying is you want apple to port swiftui to other platforms (and thats totally fair, i'd love that too) but that aint their business model
i think it would be more progress if someone forms an open-swiftui that clones apples apis (drop-in replacement) for other platforms than waiting for apple
1 Like
It isn't the "business model" of Apple to open source the Swift language either, so why did they do it?
I originally meant Apple to open source SwiftUI, not porting SwiftUI for other platforms. The actual development for other platforms does not need to be done by Apple similar how Linux/Windows ports of Swift are done by people not working for Apple.
It would be really cool to see Apple allow the community to create new SwiftUI backends. I think historically Apple would never do this, but these are different times. Especially once 64-bit WASM is out and Swift could reasonably run in a Browser with a Javascript Canvas-based backend, SwiftUI might evolve to compete with Electron and Flutter.
3 Likes
Pretty sure it has been mentioned further up the thread already, but given the last few posts I'm just gonna drop another link to Tokamak in here.
No need to wait for Apple do do or allow anything, and while Tokamak may not yet run on all the platforms and support all the API, the foundations are there and I think the future is looking bright :D
7 Likes