Overview

Hello Apple App Review team, My first iOS app submission, Gymestix 1.0, has remained in Waiting for Review since October 8, 2026, at 12:41 AM. As of October 29, the submission has been waiting for 21 days and still has not transitioned to In Review. I have already contacted Apple Developer Support and followed up on my existing support case approximately five times, but I have not received a meaningful response or an update explaining the delay. I understand that review times can vary. However, this is my first release, and I have no way of knowing whether the submission is correctly queued, blocked by an issue requiring action, or awaiting additional verification. Could someone from App Review please investigate the submission and confirm whether any action is required from my side? I am not requesting expedited review without a qualifying reason. I am requesting a status check and assistance with an unusually long delay. I can provide my existing support case number and any additional submission details through a private channel. Thank you.

Hello App Review team / fellow developers, Our first iOS app has been pending for 22 days across two review cycles and has now been in “Waiting for Review” for 12 days with no status change and no message. I’d be grateful if someone from App Review could take a look, or if anyone has seen the same pattern this month. App details App: PropTek Apple ID: 6746718503 Bundle ID: com.proptek.proptek Version / build: 1.0.3 (120) Submission ID: 31f34ed9-ceef-4353-8a31-6afc3c7f7e4b Team: PropTek Realty Private Limited (Team ID D9GG49R3XC) Timeline 7 Oct 2026 – Build 120 submitted (resolved the Guideline 5.1.1(iv) issue raised on build 119). 16 Oct 2026 – After 9 days in “Waiting for Review”, rejected under Guideline 2.1(a): the reviewer could not sign in. Cause was a demo account our QA team deleted by mistake on the review day, not an app defect. 17 Oct 2026 – Demo account restored and verified; Sign-In Information and Notes updated with the mobile number and static OTP; replied in the submission thread; resubmitted the same build. No binary changes. 17–29 Oct 2026 – “Waiting for Review”, no movement, no messages. What we have already done Replied in the submission thread (17 Oct, 22 Oct and 29 Oct), including a request for a call. Submitted a status inquiry via Contact Us → App Review. Requested an expedited review. Verified: Agreements, Tax and Banking are active; no pending agreements; no unread messages in App Store Connect; demo account and backend are live and tested on iPhone and iPad. We have not removed or resubmitted the submission, per Apple’s guidance that doing so restarts the review. Questions Is there anything on our side preventing this submission from entering review? Is the current queue genuinely this long for resubmissions, or is this submission stalled? The Android version is already live, and we missed a committed launch date of 19 October, so any guidance is appreciated. Thank you, S S Gill (Director) PropTek Realty Private Limited

Hi all, I'm wondering if anyone else is seeing this right now, or has been through it before. I resubmitted my iOS app (version 1.0, with one In-App Purchase in the same submission) on October 16 after answering a Guideline 2.1 information request. I requested an expedited review the same day and it was accepted. It has now been 13 days, and both the app and the In-App Purchase are still in "Waiting for Review". Nothing in App Store Connect has changed since October 16, and there are no new messages from App Review. I've contacted Developer Support by email several times and once by phone. Their latest reply only confirmed that the expedited review was accepted and that the review "should begin shortly". For those who had a similar wait: How long did it take before the review actually started? Did anything help, such as contacting a different support topic, or cancelling and resubmitting? Or did it just start on its own eventually? I'd rather not cancel and resubmit unless that's known to help. Apple ID of the app, in case it's useful: 6809826557 Thanks.

