Swift concurrency back deployment

Evolution Discussion
21

totally reasonable price, i'm buying.

1 Like
22

Does this have any impact when running the same binary on macOS 12 or later, or are the bundled libraries ignored there?

1 Like
23

This is amazing news. Huge thanks to everyone involved! :pray:

A couple of questions:

Same for iOS. Will the App Store strip the concurrency library when downloading our app on iOS 15? or do iOS 15 users have to pay the price too?

  1. Does this mean that old OSs won't have the memory corruption issues since the embeded library will have the fixes already?
1 Like
24

I'm really happy to hear this! Thank you everyone for making this possible!

1 Like
25

Thanks for everyone involved in making this happen for all the hard work. Much appreciated!

1 Like
26

Thank you so much! What a great day!

27

The bundled concurrency library will be ignored in favor of the OS runtime on newer OSes, similar to how the core Swift runtime libraries work for back-deployed Swift apps.

18 Likes
28

It'll get stripped out.

Most of those fixes were in the compiler, not the concurrency runtime. But yes, the embedded concurrency library has addressed all known runtime issues.

Doug

24 Likes
29

Great news! Thanks for all the hard work from everyone who made it happen.

It looks like Xcode's builtin-swiftStdLibTool copies the concurrency runtime using a new --back-deploy-swift-concurrency flag that the standalone executable in XcodeDefault.xctoolchain/usr/bin/swift-stdlib-tool doesn't support (and the source code for that tool on GitHub was last updated 2 years ago). That tool is critical for other build systems like Bazel to bundle the Swift runtime the same way as Xcode does—is there any chance the source code could be updated (and more importantly, the binary in Xcode updated to match)?

(I also filed FB9727485 since what goes into Xcode is usually out of scope for Swift forum discussions.)

13 Likes
30

Please report your findings!

(This question is important for library maintainers, Can we ship code that supports Xcode 12, 13.0, 13.1 and 13.2 or not? And if yes, will it ruin our code base?)

31

If you're okay limiting your concurrency support to Xcode 13.2 or greater, you can use #if compiler(>=5.5.2) rather than #if swift(>=5.5) to limit your APIs. However, there doesn't seem to be a way to conditionalize the availability checks. That said, the Concurrency types are now properly available back to the earlier OSes, but the various framework extensions, like URLSession's async request methods, are not.

5 Likes
32

I guess I'll be OK with this for GRDB. Do you already have a plan for Alamofire?

33

Just wanted to say thank you for all involved in making this happen. You not only listened to the community but delivered the feature in light speed. You guys are stars!

3 Likes
35

I’m not saying they’re not rockstars (they are!) but I don’t think this was a situation where they folded to community pressure, but rather one where a feature took longer to develop than hoped and they couldn’t promise it and be wrong without losing a lot of goodwill with the community. They could however not promise it and still deliver it later and then release it to (well-deserved) cheers.

7 Likes
36

Thank you for bringing this up, Tony! I hadn't realized that this tool was in use anywhere. Yes, we can get this tool updated to support the new flag... unless some eager contributor gets a pull request up first ;)

Doug

11 Likes
37

Hello, How can I test back deployment on a pre-iOS 15 simulator with Xcode 13.2 beta?

My attempts with iOS 13.7 and 14.5 have failed so far. The test is not executed, and the console contains the following message:

skipped: Test is unavailable since it uses features not supported by this OS version

The test reads:

#if compiler(>=5.5.2)
func testSomeAsyncStuff() async throws {
    guard #available(macOS 10.15, iOS 13, tvOS 13, watchOS 6, *) else {
        throw XCTSkip("Swift concurrency is not available")
    }
    ...
}

This alternative form does not help:

#if compiler(>=5.5.2)
@available(macOS 10.15, iOS 13, tvOS 13, watchOS 6, *)
func testSomeAsyncStuff() async throws {
    ...
}

EDIT: adding -lswiftCompatibilityConcurrency to OTHER_LDFLAGS in the test target (inspired from the Xcode 13.2 beta release notes, does not help.

38

@Douglas_Gregor @allevato here's a pass at updating swift-stdlib-tool for this [swift-stdlib-tool] Add support for back deployed concurrency by keith · Pull Request #39996 · apple/swift · GitHub

2 Likes
39

I've found that if a test method name contains the word "Async" it will be skipped :grinning: But async test methods work fine.

40

Thanks for the tip! Renaming test methods did not fix the issue. I still read "skipped: Test is unavailable since it uses features not supported by this OS version" in the console when I attempt at using the concurrency backport on pre-iOS 15 simulators.

I discovered since that:

  • The logged message is absent from https://github.com/apple/swift-corelibs-xctest: it is specific to Xcode.
  • Individual async tests run when I click in Xcode on the icon next to the test method.
  • Individual async tests run when xcodebuild is given the -only-testing option.

In all other setups, the async tests won't run. I'm currently comparing xcodebuild outputs: maybe I'll find a workaround. Maybe @Douglas_Gregor can share his knowledge as well?

41

I can't see anything is the xcodebuild logs, anything that could hint at why the tests are skipped. I made a project that demonstrates the issue: GitHub - groue/AsyncLib: Is it possible to test Swift concurrency on pre-iOS15 simulators?, and opened the ticket FB9733674.

2 Likes