
Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions - nan0
https://www.infoq.com/news/2020/05/swift-5-3-windows-linux/
======
judge2020
> . 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
Creating a good cross-platform GUI framework is probably harder than creating
a good cross-platform language.

~~~
veidr

        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

~~~
DeusExMachina
I think the opportunity is particularly on how SwiftUI has been implemented in
iOS, iPadOS and macOS, by relying on the native UI of each platform and
providing a common abstraction for developers.

Instead of providing the same UI that works badly on every device, SwiftUI
interprets each concept differently according to the platform.

For example, a Toggle in an iOS and iPadOS app looks like a on/off switch,
while on macOS it's rendered as a checkbox. A Picker has is scrolling wheel on
iOS but it's shown as radio boxes or a drop-down menu on macOS.

Navigation is also the same. On iOS, a NavigationView offers the drill-down
navigation common to iPhone apps, while on macOS it creates a split master-
detail interface.

Each implementation does so by using the native UI framework of each platform
under the hood, UIKit on iOS, and AppKit on macOS. I don't know how UI
development works on Windows, but my speculation is that a SwiftUI
implementation would work the same way.

~~~
FreakyT
I can’t comment on SwiftUI in particular, but I’ve found that a lot of things
like this tend to break down in most other cross platform GUI frameworks,
falling into a kind of uncanny valley, where the experience ends up being
either:

1\. Native feeling, but sufficiently inflexible that only very simple, common
UI patterns can be implemented

2\. An “uncanny valley” native ui, where things are _almost_ native but often
feel _wrong_ in subtle ways

I think that’s why Electron has succeeded where so many cross platform UI
frameworks failed: it’s so _obviously_ not native that it doesn’t fall into
that “uncanny valley” anymore

------
richard_todd
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?

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

~~~
richard_todd
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?

~~~
skohan
FWIW it's already viable to use Swift in the micro-service use-case. If you're
running logic inside containers it's trivial to get a Swift service up and
running.

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

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

~~~
pjmlp
I don't believe TF4Swift will go anywhere.

Fortran, C++, Python and Julia drive the show and work with full tooling
across UNIX flavours, Windows, macOS today.

~~~
jabl
I'd love to have a modern statically typed language with type inferencing etc.
that can be used for scripting, working in a REPL, as well as compiling to
native code.

I've never tried Swift, but it seems it _could_ have all the required
features. I guess it's just lacking a lot of libraries that work on Linux.

~~~
pjmlp
OCaml fits the bill.

~~~
jabl
Yeah, or Haskell.

But those have been out there in a more or less mature form for decades, with
no major uptake in sight. I guess they're just too esoteric for them to reach
critical mass. So here I am, stuck with bash/python/C, and dabbling a bit with
Rust..

~~~
pjmlp
If you would like to work in finance or compiler development, there is enough
uptake of ML derived languages.

------
sime2009
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?

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

~~~
jbverschoor
I'd say swift is currently probably the best languages out there. Language
features, standard library, performance, memory management.

~~~
blauditore
I'm curious, how do people judge this?

Personally I have some significant experience with maybe 5 different
languages, which is already more diverse than the average software dev as far
as I know. But I still wouldn't be comfortable to judge something like this.

For instance, I haven't worked with Swift, but I find it hard to believe it's
much better than, say, C#, Scala, or Typescript, regarding those metrics. Do
you have experience in those languages?

~~~
dimatura
It's subjective, naturally. I don't know if I'd be _that_ enthusiastic, but I
definitely like it a lot.

My main languages are Python and C++. I've also used Java, C#, Javascript but
not Typescript, among others.

In my opinion Swift does a pretty good job at striking a balance between
expressiveness/usability, safety and performance. If it gets more traction
under Linux (including a larger ecosystem and better tooling around it) I'd
definitely consider it for projects where Python could become a bottleneck but
C++-level performance is not absolutely required.

On the other hand, other languages in a similar niche - Rust, Go, even D or
Nim? are already more established outside of iOS/MacOS, so I don't know. My
experience with Swift has definitely made me more interested in learning Rust,
which seems quite similar in some respects.

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

~~~
ken
Swift wasn't originally open-source, either.

