A long “Waiting for Review” period doesn't by itself mean the submission is broken, and an expedited request isn't a guaranteed review time. Check the version page for any missing metadata or agreements, and check the Resolution Center for a message that needs a reply. If everything is complete, keep the current submission in place and follow up on one existing Support case with the submission ID and build number. I wouldn't withdraw and resubmit just to try to move it along, since that creates a new submission and can restart the wait.

If the version is still Waiting for Review, you have answered the previous questions, and the agreements show active, I would leave the submission in the queue rather than upload another build just to reset the wait. In the existing support case, ask them to confirm whether the submission is in the review queue or whether there is an account or submission hold, and include the version/build and submission ID. An expedited request is only a request, so it may not get a separate reply or a guaranteed review time. If you receive a new Resolution Center message, respond there so it stays attached to this submission.

Since this is an organization enrollment, I would follow up with Apple Developer Support and include the Enrollment ID and the exact legal entity name and D-U-N-S details. Check that the legal name and address in the enrollment match the D&B record, and check the account holder's inbox and spam folder for any verification request. Don't post company documents or personal contact details publicly; offer them only through Apple's secure support channel. After three weeks, Support is the only team that can see whether the enrollment is waiting on a verification step or stuck internally.

A 406 error doesn't show which enrollment check failed, so I wouldn't keep submitting the form. Try once in a private window or another browser, with VPN and content blockers off, and check that your Apple Account details and two-factor authentication are complete. If it still fails, contact Apple Developer Support under enrollment or membership and include the responseId, timestamp, and request URL shown in the error. Support can check the account-side reason; the forum can't see that.

I’d leave the submission in the queue if Build 5 is the version you want reviewed. An expedited request can move a case up, but the confirmation doesn’t give a review date or guarantee when it will start. Check the submission page for any unresolved item or message, and make sure the latest build is attached to the version. Since you already have a support case, add the submission ID and the October 16 expedite confirmation there rather than opening more duplicate cases. If the October 25 activation is the reason for the urgency, mention that date clearly in the existing case. I wouldn’t upload another build unless you found something that actually needs fixing.

That message means the enrollment flow is blocked for this Apple Account, but the forum cannot see the reason or restore the attempt. I would avoid retrying with different accounts or changing identity details, since that can make the review harder to follow. Open one Apple Developer Support case and reply to it rather than creating several new cases. Include the exact wording of both messages, when the status changed, your country or region, whether you are enrolling as an individual or an organization, and any Enrollment ID shown in the enrollment flow. Ask them to confirm whether the identity check can be reviewed again or whether another enrollment method is available. Keep passport images, full card details, and your Apple Account email inside Apple's private support channel, not in this public thread. If the callback option is unavailable, use the web support form and save the case number. Availability can depend on the selected issue and region. Apple's program enrollment guide and Developer Support page are the right starting points. Unfortunately, only Apple can see why the verification was rejected or whether another attempt can be enabled.

I would not assume this entitlement will be granted for this use case. The four options on the request form are a guide, but Apple decides eligibility. Since your server can read notification content, describe that accurately and ask Apple Developer Support whether the use case qualifies. Do not select end-to-end encrypted messaging if it does not apply. removeDeliveredNotifications(withIdentifiers:) can remove notifications your app already knows about, but your code has to run on the device. A silent push is only a best-effort background wakeup. iOS can delay, coalesce, throttle, or omit it, so it cannot guarantee prompt cleanup. A notification service extension is for modifying an eligible visible notification with mutable-content; it is not a general handler for a data-only read event. Empty content filtering also depends on the entitlement. If you use background pushes, send one compact update per conversation where possible, make handling idempotent, and treat the push as a hint to fetch current read state rather than an event that must arrive. Reconcile again when the app next runs. This improves consistency but still cannot guarantee immediate removal while iOS does not run your app. See Apple's docs for removing delivered notifications, background updates, and notification service extensions.

I found documentation that helps narrow this down, but it does not seem to settle the DPK-specific conflict. Apple documents kSecUseDataProtectionKeychain as the way to target the Data Protection Keychain on macOS. The key-generation API also accepts usage attributes in the private-key attributes dictionary, including kSecAttrCanSign, kSecAttrCanDecrypt and kSecAttrCanDerive. That gives you a documented way to request those settings at creation, but I could not find a documented non-export check that attests they are enforced for this exact software RSA DPK combination. The documentation for SecKeyCopyExternalRepresentation says it fails on macOS when kSecKeyExtractable is false. However, Apple DTS has also said that raw bytes can be obtained from standard DPK keys with that API. I would not assume kSecKeyExtractable and kSecAttrIsExtractable are interchangeable, or treat the requested attributes or a missing value from SecKeyCopyAttributes as proof of enforcement without Apple confirming it for this key type and OS version. The relevant references are key generation attributes, Data Protection Keychain and Apple's Mac keychain technote. Given the apparent mismatch, this looks like a good DTS question; I would ask them to reconcile those two statements and name a supported verification method without exporting the key.

