21 ms·

Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions

429 points by nan0 6y ago

_bxg1 6y ago
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.
- steveklabnik 6y ago
  (He doesn’t anymore, but he did)
  - _bxg1 6y ago
    Oh he doesn't? Didn't realize that
    - steveklabnik 6y ago
      Yep! I’m not sure what he’s doing today. We’ve had several folks go between the two teams, and they’re generally very friendly with each other!
      - _bxg1 6y ago
        Yes I certainly didn't mean it as a knock on Rust, but as a compliment to Swift
      - insulanian 6y ago
        > I’m not sure what he’s doing today. He seems to be back working on Stellar [1]. [1] https://github.com/stellar/stellar-core/commits?author=graydon https://github.com/stellar/stellar-core/commits?author=grayd...
- kccqzy 6y ago
  That's an outdated but sadly common perception. TensorFlow for example is pushing Swift pretty hard: https://www.tensorflow.org/swift/ https://www.tensorflow.org/swift/ Disclaimer: I work at Google but not on TensorFlow.
  - _bxg1 6y ago
    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.
  - akhilcacharya 6y ago
    didn't all of the original authors of TF4S, including Chris Lattner, leave?
    - komuher 6y ago
      Yes they all did
      - person_of_color 6y ago
        All of them?? Bad blood
  - iphone_elegance 6y ago
    Is tensoflow for swift even still a thing?
    - michaelbrave 6y ago
      Some of the first bits of research using it just started coming out last month
      - iphone_elegance 6y ago
        I should really start looking at it again
no_wizard 6y ago
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
- jbverschoor 6y ago
  Apple is strengthening their services revenue. They week profit from the extra reach. Also, people will continue to but their hardware because the alternatives aren’t that great Simple example.... the MacBook trackpad
  - krallja 6y ago
    Ten years ago when I was offered a choice, I told the office manager I wanted a MacBook because of the trackpad. Apple’s trackpads are even better now. How has nobody figured out Apple’s 2010s trackpad technology?
    - chongli 6y ago
      How has nobody figured out Apple’s 2010s trackpad technology? I think because the focus is so much on the trackpad technology itself, which may be a misplaced focus. My fear is that the solution may involve rearchitecting the entire application-GUI stack to get it working on Linux. Why? Because Apple's trackpad is not a mouse emulator, it's a first class input device all the way up to the application. Trying to make the driver really smart is fruitless if you throw out all of that rich information and try to reduce the inputs down to what a mouse is capable of.
      - duskwuff 6y ago
        Eh, I think you're overblowing it a bit. While Apple's trackpad does do some unique things (like Chinese character input[1]), most of the behavior that people are interested in emulating here can be reduced to the cursor position, click events, and (high-resolution) scroll events. The only part of this that isn't currently available on Linux, AFAIK, is the scrolling bits, and even that isn't critical. [1]: https://support.apple.com/guide/chinese-input-method/use-trackpad-handwriting-scim27935/mac https://support.apple.com/guide/chinese-input-method/use-tra...
melling 6y ago
I have a Swift Cookbook that I maintain on Github: https://github.com/melling/SwiftCookBook https://github.com/melling/SwiftCookBook
sakras 6y ago
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. https://github.com/compnerd/swift-win32 https://github.com/compnerd/swift-win32
- alphaomegacode 6y ago
  Thanks for sharing that, very exciting. 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.
- vitorgrs 6y ago
  Would be more interesting Swift on top of WinRT/xlang. https://github.com/Microsoft/xlang https://github.com/Microsoft/xlang That would also means you would be able to deal with WinUI XAML and all.
- valerij 6y ago
  quite the juxtaposition to see windows events loop implemented in swift while GetMessageW(&msg, nil, 0, 0) { TranslateMessage(&msg) DispatchMessageW(&msg) } but lib looks really good, i guess there goes my weekend
