The Apple Developer Program License Agreement and the Paid Apps Agreement are separate. Accepting the program license doesn't activate the Paid Apps Agreement. Apple requires the Account Holder to accept Paid Apps before offering In-App Purchases, and Apple's StoreKit sandbox setup also lists an active Paid Apps Agreement as a requirement. In App Store Connect, open Business → Agreements and check the status of both rows. If Paid Apps is available, complete the agreement there, then check whether Apple requests tax or banking details. If the row is missing or the warning remains after acceptance, this looks like an account-side issue for Apple Developer Support to investigate. Send them your team ID and screenshots of the agreement status privately; don't post account or case details here. For the empty product list, also verify that the product IDs in the app exactly match the IDs in App Store Connect and that the products have their required metadata, pricing, and availability configured. Apple’s sandbox guide has the setup checklist: https://developer.apple.com/documentation/storekit/testing-in-app-purchases-with-sandbox Agreement help: https://developer.apple.com/help/app-store-connect/manage-agreements/sign-and-update-agreements/

Six days in Waiting for Review is frustrating, especially with a launch date coming up. Unfortunately, forum members can't see or move an App Review submission, and opening a support case doesn't give us access to the queue either. I would keep the existing support case open and reply to it with the submission ID, the exact current status, and your Nov 1 event date. Ask whether they can confirm the case is routed to the right team. In App Store Connect, check that the submission still has the intended build and that there isn't a new message or action request. I wouldn't withdraw and resubmit just to try to reset the wait, since that can put it back at the end of the queue. For privacy, avoid posting the Apple ID or support case number publicly. Keep those details in your direct conversation with Apple Support.

That’s a useful reproduction, especially since it also happens with a plain video element and no Media Session calls. I don’t know of a supported web API to choose which Home Screen app opens from the Now Playing card, so I’d treat the routing as an iOS issue unless you can isolate a manifest difference. To narrow it down, try removing the other installed web apps and repeat with only PWA A installed, then add them back one at a time. Note whether the apps share an origin, and include each manifest’s id, start_url and scope in FB25262874, along with the app that actually opens. A screen recording and sysdiagnose after reproducing may help Apple trace the system handoff. I wouldn’t add Media Session code unless a controlled test shows it changes the behavior.

Por el modelo, debería ser compatible: el iPad Air con chip M3 admite Apple Intelligence, y el español de España figura entre los idiomas compatibles. Comprueba que el idioma del iPad y el de Siri sean exactamente el mismo, que haya suficiente espacio libre y que la descarga de los modelos haya terminado. Después, revisa Ajustes > Apple Intelligence y Siri; si aparece la opción, actívala y deja el iPad conectado a Wi‑Fi y a la corriente mientras descarga. Si no aparece en Ajustes, prueba a reiniciar y a instalar la beta más reciente disponible. También mira si el iPad está gestionado por una empresa o escuela, porque un perfil puede restringir funciones. Si sigue igual, comparte el número de compilación exacto de iPadOS 27.2 y una captura de Ajustes > Apple Intelligence y Siri. La compatibilidad del modelo y el idioma parece estar bien, así que esos datos ayudarán a distinguir entre un problema de beta, descarga o configuración.

Since you can reproduce the same hang in Gmail, this looks more like an iOS Password AutoFill / authentication-session issue than something specific to your app. I would file it in Feedback Assistant with a short screen recording, exact iOS build and device model, and the smallest repeatable sequence. If possible, capture a sysdiagnose while the app is still hung, before force-quitting, and attach it to the report. A useful comparison is the same login page in Safari, then in ASWebAuthenticationSession with the Passwords suggestion dismissed, and finally with the suggestion selected. Note whether Cancel or switching apps restores the session. If you can test one affected and one unaffected iOS 26 build on the same device, include those results too. I would avoid claiming a code-side workaround until that comparison isolates a specific trigger.

Given the active agreements and builds already marked READY_FOR_BETA_SUBMISSION, this does look separate from the usual missing-agreement or build-processing checks. I would keep the existing Developer Support case open and ask them specifically to verify the team-level beta contract record used by betaAppReviewSubmissions. Include the exact UTC time of a fresh failed submission and any request or correlation ID from the response, with the team ID and affected build numbers. I would avoid repeatedly resubmitting or uploading replacement builds until Support confirms the contract state, since the response points to the account or team record rather than the binary. If you have not already, attach a screenshot of Agreements showing Active and the build details showing READY_FOR_BETA_SUBMISSION to the case. There may not be an App Store Connect setting you can change to clear this error yourself.

