Post not yet marked as solved
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
Post not yet marked as solved
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.
This was due to an iOS bug which turns widgets black if image is "too large." See https://developer.apple.com/forums/thread/710745
Post not yet marked as solved
This is still a problem on iOS15.5, at least in the sandbox.
Post not yet marked as solved
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?
Post not yet marked as solved
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.
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
Post not yet marked as solved
I can confirm that this bug still occurs and that Chris's solution works. Just to spell it out a bit more, the solution is:
Add the App Groups entitlement to your app
Add a "groups.<your identifier>" sharedContainerIdentifier to your URLSession config.
Post not yet marked as solved
Interesting idea, @Claude31, but it doesn't work. If you remove leading/trailing constraints it just breaks the layout. The ReadableContentGuide is a layout guide that you're supposed to attach constraints to.
Post not yet marked as solved
Answering my own question here: my confusion was that in the "Prepare for submission" section where you have to add IAPs to this version, none of my IAPs were available to add. That's because they were already added. All I needed to do was "Submit for review" again, but because I couldn't see the IAPs that I needed, I was afraid to do so.