xvilka 6y ago
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. [1] https://github.com/immunant/c2rust https://github.com/immunant/c2rust
- cerberusss 6y ago
  In my opinion, the integration between Objective-C and Swift is so incredibly seamless, that there's no need to translate existing Objective-C code. When I started working at my current client, there was a huge existing Objective-C code base to talk to an internal HTTP API. I just started coding. When I needed to add functions, I subclassed Objective-C classes in Swift.
  - zapzupnz 6y ago
    There is need to translate existing Objective-C code: on platforms where the Objective-C bridge is unavailable (Linux and Windows), Swift code can not call Objective-C code, nor toll-free bridge with Objective-C types, and therefore Objective-C types cannot be subclassed. For non-Apple platforms, you have to use a different implementation of Foundation — which has pretty good but not identical coverage to Apple's one. As a side note, it's always seemed clear to me that when Apple provides a new technology, they provide a stop-gap solution, like Carbon, for developers who, for a variety of possible reasons, may not be able or willing to use the new tech, like Cocoa. The bridge between Objective-C and Swift has always seemed like Carbon to me. Fortunately, unlike when Carbon was canned and rewriting for Cocoa seemed like a real chore, I don't think Apple will can the Objective-C bridge any time soon — but for Swift code now targeting or intending to target non-Apple platforms, it may be best to start thinking about migrating away from relying on the bridge now — decarbonify your Swift code.
    - DagAgren 6y ago
      Doesn't seem like there would be much demand to run legacy Objective-C code on other platforms, as it would most likely be strongly tied into macOS or iOS APIs that would be availble anyway.
iamcreasy 6y ago
Quick question: Does it mean now we can write games on Windows using SDL + Swift, and it will run on MacOS without any change at all?
- keyle 6y ago
  Quick answer: no.
  - iamcreasy 6y ago
    Could you please explain why?
    - RussianCow 6y ago
      No OP, and I don't know much about game development, but "without any change at all" is too strong. SDL only does so much, and you still need platform-specific APIs for file access, networking (if applicable), threading, etc. So you'll still need platform-specific code until someone writes those abstractions in Swift.
      - blondin 6y ago
        not OP either. but i think the problem is simple. apple said no to opengl, which any other platform out there supports. btw, they are even deprecating opengl! i have no idea what that means for the tons of games written with an opengl backend. probably not an issue for the iOS ecosystem though. so that's what is going on...
        roblabla 6y ago
        OpenGL isn't relevant here, as SDL2 has a metal backend that's used by default on MacOS. See https://hg.libsdl.org/SDL/rev/1acae5590352 https://hg.libsdl.org/SDL/rev/1acae5590352
        deleted 6y ago
atarian 6y ago
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.
- chiefsucker 6y ago
  Huh? Apple provides an example implementation at https://github.com/apple/swift-nio https://github.com/apple/swift-nio and I would say it’s straightforward to “get up and running”. It’s pretty easy to take Apple’s HTTP implementation, add a router, integrate a template engine and have something working, but then the real issues start, because the ecosystem and community just aren’t there.
forrestthewoods 6y ago
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?
- rudedogg 6y ago
  I don't think you can beat: https://books.apple.com/us/book/the-swift-programming-language-swift-5-2/id881256329 https://books.apple.com/us/book/the-swift-programming-langua... Xcode Playgrounds (different from the iPad/macOS Playgrounds app) are really helpful for learning the language or testing things out. For a complete course, see http://web.stanford.edu/class/cs193p/cgi-bin/drupal/ http://web.stanford.edu/class/cs193p/cgi-bin/drupal/. Apple also has a series on creating iOS apps. It may be too beginner focused though. https://books.apple.com/book/id1118575552 https://books.apple.com/book/id1118575552
- Eric_WVGG 6y ago
  Paul Hudson's books and guides are very good. I churned through his "100 days of SwiftUI" a couple months ago, really liked it. https://www.hackingwithswift.com https://www.hackingwithswift.com
  - briandear 6y ago
    Paul Hudson is the best, along with Ray Wenderlich’s stuff.
- deleted 6y ago
  [deleted]
ww520 6y ago
This is excellent news.
memco 6y ago
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 https://twitter.com/lrz/status/1250644001604042752).
- skohan 6y ago
  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.
richard_todd 6y ago
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?
- wlesieutre 6y ago
  Probably UIKit versus Foundation. UIKit is iOS/Mac only and I think indirectly includes Foundation, which is where the essential non-UI APIs are. All this really means is you don’t get the iOS UI tools for your Windows and Linux projects.
  - pasta1212 6y ago
    UIKit is iOS only, not Mac
    - wlesieutre 6y ago
      https://developer.apple.com/documentation/uikit/mac_catalyst https://developer.apple.com/documentation/uikit/mac_catalyst
