Finally figured it out: in Pricing and Availability, you have to make the app unavailable everywhere. Only then can you remove it.

Still happening in 2024: iPhone Xr iOS 17.4.1 Xcode 15.2 ==1907==Unable to find a memory range for dynamic shadow. ==1907==space_size = 0x00006b003fff, largest_gap_found = 0x000066a00000, max_occupied_addr = 0x007000000000, new_max_vm = 0x000335000000 AddressSanitizer: CHECK failed: sanitizer_mac.cpp:1279 "((0 && "cannot place shadow")) != (0)" (0x0, 0x0) (tid=589858) <empty stack> AddressSanitizer report breakpoint hit. Use 'thread info -s' to get extended information about the report. (lldb) thread info -s thread #1: tid = 0x90022, 0x0000000104ee91dc libclang_rt.asan_ios_dynamic.dylib`__asan::AsanDie()

It could be that your privacy manifest is in the wrong place. It must be in the root folder of your app bundle. You can check to see whether Xcode is finding the manifest by generating your own privacy report. I originally had mine nested one folder down, and the generated report was empty. When I moved it to the root, the report had the privacy data.

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

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.

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

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.

Filed bug FB13079231

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.

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

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

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!

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?

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.

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.