[simonh]

For me the takeaway is that Apple is _really_ serious about supporting the use of Swift outside their own ecosystem. After all XCode won't be using this, at least for a while, so clearly it's aimed at making it easier to use Swift outside their own tool chain.

[pjmlp]

Nah, Swift still does not support Windows on their official builds.

[simonh]

Fair point, but nobody’s writing backend software to support iOS apps on Windows servers so not something Apple cares about.

But then backends for iOS apps are part of Apples ecosystem, if peripherally, so I stand corrected.

[pjmlp]

Nor anyone is writing anything big in Swift on GNU/Linux, which even with builds available, is still pretty much WIP.

Vapor, Perfect, and Kitura are no match for the offerings in Java, .NET, Go, OCaml, Haskell, Erlang.

[simonh]

Of course, but then comparatively few people are writing iOS apps in Swift either. It's still a very young and still evolving language ecosystem, so building out the tooling around it is incredibly important in order to support it's growth.

[cm2187]

It seems to be a very un-Apple thing to do. Do you know why they would want to push it?

[wlesieutre]

Get more people using Swift serverside perhaps?

I can imagine that having a swift backend for your swift mobile app would be a lot nicer to work with than converting back and forth from a bunch of stringly-typed JSON.

[kitsunesoba]

Yes, this is it precisely. Swift already has decent momentum for serverside usage with Vapor, Perfect, and Kitura among others. By adding LSP support, Apple is adding to that momentum and pushing it closer to critical mass.

[MR4D]

I'd love to use Swift on the backend, but I don't want to use XCode.

I only develop part-time, as my main job is financial in nature, but god, it is really hard to find good learning material for serverside without depending on XCode. In particular, learning the server frameworks is almost not worth it. By using one language, I can keep my productivity acceptable.

If anyone has any references, I'd be super thankful!

[flafla2]

> stringly-typed JSON

Off topic but I love this, definitely stealing it. Did you coin this?

[alexjm]

I learned this term from a 2012 blog post, which summarized a (now deleted) Stack Overflow question:

https://blog.codinghorror.com/new-programming-jargon/

My other favorite from that list is "baklava code" -- code that has too many layers.

[flafla2]

This is great, thanks!

[aaaaaaaaaab]

As the bald guy said: "Developers, developers, developers"

[intrasight]

Now if they'd only let me compile my iOS app on Linux ;)

[21]

What if this is because a lot of internal Apple developers are using VSCode instead of XCode, and they wanted better support?

[kitsunesoba]

Not impossible, but unlikely. For Mac, iOS, tvOS, and watchOS projects at Apple, Objective-C is still the dominant language due to all pre-existing projects being written in it. Swift is used in a few places — most notably the macOS Dock has been written in Swift for at least a couple of iterations now — but bulk adoption won’t come about until Swift achieves ABI stability with version 5.

[saagarjha]

> the macOS Dock has been written in Swift for at least a couple of iterations now

Dock is only partially written in Swift. A significant portion is still Objective-C.

[pjmlp]

That isn't what they announced at WWDC 2017, during the state of the union.

[saagarjha]

When did they mention this? I can't find this in the video.

[pjmlp]

Wrong year and video.

It was during WWDC 2016, "What's New in Swift" session.

https://developer.apple.com/videos/play/wwdc2016/402/

From the transcript. More on the video.

"I want to talk about a particular case study, and that's the Dock. And the Dock is interesting for two reasons. The first reason is it's a lot more than people think. It's not just the bar at the bottom of your desktop. It's actually a large amount of the macOS Windows, you know, management experience. So things like Mission Control, LaunchPad, Spaces, this is all what we consider part of the Dock. The second reason why Dock is interesting is it's actually been a Swift adopter for two releases. It started adopting Swift in El Capitan. So we have two releases to look at and to compare in how it was using Swift. So a lot of changes happened to the Dock in Sierra. First, almost all of Mission Control was rewritten in Swift, and the accessibility engine was rewritten in Swift. Why did we do this? We just didn't rewrite code just for the sake of rewriting code. The code had kind of grown organically over time as features had been added and it was time to refactor it. But also some new functionality needed to be implemented, and so it was the appropriate time to make this, you know, to do this rewrite. Now, what does this look like at the project level? So to give you an idea, Dock is about 200,000 lines of code with tens of thousands of lines written in Swift. And between El Capitan and Sierra, the amount of Swift code in the project more than doubled. And this actually, because this is part of a rewrite, this replaced a significant amount of C and Objective-C code. And the effects here are somewhat non-linear, because there's some refactoring and some new features being added, but we saw there was about 15 percent less code to replace the existing C and Objective-C code in Swift, and this is with new features being added at the same time. And the net result is this project is actually slightly smaller in Sierra than it was in El Capitan. Now, there's a lot you can read into statistics. I think the most important thing here is the engineers working on the Dock love using Swift. They are not mandated to use it. They volunteered."

So one would expect that during the last two years, the amount of Swift code has only increased, specially with the tiny spot Objective-C now gets at WWDC.