@Transpais I submitted a tech support incident request, will update with more info

Got an answer back from Apple support and it did solve the problem: Based on your request Apple Developer Technical Support believes that your question is answered by the "Xcode Release Notes: Xcode 13 Release Notes" linked here: https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-notes Specifically: Swift libraries depending on Combine may fail to build for targets including armv7 and i386 architectures. (82183186, 82189214) Workaround: Use an updated version of the library that isn’t impacted (if available) or remove armv7 and i386 support (for example, increase the deployment target of the library to iOS 11 or higher). In my case, I addressed this by installing a local version of the package and then bumping the swift-tools-version in Package.swift to 5.5. This info came in very handy: https://developer.apple.com/documentation/swift_packages/editing_a_package_dependency_as_a_local_package

Slightly different issue, but my Xcode simply spins on "Resolving package graph" and won't do anything else. If I try to close it, I get the rainbow ball of death. The fix was to delete the DerivedData dir of the project it was trying to resolve.

For me, the issue came back ... deleting DerivedData did not fix it. However, I noticed that waiting a while (eg., 1 hr) the problem resolved itself. That suggests that Xcode may be doing some caching that causes the problem and once the cache is stale the problem resolves.

If it doesn't get approved, I suggest you ask for a phone call with a human reviewer. Mine was eventually approved and I actually received a phone call and an apology from Apple. The person I spoke with is the one who told me about asking for a live phone call.

I had an exchange with an Apple StoreKit evangelist, and he confirmed that the best approach is a generic "single course" subscription. Here's what he had to say: We refer to this as a generic sku configuration. creating a sku per course after a dozen+ is just a mess to manage, so generic is the way to go now and with your future plans. So with the generic “single course” sub, you’ll manage this single “slot” to fill it with 1 course at time. Up to your business policy on how you manage swapping new courses in/out. Ie: 1 swap per week/month, etc. The course to sub assignment is 100% with the developer, so this “course swap/manage” experience and policy will be managed by your app and off platform if applicable. The mapping of the customers purchase is using the original transaction ID to the assigned course. And change that mapping per their business policy. If product ID changes to unlimited then the course mapping won’t apply. Tougher part is when downgrading from unlimited to single, what is that experience. Automatically choose whatever they access next or does it prompt the customer?

I had a breakthrough after reading @Scott's comment. It sure was behaving as if the compiler thought it was an actor. As a test, I removed the private restriction on the singleton's initializer and tried to initialize it. I got a very revealing error: func testAsync() async -> String { let app = App() // ERROR: Calls to initializer 'init()' from outside of its actor context are implicitly asynchronous ... async stuff here ... return result } Well, it turns out that App is a UISplitViewControllerDelegate and that protocol is a @MainActor! If I remove the protocol from its definition the errors go away. Is this correct behavior? I tried, but haven't been able to re-create the issue in a simple test case. In any case, thanks @eskimo and @Scott for helping me clear this up!

This is still a problem on iOS15.5, at least in the sandbox.

This was due to an iOS bug which turns widgets black if image is "too large." See https://developer.apple.com/forums/thread/710745

Four years later, I would also like an answer to this. We want to be able to put future releases into TestFlight w/o messing up our actual release version number.

Filed bug FB13079231

The non-obvious thing that's catching you here is that your task is running on the main actor (automatic with any UIViewController or NSViewController). To put work onto a background queue from the main actor, use Task.detached.

Most useful thread I have found on this issue: Swift Forums: How to prevent resolve packages from stymying developer productivity

After more experimentation (including a stab at using Carthage), I hit upon a wonderful solution to this problem. My steps for adding dependencies are now: Clone the repo into local package_dependencies folder Check out the specific release (tag) Under Xcode's Package Dependencies tab, hit the + sign and select "Add local". Select the folder containing the repo In the confirmation dialog, select the appropriate target This works great, fetching and verifying takes only a few seconds (and doesn't re-verify every single package every time!), and I have yet to encounter flaky errors. (Fingers crossed!) The only downside is that Package.resolved doesn't record specific versions anymore. That's unfortunate but the benefits completely outweigh the loss.

I wrote a simple post-checkout git hook to capture the currently checked out tag: #!/bin/sh # Get the repository name repo_name=$(basename `git rev-parse --show-toplevel`) # Get the current tag current_tag=$(git describe --tags --exact-match 2> /dev/null) # If there is a current tag if [ $? -eq 0 ]; then echo "$repo_name: $current_tag" >> ../PackageDependencies.history else echo "WARNING: Ignoring post-checkout hook, no tag found" fi