I’m seeing a Bluetooth call audio routing issue on a new iPhone 17 Pro running iOS 26.5.1, build 23F81. Bluetooth media audio works normally. Music and video audio stay on Bluetooth headphones without issues. The problem appears only when the device switches into call audio / HFP mode. Tested with multiple earbuds: Samsung, OPPO, Huawei and CMF Buds Pro 2. The behavior is similar with all of them. There are no other Bluetooth devices connected. Call Audio Routing is already set to Bluetooth Headset in Accessibility settings. The issue affects cellular calls, FaceTime Audio, Telegram and Signal. In some cases the earbuds seem to switch into call mode, but the call audio route falls back to the iPhone receiver or speaker instead of staying on the Bluetooth headset. After the call ends, Bluetooth media audio returns normally. I captured a sysdiagnose right after reproducing the issue. Relevant observations from the logs: Device: iPhone18,2 iOS: 26.5.1 Build: 23F81 Sysdiagnose time: 2026-06-03 11:22:03 +0300 In Bluetooth/CoreCapture/bluetooth_status.txt, Bluetooth was ON 3 paired devices were present 1 device was connected Connected device at the time: CMF Buds Pro 2 So the headset was not simply disconnected from the phone. In the powerlog, before the call the audio route was HeadphonesBT for media playback. Around the FaceTime Audio test, HeadsetBT / PhoneCall appeared, but then the route moved to ReceiverAndMicrophone / Speaker instead of staying on HeadsetBT. During a later cellular call, the active PhoneCall route was also ReceiverAndMicrophone rather than HeadsetBT. After the call ended, the route returned to HeadphonesBT for media playback. This looks like the Bluetooth connection remains alive, but call audio / HFP routing fails. The same sysdiagnose also contains CentauriFirmwareEvent entries under crashes_and_spins from the previous day. They show: subsystem = BT host-reason = firmware crash BTMAIN panic faulting_task = link_manager_thread LMAC_5G watchdog expired SCAN watchdog expired These firmware crash events do not happen at the exact same timestamp as the call test, so I’m not claiming that every call directly crashes Bluetooth firmware. But the sysdiagnose shows both incorrect Bluetooth call audio routing and separate BT firmware crash events. Has anyone seen similar behavior on iPhone 17 / iOS 26 with Bluetooth HFP call audio? Could this be a known iOS 26 / Apple N1 / Bluetooth firmware issue, or does it look more like a hardware defect of this particular device?

This started happening on iOS 26.5, and it is still happening after updating to iOS 26.6 beta. The issue is severe enough that my Apple devices are currently not usable for basic communication. I have lost money, time, and thought way too much about this, so I’m really hoping for a resolution. After setting up an iPhone 14 Pro Max on my Apple Account/iCloud, my Contacts, Messages, Phone, and related Apple communication services became essentially nonfunctional. This started after adding the iPhone 14 Pro Max, but it is no longer isolated to that phone. The issue has spread across my Apple devices, including my iPhone 15 Pro Max, iPhone 14 Pro Max, iPad, and Mac. Current Affected devices/apps: iPhone 15 Pro Max iPhone 14 Pro Max iPad Pro Mac Mini M4 Contacts Messages Phone/calls FaceTime or other calling/contact-related services iCloud Contacts / Apple Account syncing The apps themselves become unusable. When I open Contacts, Messages, Phone, or related services, I usually get a blank/white screen, a frozen interface, or a briefly visible cached state. Sometimes I can see old message previews or the previous app state for a split second, especially after force restarting or using the app switcher, but I cannot scroll, select, call, text, or use the interface normally. After about 10 to 15 seconds, the app freezes or crashes. This affects essentially all normal communication functions. I cannot open Contacts. I cannot read or use Messages normally. I cannot place or answer calls. I cannot use my contact list. I cannot use any of my phone numbers or receive verification codes to my phone number. The same failure appears across devices signed into the same Apple Account/iCloud. Contacts still appear to exist on iCloud.com, which makes me think this may be an iCloud Contacts, Apple Account sync, contact-card corruption, or cross-device sync corruption issue rather than simply a local device problem. Troubleshooting already attempted: Updated to iOS 26.6 beta Factory reset the iPhone more than once Tried restoring from backup Tried setting up from zero / fresh setup Tried force restarting Tried resetting SIM/cellular settings Tried setting up with no SIM Confirmed accounts were logged in Confirmed mail/accounts were present and Contacts were enabled where applicable Contacted Apple Support Apple Support escalated the case to a senior engineer Apple Support diagnostics reportedly came back “fine” or “flying colors,” but the devices are still unusable Posted on Apple Support Community, but apple deleted my post and told me to post on the developer forum because I mentioned I updated to iOS 26.6 is beta software.... One possible thing: before this started, I had an AI agent attempt to update my personal contact card with a new phone number. This is an operation that normally goes well, but it was my personal card. I did not verify exactly what it changed. I do not know if this is related, but I am mentioning it because the issue feels like something corrupted in the Apple Account/iCloud contact or identity layer, and somebody in my last thread mentioned emoji or unusual characters might cause this kind of issue. It might have changed my card with some unusual character, field, label, or operation that broke iCloud syncing. Another clue: this started after adding the iPhone 14 Pro Max to my Apple Account/iCloud. After that, the issue began affecting the rest of my Apple devices too. That is why I believe this belongs under iCloud / Apple Account / Contacts syncing rather than only iPhone.