~~~
scarface74
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
FWIW, WebKit's complete history is available in its Subversion repository, all
the way back to the initial commits in 2001 when they were importing KHTML and
convincing it to compile without Qt. Granted, there was around two years after
Safari's initial release where Apple simply published source code drops, but
the full code history has been public (first in CVS, then in SVN) since
mid-2005.

------
sakras
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)

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

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

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

------
brigandish
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
You can still get around this because it's still possible to run Hackintosh in
a VM.

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

~~~
brigandish
> The second set of digits represents major releases. The third set represents
> point releases.

It's called _being facetious_. Regardless, Xcode definitely does not use the
2nd digit for major releases[1], which does require 10.15.

> Windows Vista…

Completely irrelevant.

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

Yeah, the reality for my machine is that the upgrade did not take, which is
funny considering I only tried to upgrade because of the Xcode requirements.

> Nobody's asking you to buy a new laptop.

They sell hardware. If you think they introduce breaking changes to the
operating system tied to the hardware because of necessity then I have a
bridge to sell you.

[1]
[https://en.wikipedia.org/wiki/Xcode#Xcode_11.x_(since_SwiftU...](https://en.wikipedia.org/wiki/Xcode#Xcode_11.x_\(since_SwiftUI_framework\))

~~~
zapzupnz
> It's called being facetious

Then stop being facetious. It wasn't clear you were being facetious, anyway.

> Completely irrelevant

No, it isn't, not to the point I was making. You also don't get to decide
what's relevant to a point _someone else_ is making.

The point is that Vista's version number is 6.0, 7's was 6.1, 8's was 6.2, and
8.1's was 6.3. All seemingly minor version number bumps, all major releases.

> Yeah, the reality for my machine is that the upgrade did not take

That's unfortunate — but nobody else's problem. If you have a capable machine,
harping on about ...

> They sell hardware

... doesn't really stand. They may be selling hardware — but you don't have to
buy any.

~~~
brigandish
Personally, I try to read in a charitable way by assuming that the person
writing isn't being robotic - we may (most of us here) be techies but we're
still human. I enjoy the wit of others, especially served wry.

Now, to versioning. There is no one standard for versioning. _Again_ , we're
mainly techies here, we know this (I hope). I like semver[1] (though I'm
having doubts[2]), some prefer calver[3], others use versions as branding[4]
(which extends beyond computing). Hence, the choice of version scheme chosen
by another organisation or project has _no relevance_ to any other project,
their being in the same category or field or competing or whatever simply have
no more relevance to this subject than Ford Escort MkII moving to MkIII.

If you're into recursion you might also try applying you "who gets to choose
the relevance" logic beyond your own comments, it'll be enlightening.

Finally, if you're going to suggest that all X are capable of something but
ignore exceptions to that to me smacks of dogmatism, and more importantly, _of
no help whatsoever to the person you 're responding to_.

If you have something helpful or insightful _for me_ then please respond with
that, else you can comment further up the thread with your thoughts about
versioning and how a hardware company that has been fined for planned
obsolescence _via software updates_ [5] isn't angling for more purchases when
it stops its dev environment being backwards compatible so it can support a
half finished UI library.

[1] [https://semver.org/](https://semver.org/)

[2]
[https://www.youtube.com/watch?v=oyLBGkS5ICk](https://www.youtube.com/watch?v=oyLBGkS5ICk)
A fascinating talk by Rich Hickey where he questions semver and the way we
handle change as developers.

[3] [https://calver.org/](https://calver.org/)

[4] [https://hbr.org/2011/05/the-best-way-to-name-your-
product-20](https://hbr.org/2011/05/the-best-way-to-name-your-product-20) It's
interesting, they did lab tests:

> In laboratory and field studies involving hundreds of subjects, we found
> that when consumers see a brand-name continuation, they expect improvements
> to existing features. When they see a brand-name change, they expect
> fundamentally new features, and they perceive the product as riskier
> (likelier to fail or more prone to compatibility problems with previous
> products) but potentially more rewarding (higher in quality, more satisfying
> to use).

If OS X to macOS isn't a brand name change then what's the point (pun
intended) of the 10?

[5] [https://www.itworld.com/article/3316958/apple-and-samsung-
fi...](https://www.itworld.com/article/3316958/apple-and-samsung-fined-for-
planned-obsolescence.html) I got a free battery out of this one, perhaps I
shouldn't complain? (wry humour alert;)

Edit: I managed to muck up the numbering. Is Markdown capable of off-by-one
errors? I can make it happen.

------
melling
I have a Swift Cookbook that I maintain on Github:

[https://github.com/melling/SwiftCookBook](https://github.com/melling/SwiftCookBook)

------
no_wizard
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
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
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
_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
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-
tra...](https://support.apple.com/guide/chinese-input-method/use-trackpad-
handwriting-scim27935/mac)

~~~
chongli
It isn't just that. The scrolling in macOS is 2D (you can scroll a small
rectangle inside a large one in any direction) and has position, velocity,
acceleration, and a bounce effect on the boundaries of the content area.
Additionally, you can pinch to zoom (in and out) and the zooming is smooth and
continuous centred on the cursor location.

There are also various 3-finger swipe gestures, and force touch lets you click
on things with different levels of force to do different things.

The only Linux application I've seen that uses smooth scrolling with
acceleration is Firefox, and that isn't nearly as smooth as macOS scrolling
(which is available in every application).

~~~
duskwuff
Two-axis scrolling isn't unique to macOS. The way that scrolling has
traditionally been implemented on Linux (as mouse buttons 4 and 5) makes it
difficult to implement any kind of continuous scrolling, but once you have one
axis working, a second one isn't much harder.

The velocity and bounce effects on scrolling are implemented at the
application layer. They don't depend on any unique features of the trackpad
hardware or driver stack.

Zoom and swipe gestures are nice to have, but I don't think they're critical
in the same kind of way that pointing and acceleration are.

Force Touch is more of a gimmick than anything. It's a relatively recent
feature, and was only added to the Macbook Air in 2018; very few applications
do anything interesting with it. Personally, I leave it turned off.

~~~
chongli
_The velocity and bounce effects on scrolling are implemented at the
application layer. They don 't depend on any unique features of the trackpad
hardware or driver stack._

I didn’t say they did. Oh macOS they’re not implemented by the application
though, they’re implemented by the UI APIs and thus available to all
applications for free. This is not the case on Linux.

~~~
cycloptic
It is the case on Linux. Both GTK and Qt have this built in for a while now:

[https://developer.gnome.org/gtk3/stable/GtkScrolledWindow.ht...](https://developer.gnome.org/gtk3/stable/GtkScrolledWindow.html#GtkScrolledWindow
--kinetic-scrolling)

[https://doc.qt.io/qt-5/qscroller.html](https://doc.qt.io/qt-5/qscroller.html)

Why it's not working on your applications is a different question.

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

~~~
zapzupnz
Indeed. Although, some of the things that Apple's ObjC Foundation provides
that aren't in Swift's cross-platform Foundation are sorely missed — but I
doubt there's much impetus to put them in Swift's cross-platform Foundation,
either.

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

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

------
iamcreasy
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
Quick answer: no.

~~~
iamcreasy
Could you please explain why?

~~~
RussianCow
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
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
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)

~~~
blondin
> OpenGL isn't relevant here

oh nice, i had no idea SDL had metal support!

no one in the SDL developer community tells you how to support metal or how to
use it. instructions for MacOSX redirects you to another library, which has
since removed their instructions.

who exactly are we kidding here?

~~~
pjmlp
The whole point of using SDL is that the framework takes care of it for you.

Here,

[https://wiki.libsdl.org/SDL_SetHint?highlight=%28%5CbCategor...](https://wiki.libsdl.org/SDL_SetHint?highlight=%28%5CbCategoryAPI%5Cb%29%7C%28SDLFunctionTemplate%29)

[https://wiki.libsdl.org/SDL_HINT_RENDER_DRIVER](https://wiki.libsdl.org/SDL_HINT_RENDER_DRIVER)

And after a 5 minute search,

[https://gist.github.com/gcatlin/b89e0efed78dd91364609ca4095d...](https://gist.github.com/gcatlin/b89e0efed78dd91364609ca4095da346)

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

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

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

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

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

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

------
andrewrothman
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
Windows switching to the Linux kernel would be wild, but I think we all know
it's coming.

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

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

------
forrestthewoods
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?

~~~
Eric_WVGG
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
Paul Hudson is the best, along with Ray Wenderlich’s stuff.

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

------
awinter-py
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
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-
dict...](https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-
of-the-small-minority-3f1f83ce4e15)

~~~
saagarjha
> 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?

------
ww520
This is excellent news.

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

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

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

