“Account Locked”

A few brief clarifications and comments: I am seeking clarification on whether the various driverkit entitlement families (com.apple.developer.driverkit.family.*) are available for development on my local Mac without requesting entitlements from Apple. Making the more explicit, they Development Only entitlement variants do two things: They match against a VERY broad hardware configuration, basically letting you match any hardware. Their ONLY available to Development signed builds. Note that the second criteria heavily restricts distribution, as development builds will ONLY run on machines which were registered with your developer account at the point the signing profile was generated. This is largely invisible when using automatic signing (Xcode will just generate a new profile), but can be easy to overlook with manual signing. At WWDC2022 Apple stated that In MacOS... In fact, all DriverKit family entitlements are now available to use for development. On these very forums, Eskimo himself also sugges

Quinn is helping this, which is great. I am just curious if the com.apple.developer.icloud- is really com.apple.developer.icloud-container-identifiers. I am guessing that the provisioning profile on your machine, either your notebook or Mac Mini, is not up to date, which leads to the different behaviors. Maybe you can try the following: Be sure your developer account is correctly set up in Xcode Settings > Apple Accounts, and your Mac has the access Apple's developer portal. Uncheck the Automatically manage signing box, and check it back. This tells Xcode to refresh the provisioning profile. If that doesn't help, try to remove the iCloud capability – You are not using any iCloud feature, and so don't really need the capability just yet. If you do need the iCloud capability, check one of the services, and pick an iCloud container if the service you checked is iCloud Documents or CloudKit. This is how folks use the capability. If everything goes well, the .entitlements file in your project

Similar situation. First time app, macOS and iOS versions, no login, no account, no server - just plain SwiftData, CloudKit, and one in-app purchase to unlock lifetime access. TestFlight: macOS build: submitted Feb 09, 2026 -> approved Feb 11, 2026 iOS build: submitted Feb 09, 2026 -> waiting -> re-submitted by incrementing build number Feb 18, 2026 -> still waiting, status on Mar 12, 2026: 'Waiting for Review' In-app purchase: didn't require submission I got enough feedback from my macOS beta testing that I decided to go ahead with the final app approval submission. Production: macOS build: submitted Mar 06, 2026 -> approved Mar 09, 2026 iOS build: submitted Mar 06, 2026 -> still waiting, status on Mar 12, 2026: 'Waiting for Review' In-app purchase: status on Mar 12, 2026: 'In Review' Without the IAP approval, it doesn't even make sense to announce my macOS release to my network because the app will just lock up after 14 days if they're unable to purchase. Why are things h

Hi Tigerio, It is not possible to delete containers, but team admins can hide and unhide them in the CloudKit Console by going to the Manage Containers feature in the container selection drop-down. New containers can be created in the developer portal here: https://developer.apple.com/account/resources/identifiers/cloudContainer/add/ If you run into an issue doing either of these please reply with the details and we can provide further assistance

I'm in the same boat...my account is pending. It says I need to complete payment, but I have already completed payment and have the receipt from Apple. Maybe this is like Apple purgatory??

Ok - this is ridiculous. You don't respond to emails, you don't follow up on you forum messages (no response from you despite the message above). I just spent 20 minutes waiting to speak with someone only to be hung up on, while waiting for them to 'look into my account'. At what point does someone your side take responsibility and shed some light on what's actually happening?

Update (Day 5): Still no response from Apple Staff. This is now affecting 5 apps on my account, all stuck since early February. Developer Support cases (102842489731) provide no answers. This appears to be a system-level issue where binaries are ghosted in the review queue. Can someone from Apple please acknowledge this? We are considering resubmitting all apps, but this wastes significant engineering resources.

I'm not sure associating the push device token to a user account would even solve the problem, unless you only allow one token per user account. But that would prevent users from using multiple devices (such as their iPhone and iPad) with the same account. Our app requires the users to login and we do associate the push device tokens to the respective user account, but we allow multiple tokens per account. And we have noticed for a while that these tokens stack up, even if users only use one device. I don't think we had a case of the same push notification being sent multiple times to the same device yet though. (Haven't tested with iOS 26.4 Beta).

Thank you for your response. I understand the following point: To summarize this interpretation: Existence of a 410 status merely indicates that the token is no longer valid and should not be used anymore. However, in some cases it is difficult to associate a device token with a user account because the app does not provide a login feature or user accounts. In our case, the following scenario can occur: The user installs the app on a device (IDFV: A, DeviceToken: a) The user uninstalls the app The user reinstalls the app on the same device (IDFV: B, DeviceToken: b) Push notifications are sent using both DeviceToken: a and DeviceToken: b As a result, two push notifications are delivered to the same device If we cannot associate the device token with a user account, what would be the recommended way to prevent duplicate push notifications being delivered to the same device in this situation? I would appreciate your guidance.

Thank you for your reply, and I apologize for not providing enough detail earlier. Our app is built with React Native, and we implemented in-app purchases using an OpenIAP-related library that supports StoreKit 2. We are currently testing with a Sandbox account. The feature itself is not completely broken, but we are seeing several abnormal behaviors during testing. For example, even when a purchase is attempted only once, we sometimes receive the purchase-completed message two or three times. We have also observed other inconsistent behaviors during Sandbox testing. Because of this, we were wondering whether this might be related to instability or known issues in the Sandbox environment, rather than being entirely caused by our implementation. Has anyone experienced similar issues when testing subscriptions with StoreKit 2 in a React Native environment? If there are any known Sandbox limitations or specific points we should check first, I would greatly appreciate your advice.