Linux and Xcode and Concurrency

I'm using Xcode 13 on MacOS 12 to develop a Mac client and a Raspberry Pi 4B sever. The RPi has the latest 64bit Bullseye release. The server code is contained in a Swift Package. I write the code in Xcode, then compile and run it on the RPi using Terminal.

I can add words like 'Task' and 'async' to the client code OK, but when I try to add these words to the server package I get the following errors...

"'Task' is only available in MacOS 12.0 or newer" and "Concurrency is only available in MacOS 12.0 or newer"

Now I know this this isn't true, because my server code will compile and run on the RPI just fine. Therefore, it would seem that Xcode couldn't care less about servers - unless there's a way to fool it.

I've found it extremely helpful to 'Build', but not 'Run', the server code in Xcode, prior to compiling on the RPi.

So my question is; how can I carry on using Xcode to edit code for a linux host?

The Xcode issue will likely be remedied by adding the following argument to your Package.swift:

platforms: [.macOS(.v12)],

This sets the minimum deployment target on macOS to 12. Without that argument, macOS compiles to deploy on older versions of macOS which do not support concurrency (you can also use @available to enable this for a particular function or class).


That said, I’m not sure working in Xcode is the best bet for you as you are compiling in an environment different from your target environment. You may run into issues like importing headers that are Apple only which are not available on Linux, and you will not be compiling code that is guarded by #if os(Linux).
I’d recommend you look into Visual Studio Code, which with some setup has pretty OK Swift support. You can use remote-over-ssh in VSCode to connect to the Raspberry Pi directly while still developing on macOS. I personally use VSCode’s devcontainer functionality to develop for Linux inside a docker container, which works pretty well for me.

1 Like

Doesn't matter whether it's server or client code, Xcode treats everything the same. It's just a front end to clang, swiftc, lldb, the linker, and other tools that you could actually use from the command line.

You might want to check the build settings for your server target and make sure the deployment target is set to macOS 12.0

You could try submitting an Apple Feedback ticket for this.

Technically, since a lot of Xcode's knowledge of Swift source comes from the compiler toolchain (highlighting, code completion, refactoring, etc), and the compiler is capable of cross-compiling, it should be possible to allow you to set the flags which tell Xcode's compiler-driven tools to use a different target platform (and some form of this surely already exists to support iOS/watchOS/tvOS development on a Mac).

It would enable a lot of workflows just like yours - library and server developers could download a pre-packaged Linux cross-compile toolchain and quickly test that their code builds on Linux, while editing and prototyping on their Macs in the familiar Xcode interface.

So it seems like a reasonable thing to ask for, but it's ultimately up to Apple's Xcode team. Send a Feedback.

George, thank you so much. "platforms: [.macOS(.v12)]," appears to do the trick.

Terms of Service

Privacy Policy

Cookie Policy