> . 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.<p>Everybody would jump to Swift [for new projects] if it meant a cross-platform GUI framework.
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?
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.<p>Fun fact: Graydon Hoare, the original inventor of Rust, now works at Apple on Swift.
But why?<p>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?<p>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 is not clear at the moment if Apple has any plans to port Swift UI to Windows and/or Linux<p>It seems pretty clear they have 0 plans on doing that. They could've open sourced it in the first place, along with Combine.<p>Not open sourcing Combine seems like a pretty short sighted decision to me.
Also worth noting that Saleem has also been working on a wrapper of Windows GDI for Swift. While it's not a port of SwiftUI, it looks pretty similar.<p><a href="https://github.com/compnerd/swift-win32" rel="nofollow">https://github.com/compnerd/swift-win32</a>
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 (<a href="https://twitter.com/lrz/status/1250644001604042752" rel="nofollow">https://twitter.com/lrz/status/1250644001604042752</a>).
> It is hard to think that any Windows programmer would prefer Swift as a language over .NET languages,<p>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.
XCode (and hence most of the useful parts of using the Apple development ecosystem) as of v11.4 won't install on Macs running Mojave it's actually better, in my view, to use Mono/C# and things like Xamarin than start off with Swift and think you can port the other way and not be forced into upgrading your laptop for the <i>privilege</i> of writing apps for Apple systems.
I have a Swift Cookbook that I maintain on Github:<p><a href="https://github.com/melling/SwiftCookBook" rel="nofollow">https://github.com/melling/SwiftCookBook</a>
Wonder if some macOS only software will get ported to Windows once this happens. That if course is assuming there’s good support for the Windows APIs for building apps
They need objc2swift, something like c2rust[1], to speed up the legacy code upgrade. Transpiler and code refactoring tool, all while preserving the ability to run tests. Or, on the other side, c2rust should get an Objective C support as an input.<p>[1] <a href="https://github.com/immunant/c2rust" rel="nofollow">https://github.com/immunant/c2rust</a>
I imagine the idea is basically writing Swift servers and sharing code between platforms.<p>I could be wrong but I <i>seriously</i> doubt we will cross platform SwiftUI, UIKit, etc.
This is extremely exciting for me. I started writing a toy application for my iPhone using SwiftUI a few months ago and have been <i>very</i> impressed by Swift (coming from C#).
So far, SwiftUI has felt exactly like what I wished XAML would become.<p>The documentation and error messages are a complete disaster though (<a href="https://nooverviewavailable.com/" rel="nofollow">https://nooverviewavailable.com/</a>)
Sounds like great news! Am excited to see, where Swift will end. I am no developer but I like to code things and script tasks (at work that's even my job). Already tried many different languages. In the end I always used Python, because i feared that nobody can rewrite my code, if I write it in something more exotic.<p>Out of interest I spend some evenings in swift (server-side) and it felt some kind of fresh air. Python feels so 'slugish' all the time. But I am worried, if swift will ever be 'useful' server-side.
I don't think this is evidence for a move to cross plattform UI apps, but I hope it's a move to make Swift more useful on the server side.<p>As I've understood it, Foundation support is pretty good these days? But it would be cool if Apple ported even more frameworks that could be useful for server side applications. Recently I would have loved to have had AVFoundation available when doing some HLS parsing server side, for example.
Very interesting - so basically it will be versus React Native on Windows & Mac (using Typescript) <a href="https://microsoft.github.io/react-native-windows/" rel="nofollow">https://microsoft.github.io/react-native-windows/</a><p>Arguably people are already used to creating desktop apps using JS/Typescript using the Electron framework. React Native builds upon that.<p>2021 is going to be interesting
I hope they also add better builtins for HTTP. Last time I worked with Swift it was difficult to get a simple server up and running without a framework.
Off-topic, but I read the title as "Supported on Linux distributions including but not limited to Windows". Microsoft, you know what we want.
Surprised OP have overlooked the importance of adding Amazon Linux 2.<p>That opens the door to seamless and full supported AWS Lambda functions in Swift.
What’s the best resource to learn Swift? Should I grab a Bluetooth keyboard and go through Swift Playgrounds on iPad? Or is that more for children brand new to programming?
This looks good. I started learning Swift a few days ago because I want to play around with iOS and macos apps, so good to see I could use it on other platforms too.
Huh, might finally get around to Apple garbage. Closing your users to one internal system with internal hardware works for speed and maintenance issues([with users] look at early Windows with it's struggles and blue screens despite it's prevalent use across various hardware systems. But it doesn't work with devs. Dude if I can't code your stuff or for your platform on my shitty little linux, I have zero interest in working on your platform or utilizing your tech stack.
So many comments suggesting different UI frameworks with varying levels of cross-platform support.<p>Guys, I hate to say this, just use Java. Its fully cross-platform with a complete UI toolkit that looks native and isn't slow. You're not going to find anything else thats as complete or performant. Java has been focused on this niche forever.<p>I bet you use Java GUI's all the time without even knowing it. Most of you every day. Tons of IDE's, database visualizers, and other dev tools are made with Java GUI's.<p>Every Jetbrains tool, DBeaver, DB Visualizer, MySQL Workbench, other stuff I'm too lazy to look up. If you have a tool thats not web with a big UI, its Electron or Java 90% of the time.