- ken 6y ago
  Random numbers, at least, are now part of the standard library. As for the rest, it depends on what you consider "basic functionality". AppKit/UIKit is probably never going to be ported.
- Disparallel 6y ago
  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.
myko 6y ago
> It is not clear at the moment if Apple has any plans to port Swift UI to Windows and/or Linux 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.
- thought_alarm 6y ago
  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.
- ken 6y ago
  Swift wasn't originally open-source, either.
  - plorkyeran 6y ago
    They announced that it would be open-source in the future almost immediately.
    - comex 6y ago
      Not "almost immediately". They announced it would be open source at WWDC 2015, a year after Swift was first introduced at WWDC 2014. The actual open source release then happened a few months later in December 2015.
  - scarface74 6y ago
    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.
    - bdash 6y ago
pier25 6y ago
I imagine the idea is basically writing Swift servers and sharing code between platforms. I could be wrong but I seriously doubt we will cross platform SwiftUI, UIKit, etc.
andrewrothman 6y ago
Off-topic, but I read the title as "Supported on Linux distributions including but not limited to Windows". Microsoft, you know what we want.
- zelly 6y ago
  Windows switching to the Linux kernel would be wild, but I think we all know it's coming.
  - asveikau 6y ago
    I don't know how they can pull that off. They would need to support customers who need that compatibility. So either they start being major contributors to WINE or something like it ... But then what about people who need a propriatary driver? Maybe a VM with hardware passthrough.... But they already have WSL for compatibility in the other direction. Not good enough?
    - zelly 6y ago
      It won't happen all at once. Linux already coexists with Windows through WSL and virtualization. The real work is in porting the APIs that the core MS products make heavy use of (DirectX, .NET, GDI, etc.). The old Windows kernel will run in a hypervisor as needed. Windows already takes advantage of virtualization for everyday programs for security purposes. It wouldn't be that much of a shift to virtualize the kernel too. More and more of the MS stack is being ported to Linux, seemingly in preparation for this. As of recently you can run PowerShell on Linux and run .NET "Core" on Linux. Since Visual Studio and Office are all .NET, if the Windows graphics/GDI layer is also ported to Linux, then it should be possible soon to build Microsoft Word for Linux.
  - pansa2 6y ago
    Why would Microsoft ever want to do that?
  - pjmlp 6y ago
    Why would Microsoft want to adopt a less technology interesting kernel stuck in the age of monotliths? WSL is there to sell Windows laptops to those that would rather buy Macs without any interest in Apple's eco-system, rather using them as pretty UNIX for GNU/Linux work. They realised the mistake of not giving first class support to the POSIX subsystem and nowadays Linux compatibility is more relevant than POSIX.
awinter-py 6y ago
linux builds of ios apps would lead to general improvement in the state of build tooling for mobile (IMO) I take it this isn't that?
- zelly 6y ago
  This will never happen. Part of the reason programmers or aspiring programmers buy MacBooks is they think they will be working on iApps at some point in time. This is an example of the most intolerant minority winning[1]. I may have to use Windows to make games, but I can install Windows on a MacBook. I cannot install MacOS on a laptop with Windows or Linux pre-installed. [1] https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15 https://medium.com/incerto/the-most-intolerant-wins-the-dict...
  - saagarjha 6y ago
    > Part of the reason programmers or aspiring programmers buy MacBooks is they think they will be working on iApps at some point in time. Or perhaps they like the hardware or OS and have no intention to work on apps?
- zapzupnz 6y ago
  Indeed it isn't. That would require Apple's proprietary frameworks and macOS-specific utilities that support their Apple-only toolchains.