I’m developing a watchOS application for Apple Watch Ultra 2 that continuously monitors heart rate during non-sporting activities, such as driving. The application uses: ● HKWorkoutSession ● HKLiveWorkoutBuilder ● HKAnchoredObjectQuery to retrieve heart rate samples I have observed that starting a workout session allows frequent heart rate measurements to continue even when the Apple Watch display becomes dimmed. However, this creates an unwanted side effect: although the user is not exercising, the session contributes to the Activity rings. In my tests, a workout recorded as type .other generated Exercise Minutes and Active Energy, even though the saved workout itself reported 0 active calories. The problem occurs when deleting the workout. After selecting Delete Workout & Data in the Health/Fitness interface: 1. The workout disappears from the workout history. 2. The Exercise Minutes generated during the session remain in HealthKit. 3. The Active Energy samples generated during the same interval also remain. 4. The corresponding Activity ring totals are not immediately corrected. I subsequently deleted the Exercise Minutes samples manually from the Health app. This corrected the numerical Exercise Minutes total. The Active Energy samples required separate handling. In some tests, the numerical values and the graphical representation of the Activity rings also appeared temporarily inconsistent. My questions are: 1. Is this the expected behavior of HealthKit when deleting a workout created using HKWorkoutSession and HKLiveWorkoutBuilder? 2. Why does Delete Workout & Data leave Exercise Minutes and Active Energy samples generated during the workout interval? 3. Are these samples considered independent system-generated measurements rather than data associated with the workout? 4. Is there a supported way to prevent a monitoring session from contributing to the Activity rings while still maintaining frequent heart rate acquisition in the background? My objective is to monitor physiological parameters during activities that are not exercise, without modifying the user’s fitness statistics. I would appreciate clarification about the intended behavior of these APIs and the recommended implementation approach.

Hello, My app Opinion Scanner (Apple ID 6812309557, iOS, version 1.0) was first submitted on September 29, 2026. The only message I ever received from App Review was an automated one on September 30 (guideline 3.1.2, Terms of Use link). I fixed it the same day: custom EULA set in App Store Connect and Terms of Use link added to the description. Since then: I resubmitted several times (September 30, October 4, October 10, October 21), with new builds. The current submission (October 21) is still “Waiting for Review”. Two expedited review requests were accepted. Two support cases are open without any answer: 102990023433 and 103001051587. All agreements are active, the updated Paid Applications Schedule is accepted, and the App Privacy details are up to date. My server logs show visits from the review team on October 12 and October 16, but the status never changed and no message was sent. I am not asking for an approval. I only need an answer: could someone confirm that my submission is correctly queued, or reject it with the reason so that I can fix it? Thank you for your help. FredMar

Hello App Review team / fellow developers, Our first iOS app has been pending for 22 days across two review cycles and has now been in “Waiting for Review” for 12 days with no status change and no message. I’d be grateful if someone from App Review could take a look, or if anyone has seen the same pattern this month. App details App: PropTek Apple ID: 6746718503 Bundle ID: com.proptek.proptek Version / build: 1.0.3 (120) Submission ID: 31f34ed9-ceef-4353-8a31-6afc3c7f7e4b Team: PropTek Realty Private Limited (Team ID D9GG49R3XC) Timeline 7 Oct 2026 – Build 120 submitted (resolved the Guideline 5.1.1(iv) issue raised on build 119). 16 Oct 2026 – After 9 days in “Waiting for Review”, rejected under Guideline 2.1(a): the reviewer could not sign in. Cause was a demo account our QA team deleted by mistake on the review day, not an app defect. 17 Oct 2026 – Demo account restored and verified; Sign-In Information and Notes updated with the mobile number and static OTP; replied in the submission thread; resubmitted the same build. No binary changes. 17–29 Oct 2026 – “Waiting for Review”, no movement, no messages. What we have already done Replied in the submission thread (17 Oct, 22 Oct and 29 Oct), including a request for a call. Submitted a status inquiry via Contact Us → App Review. Requested an expedited review. Verified: Agreements, Tax and Banking are active; no pending agreements; no unread messages in App Store Connect; demo account and backend are live and tested on iPhone and iPad. We have not removed or resubmitted the submission, per Apple’s guidance that doing so restarts the review. Questions Is there anything on our side preventing this submission from entering review? Is the current queue genuinely this long for resubmissions, or is this submission stalled? The Android version is already live, and we missed a committed launch date of 19 October, so any guidance is appreciated. Thank you, S S Gill (Director) PropTek Realty Private Limited

I've been trying to sign up to the developer program and the response I've gotten is weird. "For one or more reasons, your enrollment in the Apple Developer Program couldn't be completed. We can't continue with your enrollment at this time." Is there absolutely nothing I can do to fix this? I can't even get a reason for why my enrolment has been blocked. I've tried signing up on 3 different devices and they all have different reasons for why I can't continue. iPhone: "Unable to Continue. Contact support" iPad: ID Verification Rejected MacBook: Unable to Verify (Tried driver's licence and passport, passport matches my Apple ID name exactly.

