Apple is open sourcing Swift Build

Swift announced Linux support in 2015 when it went open source. Aspects of parity have taken years, and the Objective-C interop that isn't relevant outside Apple platforms but made adoption take off at all occupied a lot of early effort, but every Swift talk at FOSDEM today was about embedded or Linux server applications, or platform-agnostic C++ and Java interop. What can you possibly mean by "Mac only" or "bare minimum"?

> At this point it's a dying language.

I disagree.

Source: Someone who has been programming Apple since 1986, and has heard last rites being administered to Apple, many times.

Is it dying? I think it's still pretty popular for app development isn't it?

I was pretty excited to hear that Ladybird is doing a lot of stuff in Swift, because I think it's a pretty decent and fast language and I think it'd be pretty neat to see a browser written in it.

Lol, as long as it’s the preferred programming language for the most lucrative consumer devices ever, it cannot die.

Impossible to argue otherwise.

What language are you using to develop native apps for macOS and iOS and visionOS and watchOS, since Swift is dying?

There's a lot more buzz and activity around Swift than many other languages. It's literally up there with Rust, in terms of excitement (perhaps not quite as high). But I think if they get excitement outside of the Apple ecosystem, things should start to get super interesting.

Some are already adopting it like Ladybird browser.

trolling for reactions is trite and predictable

Come on now, iOS development is my livelihood.

No one uses Apple platforms - sent from my iPhone

Damned if you do, damned if you don’t. The perfect way to draw companies to embrace open source.

> I'm a bit confused about the "don't trust Apple" sentiment here.

Let me help you out; replace "Apple" with "Microsoft" and it will make a lot of sense suddenly.

The Open Source community has heard all this before. We've seen Sun Microsystems "generously" publish their Java spec to the public, we've seen Microsoft "give" their community C#. In the end, it's always more trouble than it's worth to cooperate with these language stewards and someone (either the business or community) ends up getting burned. I don't think many developers look at Swift with optimism that it won't end in the same Dotnet/Mono nightmare we've seen in the past.

You can lead a horse to water, but you can't make them drink. Apple has invested heavily in a language that, like C#, has a bunch of incredible features. Unfortunately they have yet to invest in the developer relations requisite for making such a language popular. Lord only knows that I'm not wasting my time to do Apple's work for them just to get a cross-platform app to compile with upstream LLVM and Clang. I could use any other language - nobody is going to commit to an ecosystem that treats them as a second-class citizen.

> people familiar with macos or ios development who want to write for other platforms.

This is a rather small userbase when it comes to enterprise.

Especially because Swift will never be as versatile as Python or as efficient as Rust.

And then there's also Go, C# and Kotlin with much better tooling.

That crowd has the disadvantage of not being primarily interested in the other platforms, so they won't be much invested in optimizing or better matching the target capabilities.

That's the same dynamic as web devs writing React Native apps: you won't expect them to contribute extensions that manipulate local apfs metadata for instance.

So while it's nice to have them use the tools, you still need people who primarily care for non Apple platform and embrance swift for their purpose to have it expand.

You mean like the huge ecosystem of libraries for almost anything one can thing of, and IDE tooling, with 30 years of experience in production?

I was using Swift before. Currently learning Rust. Want to use it for cross-platform UI, and I'm stuggling with exactly what you describe there.

So you haven't heard of Kotlin Multiplatform.

fwiw Swift still doesn't support mixed-language targets so the interop is somewhat less useful to me than I'd like: https://forums.swift.org/t/se-0403-package-manager-mixed-lan...

The creator of Rust also briefly worked on Swift

> but now it's just power-user-hostile and considerably more locked down and buggy.

Sure, macOS has continued to secure more and more elements of the OS. They have taken a different approach than Windows and Linux, which both keep large swaths of the OS woefully insecure from third-party apps for legacy reasons. But for each and every new lock, there is a key. An incredibly secure OS that gives you the power to control what third-party apps access on your computer is the best power-user feature.

> now it's just power-user-hostile and considerably more locked down and buggy

Hm, I've been using macOS (alongside others) for the past 20 years straight. In what ways is it hostile and buggy?