brigandish 6y ago
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 privilege of writing apps for Apple systems.
- zelly 6y ago
  You can still get around this because it's still possible to run Hackintosh in a VM.
  - brigandish 6y ago
    Okay, but surely that's a workaround for devs who are primarily on non-Mac systems who want to use native features for Mac. What's the win with Swift if I'm developing on Windows over using, say, C# and benefitting from all the support for my primary base and then using something like Xamarin. I'm on a Mac already (Macbook with 10.14) - am I really going to have to run a VM because of a point release? (That goes for both the OS and Xcode so that's even more absurd) The standard of their laptops is not good enough any more for me to justify the continued and continuous upgrades. Maybe access to their market would be but I'd need an existing set of customers to justify it, else Visual Studio et al look just as juicy.
    - zapzupnz 6y ago
      > because of a point release The second set of digits represents major releases. The third set represents point releases. macOS has been out, using this versioning scheme for a little over 20 years. Don't belittle the work between major releases just because the first set of digits hasn't changed. Windows Vista through Windows 8.1 are all 6.x, but nobody would claim that Vista and its service packs, 7 and its service pack, and the 8 family are minor upgrades — there were some colossal technical changes under the hood between each, especially regarding security and device drivers. Same thing for major releases of macOS, even if the user-facing stuff doesn't appear to be all that different. Also, if your machine supports 10.14, it supports 10.15. The last MacBook Pro that dropped support for anything more recent came out in 2011. Nobody's asking you to buy a new laptop.
judge2020 6y ago
> . 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.
- ashtonkem 6y ago
  Creating a good cross-platform GUI framework is probably harder than creating a good cross-platform language.
  - davidcorbin 6y ago
    100% correct
  - choward 6y ago
    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.
    - giancarlostoro 6y ago
      Heck if you go the Sciter route you can have a very well known approach but without going full Electron about it.
    - ashtonkem 6y ago
      A native look and feel is definitely an implicit assumption I held. You’re right that eliminating this requirement changes the level of difficulty significantly.
    - jolux 6y ago
xscott 6y ago
> 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.
badprose 6y ago
This is extremely exciting for me. I started writing a toy application for my iPhone using SwiftUI a few months ago and have been very impressed by Swift (coming from C#). So far, SwiftUI has felt exactly like what I wished XAML would become. The documentation and error messages are a complete disaster though (https://nooverviewavailable.com/ https://nooverviewavailable.com/)
- Austin_Conlon 6y ago
  Regarding error messages, which Xcode version are you on? They substantially improved after the Xcode update with an overhauled diagnostics engine. Documentation has been steadily improving, I’ve found that Apple does respond to Feedback Assistant reports about missing overviews and code listings, albeit way slower than I’d like.
  - badprose 6y ago
    I’m generally always on the latest released version. It _has) gotten better, but its still not good enough. For example, having two @Published variables in the same class with the same name causes a crash in the compiler with no pointers to the source.
sandGorgon 6y ago
Very interesting - so basically it will be versus React Native on Windows & Mac (using Typescript) https://microsoft.github.io/react-native-windows/ https://microsoft.github.io/react-native-windows/ Arguably people are already used to creating desktop apps using JS/Typescript using the Electron framework. React Native builds upon that. 2021 is going to be interesting
mister_hn 6y ago
I will find swift interesting only once you can build apps without having a Mac
sime2009 6y ago
But why? 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?
- skohan 6y ago
  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.
  - HacklesRaised 6y ago
    I was not aware that swift had affine types. Never been a big fan of Swift, I loved objective-c, so there is some built in bias there.
- ElFitz 6y ago
  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.
eggsnbacon1 6y ago
So many comments suggesting different UI frameworks with varying levels of cross-platform support. 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. 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. 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.
- zapzupnz 6y ago
  > that looks native and isn't slow No. > You're not going to find anything else thats as complete [...] Qt. WxWidgets. Soon, React Native for Windows and macOS. > [...] or performant No. > I bet you use Java GUI's all the time without even knowing it. Oh, people know it. Even users of Windows and Linux, platforms where a consistent native look and feel for applications is now a veritable pipe dream, can tell. Plenty of people specifically avoid apps written with a Java UI because they feel so non-native and slow. (Disclaimer: I'm not saying Qt, WxWidgets, necessarily feel any more native than Swing or JavaFX; I only mentioned them as examples of complete cross-platform UI kits, not necessarily as ones with the best integration — although well-designed Qt and WxWidgets apps will still feel miles more integrated with both Windows and macOS, notoriously difficult to emulate, than Swing) > 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 If you use apps from that specific set you listed, sure.
filleokus 6y ago
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. 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.
tempodox 6y ago
Good news. I'm feeling a strong reluctance against languages that only work on one platform.
mosselman 6y ago
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.
cutler 6y ago
... but not on OS X Mojave. What a joke.
deleted 6y ago
[deleted]
nloladze 6y ago
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.
brendenw 6y ago
Surprised OP have overlooked the importance of adding Amazon Linux 2. That opens the door to seamless and full supported AWS Lambda functions in Swift.
VexorLoophole 6y ago
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. 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.