One important limitation is that a mount path, volume name, or BSD device name should not be treated as a durable identity. Device names can be reused after detach, and the path can be remounted. If you create the sparsebundle, put a random identifier in metadata inside it and compare that after the user mounts it. For an image you do not control, use Disk Arbitration to inspect the current disk and volume descriptions, correlate the mounted volume with the attached image, and treat missing or conflicting fields as unknown. I would not make a safety decision from a parsed display name alone. For the read-only checks, collect the mounted volume URL and its volume UUID, read-only state, and ownership state, then verify those values again immediately before copying. A check followed by a later path-based copy still has a race. Where possible, open the destination directory once, retain its file descriptor, and perform traversal relative to that descriptor with no-follow checks, verifying the volume identity again if the mount can change. If the identity or ownership state cannot be established, fail closed and do not copy. The exact fields available vary by filesystem and OS version, so I would validate the behavior on the macOS versions and image types you support rather than assuming hdiutil or diskutil output is a stable API contract.

If the status is Waiting for Review, Apple has received the submission but review has not started yet. If it says In Review, it has started. App Review aims to review most submissions within 48 hours, but that is a goal, not a guarantee, and first submissions or submissions needing extra checks can take longer. Since it has been 21 days, I would open the submission in App Store Connect and check the exact status, the Resolution Center, and whether any item in the submission is still Ready for Review. If everything really is submitted and there is no message, reply to one existing Developer Support case with the app name, version/build, submission ID, date submitted, and current status. Avoid opening more duplicate cases. The forums cannot see or escalate an individual review, so only Apple Support can check the account-specific queue.

I checked the public AlarmKit configuration APIs too. The documented preAlert and postAlert values control the countdown before an alarm fires and the countdown after a person snoozes it. They are not limits on how long the alert sound plays. The alarm configuration exposes the sound and stop or secondary intents, but I can't find a public alert-duration or automatic stop setting. A stopIntent is for handling the person's Stop action. It isn't a timer that AlarmKit runs after the sound has played for a set number of seconds, so I wouldn't rely on it to implement an unattended 10-second cutoff. The WWDC session also describes the countdown intervals as the time before the alert and the time before it fires again after snoozing. I also wouldn't assume a chain of preregistered alarms can be cancelled atomically when the system Stop UI or hardware button is used, especially across reboot and before first unlock. The docs describe managing alarms individually, and note that some Live Activity UI isn't available before first unlock. If those exact guarantees matter, I'd ask DTS and file a Feedback Assistant request for a system-owned alert timeout and repeat policy. References: AlarmManager.AlarmConfiguration and Wake up to the AlarmKit API

I get why this is stressful, especially with a launch date coming up. Forum users can’t escalate a review or see what is holding it. Check App Store Connect for any unresolved item or message, then follow up on one existing Developer Support case with the app name, Apple ID, submission ID, date submitted, and the fact that the expedited request was approved. I’d avoid withdrawing and resubmitting unless App Review asks, since that can put the submission back in the queue. If you have a specific release deadline, explain the concrete impact in the case, but approval of an expedited request still doesn’t guarantee a start time.

An accepted expedited request is helpful, but it still doesn't guarantee an immediate start or expose the internal queue status. In App Store Connect, I'd first confirm that the current submission is the one you expect and that there isn't a new message or action under App Review or Resolution Center. Since support already has the private details, follow up on that same case with the current version/build, submission date, and the expedite confirmation, and ask them to confirm whether the resubmission is linked to that request. I wouldn't withdraw and resubmit just to try to trigger the queue again.

I don't know of a public AlarmKit setting that gives an alarm an expiry window or lets an app filter it before the system presents it. Since the device was powered off, cleanup in your app after launch would be too late for this case. I'd file this with Feedback Assistant as a reproducible behavior or API request, including the exact iPhone model, iOS build, alarm configuration, due time, shutdown/restart times, and whether the device was unlocked afterward. A small sample app would help Apple determine whether this is expected behavior or a bug. If anyone has found a documented AlarmKit API for this, I'd be interested too.

You have already given the reviewer a clear path through the app, which is helpful. At this point I would leave the submission in the queue rather than withdraw it or send the same explanation through several channels. Check that the optional Google Lens flow works on a review device without requiring sign-in, and that your App Review Notes match what you said in the Resolution Center about data leaving the device. If those checks are good, keep the submission ID handy and follow up through one existing support case if the status remains unchanged. There is no way to tell from App Store Connect whether a particular reviewer has opened your reply, so the status alone does not mean it was missed.

An approval on macOS does not automatically carry over to iOS. Each platform build and its user experience are reviewed separately, so I would focus your reply on the iOS app and the specific 4.3(a) concern rather than relying only on the macOS approval. In the Resolution Center, give concrete examples of what makes the iOS version distinct, such as its features, content, and intended users. If you believe the rejection does not fit, ask which similarities App Review identified and explain why they do not apply. If the discussion does not resolve it, you can use the App Review Board appeal process. Keep the submission ID in the conversation so the case is easy to trace.

Yes, it can happen. A submission can stay in Waiting for Review for several days, and the time varies, so that status by itself does not mean something is wrong. Check App Store Connect for any missing information or a message from App Review. If it remains there much longer, contact Developer Support with the submission ID. I would not withdraw and resubmit just to try to move it along, since that can put it back in the queue.