Hi there, Hope you are all well. I would like to know on how I am able to develop/build for both current software, like iOS 26 and iOS 27 at the same time. If it is possible, please let me know how. This is also my first WWDC as a developer, so I may have many questions. Sorry in advance lol. Thanks, Jason

Safari on iOS 17, when entering characters into text input box after deleting characters, the layout is off. Here's the HTML: <body> <div id="J001" style="display: inline-block;"> <div id="J001__0" style="display: inline-block;"> <input id="J001__0__input" style="display: inline-block; height: 28px; padding:2px; border:1px solid gray;"></div> <div id="J003__0" style="display: inline-block;"> <button id="J003__0__btn" style="display: inline-block; height:34px;">a</button> </div> </div> </body> Enter "A" into text input box. Delete "A" with the backspace(x). Enter "A" into text input box, the button position will be shifted down. iOS 17 の Safari にて、テキスト入力ボックスで文字を削除した後、文字を入力するとレイアウトが崩れます。 テキスト入力ボックスに「A」と入力します。 バックスペース(x)で「A」を削除します。 テキスト入力ボックスに「A」と入力すると、ボタンの位置が下にずれます。

I have an App which supports multiple windows on the iPad. The App can receive URLs from other Apps (via application.openURL()) and also files via "share sheet" (via UIActivityViewController). When receiving a URL from another App the delegate method scene(_ scene: UIScene, openURLContexts URLContexts: Set) will be called on an existing UIScene, however when a file is received through the share sheet from another App, a new UIScene is created and therefore also a new window (eg the delegates application(_ application: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options: UIScene.ConnectionOptions) and scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) are called). In both cases I do get the URL and file just fine, however I do not want to get new UIScenes and windows created when receiving a file via share sheet. How can I prevent to get a new UIScene or window? The received files should be used in the existing windows and should not create new ones.