Kotlin is compiled in the sense that it compiles down to bytecode read by the JVM. It's not machine code level but it is still compiled to a certain degree. And Kotlin can compile natively for multiple targets including macOS and iOS without need for the JVM. There's also WASM support too.

this, because msft spent years and many $$$ to build an open-source ecosystem. apple hasn't done that yet, so I'm not sure why anyone would trust them

If you want to use Visual Studio Code the 'DevKit' extension which provides essential features (language server) is proprietary and requires a Visual Studio licence regardless of platform.

Also I find since C# is an 'enterprise' language developers take the p--s in what they want to charge for, as enterprise will pay as a 'cost of doing business'. Recently FluentAssertions, a freakin test assertion library decided they wanted to charge for newer versions. You don't get that in other languages like Python/Ruby etc.

https://youtu.be/ZFc6jcaM6Ms

Don't get me wrong, C# is my dayjob and I love the language but for personal projects where I don't have the money I'd be hesitant to touch it.

I used C# on .NET framework (the old .NET running only on Windows) 10 years ago at work. Then I had to use it 2 years ago again, and man, did it change! ASP.NET Minimal API is absolutely awesome, as the Generic Host integrating config, logging and DI is a great too. A very mature and complete framework.

It brings everything to the table a great modern language and ecosystem needs. Even null safety.

Regarding error handling, I don't have a strong opinion yet. I think Rust has nailed it, but C# (with unchecked exceptions) didn't create any issues in the projects I worked on.

Seems lovely but headed in a Scala-like bloated direction. The "too complex" type issues were really bad last I tried.

And one of my biggest gripes is the way you can extend things from anywhere else, easy to cause a mess.

I’ve spent some time looking into swift as well and was quite pleased with the overall language, it really contained some really good ideas. This makes it a bit of a shame that it is tied so closely to Apple

Scooby doo meme

<Open source contributor> “let’s see who you really are”. <pulls off mask>. Apple employee.

> All of which are detrimental to Apple because they force apps to adopt a lowest common denominator approach and not use the latest Apple technologies.

I think you might have this backwards. What you say used to be true back in the days of phonegap, where the hardware was abstracted far away, but all of the frameworks you mention provide pretty easy paths to access new APIs and hardware features. But companies that are drawn to cross-platform tooling already want a uniform experience across devices - and that's why you get the lowest common denominator being used with tools like react native.

Xcode as an example of quality? It's atrocious from my experience.

Updates tied to OS and crashes more than it should.

> Maybe the friendly default would be to have the symbolicated reports on

As a comment just below says, the solution is quite simple:

> ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it

The goal is to probably avoid duplicating efforts when llvm-symbolize already exists.

There’s obviously a snarky comment to make here about Go developers and duplicating efforts.

I don't know, I write Swift on a Mac targeting macOS or iOS. I usually have Xcode open to build/run/debug and for documentation lookup, and alternate between that and VSCode for actually writing the code; worst thing about Xcode for me is the find-replace, that's probably the biggest reason I keep VSCode open.

You can load the coredump into GDB.

At least the jetbrains ide exists for all major platforms.

That's a good point. I had in mind that there's some regret about the combination of type inference with type-based overloads, due to the search expense it adds to what ought to be straightforward parsing of long expressions.

Swift Package Manager exists

Cocoapods has been end of life’d

Miguel has long left Microsoft and nowadays focus on Apple ecosystem, and Godot.

He also voiced back on twitter his disapproval on how Xamarin.Forms became MAUI.

Microsoft had a research version of the CLR called Rotor (2002) that predated Mono (2004). Rotor built for Windows, FreeBSD, and macOs, albeit with a not-very-open license.

When Mono came along, the internal position at Microsoft was surprisingly positive. There was a dev slide deck that went into Mono in some depth. And a telling slide that said it wasn't a threat because the performance wasn't competitive at the time.

https://en.m.wikipedia.org/wiki/Shared_Source_Common_Languag...

https://en.m.wikipedia.org/wiki/Mono_(software)

He is deep into Swift/SwiftUI now

What don’t you like about the VSCode plugin?

Building Swift code for iOS without going through xcodebuild is sort of obnoxious but is possible. You do need to have a copy of Xcode installed regardless of programming language simply because the iOS SDKs aren't distributed separately.

