- The world where everyone Apple Developer uses Flutter, making apps on Apple platforms
1 Like
As for the Web, you could use GitHub - SwiftWebUI/SwiftWebUI: A demo implementation of SwiftUI for the Web if it did not came with that jerky license (but what do I expect, it's Helge being Helge)
What you are describing is not the whole picture. Yes, SwiftUI makes it easier to make apps for Apple platforms but tools like Flutter or ReactNative make it easier to make apps for all platforms.
Those frameworks are winning over developers since developers want to reach as wide audience as possible. For most businesses starting to develop apps the choice is clear, if the app is simple and does not use hardware extensively, cross platform solutions are just cheaper and easier to maintain. In the long run this will decrease the number of Swift developers and make the overall quality of the apps worse.
I work for a software house doing native development and we are seeing enormous pressure from cross platform solutions. Many clients ask us to do cross platform up front because it's cheaper and they can reach a wider audience from the start. I personally know a few people who already dropped native development in favor of React Native. If the trend continues then Swift will start to loose ground even on the iOS stronghold which does not align well with the world domination goal.
On the other hand, if SwiftUI would be made cross platform the language usage would increase. Cross platform apps will be made regardless of SwiftUI being cross platform its just a matter of writing them in JS rather than Swift.
8 Likes
Apple has its own preferences, but in their position, I'd certainly prefer the world where all apps are developed with a technology under my control.
I think you vastly overestimate the value of SwiftUI as usp — superior technology alone buys you nothing in our business, and I don't think SwiftUI is a reason to ditch other platforms: Cocoa is way older than the iPhone, and despite "inferior" libs, Windows has been way more attractive for developers (or at least their managers 
).
Now, iOS does not have the marketshare to dominate the whole industry — according to the latest numbers I found, Android is three times as big!
It does not matter much if apps on iOS are a little bit better than their counterparts on other platforms if app creators ditch it because they can't reach their target group with it.
However, SwiftUI could be an argument for people to put their focus on iOS if they would get the Android version for free.
Of course, in this scenario, iOS would still offer the superior experience — most likely even more than today.
4 Likes
I agree with everything you've said. Just a little addition: while it is less expensive to roll out a cross platform solution, the software company going down that road still pays with the reduced quality of its not-entirely-native product. In majority of cases it doesn't mean much. The client is happy. However, if this app has a pure native competitor things are less rosy.
So, bigger software companies that can afford it will continue to push separate clients, as long as there's noticeable divergence in features / visual style between targeted platforms. For them having the best possible client on every platform matters more.
1 Like
how do Apple make their apps for windows / android
wouldn't it be better if they could do it only using their tech (SwiftUI) ?
i think Apple should consider it, not only it'll help them save time, but also money
3 Likes
Someone is working on an open source implementation of SwiftUI, already works on linux!!
5 Likes
I believe this is the way to go if everything else fails. Data binding should work just fine. It will definitelly mean a lot of duplication of internal SwiftUI logic that could be reused for other platform if SwiftUI itself was opensourced. However, it seems feasible to me.
A bit of off topic here, but as far as I know Apple makes apps for other OSes by following their corresponding design guidelines. So, that means it not just changes how controls look, it may also change more in-depth things like navigation stack. And I as a sufferer of numerous apps with cross platform UI on Apple devices do believe this is the right way to do it.
Yes, theoretically you could do that with SwiftUI and make it auto-adapt for the platform in hand. But it is way easier, say, to just write a separate Android app than to port SwiftUI on Android.
3 Likes
Oh, I couldn't agree more with the sentiment of not trying to create a one size fits all UI stack.
I used to be a member of Borland's TeamB, helping on forums with technical advice, etc.
They brought out a version of Delphi for Linux, called Kylix. What a dog!!! They didn't seem to comprehend that: 1. there are too many UI frameworks for Linux to even get a one size fits all just for that one platform and 2. Who was going to pay thousands for a development tool aimed at a platform where everyone wants everything for free?
Then they moved to trying to create a UI framework that would do Windows, iOS, Android and macOS. The trouble was, as you say, platform differences are about much more than the look and feel of buttons.
First, there is the question of the macOS default button being placed in a different order to that on Windows.
Then they created a spreadsheet like table view that was expected to work on an iPhone - you know, with multiple columns as well as multiple rows.
Not forgetting to mention the idea of drop-down combo boxes for a touch device, where you needed a pencil sharpener to shave your finger tips down to a size small enough to tap on the drop-down arrow.
And I could go on and on - but I won't, and you get the picture.
I also know of many development shops who started out with the idea of doing an iOS and Android app, only to realise that Android is hard and to drop the idea of porting the now completed iOS app over.
The best apps use native UI frameworks and reduce the code by putting as much business logic as possible into a common codebase.
5 Likes
this can work for apps, but electron showed that nobody cares about native UI's, they want good looking UI with nice UX, native UI isn't always what people want
and for games or any other interactive apps, native UI is not something you want
so yeah, just like flutter, i believe swift COULD have played a big role, maybe it's too late.. maybe this community don't believe in crossplatform swift, it's weird and sad at the same time
5 Likes
Yes it is. End users don’t care about cross-platform apps. They only care about the platform they use. People use Electron apps because they exist, that’s all.
11 Likes
That's misinterpreting what @RUSshy said, which wasn't "people want cross-platform". It was "people want good looking UIs, regardless of whether they're native or not".
It is true that some (not all) Apple (both on mac and iOS) users seem to care a lot about "the app needs to look native", but this is a very uncommon sentiment for most people in general (especially people who are used to Windows), I think. All things being equal, they might prefer a native app, but things are not always equal, and businesses have to make trade-offs, and if Slack or VSCode decide that using Electron is the best business decision for them, it doesn't seem to really hinder their popularity.
1 Like
not only that but the whole of swiftui is already not “cross-platform” outside of apple
for example navigationview and tabview... how do you adapt that to a windows app? it could look very weird on windows to have a drill down like navigation view... even if your implementation abstracted that to act more windows-like, you’ve now just created two different behaviors and debugging scenarios that you’ve got to handle with “one” group of source code (in other words now you have two source codes)
a lot of windows apps have something like a ribbon interface.... emulating that with a collection of vstacks and hstacks sounds awful and would look totally out of place in an iphone for example... so now you create a special ribbonview, congratulations now it’s no loner swiftui that can work on a mac (without lots of effort anyways)
i don’t really think swiftui can be portable across non-apple platforms and have any kind of good ux, but maybe i’m missing something....
A lot of SwiftUI types are platform specific, which means if TabView makes no sense then it doesn‘t need to exist for an OS like Windows, just mark it unavailable. On the other hand the other primitive types make total sense for most OS‘s regardless on how they are baked behind the scenes for each platform.
Everyone who played with the framework and tried to build something for multiple Apple OS‘s knows that it‘s not 'build once' and it works and looks great on each platform, tweaks for each platform are always necessary. This wouldn‘t be different for other OS‘s. You will learn how to work with the framework, then apply necessary steps to make the UI and UX feel good for each individual targeting OS. The huge benefit here would be that you have to learn the framework once, and then you can reuse 'the knowledge' everywhere, not necessarily 'reuse same code' everywhere. ;)
Even at the WWDC session they stated this loud and clear for the supported platforms:
And this gets to the heart of something really important across all of SwiftUI.
The idea that you can learn a concept once and apply it anywhere.
SwiftUI is not just a means to write once and run anywhere, but it's a framework that enables you to learn these core concepts and use them in a variety of different contexts and platforms.
9 Likes
To amplify what I think you're saying... the benefit to cross-platform SwiftUI is not the widgets the framework provides, but rather it's the framework itself. The way UI code is written, not how the UI itself appears. The structure of the code, the language mechanisms that are used. These are more important than sharing a composite view or even a particular control.
16 Likes
From what I've seen in tutorials/articles, people want to write layout code in SwiftUI and if you use SwiftUI that way, you will never be able to use it on multiple platforms efficiently.
You want high level components in SwiftUI that conform to UIViewRepresentable (and similar protocols on all platforms) and do the layout code in a platform specific way.
Of course this way you will still have stuff that only makes sense on Desktop or Mobile but hopefully not many elements that only makes sense on 1 specific platform because that's mostly handled by your platform specific representation.
Of course you need to develop for more than 2 platforms to see efficiency in working this way. And even if SwiftUI runtime magically gets released to all platforms, there are still a million basic components to be made before one can start being efficient using SwiftUI for cross platform.
SwiftUI was built upon some core components of Apple technologies such as metal, combine, and core graphics; and other non-apple platforms do NOT have them natively.
So SwiftUI will never port to non-apple systems, like win32 winform wpf can't be used on non-windows systems.
That is an overoptimistic claim. Just because SwiftUI uses Apple platform specific frameworks under the hood on Apple platforms does not imply that SwiftUI primitive types and the layout-system and what not cannot be baked differently on other platforms. The framework itself does not expose these implementation details which means it's not restricted to that engine. Things like integration for UIKit/AppKit, Core Data or even Combine are all optional and can work differently on non-apple platforms. Although I still hope that Combine will be open sourced one day just like Swift was. Remember it took us some time before we got our hands on Swift open source itself, we could see the same happen to Combine and SwiftUI (at least in some adaptable form) after several years.
16 Likes
Rust will die when Microsoft will release their new language (Project Verona)
JVM = C/C++
Scala = Rust
Kotlin = Swift | Project Verona
everyone knows what happened to scala.. :)