429 points by nan0 6y ago

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.

steveklabnik 6y ago
(He doesn’t anymore, but he did)
- _bxg1 6y ago
  Oh he doesn't? Didn't realize that
  - steveklabnik 6y ago
    Yep! I’m not sure what he’s doing today. We’ve had several folks go between the two teams, and they’re generally very friendly with each other!
    - _bxg1 6y ago
      Yes I certainly didn't mean it as a knock on Rust, but as a compliment to Swift
    - insulanian 6y ago
      > I’m not sure what he’s doing today. He seems to be back working on Stellar [1]. [1] https://github.com/stellar/stellar-core/commits?author=graydon https://github.com/stellar/stellar-core/commits?author=grayd...
kccqzy 6y ago
That's an outdated but sadly common perception. TensorFlow for example is pushing Swift pretty hard: https://www.tensorflow.org/swift/ https://www.tensorflow.org/swift/ Disclaimer: I work at Google but not on TensorFlow.
- _bxg1 6y ago
  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.
- akhilcacharya 6y ago
  didn't all of the original authors of TF4S, including Chris Lattner, leave?
  - komuher 6y ago
    Yes they all did
    - person_of_color 6y ago
      All of them?? Bad blood
- iphone_elegance 6y ago
  Is tensoflow for swift even still a thing?
  - michaelbrave 6y ago
    Some of the first bits of research using it just started coming out last month
    - iphone_elegance 6y ago
      I should really start looking at it again

no_wizard 6y ago

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

jbverschoor 6y ago
Apple is strengthening their services revenue. They week profit from the extra reach. Also, people will continue to but their hardware because the alternatives aren’t that great Simple example.... the MacBook trackpad
- krallja 6y ago
  Ten years ago when I was offered a choice, I told the office manager I wanted a MacBook because of the trackpad. Apple’s trackpads are even better now. How has nobody figured out Apple’s 2010s trackpad technology?
  - chongli 6y ago
    How has nobody figured out Apple’s 2010s trackpad technology? I think because the focus is so much on the trackpad technology itself, which may be a misplaced focus. My fear is that the solution may involve rearchitecting the entire application-GUI stack to get it working on Linux. Why? Because Apple's trackpad is not a mouse emulator, it's a first class input device all the way up to the application. Trying to make the driver really smart is fruitless if you throw out all of that rich information and try to reduce the inputs down to what a mouse is capable of.
    - duskwuff 6y ago
      Eh, I think you're overblowing it a bit. While Apple's trackpad does do some unique things (like Chinese character input[1]), most of the behavior that people are interested in emulating here can be reduced to the cursor position, click events, and (high-resolution) scroll events. The only part of this that isn't currently available on Linux, AFAIK, is the scrolling bits, and even that isn't critical. [1]: https://support.apple.com/guide/chinese-input-method/use-trackpad-handwriting-scim27935/mac https://support.apple.com/guide/chinese-input-method/use-tra...

melling 6y ago

I have a Swift Cookbook that I maintain on Github: https://github.com/melling/SwiftCookBook https://github.com/melling/SwiftCookBook

sakras 6y ago

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. https://github.com/compnerd/swift-win32 https://github.com/compnerd/swift-win32

alphaomegacode 6y ago
Thanks for sharing that, very exciting. 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.
vitorgrs 6y ago
Would be more interesting Swift on top of WinRT/xlang. https://github.com/Microsoft/xlang https://github.com/Microsoft/xlang That would also means you would be able to deal with WinUI XAML and all.
valerij 6y ago
quite the juxtaposition to see windows events loop implemented in swift while GetMessageW(&msg, nil, 0, 0) { TranslateMessage(&msg) DispatchMessageW(&msg) } but lib looks really good, i guess there goes my weekend

xvilka 6y ago

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. [1] https://github.com/immunant/c2rust https://github.com/immunant/c2rust

