Cannot archive build on Xcode 13 beta 3

[d-date]

Describe the bug

When running archive build on Xcode 13 beta 3, the build fail since it depends on Combine.framework built by different compiler version.

Failed to build module 'Combine'; this SDK is not supported by the compiler (the SDK is built with 'Apple Swift version 5.5 (swiftlang-1300.0.24.14 clang-1300.0.25.10)', while this compiler is 'Apple Swift version 5.5 (swiftlang-1300.0.24.13 clang-1300.0.25.10)'). Please select a toolchain which matches the SDK.

Screenshots

Environment

• Xcode 13 beta 3
• Swift 5.5

[stephencelis]

Hi @d-date! I'm able to successfully build a project that depends on CombineSchedulers in beta 3. The error message you posted makes it sound like you have a custom toolchain selected in Xcode. Can you check the "Xcode > Toolchains" menu and verify that "Xcode 13.0" is selected?

The only other thing I can think of is maybe you have some stale build products getting in the way. "Product > Clean Build Folder" could help, or you could try fully deleting the Derived Data folder.

[d-date]

@stephencelis
Did you succeed in the Archive, right?
I'm able to build and run, but archive has failed.

As you say, I checked that Xcode 13 was selected as the toolchain. I also tried a clean build, but didn't change.

[kamcma]

I am also seeing this error. Although to start I am suspecting beta 3 or maybe something about my workspace configuration more than combine-schedulers per se.

I don't think I have any alternative toolchains installed. (The toolchain items don't even appear in the Xcode menu or Preferences > Components.) Deleted derived data. M1 Mac, if it matters.

[kamcma]

Seems to be the same issue:

https://developer.apple.com/forums/thread/682285?answerId=682006022#682006022

[mbrandonw]

😢 oof, good to know.

I'm going to covert this to a discussion since it's not really a CombineSchedulers issue and so that we can continue sharing information about it.

[tgrapperon]

I also had the issue while trying to profile a TCA iOS15 only app with Xcode 13b3. I've added platform availability in a local copy of Package.swift and it solved the issue:

// swift-tools-version:5.1

import PackageDescription

let package = Package(
  name: "combine-schedulers",
  platforms: [
    .iOS(.v13),
    .macOS(.v10_15),
    .tvOS(.v13),
    .watchOS(.v6),
  ],
  products: [...

[schneiderandre]

Unfortunately, the issue is still present in Xcode 13 beta 4, but Apple is already aware of the issue.

Since SPM does currently not allow to replace a specific sub-dependency with a fork, I for now forked:

• https://github.com/pointfreeco/combine-schedulers, changed the package platforms information to

.platforms: [
    .iOS(.v12),
    .macOS(.v10_14),
    .tvOS(.v12),
    .watchOS(.v5)
  ]

and replaced the sub dependency in the package in a fork of:

• http://github.com/pointfreeco/swift-composable-architecture

While this is not optimal, it is at least a functioning workaround for now, locally and on the CI.
I am unsure if we should directly have a branch with this temporary fix in both main repositories to make it easier for others or wait and assume that the next beta will address the issue.

[maximkrouk]

@mycroftcanner, do you use the package as a part of another package or as a part of an xcodeproj?

[mycroftcanner]

I have a big Packages.swift similar to the one in is-words.

[mycroftcanner]

Specifying 0.5.1 doesn't help

[mbrandonw]

Is there anyway to fix this besides forking all the packages? Profiling and archiving is broken.

@mycroftcanner Do you know of a fix for this issue? What would you do in the forked packages? We're definitely interested in fixing this issue, we're just not sure what the solution is.

[tgrapperon]

@mbrandonw Specifying platforms in Package.swift seems to fix the issue. Maybe TCA can temporarily rely on a branch of combine-schedulers with this addition until it's resolved by Apple?
It seems to affect packages that are importing Combine, like Alamofire, GRDB or Realm.

[tgrapperon]

I've asked why the "platforms" field had to be removed, but then read the original PR, understood the reason, and deleted my question. Unfortunately, @maximkrouk had already responded. Here is the response: Nope, but it can be a part of the app that does support iOS13- and uses it just for iOS13+ features and you won't be able to use it at all if the platform is defined by the package (at least if an app or framework use spm-based modularization) Anyway it seems like an SPM bug and I have something strange here too https://github.com/MakeupStudio/cocoa-aliases/blob/main/Sources/CocoaAliases/CocoaAlisaes.swift (when building in release mode the compiler cannot find UIViewRepresentable)

[maximkrouk]

I couldn't find your comment, so I deleted the reply too 😅

[stephencelis]

Sounds like we should revert the platform removal to work around this bug. Does that make sense to you @maximkrouk?

[maximkrouk]

Yep

1. Seems like it is the only workaround for now
2. The bug will probably affect me too when migrating to XCode 13 and packages that I currently make (combine-schedulers -> combine-extensions -> combine-cocoa -> swift-extensions -> composable-architecture-extensions) are private (no one depends on them yet, even I) and probably they will suffer from the bug too, so I'll have to add platforms to use them
3. It will be pretty easy to remove platforms when the bug is fixed

[stephencelis]

We just published 0.5.2, which will hopefully resolve the issue.

[nmccann]

@stephencelis 0.5.2 seems to have resolved the previous issues mentioned in this discussion, however I'm still encountering archiving issues on Xcode 13 Beta 5 - specifically: SourcePackages/checkouts/combine-schedulers/Sources/CombineSchedulers/FailingScheduler.swift:77:5: cannot find 'XCTFail' in scope

In my Google searching for the issue, I also found this possibly related solution: https://github.com/groue/CombineExpectations/pull/15/files

[stephencelis]

@nmccann You may need to bump XCTestDynamicOverlay, too. What version are you on?

[nmccann]

@stephencelis I think you're correct - looking at my Package.resolved, I'm on 0.1.0, not the latest (0.2.1) - I'll ensure those are updated and try it again. Thank you for the quick response.

[nmccann]

Resolving the latest versions resolved my issue, thanks again!