Environment: MacBook Air M4 macOS 27 Beta Safari Safari Technology Preview Issue: I am experiencing an issue where mouse/trackpad clicks are intermittently ignored near the bottom portion of a webpage. The trackpad hardware appears to be functioning normally, as physical clicks are registered and the issue does not occur consistently across all browsers. Steps to Reproduce: Open Safari or Safari Technology Preview. Navigate to a webpage with interactive elements near the bottom of the visible page. Attempt to click links, buttons, or text fields located in approximately the bottom quarter of the browser window. Observe that clicks are sometimes not registered. Resize the Safari window so that the affected area is no longer located in the bottom portion of the screen. Attempt the same clicks again. Expected Result: Clicks should be consistently registered regardless of their position within the webpage. Actual Result: Clicks in the lower portion of the webpage are sometimes ignored. Resizing the window may temporarily resolve the issue. Additional Information: The trackpad itself appears to function normally. Physical clicks are detected. I have observed the issue in both Safari and Safari Technology Preview. I tested the same website in Perplexity Comet, where the issue does not appear to occur. This suggests the issue may be related to Safari’s rendering, hit-testing, event handling, or window management rather than the website itself. Has anyone else been able to reproduce this on macOS 27 Beta?

Hi. It is not as much as widgets itself but it goes along with live activities for sure I believe. Question 1: Hybrid Intelligence & Proactive Context How can developers leverage the Intelligence Platform (specifically intelligenceplatformd) to ensure 3rd-party apps provide the same deep proactive context as first-party services like Spotlight, but strictly through on-device processing to maintain total user privacy? Question 2: Autonomous Diagnostics & Private Reporting Is there a roadmap for Feedback Assistant to autonomously aggregate complex system-level interactions—using spindump or system_profiler—to generate "ready-to-implement" solutions for users, while ensuring these diagnostic insights remain local and are never transmitted to Apple or Google without explicit, granular consent? Question 3: Deep Indexing for Hybrid Data Sources With the shift toward ecosystem-wide intelligence, are there upcoming APIs that will allow Siri or App Intents to more deeply index "hybrid" private data sources—such as external databases or complex Markdown structures in Obsidian—without compromising the local-first security model?