Hello fellow developers and Apple Review Team, I am reaching out to the community and any Apple App Review representatives here as a matter of absolute business urgency. Our essential health app, BeatO Diabetes Management (App ID: 1070739458), has been effectively paralyzed in the review queue for nearly 40 days (since late April 2026), severely impacting thousands of chronic care patients who rely on our ecosystem daily for blood glucose tracking. We are completely aligned with Apple’s rigorous safety standards, but we have reached an operational dead end where detailed, compliant answers are met with week-long silence. ⏱️ The Timeline of the Review Deadlock: Late April 2026: Initial build submitted. Flagged under Guideline 1.4.1 (Safety - Physical Harm) regarding our connection to external hardware (a CE-certified glucometer). May 12, 2026: We provided absolute regulatory documentation: official CE certifications, supplier details, clinical validation reports, and proof of prominent American Diabetes Association (ADA) threshold disclaimers inside the UI. May 15, 2026: Apple responded stating: "Your submission's review will require additional time... We do not require any further information at this time." May 26/27, 2026: After a prolonged freeze, we halted the initial release to clear the pipe and submitted a completely fresh build (Submission ID: a0bf3856-693b-4577-adc7-9199a5f9fe34) hoping to reset any stuck internal states. May 27, 2026: Apple requested information under Guideline 2.1 (Information Needed) asking two specific questions about algorithmic personalization and our "tailored diabetes program" marketing text. May 27, 2026: Within a couple of hours, we provided an exhaustive, definitive response: Clarified ADA Guidelines: Confirmed that high/low glucose classifications are strictly based on standard published clinical data (ADA Standards of Care) and explicitly disclosed in our Terms & Conditions, not personalized by an algorithm. Clarified Program Architecture: Proved that 0% of the program is generated by an algorithm. The app acts purely as an introductory storefront/brochure. The actual care management is fulfilled entirely offline directly by human doctors and certified medical professionals. It is definitively not an algorithmic medical device feature. May 28, 2026 to Present: The app was re-entered into the "In Review" state and has sat completely frozen ever since. 🛑 The Core Problem & Business Impact We have successfully provided every piece of documentation Apple has asked for - legal, medical, clinical, and architecture definitions. The reviewer explicitly stated they have everything they need, yet we are trapped in an endless manual review loop. Because our app manages active diabetic health metrics, this prolonged delay prevents us from deploying critical performance optimizations and bug fixes. Our patient support lines are flooding, and our operational product roadmap for the quarter is completely stalled. 🙏 Request to the Community / Apple Engineers Has anyone else dealing with health hardware/software integration hit this specific wall where your answers are fully compliant, but the review desk simply stops processing the ticket? If any Apple App Review moderators or App Store Connect engineers see this, we respectfully request an internal escalation or an App Review Appointment to unblock this build. We are ready to jump on a call immediately to provide any final clarity required. App Name: BeatO Diabetes Management App ID: 1070739458 Latest Submission ID: a0bf3856-693b-4577-adc7-9199a5f9fe34 Thank you for your time and guidance. Regards, Sanketkumar Biswas

Hi everyone, I’m having an issue with an app update in App Store Connect and wanted to ask if there is anyway to get urgent support. The update was approved successfully, and the status has been showing as “Ready for Distribution” for over 4 days. Usually, once an update reaches this stage, it becomes available on the App Store within a few hours, but this time it still hasn’t appeared. So far, I’ve checked the following: The app review was completed successfully. The version is approved and showing a green status. I contacted Apple Developer Support a few days ago. Case ID: 102906011756 I have not received any update from Apple Support yet, other than the initial confirmation. Has anyone else recently had an approved app update stay in “Ready for Distribution” for several days? Is there anything I can do from App Store Connect to push the release forward, or do I just need to wait for Apple Support? Any suggestions would be appreciated. Thanks.

