Thank you for your response. I eventually found an alternative solution at  https://bitbucket.org/blog/deprecating-atlassian-account-password-for-bitbucket-api-and-git-activity. Essentially, all I needed to do was to create an app password and enter it into the Xcode account for the Bitbucket repository. This seems to be the least disruptive solution, but I was unable to find it during my first search into the Bitbucket literature.

We are in the same position. After several months of wrangling with App Store Review, we finally had our app (with IAPs) approved in January. We recently submitted an update (without any changes to StoreKit functionality), which was rejected for the same reason. Fortunately, we had some instrumentation which pointed explicitly to a failure to refresh the receipt. In retrospect, it seems that our initial success was a stroke of luck. (1) I agree with zixtix. There is no consistency in the reviewers' process. Furthermore, they offer no explanation on their specific actions (e.g., did they press the Cancel button on the sign-in dialog?). This type of information would be greatly helpful. (2) If I hadn't found this Forum thread, we would still be stuck. Apple needs to present these requirements more prominently in the overall Human Interface guidelines. (3) As an independent developer, my primary job should be to bring my client's vision to reality, not navigate the arcane details of the App Store. Over the past 2 years (yes, on this single project) I have read through scores of tutorials, documents and threads to piece together a basic understanding of StoreKit and how to use it. It would be tremendous if Apple would provide a single source for everything relating to the App Store. (4) Having to insert a considerable amount of code, simply to pass App Store Review, seems a waste of any developer's time (and client's money).

I've received the same error, but related to 'com.app.developer.icloud-container-identifiers', even though I haven't touched iCloud in over a year. So I think that the problem is more general than HealthKit.

I saw this identical problem on App Store Connect from my Macbook Pro (Catalina) and Safari. When I logged in from my Windows PC and Edge, everything was displayed correctly. I can't see the logic to this, since both browsers are presumably simply displaying an HTML page.

I hope that this thread is still monitored, and that someone can provide a bit of guidance. Our app uses two separate auto-renewable subscriptions (monthly/yearly). We have submitted it twice for review. Each time the app has failed to load the subscriptions successfully, and the review has failed. The app has worked consistently for months in Sandbox/TestFlight. Note: All of our contracts with Apple are in place and current. We have an additional concern about submitting this app and subscriptions: Since our organization is still scaling up the back-end (mostly personnel, rather than servers), we cannot yet release the app to the general App Store public. Nevertheless, we need to have it reviewed as soon as possible so that any pending deficiencies won't delay our overall product release. Therefore, we set the Version Release option to “Manually release this version”. One additional possible complication is that the app decrypts and verifies the receipt on-device, rather than through the App Store. We don't believe that will interfere with the process, but someone might have a better understanding. Here is our dilemma: Our understanding of Rich Kubota's post (above) is that the subscriptions will not be available to the App Store until the app is released. However, the app cannot be reviewed and accepted unless the subscriptions are in place. So we have a couple questions: (1) Is it even possible to submit both the app and the subscriptions concurrently? (2) Does our decision to release the app manually render the review impossible? If we cannot submit the app and subscriptions together for manual release, how can we have the app reviewed? In our case, the app will display only a blank screen until the subscriptions are activated. We would need to rearchitect the app significantly to submit a viable product without subscriptions. At the moment, we can envision only the following scenario for approving our app: (1) Create a free app version which loads and runs without IAP subscriptions. (2) Submit this version for immediate release and wait for App Store approval. (3) Once the version is approved, create new IAP subscriptions on App Store Connect. (4) Wait 48 hours for the subscriptions to be available. (5) Submit the real (original) app as an update to the App Store. Hopefully, this time the subscriptions will be available, the app will load and run, and the App Store will approve it. Has anyone had a similar situation? Our concern here is that the free version of the app will be publicly available for several days.