cerberusss 6y ago
In my opinion, the integration between Objective-C and Swift is so incredibly seamless, that there's no need to translate existing Objective-C code. When I started working at my current client, there was a huge existing Objective-C code base to talk to an internal HTTP API. I just started coding. When I needed to add functions, I subclassed Objective-C classes in Swift.
- zapzupnz 6y ago
  There is need to translate existing Objective-C code: on platforms where the Objective-C bridge is unavailable (Linux and Windows), Swift code can not call Objective-C code, nor toll-free bridge with Objective-C types, and therefore Objective-C types cannot be subclassed. For non-Apple platforms, you have to use a different implementation of Foundation — which has pretty good but not identical coverage to Apple's one. As a side note, it's always seemed clear to me that when Apple provides a new technology, they provide a stop-gap solution, like Carbon, for developers who, for a variety of possible reasons, may not be able or willing to use the new tech, like Cocoa. The bridge between Objective-C and Swift has always seemed like Carbon to me. Fortunately, unlike when Carbon was canned and rewriting for Cocoa seemed like a real chore, I don't think Apple will can the Objective-C bridge any time soon — but for Swift code now targeting or intending to target non-Apple platforms, it may be best to start thinking about migrating away from relying on the bridge now — decarbonify your Swift code.
  - DagAgren 6y ago
    Doesn't seem like there would be much demand to run legacy Objective-C code on other platforms, as it would most likely be strongly tied into macOS or iOS APIs that would be availble anyway.

iamcreasy 6y ago

Quick question: Does it mean now we can write games on Windows using SDL + Swift, and it will run on MacOS without any change at all?

keyle 6y ago
Quick answer: no.
- iamcreasy 6y ago
  Could you please explain why?
  - RussianCow 6y ago
    No OP, and I don't know much about game development, but "without any change at all" is too strong. SDL only does so much, and you still need platform-specific APIs for file access, networking (if applicable), threading, etc. So you'll still need platform-specific code until someone writes those abstractions in Swift.
    - blondin 6y ago
      not OP either. but i think the problem is simple. apple said no to opengl, which any other platform out there supports. btw, they are even deprecating opengl! i have no idea what that means for the tons of games written with an opengl backend. probably not an issue for the iOS ecosystem though. so that's what is going on...
      - roblabla 6y ago
        OpenGL isn't relevant here, as SDL2 has a metal backend that's used by default on MacOS. See https://hg.libsdl.org/SDL/rev/1acae5590352 https://hg.libsdl.org/SDL/rev/1acae5590352
        deleted 6y ago

atarian 6y ago

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.

chiefsucker 6y ago
Huh? Apple provides an example implementation at https://github.com/apple/swift-nio https://github.com/apple/swift-nio and I would say it’s straightforward to “get up and running”. It’s pretty easy to take Apple’s HTTP implementation, add a router, integrate a template engine and have something working, but then the real issues start, because the ecosystem and community just aren’t there.

forrestthewoods 6y ago

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?

rudedogg 6y ago
I don't think you can beat: https://books.apple.com/us/book/the-swift-programming-language-swift-5-2/id881256329 https://books.apple.com/us/book/the-swift-programming-langua... Xcode Playgrounds (different from the iPad/macOS Playgrounds app) are really helpful for learning the language or testing things out. For a complete course, see http://web.stanford.edu/class/cs193p/cgi-bin/drupal/ http://web.stanford.edu/class/cs193p/cgi-bin/drupal/. Apple also has a series on creating iOS apps. It may be too beginner focused though. https://books.apple.com/book/id1118575552 https://books.apple.com/book/id1118575552
Eric_WVGG 6y ago
Paul Hudson's books and guides are very good. I churned through his "100 days of SwiftUI" a couple months ago, really liked it. https://www.hackingwithswift.com https://www.hackingwithswift.com
- briandear 6y ago
  Paul Hudson is the best, along with Ray Wenderlich’s stuff.
deleted 6y ago
[deleted]

ww520 6y ago

This is excellent news.

memco 6y ago

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 https://twitter.com/lrz/status/1250644001604042752).

skohan 6y ago
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.

richard_todd 6y ago

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?

wlesieutre 6y ago
Probably UIKit versus Foundation. UIKit is iOS/Mac only and I think indirectly includes Foundation, which is where the essential non-UI APIs are. All this really means is you don’t get the iOS UI tools for your Windows and Linux projects.
- pasta1212 6y ago
  UIKit is iOS only, not Mac
  - wlesieutre 6y ago
    https://developer.apple.com/documentation/uikit/mac_catalyst https://developer.apple.com/documentation/uikit/mac_catalyst
