Thanks @Claude31. Yes, I would use groups for varieties and dishes. But I don't think you understood my question. The groups only handle layout. The issue is having to flatten the data source bc index path only has section + item.

If we let each fruit be its own section, and look at it through the lens of IndexPath:Number of sections: fruitArray.countNumber of rows (items) in "apple" section: appleVarieties.count + appleDishes.countThe flattening is that we had to treat varieties and dishes as if in same array.But maybe my problem is just that I'm still thinking in terms of IndexPath and now diffable data sources are organized in terms of identifiers. I need to play with that some more and maybe this whole issue goes away...

I must not be explaining myself very well... it's not that I can't manage my array indexes. Anyway, thank you so much for trying! I'm going to play with this some more ...

If I were coding this the "usual" way, I would design a cell that had a title label and then had subviews that could contain variable numbers of images for varieties and dishes. When I designed my data source, it would have a single section; and one row for each type of fruit. And each type of fruit would map onto a single cell.But this new compositional layout approach is totally different. To take advantage of this, I can't design a single cell that will handle a fruit type. Instead, I'll have a cell that shows the title ("Apple", "Orange", etc.); a different cell type to handle a single variety (laid out in a group, with line-wrapping); and maybe another cell type to handle a single dish (laid out in another group).So I have three cell types, and I have to flatten all my data into one set of rows.After playing with this a bit, I realize that identifiers come to the rescue, you don't have to fuss with index path at all. But it still feels pretty odd.

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.

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.

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.

Restart Xcode works.

@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!