If this is the first build you submitted for external testers, it does need TestFlight App Review before they can install it. Internal testers who are App Store Connect users can usually test an eligible build without that review. Check the build status under App Store Connect > TestFlight > iOS Builds, and open App Review there if the build was rejected. Are you waiting on external testers or internal testers? Apple’s overview: https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview/

First check that you are signing in with the Apple Account used as the Account Holder during enrollment. If someone else completed the organization enrollment, ask that person to sign in first and invite your Apple Account from App Store Connect > Users and Access. Apple says the Account Holder is initially the only person who can sign in, and can then invite additional users. If you are the Account Holder and enrollment is active but you still get this message, reply to your existing support case with the team name and Enrollment ID and ask them to check that App Store Connect access has been provisioned for the account. I would keep the case details private rather than adding them to a public post. Apple’s guide: https://developer.apple.com/help/app-store-connect/get-started/app-store-connect-workflow/

That 90% figure is an overall review-time target, not a promise that every submission will be reviewed within 24 hours. Since both submissions have been waiting for several days and you have already checked the agreements and Resolution Center, I’d leave them in the queue rather than cancel and resubmit, and follow up on the existing support case with both app IDs, version/build numbers, submission dates, and the case number. Ask whether either submission or the account needs an action from you. The public forum can’t see your App Store Connect queue, so only Apple Support can confirm whether there’s an account-specific hold.

Apple’s enrollment guidance says the Apple Account details used for enrollment should be current, and your legal name needs to match your ID. Since the name is correct in your account menu but wrong in the locked Support field, I’d keep the open case and ask Developer Support to correct or refresh the enrollment record before trying again. Include the exact legal spelling as it appears on your ID and mention that the enrollment page is read-only for you. I wouldn’t post the case number or ID document here; share those only through Apple’s secure support channel. Apple’s identity-verification steps are here: https://developer.apple.com/help/account/membership/identity-verification/

The error is specifically about Font Enumeration, which is different from the normal Fonts capability. Apple says enumeration of all installed fonts needs a separate entitlement request; adding the regular Fonts capability to the App ID may not be enough. If your app only needs the user to choose a font, check whether UIFontPickerViewController can replace enumeration. If you really need to list installed fonts, confirm that Apple approved the Font Enumeration entitlement for this bundle ID and that the matching entitlement is present in the Xcode Cloud archive’s signed entitlements and provisioning profile. A local archive succeeding doesn’t confirm Cloud has the same signing assets. Apple’s font overview explains the distinction: https://developer.apple.com/documentation/technologyoverviews/fonts. If approval is already in place and Cloud still asks to enable Font Enumeration, this looks like an Xcode Cloud signing issue worth filing in Feedback Assistant with the workflow log and request ID.

For a macOS app, the name shown by Finder comes from the app bundle you actually install, so first check the built .app in Xcode’s Products folder. Make sure you changed the settings for the macOS target and configuration you archive, not just the iOS target or a Debug-only setting. Check the built app’s Info.plist for CFBundleDisplayName and CFBundleName, then archive and upload that build. Also check the app bundle’s filename. Finder can show that name in some places, while the display name is used elsewhere. App Store Connect’s product name is a separate setting and changing it doesn’t rename the installed app. On the test Mac, delete the old app before installing the new TestFlight build, then restart Finder or give Spotlight some time to refresh. If a clean install still shows App1, inspect the archived app’s Info.plist; that will tell you whether the new name actually made it into the build.

I read 2.5.19 as being about hidden or undocumented functionality, rather than a blanket ban on A/B tests. If the variants are just different presentations of features already in the submitted app, that seems different from remotely switching on a feature that was not visible to App Review. The guidelines also say apps may not download code that adds or changes functionality. I’d make the review path predictable: explain the variants in Review Notes and give the reviewer a way to see each one, such as a clearly documented setting or test account. Keep the reviewed experience representative of what users can get, and don’t use reviewer-specific behavior to conceal a variant. For digital subscriptions or consumables, keep the purchase flow within the applicable In-App Purchase rules. I wouldn’t treat Review Notes as approval for a substantially new feature after release. If a remote change adds functionality, submit an update for review first. Apple’s guidelines don’t give a specific safe harbor for every paywall experiment, so for a business-critical setup I’d ask App Review directly, as the other reply suggests: https://developer.apple.com/app-store/review/guidelines/