ken 6y ago
Random numbers, at least, are now part of the standard library. As for the rest, it depends on what you consider "basic functionality". AppKit/UIKit is probably never going to be ported.
Disparallel 6y ago
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.

myko 6y ago

> It is not clear at the moment if Apple has any plans to port Swift UI to Windows and/or Linux 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.

thought_alarm 6y ago
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.
ken 6y ago
Swift wasn't originally open-source, either.
- plorkyeran 6y ago
  They announced that it would be open-source in the future almost immediately.
  - comex 6y ago
    Not "almost immediately". They announced it would be open source at WWDC 2015, a year after Swift was first introduced at WWDC 2014. The actual open source release then happened a few months later in December 2015.
- scarface74 6y ago
  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.
  - bdash 6y ago

pier25 6y ago

I imagine the idea is basically writing Swift servers and sharing code between platforms. I could be wrong but I seriously doubt we will cross platform SwiftUI, UIKit, etc.

andrewrothman 6y ago

Off-topic, but I read the title as "Supported on Linux distributions including but not limited to Windows". Microsoft, you know what we want.

zelly 6y ago
Windows switching to the Linux kernel would be wild, but I think we all know it's coming.
- asveikau 6y ago
  I don't know how they can pull that off. They would need to support customers who need that compatibility. So either they start being major contributors to WINE or something like it ... But then what about people who need a propriatary driver? Maybe a VM with hardware passthrough.... But they already have WSL for compatibility in the other direction. Not good enough?
  - zelly 6y ago
    It won't happen all at once. Linux already coexists with Windows through WSL and virtualization. The real work is in porting the APIs that the core MS products make heavy use of (DirectX, .NET, GDI, etc.). The old Windows kernel will run in a hypervisor as needed. Windows already takes advantage of virtualization for everyday programs for security purposes. It wouldn't be that much of a shift to virtualize the kernel too. More and more of the MS stack is being ported to Linux, seemingly in preparation for this. As of recently you can run PowerShell on Linux and run .NET "Core" on Linux. Since Visual Studio and Office are all .NET, if the Windows graphics/GDI layer is also ported to Linux, then it should be possible soon to build Microsoft Word for Linux.
- pansa2 6y ago
  Why would Microsoft ever want to do that?
- pjmlp 6y ago
  Why would Microsoft want to adopt a less technology interesting kernel stuck in the age of monotliths? WSL is there to sell Windows laptops to those that would rather buy Macs without any interest in Apple's eco-system, rather using them as pretty UNIX for GNU/Linux work. They realised the mistake of not giving first class support to the POSIX subsystem and nowadays Linux compatibility is more relevant than POSIX.

awinter-py 6y ago

linux builds of ios apps would lead to general improvement in the state of build tooling for mobile (IMO) I take it this isn't that?

zelly 6y ago
This will never happen. Part of the reason programmers or aspiring programmers buy MacBooks is they think they will be working on iApps at some point in time. This is an example of the most intolerant minority winning[1]. I may have to use Windows to make games, but I can install Windows on a MacBook. I cannot install MacOS on a laptop with Windows or Linux pre-installed. [1] https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15 https://medium.com/incerto/the-most-intolerant-wins-the-dict...
- saagarjha 6y ago
  > Part of the reason programmers or aspiring programmers buy MacBooks is they think they will be working on iApps at some point in time. Or perhaps they like the hardware or OS and have no intention to work on apps?
zapzupnz 6y ago
Indeed it isn't. That would require Apple's proprietary frameworks and macOS-specific utilities that support their Apple-only toolchains.

brigandish 6y ago

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 privilege of writing apps for Apple systems.