When switching from RealityView’s .spatialTracking camera mode to .virtual camera mode, the camera’s orientation relative to the scene is preserved permanently with no way to reset to default World-Up orientation. Since .spatialTracking’s camera mode will always have a non-default orientation, switching to .virtual camera mode ensures that the cameras’s ‘UP’ direction will never match the device display’s ‘UP’ direction as is default. This is especially noticeable when using .orbit camera controls, as the orbit’s UP direction matches the scene, not camera, and all rotation directions give unexpected results. Expected: When setting virtual camera mode after using spatialTracking camera mode, either 1. The Virtual Camera orientation returns to default (world up). Or 2. A 'content.camera.resetOrientation()' call is made available which resets the RealityView camera to default orientation. Reality: Switching from .spatialTracking -> .virtual camera mode permanently locks the .virtual camera’s orientation the final frame of the .spatialTracking camera’s rotation (relative to the RealityView content scene). One imperfect workaround is to reset / rebuild the entire RealityView after changing modes (by resetting .id() or otherwise. This is not ideal as it causes everything inside the make closure to rerun, which not only is a performance & time cost, visually incurs a flicker and can also be problematic with managing increasingly complicated views. Another imperfect alternative is to use more than one RealityView - which is not ideal as it incurs double the base ram usage, significantly increases code, and seemingly goes against the intent of being able to change the camera .virtual/.spatatialTracking mode at will. Code Sample: import SwiftUI import RealityKit struct RKSpatialVirtualToggle: View { @State var showAR: Bool = false var body: some View { RealityView { content in let cube = ModelEntity(mesh: .generateBox(size: 0.25), materials: [SimpleMaterial()]) cube.position.z = -1 content.add(cube) content.camera = showAR ? .spatialTracking : .virtual content.cameraTarget = cube } update: { content in content.camera = showAR ? .spatialTracking : .virtual } .realityViewCameraControls(.orbit) VStack{ Spacer() Button("Toggle AR"){ showAR.toggle() } .buttonStyle(.borderedProminent) } } } Xcode Version: Version 26.0 (17A324) iOS Version: iOS 26.5 (23F75) Tested on devices, iPhone 12 Pro, iPhone 15 Pro

I’m evaluating a simple iOS application that would perform real-time beat detection and audio analysis. My question is: Can an App Store-compliant iOS application access or analyze audio that is being played by other applications on the same device (e.g. Spotify, Apple Music, YouTube, TikTok, Safari, etc.) in real time, without using the microphone? Specifically: Is there any Apple-supported framework that allows access to system audio for real-time beat detection or frequency analysis? Can ReplayKit be used to analyze audio buffers from other applications in real time without recording or saving the audio? If direct access is not permitted, what Apple-approved architecture would be recommended for synchronizing external hardware with music being played on the iPhone? Would such an implementation be acceptable under App Store Review Guidelines? I am trying to determine whether real-time beat detection from audio played by other apps is technically and policy-wise supported on iOS. Thank you.

Hello, I’m currently dealing with an App Review situation that has been stuck with no real progress and no useful feedback from Apple. App Name: Juego de Impostor: Palabras Apple ID: 6757995242 Bundle ID: com.rgioia.impostorwords Version: 1.8.0 Current Status: Ready for Review Previous Version: 1.7.0 Ready for Distribution Timeline: The app/update has been waiting for review for an unusually long time. There has been no clear movement, no rejection, no explanation, and no actionable feedback from the review team. This is especially frustrating because this is not a new experimental app or an unclear submission. The app is already prepared for release/update, and I need to push fixes and improvements for users. What I already did: Requested expedited review → approved Contacted Apple Developer Support multiple times Followed up several times Waited without receiving any meaningful update The only response I received was that the expedited review request was accepted, but after that nothing actually happened. Impact: The app/update is completely blocked I cannot release fixes or improvements There is no rejection reason to fix There is no communication from App Review I have no visibility into whether this is a review queue issue, an account issue, or a pipeline problem At this point, this does not feel like a normal App Review delay. It feels like the submission is stuck somewhere internally with no owner and no progress. Questions: Is anyone else experiencing this kind of delay recently? Is there any real way to escalate a stuck App Review case after an expedited review was already approved? Could this indicate an issue with the App Review pipeline or my account/app status? How can I get someone from Apple to actually look into the submission instead of receiving generic support replies? I understand that delays can happen, but having an app/update blocked for this long with no feedback, no rejection, and no progress is not acceptable for developers trying to maintain a live product. Any help, visibility, or escalation path would be appreciated. — Ramiro Gioia

Hello everyone, I'm facing an unusual issue with App Store Connect. My app has been in the "Ready for Distribution" status for over 2 weeks (17 days) now. Normally, distribution starts within a few hours after approval, but in this case nothing happens. What I already did: The app successfully passed the review (status is green / approved). Distribution is set to automatic release (I also tried manual — no difference). I submitted a ticket to Apple Developer Support via the official form few days ago. Ticket number: Case ID: 102898955253 I haven't received any response from Apple so far — not even an automated acknowledgment beyond the initial one. Checked spam/junk folders — no emails from Apple. My question to the community: Has anyone experienced such a long delay in the "Ready for Distribution" state recently? Is there any way to "nudge" the process without waiting for Apple Support? Would re-submitting a new build (incrementing the version number) help reset the state? Any advice would be greatly appreciated. Thank you.

We are working on an HCE application following your documentation. Almost everything is working fine except that we encounter a crash when using CardSession.init() method. We are calling CardSession.isEligible() before CardSession.init(). This crash is random and affects very few user and we did not find a way yet to reproduce this crash on our side. Our theory is CardSession.isEligible() is doing thing under the hood and make CardSession.init() cause a crash, but that just our theory. Here are some stacks : CoreNFC/NFCCardSession.swift:431: Fatal error: Previous session exists 0 libswiftCore.dylib   0x000000019ed73800 _assertionFailure(_:_:file:line:flags:) + 168 (AssertCommon.swift:171) 1 CoreNFC   0x000000025b99f630 NFCCardSession.startSession() + 296 (NFCCardSession.swift:431) 2 CoreNFC   0x000000025b994771 CardSession.begin() + 1 (CardSession.swift:337) 3 CoreNFC   0x000000025b99427d CardSession.init() + 1 (CardSession.swift:320) 4 Paiement Mobile   0x000000010197f345 HceNativeSDK.startCardSession() + 1

Hello everyone, We are encountering a critical regression introduced in iOS 26.4 that results in permanent workout data loss for users. When invoking HKWorkoutBuilder.finishWorkout(completion:) while the iOS device is locked, the save operation fails completely. However, it fails silently: the completion handler executes but returns both a nil workout and a nil error. Expected Behavior: Before iOS 26.4 finishWorkout resulted in a workout id, and correctly stored the workout data in HealthKit. According to HealthKit data protection documentation, saving data when the device is locked should either succeed (writing to a temporary journal file to be merged upon unlock) or explicitly throw an error such as HKError.Code.errorDatabaseInaccessible. Actual Behavior: Because the framework returns nil for both the object and the error, the application has no way to detect that the save failed. We cannot implement a retry mechanism or queue the save, resulting in silent data loss. Steps to Reproduce: We have built a Minimal Reproducible Example (MRE) that reliably triggers this: Initialize an HKWorkoutBuilder and call beginCollection(withStart:) followed by endCollection(withEnd:). Wrap the finishWorkout call in a short 5-second asynchronous delay, protected by a UIBackgroundTask to prevent app suspension. Lock the physical device during this 5-second window. The finishWorkout completion handler will execute while the device is locked, returning workout == nil and error == nil. Existing Reports: We have filed this via Feedback Assistant (a month ago) and opened a TSI (a week ago), providing the MRE project and a sysdiagnose captured at the time of failure: Feedback ID: FB22396180 TSI Case-ID: 19755043 As we have not yet received a response or a suggested workaround through these official channels, we are reaching out to the community. Has anyone else encountered this silent failure with HKWorkoutBuilder recently? Any insights or escalation help would be greatly appreciated.

Hello Apple Developer Support, Our app, GluAI (Apple ID: 6757767664), is currently live and available on the App Store. The direct App Store URL works correctly: https://apps.apple.com/app/id6757767664 However, the app does not appear in App Store search results when searching for the exact app name "GluAI". The app has been live for approximately 3 weeks, so we would appreciate it if you could verify that the app has been properly indexed and is eligible to appear in App Store search results. App Name: GluAI Apple ID: 6757767664

I’m seeing a regression in Xcode 26.4 where Interface Builder will not allow connecting IBOutlets or IBActions. Symptoms: The usual gutter circle/dot does not appear next to IBOutlet / IBAction in the code editor Because of this, I cannot: drag from storyboard → code drag from code → storyboard The class is valid and already connected to the storyboard (existing outlets work) Assistant Editor opens the correct view controller file Important: The exact same project, unchanged, works perfectly in Xcode 26.3. I can create and connect outlets/actions normally there. ⸻ Environment Xcode: 26.4 macOS: 26.4 Mac Mini M4 Pro 64G Ram Project: Objective-C UIKit app using Storyboards This is a long-running, ObjC, project (not newly created) ⸻ What I’ve already tried To rule out the usual suspects: Verified View Controller Custom Class is correctly set in Identity Inspector Verified files are in the correct Target Membership Verified outlets are declared correctly in the .h file: @property (weak, nonatomic) IBOutlet UILabel *exampleLabel; Opened correct file manually (not relying on Automatic Assistant) Tried both: storyboard → code drag code → storyboard drag Tried using Connections Inspector Clean Build Folder Deleted entire DerivedData Restarted Xcode Updated macOS to 26.4 Ran: sudo xcodebuild -runFirstLaunch Confirmed required platform components installed Reopened project fresh ⸻ Observations In Xcode 26.4 the outlet “connection circles” are completely missing In Xcode 26.3 they appear immediately for the same code Existing connections still function at runtime — this is purely an Interface Builder issue ⸻ Question The gutter circles appearance has always been flaky in Xcode over the 13+ years I've been using it but now with 26.4 they have completely disappeared. Has anyone else seen this in Xcode 26.4, or found a workaround? At this point it looks like a regression in Interface Builder, but I haven’t found any mention of it yet.

Environment： OS: iOS 16.0 and later (up to iOS 17.x / 18 beta) Subtopic: CarPlay (Wireless / Wi-Fi & Bluetooth Link) Frameworks: WebKit (WKWebView), AVFAudio (AVAudioSession), CoreAudio Description ： We have encountered a critical audio routing and scheduling anomaly specific to Wireless CarPlay environments when a WKWebView leaves a residual AudioContext instance. In our iOS application, we embed an H5 page that utilizes the Web Audio API (AudioContext) to handle audio playback, which includes standard user-interaction-based mute unlocking logic. Under normal conditions (including standalone device playback, Bluetooth A2DP, and Wired CarPlay), if the H5 page is dismissed without explicitly invoking AudioContext.close(), the system handles resource recycling gracefully without side effects. However, exclusively under a Wireless CarPlay connection, if the H5 page is destroyed but the WebKit AudioContext instance remains active or is not explicitly closed by the frontend script, a severe system-level audio scheduling conflict occurs. This anomaly breaks the audio pipeline behavior, causing persistent stuttering, dropped frames, and intermittent audio dropping in concurrent third-party music applications (such as KuGou Music, Spotify, etc.). Observed Behavior & Technical Analysis： Wireless CarPlay Specificity: The issue cannot be reproduced on Wired CarPlay or standard Bluetooth audio routing. This suggests that the CarPlay audio server daemon over Wi-Fi (AirPlay-based transport mechanism) has a different constraint or synchronization mechanism regarding audio graph changes. AudioSession / Audio Graph Contention: It appears that when AudioContext is alive, WebKit maintains an active AVAudioSession or an unreleased node in the system audio graph. When the app switches context or destroys the webview wrapper, the system fails to force-evict or deactivate this residual context under Wireless CarPlay scheduling rules. Resource Starvation for Background Apps: The persistent, phantom audio node induces scheduling friction or thread starvation in the CarPlay audio routing daemon, manifesting as severe buffering/stuttering in whatever third-party audio app currently holds the primary AVAudioSession mixable/non-mixable slot. Questions for Apple Engineers ： Root Cause of Wireless CarPlay Routing Discrepancy: Why does the CarPlay audio routing daemon handle unreleased WebKit AudioContext nodes differently over Wireless CarPlay compared to Wired CarPlay and native device endpoints? Is there an underlying lock or stream synchronization issue within the wireless CoreAudio server pipeline? Native iOS Client Side Mitigation/Fallback: Is there an recommended pattern for the native iOS app wrapper (WKWebView container) to forcefully invalidate or tear down WebKit-initiated AudioContext sessions upon view dismissal, ensuring a foolproof fallback even if the H5 frontend fails to call .close() properly? Best Practices for Web Audio + CarPlay Integration: Are there any specific AVAudioSession.CategoryOptions or WebKit configurations we should enforce to prevent a background H5 page from interfering with the system-wide CarPlay audio scheduling? Any insights, workarounds, or documentation pointers from the CoreAudio or CarPlay teams would be greatly appreciated. Thanks!

I have an iOS app with two auto-renewable subscriptions (monthly and annual) that are fully configured and ready for their first submission. Both products have complete metadata, pricing, localizations, review screenshots, and review notes. The problem: The "In-App Purchases and Subscriptions" section does not appear on the version preparation page. It should appear between "App Review Information" and "App Store Version Release," but it's missing entirely. This means I cannot link the subscriptions to my app version for a combined submission. How I got here: I initially submitted the subscriptions for review independently (via the "Submit for Review" button on the subscription product page), not realizing they needed to be submitted alongside a binary. This resulted in a Guideline 3.1.1 rejection. I then created a new app version with a build, but the "In-App Purchases and Subscriptions" section did not appear on the version page. Not realizing this section should exist, I submitted the app — it was approved and published without the subscriptions. I have since created another new version with a fresh build. The app version, monthly subscription, and yearly subscription are all in "Ready to Submit" state. The section still does not appear. What I've verified: All subscription metadata is complete (pricing, localizations, review screenshots, review notes) Subscription group has a localization A new app version is in "Prepare for Submission" with a build uploaded All business/agreements/tax/banking setup is complete The app has no consumable or non-consumable IAPs — only auto-renewable subscriptions All subscription testing appears to work I've reviewed other forum threads with the same issue (e.g., https://developer.apple.com/forums/thread/778258) and followed all suggestions Environment: App uses StoreKit 2 via Flutter in_app_purchase plugin Two products: monthly and annual auto-renewable subscriptions First-time IAP submission for this app App is currently live on the App Store I opened a Developer Support ticket 7 days ago and have not yet received a resolution. Has anyone encountered this issue and found a workaround? Is there a way to reset the subscription review state so they can be properly linked to a version?

Hi everyone! Today I finally submitted my first iOS app for App Store review after previously publishing the Android version on Google Play. App ID: 6771439707 The app was developed with Flutter and the process was a very interesting learning experience, especially around: App Privacy configuration screenshots and metadata archive/distribution process App Store Connect setup adapting branding/assets to platform guidelines Coming from Android publishing, I have to admit the Apple review pipeline feels much stricter and more detail-oriented 😄 but also very polished once everything is correctly configured. I just wanted to thank the community because many forum posts helped me solve issues during the submission process. Now waiting for review results 🤞 Greetings from Argentina!

Hi, Hi have released a new app on May 12th, that got reviewed and approved fairly fast (3 days after a single iteration for meta data content). On May 15th, I uploaded an update on the app, improving some feedback and user experience on one of the key features of it. I was expecting a similar delay (1-3 days) but it has been 10 already, and I have not had any contact from apple. My app is related with the World Cup, starting in 15 days, and this delay is working against it ... as I cannot market the app properly until it has the desired update. The submission id is 54d8dd83-8988-499e-964f-222ce9bb4cd3 Is there anyway of getting an answer from Apple on the reason why the review is taking so long?

To the App Review and Developer Support Teams, I am writing this post to bring an ongoing and time-sensitive App Review issue to your attention, as my submission has remained in “Waiting for Review” for an unusually long period of time and standard support channels have not yet provided a clear update or resolution. Issue Summary: My app, Cupie, was submitted for review on May 21, 2026. However, the submission has remained in “Waiting for Review” since then and has not moved to “In Review” after several days. I have already submitted an expedited review request and also contacted Apple Support regarding the delay. However, I have not yet received any clear explanation, actionable feedback, or confirmation on whether there is an issue with my account, metadata, build, agreements, or submission queue. Lack of Communication: I have opened the following support cases regarding this issue, but I have not received a meaningful update so far: Case IDs: 102900823761 102901498888 The current lack of communication makes it difficult for me to understand whether my submission is properly queued for review, whether it is stuck, or whether there is any action required from my side. Impact: This is our first public launch submission, and the delay is directly affecting our launch schedule, business operations, and user onboarding plan. We are ready to provide any additional information, test accounts, explanations, or compliance materials required for App Review. Request: I respectfully request that the App Review or Developer Support team help confirm the current status of this submission and clarify whether there is any issue preventing it from moving forward. Specifically, I would appreciate confirmation on the following: Whether my app submission is properly queued for review. Whether there is any issue with my account, metadata, build, agreements, or in-app purchase configuration. Whether the submission is delayed due to additional manual review or review queue congestion. Whether any action is required from my side to proceed. App Name: Cupie - 語音視訊、聊天交友 App ID: 6768550401 Current Status: Waiting for Review Submitted Date: May 21, 2026 Related Case IDs: 102900823761 102901498888 I would sincerely appreciate a prompt update or escalation from an Apple representative, as the submission has been waiting for review for an extended period without clear communication. Thank you for your assistance. Sincerely, Cupie Development Team