Hence this announcement is great, since it seems to say they’re (going to?) support building GUI apps with SwiftPM and/or the newly open sourced build tool.

But you cannot run the product on an iDevice and a build for Mac Catalyst isn't even possible. “Bundled with Xcode” is very much necessary.

Isn't that their complaint though? They don't want to participate in a language where they can only ever be a second class citizen.

I can run the latest version of my OS of choice on hardware twice that old.

This is only a problem that Apple has created to help them sell hardware. These days, a 6-year-old laptop is still a perfectly capable machine.

> how is this different from for example Rust, Go, Zig or Python

I believe op means Swift is different because Apple is the gatekeeper at the top of the Swift project https://www.swift.org/community/#project-lead

By contrast, other open languages usually have elected leadership and aren’t directly subject to a specific corporation.

> About control - serious question: how is this different from for example Rust, Go, Zig or Python?

You can ask Chris Lattner about how many many changes were forced through the language before they were ready, or even properly designed, because Apple needed them: https://www.youtube.com/watch?v=ovYbgbrQ-v8

Basically, if companies who created language dump it on Github and let open source community take over it is nonviable. Because who will pay for project development that these mega corps dumped on community and washed their hands off.

On the other hand if companies take ownership, provide financing, design, vision, evolution of language, compiler, libraries and ecosystem etc it is nonviable because it is dictatorship now.

Solution is to let drive by commentators to have full commit rights on open source repositories if they want to change any part of language. Anything less unacceptable.

You’re only focusing on access to source code, the comment is about leadership and decision making. Remember the OmniSharp story around VSCode from just two years ago? It’s a very high profile example of what can (and eventually will) happen with corporate-controlled projects.

Swift can’t evolve or even exist without Apple and so unless you’re Apple, then Swift is too great of a risk.

Encountering an Apple employee on HN is like finding a Papa John's employee in the food court.

Tim is a unicorn.

For the most part, yes, it should be very achievable. Embedded Swift basically just produces an object file that looks like any object file from a C compiler. The objects mostly rely on very basic primitives like malloc/memcpy so it's pretty freestanding (you can turn off allocations, too). It also has very good support for importing C headers into Swift code so you can interop easily.

Probably the biggest roadbump for something like FreeRTOS is the asynchronous support though. Embedded Swift's async support is still extremely rudimentary and I didn't find much about how to extend it/attach it to other control loops. I think it only supports single-threaded execution right now as well.

If you look at the blinking LED sample, it's pulling in the freertos header:

  #include "freertos/FreeRTOS.h"

Why should it not, one of the design goals of Swift as C, Objective-C and C++ replacement was painless interop with those languages.

Thus it is more an issue of Swift embedded toolchain being able to be used alongside FreeRTOS on the specific hardware target.

Agreed. It's not like they didn't have enough time to fix it either. And they seem semi-capable of creating usable UI's elsewhere.

The thing is, when it comes to applications, both Apple and Microsoft compete with their own customers; which makes a pretty solid motivation for providing shitty developer experiences.

Did something happen with Xcode? I used it around 5 years ago, and it was pretty good and fast. I don't think it had dark mode but that's not too important to me.

Distro packaging for programming language ecosystems is so often hopelessly out of date. I’ve never used a distro toolchain or packages to build production software for any language Python’s age or younger.

Outside of C/C++/Fortran pretty much every project I see on Github prefers things like Rustup or Nix for toolchains to navigate around Debian/Ubuntu/RHEL’s “stability” approach.

Working on it: https://github.com/swiftlang/swiftly?tab=readme-ov-file

I remember when all Linux projects used to be install a source tarball and do the configure, make config, make, make install dance.

That hasn't prevented Linux to take over most UNIX workloads.

Go has been shipping for more than a decade as a .tgz and does not have this stigma at all ...

Anyway, you probably missed the following

https://www.swift.org/install/linux/

I see packages for all major distros there.

But people will probably mention some distro not listed and say the mainstream distro support is a farce. For some reason people have set the bar for Swift incredibly unrealistically high and there will always be something wrong it.

Your loss though. Swift is amazing. Both on MacOS and Linux.