zelly 6y ago
You can still get around this because it's still possible to run Hackintosh in a VM.
- brigandish 6y ago
  Okay, but surely that's a workaround for devs who are primarily on non-Mac systems who want to use native features for Mac. What's the win with Swift if I'm developing on Windows over using, say, C# and benefitting from all the support for my primary base and then using something like Xamarin. I'm on a Mac already (Macbook with 10.14) - am I really going to have to run a VM because of a point release? (That goes for both the OS and Xcode so that's even more absurd) The standard of their laptops is not good enough any more for me to justify the continued and continuous upgrades. Maybe access to their market would be but I'd need an existing set of customers to justify it, else Visual Studio et al look just as juicy.
  - zapzupnz 6y ago
    > because of a point release The second set of digits represents major releases. The third set represents point releases. macOS has been out, using this versioning scheme for a little over 20 years. Don't belittle the work between major releases just because the first set of digits hasn't changed. Windows Vista through Windows 8.1 are all 6.x, but nobody would claim that Vista and its service packs, 7 and its service pack, and the 8 family are minor upgrades — there were some colossal technical changes under the hood between each, especially regarding security and device drivers. Same thing for major releases of macOS, even if the user-facing stuff doesn't appear to be all that different. Also, if your machine supports 10.14, it supports 10.15. The last MacBook Pro that dropped support for anything more recent came out in 2011. Nobody's asking you to buy a new laptop.

judge2020 6y ago

> . 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.

ashtonkem 6y ago
Creating a good cross-platform GUI framework is probably harder than creating a good cross-platform language.
- davidcorbin 6y ago
  100% correct
- choward 6y ago
  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.
  - giancarlostoro 6y ago
    Heck if you go the Sciter route you can have a very well known approach but without going full Electron about it.
  - ashtonkem 6y ago
    A native look and feel is definitely an implicit assumption I held. You’re right that eliminating this requirement changes the level of difficulty significantly.
  - jolux 6y ago

xscott 6y ago

> 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.

badprose 6y ago

This is extremely exciting for me. I started writing a toy application for my iPhone using SwiftUI a few months ago and have been very impressed by Swift (coming from C#). So far, SwiftUI has felt exactly like what I wished XAML would become. The documentation and error messages are a complete disaster though (https://nooverviewavailable.com/ https://nooverviewavailable.com/)

Austin_Conlon 6y ago
Regarding error messages, which Xcode version are you on? They substantially improved after the Xcode update with an overhauled diagnostics engine. Documentation has been steadily improving, I’ve found that Apple does respond to Feedback Assistant reports about missing overviews and code listings, albeit way slower than I’d like.
- badprose 6y ago
  I’m generally always on the latest released version. It _has) gotten better, but its still not good enough. For example, having two @Published variables in the same class with the same name causes a crash in the compiler with no pointers to the source.

sandGorgon 6y ago

Very interesting - so basically it will be versus React Native on Windows & Mac (using Typescript) https://microsoft.github.io/react-native-windows/ https://microsoft.github.io/react-native-windows/ Arguably people are already used to creating desktop apps using JS/Typescript using the Electron framework. React Native builds upon that. 2021 is going to be interesting

mister_hn 6y ago

I will find swift interesting only once you can build apps without having a Mac

sime2009 6y ago

But why? 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?

skohan 6y ago
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.
- HacklesRaised 6y ago
  I was not aware that swift had affine types. Never been a big fan of Swift, I loved objective-c, so there is some built in bias there.
ElFitz 6y ago
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.

eggsnbacon1 6y ago

So many comments suggesting different UI frameworks with varying levels of cross-platform support. 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. 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. 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.

zapzupnz 6y ago
> that looks native and isn't slow No. > You're not going to find anything else thats as complete [...] Qt. WxWidgets. Soon, React Native for Windows and macOS. > [...] or performant No. > I bet you use Java GUI's all the time without even knowing it. Oh, people know it. Even users of Windows and Linux, platforms where a consistent native look and feel for applications is now a veritable pipe dream, can tell. Plenty of people specifically avoid apps written with a Java UI because they feel so non-native and slow. (Disclaimer: I'm not saying Qt, WxWidgets, necessarily feel any more native than Swing or JavaFX; I only mentioned them as examples of complete cross-platform UI kits, not necessarily as ones with the best integration — although well-designed Qt and WxWidgets apps will still feel miles more integrated with both Windows and macOS, notoriously difficult to emulate, than Swing) > 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 If you use apps from that specific set you listed, sure.

filleokus 6y ago

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. 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.

tempodox 6y ago

Good news. I'm feeling a strong reluctance against languages that only work on one platform.

mosselman 6y ago

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.

cutler 6y ago

... but not on OS X Mojave. What a joke.

deleted 6y ago

[deleted]

nloladze 6y ago

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.

brendenw 6y ago

Surprised OP have overlooked the importance of adding Amazon Linux 2. That opens the door to seamless and full supported AWS Lambda functions in Swift.

VexorLoophole 6y ago

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. 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.