> . It is hard to think that any Windows programmer would prefer Swift as a language over .NET languages, as many commenters pointed out on Reddit, but a port of Swift UI on Windows could be a game changer.
Everybody would jump to Swift [for new projects] if it meant a cross-platform GUI framework.
Creating a good cross-platform
GUI framework is probably harder
than creating a good cross-platform
language.
Way way way way way harder, I'd think. It's basically never been done in the modern era. All the successful ones from the past look (and work) like garbage on a modern desktop computer (I use gnucash for my dad's business, ha ha).
SwiftUI is an interesting re-think, though, and as a Windows 10 user, I can tell you that the current "native" experience sucks green potatoes. There are like 9 or 12 different UI technologies I must interact with each month. All with different text sizes and massively inconsistent UI paradigms.
So I think there is an opportunity here.
But, I bet SwiftUI → Web will come first. And if that happens, SwiftUI on Windows, and desktop Linux, will be a no-brainer and will happen.
And if it doesn't happen, then probably SwiftUI won't matter outside of the Apple ecosystem, and that will mean Swift won't matter much in the end, either. (EDIT: I don't mean Apple need do this and I don't expect they will. But SwiftUI is just an API; anybody could port it to whatever environment they want, and there are already some nascent third-party efforts to implement it for HTML/web.)
Full disclosure disclaimer: former NewtonScript programmer
Possibly, but that's if you include the part about making it look/feel native. If you just provide the tools the are just focused on the language and framework and let the people who care about making it look native on whichever platform it's running focus on that then I think it's doable.
Unlike things like react native you wouldn't be actually using the native components necessarily unless you can implement the UI frameworks components in terms of them. Otherwise they would need to be written from scratch.
Personally I wouldn't mind creating a new UI for every platform I need to support as long as I could use the same language with the same build tools and reusing components between them.
That's a big if. From what I've read, SwiftUI isn't even a great Mac/iOS GUI framework yet. And Windows and Linux are drastically more different than those two.
I really enjoy swiftUI. It appears like it tried to emulate react and succeeded on a few fronts, is better in a few fronts (child modifying parent variable), and worse in a few fronts (side effects).
That being said, my experience with SwiftUI users is that they don't like it because it is so different from the standard Mac experience (props and re-renders and state...). And the documentation is poor (IMO has been Apple standard from MapkitJS to iOS Swift documentation to SwiftUI) which leads to a negative dev experience. Try finding what causes a component to re-render in SwiftUI vs React. If you find it great and please post it, but it's not easy to find in my simple research.
Agreed. Just watched a recent tutorial on SwiftUI where changes to Hello World were taking a lifetime to update in canvas view. SwiftUI, like most of Apple's OS releases, is beta quality.
Although it technically has cross platform GUI, Flutter has actually reimplemented all the native OS widgets. As soon as the OS changes some look and feel your app will look out of date.
Flutter is one of the fastest growing frameworks for the past two years and therefore dart too. It most likely will succeed cause of this pace and the community growing around it.
When flutter for desktop lands into beta I think it will pick up even more pace and would be very hard to ignore for a lot of companies.
Every time mobile cross-platform is discussed, someone brings up Qt when it's less popular for mobile development than React Native, Flutter, Xamarin, or PhoneGap/Codova. Maybe even less than Ionic, NativeScript, or Appcelerator. Why even bother with such a niche solution? Are there even live cases of mobile apps using Qt?
Hate to say it, but the sanest thing to do if you need a cross platform UI is use Java. Your other choice is Electron, which is way slower and uses many times as much ram
>Everybody would jump to Swift [for new projects] if it meant a cross-platform GUI framework.
Not really. I'm sure there are plenty who will just stick with Qt based options or even Electron.
I've seen a lot of stuff built in PyQt by people who aren't strictly developers and who learned Python only because it fits with some other aspect of their job. There isn't a lot to incentivise them in learning a new language.
Qt licensing can be problematic depending on your project. They also no longer publish LTS releases under an open-source license. Swift UI would presumably not be encumbered in this way.
I think they are choosing react native because they genuinely like react.
I don’t remember which video it was exactly, but one of the higher ups talked about future technologies within Microsoft and how they were doing more and more GUI-based thing with react. And if you look at it, they’ve done pretty amazing things within the JavaScript eco-system in general. Office 365 is amazing, Visual Studio Code is amazing and it just wouldn’t make sense for them to go from typescript to dart.
Especially when you consider how unfinished flutter is. We’re a C#/power shell with a little Python shop with a lot of Enterprise Microsoft techs. We still considered Flutter because Xamarin wasn’t working out for us and we’re not big on JS or big enough to do native, but flutter just doesn’t fill our needs either. That’s anecdotal, but the difference is that react and react native are proven techs and flutter still isn’t.
What is the relative efficiency penalty these days, for using JavaScript to build the GUI, as opposed to using native code?
Like, isn’t VSCode all JavaScript? Surprisingly, this is probably what allowed Microsoft to build software that runs on both Window, Mac, and Linux! The JavaScript platform, ultimately became what Java dreamed of becoming back in the 1990s. And without the need to install a separate virtual machine layer, but at the expense of more inefficient code.
But VSCode is painfully slow, if you run it on an older PC.
And you’re not going to be running Windows 10 on a 15 year old PC anymore.
So could this mean, that software companies are going to force people to buy newer hardware, to run their programs? Most likely. Apple has programmed the consumer into spending unnecessarily for new hardware every year.
Best part about maturity. It matures. I would jump ship in a heartbeat to Swift. I don't use it because I can't use it in most places, and I am slowly learning to choose what I become an expert in. It sure isn't everything.
But when I did use it, I loved it. I've written in quite a few languages, and it is my favorite, but not my go-to because of its limited environment.
Not to mention that developing C# in Visual Studio or Rider feels years ahead of what's considered good enough IDE assistance in other languages. Comparable with Java even.
I have doubts. We already have cross-platform languages with decent GUI like Java (people give it tons of shit but I bet you use a Java GUI every day without knowing it). Python has some decent ones too though.
And of course Electron, which is somehow even worse than Java.
To specify, it does contain what SwiftUI calls a List. And each row in the list can of course contain a number of widgets, so you can approximate a table.
However for the desktop, a good real table, with columns, would be nice.
Whenever I've looked at examples on Swift on Linux in the past, the code always started with (hazy memory here) `use glibc` or similar, whereas the macOS version used a different library. So for example even just to produce a random number you had to use two completely different library functions imported with completely different names. All that to say: it's always felt to me like "cross-platform" for Swift means "the same syntax on a completely different platform." Has that changed, or will basic functionality on windows require a third completely different set of libraries?
It depends on what you're doing. Swift Foundation is cross platform for Windows/Linux/macOS and exposes apis for things like file systems, paths, process creation with the caveat that what a "Thread" is or what it means if a file is executable is a little different between platforms. If you're writing a cli tool you should be able stay mostly within the Swift stdlib and Foundation and that'll work on all platforms. As more libraries are ported to Windows (e.g. hopefully swift-nio), that should become more and more the case.
Where this isn't the case would be if performance mattered, some of Foundation system api implementations (at least, the Windows ones) can be a little inefficient since the Foundation api model and the Windows way of doing things doesn't always match and the Windows implementation has to do extra work to match the semantics.
Another would be UI wise, I haven't heard of plans for Apple to open source SwiftUI. Though since Swift can call into the native platform apis, it's quite possible to write a (perhaps not as slick) alternative.
Sounds like things have improved in the last couple years, thanks for the information. If they get to the point where a basic database-querying microservice will usually compile on all three platforms, I could imagine a lot more server-side interest in the language. Who knows?
This is really exciting. Every time I see something about Swift my thought process is "that looks like a lovely language but I don't build iOS/macOS apps, oh well". Maybe now I'll give it a real go.
Fun fact: Graydon Hoare, the original inventor of Rust, now works at Apple on Swift.
I know it's had some mixed support for other platforms for a while, but it's hard to really invest time and effort into a language before you know it has official support.
Sure, there are people who want to tinker with it for fun, but outside of that what is the point in having Swift on Linux and Windows?
You can't use it to build mac or iOS apps on Linux because the important libraries aren't there. There is no cross platform UI and Apple isn't likely to port and support theirs from macOS. If you are into servers then you have plenty of better languages options with established ecosystems. Maybe there are some command line apps on macOS which can now be ported to Linux/Window, but beyond that, what is the point? Where is Apple trying to go with this?
It's a fully fledged programming language. An open-source programming language, at that, with a lot of community input and involvement.
Not a macOS or iOS app creation DSL.
It's also quite pleasant to use, and has already seen a few uses beyond macOS and iOS apps, including some backend development (Vapor, Kitura, SwiftNIO, probably others).
So you could use it to write command line tools. To write Linux or Windows apps. Or to write servers. Just like any other programming language.
I use it for all kinds of things, like computer graphics and various tools in my CLI-driven workflows.
I find it nice to work with, because it has a lot of the nice features Rust does, like affine types, 1st class optional handling, decent single-threaded safety guarantees, and it has a very nice, ergonomic interface. Generally the performance characteristics are not what you would get with Rust, but I am generally more productive in Swift because I don't have to worry about the low level details.
There's definitely some downsides - cross platform support being one of them - but if I'm just working on a tool for me myself to use, I will generally reach for Swift because it's pleasant to work with. I would be happy if I could use it for projects which need to be deployed across different platforms.
This is basic foundation building. It's true there aren't too many good use-cases for Swift on Windows or Linux now. But that can't really start to change until Swift has decent support for Windows and Linux.
Of course, it will take a lot more than this for Swift to catch on outside of its home territory. This is just one necessary step.
More broadly, I think we're still in the middle of the language wars, where the limitations of the historically dominant languages (like C, C++, Java, Javascript) have created openings for one or more newer languages. I think Apple and other Swift proponents would like Swift to become one of those newer established languages and take steps like these to at least keep it in the running.
They’re looking to build demand over time by making Swift available in as many places as possible.
And this is the Swift Open Source team, not Apple specifically. It’s not an Apple business decision (aside from lowering the learning hurdle for new iOS projects)
They provide some sources, but they are not complete and are more to look at than to use.
I figure this got through the approval process because it could plausibly get developers to pay attention to apple without letting others exit the apple ecosystem.
Apple has to ensure that Swift is adopted as widely as possible to ensure that enough people in the world are theoretically able to submit apps to their store.
The important aspect of SwiftUI is tight integration with AppKit and UIKit. SwiftUI for Win32 (or whatever) would be a completely different beast.
There's nothing stoping anyone from implementing such a thing, just as someone wrote a SwiftUI for HTML. All the pieces are there, but it would be a huge amount of work unrelated to SwiftUI on Mac and iOS.
It seems like it could still be coming. They might be following the same pattern for SwiftUI (and Combine) that they used with Swift itself:
1. Create and introduce it as proprietary
2. Iterate fast, changing a lot of things to improve it quickly.
3. Stablize
4. Open source it (and continue iterating with an open process)
The advantage to starting proprietary is the initial iteration phase can move move quickly and stay focused on the goals of the people in the controlling group.
Not only did they announce that it would be open source immediately, unlike the source code dump they did with WebKit, Apple made the entire git commit history public from the initial commit.
XNU is one of the few parts of macOS that is actually open source. I’d be pretty surprised though if swiftUI were deeply dependent on the kernel itself, rather than on some graphics toolkit within macOS
If by some stretch that means Swift can then make complete Windows programs, that could be good for consumers but particularly good for enterprise developers.
This is good news to me! I've been very interested in Swift for a long time, but mostly work doing web dev so it would only be useful to me if I could run it on Linux and it initially didn't have a great support story. I know it has been able to run on some Linuxes for a while, but it just didn't appear to be a great ecosystem. Now, there's interesting stuff happening for both backend and fronted (https://twitter.com/lrz/status/1250644001604042752).
The ecosystem isn't npm or anything but it's not terrible if you don't care about targeting Windows. The standard library is pretty good, and between C and Python interop there's generally always a way to do something even if there's not great library support directly in Swift.
> It is hard to think that any Windows programmer would prefer Swift as a language over .NET languages,
It's not hard for me to think that. I've never been interested in .Net languages, and I write stuff for both Linux and Windows. If it was just Swift the language and compiler, and I had to wrap Win32 API calls by hand, I'd happily use it.
Readit News
Everybody would jump to Swift [for new projects] if it meant a cross-platform GUI framework.
SwiftUI is an interesting re-think, though, and as a Windows 10 user, I can tell you that the current "native" experience sucks green potatoes. There are like 9 or 12 different UI technologies I must interact with each month. All with different text sizes and massively inconsistent UI paradigms.
So I think there is an opportunity here.
But, I bet SwiftUI → Web will come first. And if that happens, SwiftUI on Windows, and desktop Linux, will be a no-brainer and will happen.
And if it doesn't happen, then probably SwiftUI won't matter outside of the Apple ecosystem, and that will mean Swift won't matter much in the end, either. (EDIT: I don't mean Apple need do this and I don't expect they will. But SwiftUI is just an API; anybody could port it to whatever environment they want, and there are already some nascent third-party efforts to implement it for HTML/web.)
Full disclosure disclaimer: former NewtonScript programmer
It looks like the bear is in keeping up with all the platform updates all the time though.
Unlike things like react native you wouldn't be actually using the native components necessarily unless you can implement the UI frameworks components in terms of them. Otherwise they would need to be written from scratch.
That being said, my experience with SwiftUI users is that they don't like it because it is so different from the standard Mac experience (props and re-renders and state...). And the documentation is poor (IMO has been Apple standard from MapkitJS to iOS Swift documentation to SwiftUI) which leads to a negative dev experience. Try finding what causes a component to re-render in SwiftUI vs React. If you find it great and please post it, but it's not easy to find in my simple research.
When flutter for desktop lands into beta I think it will pick up even more pace and would be very hard to ignore for a lot of companies.
But Swift doesn't run on Android, does it?
Not really. I'm sure there are plenty who will just stick with Qt based options or even Electron.
I've seen a lot of stuff built in PyQt by people who aren't strictly developers and who learned Python only because it fits with some other aspect of their job. There isn't a lot to incentivise them in learning a new language.
Maybe befause React native uses OS UI components while Flutter creates everything from scratch. https://microsoft.github.io/react-native-windows/
I don’t remember which video it was exactly, but one of the higher ups talked about future technologies within Microsoft and how they were doing more and more GUI-based thing with react. And if you look at it, they’ve done pretty amazing things within the JavaScript eco-system in general. Office 365 is amazing, Visual Studio Code is amazing and it just wouldn’t make sense for them to go from typescript to dart.
Especially when you consider how unfinished flutter is. We’re a C#/power shell with a little Python shop with a lot of Enterprise Microsoft techs. We still considered Flutter because Xamarin wasn’t working out for us and we’re not big on JS or big enough to do native, but flutter just doesn’t fill our needs either. That’s anecdotal, but the difference is that react and react native are proven techs and flutter still isn’t.
Like, isn’t VSCode all JavaScript? Surprisingly, this is probably what allowed Microsoft to build software that runs on both Window, Mac, and Linux! The JavaScript platform, ultimately became what Java dreamed of becoming back in the 1990s. And without the need to install a separate virtual machine layer, but at the expense of more inefficient code.
But VSCode is painfully slow, if you run it on an older PC.
And you’re not going to be running Windows 10 on a 15 year old PC anymore.
So could this mean, that software companies are going to force people to buy newer hardware, to run their programs? Most likely. Apple has programmed the consumer into spending unnecessarily for new hardware every year.
I wouldn't. I don't like Swift's syntax. The ecosystem would likely not be mature enough either.
But when I did use it, I loved it. I've written in quite a few languages, and it is my favorite, but not my go-to because of its limited environment.
Not to mention that developing C# in Visual Studio or Rider feels years ahead of what's considered good enough IDE assistance in other languages. Comparable with Java even.
And of course Electron, which is somehow even worse than Java.
wtf.
However for the desktop, a good real table, with columns, would be nice.
Where this isn't the case would be if performance mattered, some of Foundation system api implementations (at least, the Windows ones) can be a little inefficient since the Foundation api model and the Windows way of doing things doesn't always match and the Windows implementation has to do extra work to match the semantics.
Another would be UI wise, I haven't heard of plans for Apple to open source SwiftUI. Though since Swift can call into the native platform apis, it's quite possible to write a (perhaps not as slick) alternative.
As for the rest, it depends on what you consider "basic functionality". AppKit/UIKit is probably never going to be ported.
All this really means is you don’t get the iOS UI tools for your Windows and Linux projects.
Fun fact: Graydon Hoare, the original inventor of Rust, now works at Apple on Swift.
Disclaimer: I work at Google but not on TensorFlow.
Fortran, C++, Python and Julia drive the show and work with full tooling across UNIX flavours, Windows, macOS today.
Sure, there are people who want to tinker with it for fun, but outside of that what is the point in having Swift on Linux and Windows?
You can't use it to build mac or iOS apps on Linux because the important libraries aren't there. There is no cross platform UI and Apple isn't likely to port and support theirs from macOS. If you are into servers then you have plenty of better languages options with established ecosystems. Maybe there are some command line apps on macOS which can now be ported to Linux/Window, but beyond that, what is the point? Where is Apple trying to go with this?
Not a macOS or iOS app creation DSL.
It's also quite pleasant to use, and has already seen a few uses beyond macOS and iOS apps, including some backend development (Vapor, Kitura, SwiftNIO, probably others).
So you could use it to write command line tools. To write Linux or Windows apps. Or to write servers. Just like any other programming language.
I find it nice to work with, because it has a lot of the nice features Rust does, like affine types, 1st class optional handling, decent single-threaded safety guarantees, and it has a very nice, ergonomic interface. Generally the performance characteristics are not what you would get with Rust, but I am generally more productive in Swift because I don't have to worry about the low level details.
There's definitely some downsides - cross platform support being one of them - but if I'm just working on a tool for me myself to use, I will generally reach for Swift because it's pleasant to work with. I would be happy if I could use it for projects which need to be deployed across different platforms.
This is basic foundation building. It's true there aren't too many good use-cases for Swift on Windows or Linux now. But that can't really start to change until Swift has decent support for Windows and Linux.
Of course, it will take a lot more than this for Swift to catch on outside of its home territory. This is just one necessary step.
More broadly, I think we're still in the middle of the language wars, where the limitations of the historically dominant languages (like C, C++, Java, Javascript) have created openings for one or more newer languages. I think Apple and other Swift proponents would like Swift to become one of those newer established languages and take steps like these to at least keep it in the running.
And this is the Swift Open Source team, not Apple specifically. It’s not an Apple business decision (aside from lowering the learning hurdle for new iOS projects)
Not to mention there’s Swift for TensorFlow, would be nice if you could handle your code locally on a Windows machine: https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
Apple's behavior with open source is kind of "throw it over the wall" which isn't really good leadership.
The good stuff at apple is frameworks and apps, none of it released.
For examples of this, look at Darwin on https://opensource.apple.com
They provide some sources, but they are not complete and are more to look at than to use.
I figure this got through the approval process because it could plausibly get developers to pay attention to apple without letting others exit the apple ecosystem.
It seems pretty clear they have 0 plans on doing that. They could've open sourced it in the first place, along with Combine.
Not open sourcing Combine seems like a pretty short sighted decision to me.
There's nothing stoping anyone from implementing such a thing, just as someone wrote a SwiftUI for HTML. All the pieces are there, but it would be a huge amount of work unrelated to SwiftUI on Mac and iOS.
1. Create and introduce it as proprietary
2. Iterate fast, changing a lot of things to improve it quickly.
3. Stablize
4. Open source it (and continue iterating with an open process)
The advantage to starting proprietary is the initial iteration phase can move move quickly and stay focused on the goals of the people in the controlling group.
https://github.com/compnerd/swift-win32
That would also means you would be able to deal with WinUI XAML and all.
If by some stretch that means Swift can then make complete Windows programs, that could be good for consumers but particularly good for enterprise developers.
It's not hard for me to think that. I've never been interested in .Net languages, and I write stuff for both Linux and Windows. If it was just Swift the language and compiler, and I had to wrap Win32 API calls by hand, I'd happily use it.