My latest app communicates, via TCP, with an embedded device. The embedded device is programmed in C and sends my Swift app data encapsulated in "messages" which are actually structures defined like this: { uint16_t sig; uint16_t len; // Total length of message, include header and playload; uint16_t type; uint32_t data; // 32 Bits of data. } MSG_t; In my Swit app they arrive via NWConnection, and are sent to my controller delegate as Data (That's the swift type called Data, not just the general term 'data') So me question for you harties is this: How can I unpack this 'Data' into something resembling my C struct - and acess it's members by name. In Pseudo code I'd like to do something like: if let myData = data { myStruct = <cast myData.bytes onto a struct > if myStruct.sig == CORRECT_MSG_SIG { // do soemthig with the message... } } So is this possible? Is it the wrong approach? Is there a better approach?

TTS Stuttering & Noise When using Apple’s native TTS API on an iPhone or iPad—specifically while connected to Bluetooth earphones or headsets—users are experiencing audio noise or intermittent gaps in speech, causing parts of sentences to drop out during playback. There were no reports or inquiries regarding such issues up through iOS/iPadOS 26. Since the release of iOS/iPadOS 27, however, there has been a significant increase in reports and inquiries about this problem. If you happen to know the cause of this issue or have any suggestions for a fix, please leave a reply. The issue persists even after removing the AirPods or headset from the device and reconnecting them. The issue persists even after rebooting the device. The issue occurs even on the latest versions, from iOS/iPadOS 27 through 27.2.

I am evaluating a local macOS C XPC design. The target under consideration is macOS 27.0.1, build 26A434, on Apple silicon. This is a source-design question; I have not run a reproducer or established that the public source below matches that OS build. The public SecCode.h comment describes SecCodeCreateWithXPCMessage as obtaining a code reference for the sender of the supplied XPC message using associated audit identity. The implementation at Apple Security commit 97c3a4296c1ea06b0fe1877a7e616aa84450b5b2 obtains the dictionary's remote connection, takes that connection's audit token, and uses it for code lookup: https://github.com/apple-oss-distributions/Security/blob/97c3a4296c1ea06b0fe1877a7e616aa84450b5b2/OSX/libsecurity_codesigning/lib/SecCode.h https://github.com/apple-oss-distributions/Security/blob/97c3a4296c1ea06b0fe1877a7e616aa84450b5b2/OSX/libsecurity_codesigning/lib/SecCode.cpp Function anchor in both files: SecCodeCreateWithXPCMessage. I am treating this as a question about the supported API contract, not evidence of a vulnerability or proof of installed implementation. For an actual received C XPC dictionary M, retained for deferred processing, I need to understand the supported identity and reply guarantees: Does SecCodeCreateWithXPCMessage(M, ...) resolve audit identity fixed to M's original sender occurrence, or can the associated connection's identity at lookup time differ? In particular, what is guaranteed if another message arrives or processing occurs concurrently on another queue? If the sending process performs exec before the lookup, or after lookup but before a reply, what does the resulting SecCode reference identify? Is there a documented supported way to distinguish the original message-sending occurrence and executable from a later executable or replacement peer without using PID-based reconstruction or private XPC APIs? If I retain M and later use its supported C reply context, does the reply remain addressed to that same original sending occurrence? What are the documented effects of connection invalidation, exec, forwarding/delegation of relevant rights and outstanding aliases? I am not assuming that retaining M or the returned SecCode reference locks peer identity or revokes other holders. If these APIs do not jointly provide those guarantees, which public API and ownership pattern should a design use to validate the actual eventual reply recipient before sending sensitive data? A statement that a guarantee is unavailable or requires a different design would also help. Please distinguish C XPC behavior from Swift XPCReceivedMessage; I am not assuming an undocumented conversion between them. Could you point to the applicable documentation and supported macOS versions, and clarify whether the cited public source revision is representative of the target? If exact-build behavior cannot be established publicly, please identify that limitation. This question concerns transport identity and context lifetime only. A valid code identity would still need separate application authorization; I am not asking XPC to issue role, run or resource authority. I would prefer a documented contract over an inference from a successful test. I can prepare a separately scoped minimal example if one is necessary, but no executable example is included in this question.

Hello, We develop a sandboxed Mac App Store app that runs virtual machines with Virtualization.framework on Apple silicon (macOS 27). Users want to install a macOS guest onto an external USB disk and start the VM from it, so they can keep a VM on portable storage or on a disk larger than the Mac's internal drive. What we tried USB passthrough: we attach the disk before the VM starts, with VZUSBPassthroughDeviceConfiguration (from an AAUSBAccessory) on a VZXHCIControllerConfiguration. Linux guests install onto the disk and boot from it without problems. For a macOS guest, VZMacOSInstaller fails to start when the USB disk is the only storage: As we understand it, a macOS VM can only start from its own storage devices, never from a USB device, so even a successful install would not boot. VZDiskBlockDeviceStorageDeviceAttachment: this needs an open file handle to /dev/diskN. That requires admin rights, which a sandboxed app can't obtain, so we can't use it in our App Store app. Questions Is there a supported way to install a macOS guest onto an external USB disk and start the VM from it? Is there a sandbox-compatible way to get a VZDiskBlockDeviceStorageDeviceAttachment for an external disk, for example after user consent, similar to how AccessoryAccess grants USB devices? If neither is possible today, is support for this planned, or is there a recommended alternative? Thank you for any guidance.

Hello everyone, Our app has been stuck in the “In Review” status for several days without any updates. We have contacted App Review but haven’t received a response. The latest build was created using Apple’s latest development tools, with several third-party SDKs migrated. We also need to update our app screenshots for iPhone Duo, but we’re unsure whether withdrawing the current submission and resubmitting would cause further delays. Has anyone experienced a similar situation recently? Would you recommend continuing to wait or withdrawing and resubmitting? Any advice or shared experiences would be greatly appreciated. Thank you!

Hi everyone! We recently integrated "Sign in with Apple" into our application using standard social login flows. For the vast majority of our users, the integration works perfectly—we receive the user's email during sign-in and sign-up. However, we are noticing an edge case where a small subset of users are returning an ID token that is completely missing the email. We can't seem to reproduce this error ourselves during testing. Every time we test a sign-up or sign-in, the email payload is included exactly as expected. My Questions: Is there a specific reason why Apple would omit the email claim from the ID token? Any insights or guidance would be greatly appreciated. Thank you!

We are in the process of transferring our existing Apple account to a new account. We read the documentation and we realized that "Sign in with Apple" users needs to be migrated via API. This API seems to require "sub" which we are not currently storing in our systems. So we are planning to "collect subs" over a period before we can start transfer. I want to make sure we are collecting correct data so I am looking for confirmation from Apple engineers on this. Should we get "sub" from "user" property in ASAuthorizationAppleIDCredential or by decoding identityToken and get "sub" from the token? I think both are same but wanted to double check. Thank you!

My macOS app, AnimacX, cannot complete Developer ID distribution export in Xcode Cloud. The affected build is 1144, and the preceding build 1143 contains the following certificate lookup and creation failures. Environment: Team ID: SWWMY4BCX7 Bundle ID: app.anix.AnimacX Xcode version recorded in the Build 1143 logs: 27.1 (27A9275) Automatic signing enabled Failing step: Export archive for developer-id distribution xcodebuild -exportArchive exits with code 70 The provisioning log shows this sequence: Xcode Cloud queries certificates with type DEVELOPER_ID_APPLICATION_MANAGED. The response contains an empty data array and a total count of 0. Xcode then attempts to create a managed Developer ID Application certificate. The creation request fails with: HTTP 409 code: ENTITY_ERROR resultCode: 7460 You already have a current Developer ID Application Managed certificate or a pending certificate request.The export subsequently reports: No signing certificate "Developer ID Application" found No "Developer ID Application" signing certificate matching team ID "SWWMY4BCX7" with a private key was found. No profiles for 'app.anix.AnimacX' were found.However, the Certificates page for this team lists two Developer ID Application Managed (Xcode Cloud) certificates, both created by Xcode Cloud and expiring on February 2, 2027. I have an Admin role on the team. This workflow was working normally until recently, and I have not created, revoked, or otherwise modified any certificates. Building and uploading the macOS app to App Store Connect directly from local Xcode still succeeds. The iOS and tvOS builds and distribution workflows also continue to work normally. The failure is limited to Developer ID distribution export for macOS in Xcode Cloud. I contacted Apple Developer Support under case 103008194927 and was directed to post here. Screenshots are attached, and I can provide the full distribution logs. Could an Apple engineer help determine why Xcode Cloud returns no certificates while the creation service reports an existing certificate or pending request? What action is required to restore Developer ID export, and does this require investigation of the team’s cloud-managed signing state?

Hello Apple networking team and fellow developers, Summary We are investigating increased Wi-Fi login and reconnection timeouts after users upgrade to iOS 27. Some players report repeated reconnection failures during battles, preventing completion and potentially losing Star Hunt points. The root cause is not confirmed. 1. Wi-Fi timeout rates by OS version +------------+------------------------+--------------+ | OS version | Timeouts / online hour | Dates (2026) | +------------+------------------------+--------------+ | iOS 26.x | 0.086 | Oct 8-21 | | iOS 27.0 | 1.779 | Oct 8-21 | | iOS 27.0.1 | 1.737 | Oct 8-21 | | iOS 27.2 | 1.437 | Oct 26-28 | +------------+------------------------+--------------+The 27.2 observation cutoff is October 28, 14:15 UTC+8. The earlier iPhone comparison showed approximately 20 times as many Wi-Fi login/reconnection timeout records per online hour on 27.0/27.0.1 as on 26.x. Comparison limit: The 27.2 row uses a different population and observation window. It is not a direct before/after upgrade comparison. 2. Paired comparison: 27.0.1 → 27.2 We separately compared 51 paired iPhone account/device samples: the same account and device, game package version 1.9.1, and 24 hours before and after the first observed 27.2 event. Each side required at least 30 minutes of Wi-Fi online time. These samples first reported 27.2 on or after October 26. +------------------------+----------------+-------------+ | Metric | Before: 27.0.1 | After: 27.2 | +------------------------+----------------+-------------+ | Wi-Fi online hours | 96.69 | 91.05 | | Timeout records | 142 | 45 | | Timeouts / online hour | 1.47 | 0.49 | | Samples with timeouts | 17 / 51 | 6 / 51 | +------------------------+----------------+-------------+This small paired sample suggests an initial improvement of approximately 66%, but failures remain. Measurement limits: Both tables count application-level timeout records, including repeated retries, rather than independent disconnections. The 27.2 sample and observation period are limited. Our OS-version telemetry does not distinguish beta/RC builds from final builds sharing the same version string. 3. Other observations Earlier cohort comparisons did not show a comparable increase over 4G/5G. Wi-Fi-only iPad models are also affected, so switching to the device's own cellular connection cannot explain all cases. Ordinary request errors did not increase to the same extent as login/reconnection timeouts. Connection recovery is an investigation lead, not a confirmed cause. Our iOS HTTP requests use NSURLSession. Current application telemetry does not retain enough native NSError details to identify whether DNS, TCP, TLS, or another stage is responsible. 4. Questions for Apple Are there known iOS/iPadOS 27 changes or regressions involving Wi-Fi connection recovery or NSURLSession that could fit this pattern? Are there relevant fixes in 27.2, or specific OS builds we should compare? Which diagnostics should we collect from affected physical devices (for example, a CFNetwork diagnostic profile, sysdiagnose, or URLSessionTaskMetrics), and how should we submit them privately? We are looking for a systematic way to isolate the cause rather than assuming all cases share one OS bug. Any guidance would be appreciated.

For an application supporting iOS 16 and later, including iOS 18 and newer releases, I would like to clarify the supported guarantees for deciding whether persisted monotonic time evidence belongs to the current boot. I have read the DTS reply in “Time verification in iOS 18+” and the linked recommendation to use CLOCK_MONOTONIC with an exclusively created POSIX named semaphore: https://developer.apple.com/forums/thread/774658?answerId=825483022#825483022 https://developer.apple.com/forums/thread/110044?answerId=754364022#754364022 That recommendation describes semaphore cleanup on restart as a reasonable assumption. My question is specifically about the documented guarantees and safe failure conditions of that approach, rather than another request for a replacement for kern.bootsessionuuid. The required distinction is between process or application-engine restarts during the same boot and an actual device reboot. A continuity mechanism should remain valid across the former and distinguish, or safely invalidate, observations retained across the latter. It must not depend on an assumed-stable wall clock or on comparing uptime magnitudes that could overlap after a reboot. For an App Group-namespaced semaphore on supported iOS versions: Is cleanup at every device reboot, and persistence across ordinary process termination or suspension within a boot, a documented guarantee that an application may rely on? What sandbox, resource-limit, lifecycle or name-reuse conditions can invalidate that inference? Is there a supported way to avoid treating a recreated or unrelated same-name semaphore as proof that older persisted observations belong to this boot? If those guarantees cannot be established, is there another supported boot-continuity mechanism? Please identify its OS availability and applicable privacy or required-reason API constraints. No raw boot identifier or raw uptime needs to be sent off-device. If supported cross-process continuity cannot be established, is a continuously alive native process's sleep-inclusive monotonic clock a documented comparison domain until that process ends? In that narrower design, all previous-process observations would be invalidated, accepting the loss of same-boot recovery. A process UUID or application-engine identity would not be treated as an operating-system boot identity. I am seeking documented guarantees, limitations or supported alternatives, not an undocumented sysctl or an inference from macOS behavior. This question concerns clock-domain continuity; it does not assume that continuity alone proves when a location observation was originally acquired.

Does Apple provide a supported public API or entitlement for an App Store iPhone app to simulate the system location consumed by other apps entirely on-device? Would using a bundled Network Extension and on-device developer pairing remain restricted to development/testing workflows?