My app has been stuck in “Waiting for Review” for a very long time and I’m honestly getting really frustrated. I already fixed all previous issues and submitted everything properly, but there has been no update at all. This delay is seriously affecting my launch plans and business operations. I understand reviews can take time, but the waiting period feels unusually long compared to my previous submissions. Has anyone else experienced this recently? Is there anything I can do to speed up the review process or get an update from Apple? I’d really appreciate any advice or shared experiences. Thank you.

Hello, I honestly don’t understand what’s going on with my app review. My app was already approved before, and I submitted a new build on April 7th with some new features and important bug fixes. Since then, it has been stuck on “Waiting for Review” with absolutely no update. It’s been 40 days now, which is honestly unacceptable. I even submitted an expedited review request, but that didn’t help either. The worst part is that this build contains bug fixes for users, and the delay is directly affecting the app experience. Waiting this long without any response or progress is really frustrating. Can someone from Apple please look into this and help resolve it ASAP? Thank you.

Hello Apple Review Team, Our app (Apple ID: 6758392381) has been stuck in “Waiting for Review” for the past 6 days. We have already contacted Apple Support and also submitted an Expedited Review Request, but unfortunately we haven’t received any response or update yet. This delay is affecting our release timeline, and we would really appreciate any guidance regarding the current status of the review. Could you please let us know: If any additional information or documentation is required from our side? If there is any issue or blocker causing the delay? We are ready to provide any details or make any necessary changes immediately. Thank you.

I have two auto-renewable subscriptions (RedBird.Monthly and RedBird.yearly) that have been stuck in "Waiting for Review" status through 4 separate app version submissions and approvals. Each time I submit a new app version, the app itself gets approved and released, but the subscriptions remain in "Waiting for Review" and are never reviewed alongside it. I have: Added screenshots to both subscriptions under Review Information Filled in all required localization fields Submitted the app with a build attached each time Tried clicking "Submit for Review" on each subscription individually The subscriptions are part of a subscription group called "RedBird Premium." The app is a Capacitor-based iOS app (com.redbird.wellness). Has anyone experienced this? Is there a specific step required to explicitly link subscriptions to an app version submission in the current App Store Connect UI? The "In-App Purchases and Subscriptions" section described in Apple's documentation does not appear on my version page. Any help appreciated.

Dear App Review Team, We would like to kindly follow up regarding our app submission, which has been in “Waiting for Review” status since Apr 10, 2026, with no progress update to date. We have also submitted 3 expedited review requests, plus 2 support requests email but unfortunately have not received any response yet. This prolonged delay is now significantly impacting our project timeline and scheduled deployment commitments. We understand review times can vary, but it has now been over a month without movement or communication. App ID: 6752937247

Dear App Review Team, I hope you are doing well. I am writing regarding our game My Garage Story (App ID: 6762339825), which has been stuck in the “Waiting for Review” status for a very long time. My Case ID is 102886678091. I have already contacted support multiple times regarding this issue, but unfortunately, we have not received a proper resolution or update yet. It has now been almost 3 weeks, and we kindly request that this matter be treated with priority and resolved as soon as possible. We currently have the game available for pre-order in the US region, and we are eagerly waiting for the review approval so we can officially launch it for iOS users. Our next build is also ready with further polish, optimizations, and bug fixes. Additionally, the same game is already live on Google Play under a changed title and the same developer account. For your reference, I am sharing the Android version link below: https://play.google.com/store/apps/details?id=com.playspare.mycardealershipsimulator We also have an active Discord community of around 400K members who have been waiting for the iOS release for quite some time. Due to the current delay, our iOS launch plans are being heavily impacted. We kindly request you once again to please review this case seriously and help us get the app into review and approved as soon as possible. Thank you for your time and support. We look forward to your response.

Hi App Review Team, My app Fluto AI: Anime & Art Painter (Apple ID: 6762746586) has been in "Waiting for Review" for 17 days with no update. Quick timeline: the app was previously approved but unpublished. After minor changes I resubmitted, it was rejected and a demo video was requested. I added the public video URL to App Review Notes and resubmitted. Since then, no movement, no messages in Resolution Center, no response to my support case or expedited review request. Could someone please confirm if there's a blocker or any additional information needed? Happy to provide anything immediately. Thank you.

Hello, Our iOS app “DOITDO” has been stuck in “Waiting for Review” since April 29, 2026, and it has not entered the “In Review” stage yet. This is the first App Store review submission for this app. Timeline: April 29, 2026: Submitted version 1.0.0 for App Review May 6, 2026: Submitted an expedited review request because the app had already been waiting for 7 days May 15, 2026: Apple Developer Support confirmed that the expedited review request was accepted and said the review should begin shortly May 19, 2026 KST / May 18, 2026 Pacific Time: The app is still in “Waiting for Review” with no status change App details: App Name: DOITDO Platform: iOS Version/Build: 1.0.0 Bundle ID: com.d107.doitdo Original Submission Date: April 29, 2026 Current Status: Waiting for Review We have checked the required review information, including the demo account, backend availability, and review notes. We do not see any pending action, rejection, metadata rejection, or request for additional information. At this point, the delay appears to be far outside a reasonable review timeframe, especially because the expedited review request was already accepted several days ago. The app has now been waiting for approximately 20 days since the original submission without entering review. We understand that expedited reviews cannot be guaranteed. However, we are not submitting a new expedited review request. We are asking whether Apple can investigate why this already-accepted expedited review has not moved forward. Could someone from Apple please check whether there is any blocker, queue issue, compliance issue, account issue, or missing information preventing the review from starting? If there is no blocking issue on our side, we would greatly appreciate it if this could be escalated to the appropriate App Review team so the review can begin as soon as possible. Thank you.

Hi Apple Developer community and Apple Review team, I'm hoping to get assistance with a persistent 4.3(a) rejection for our app ByGate (net.bygate.vpn). Submission ID: c8278a90-8e90-45b2-9256-d2e6b34e9518 Latest review date: May 19, 2026 Our situation: ByGate is not a generic VPN tool. It is a dedicated client application for ByGate's proprietary server infrastructure. The app works exclusively with ByGate servers - users cannot enter custom addresses, import third-party configurations, or connect to any other provider. It is functionally similar to a banking app or a streaming app: it only connects to one specific service. We have been operating ByGate as a cross-platform service: Android app live on Google Play Windows desktop app distributed via our website macOS desktop app distributed via our website Active paying subscriber base across all platforms Our existing users regularly contact our support team asking when the iOS version will be available. They are already using our servers and subscriptions on other devices and want the same experience on iPhone. Why we believe the rejection doesn't apply: Apple's own guidelines (4.8) recognize "apps that are a client for a specific third-party service" as a distinct, legitimate category. ByGate fits this exactly - the same way Netflix, Spotify, or any banking app is a dedicated client for one specific service. The concern about "similar binary" is understandable - like many VPN apps, we use an open-source networking library. But using a shared networking library (like WireGuard, OpenVPN, or in our case libbox) does not make an app conceptually identical to others, just as using SQLite doesn't make a database-backed app a duplicate of every other such app. Unique features of ByGate not found in other apps on the App Store: Split tunneling mode specifically pre-configured for Russian-language internet services Anonymous account creation (no email or phone number required) Freemium model with 100 MB free tier, no registration required Access exclusively to ByGate's own server nodes in Europe and USA Our 24/7 support on Russian-language We have responded to every rejection with detailed explanations, but receive only the standard templated response. We are genuinely committed to compliance and would welcome direct guidance on what specifically needs to change, or a review call with the App Review team. Thank you for your time.

I'm building a custom keyboard extension that offers voice dictation. Because keyboard extensions are constrained (memory cap ~30–48 MB, restricted audio session access), I delegate recording to my container app: User in a host app (e.g., Safari) taps the mic in my keyboard extension. The keyboard calls extensionContext.open(URL("myapp://dictation")) to launch the container app. The container app records audio via AVAudioEngine + SFSpeechRecognizer, writes the final transcript to the App Group, and signals completion via a Darwin notification. 4. The user is expected to be returned to the original host app (Safari) automatically so they can keep typing. The problem (step 4): On iOS 26.4 I can no longer identify which app was the host. Every previously-known path returns nil for the keyboard extension's host: parent.value(forKey: "_hostBundleID") → returns the literal string parent.value(forKey: "_hostApplicationBundleIdentifier") → returns NSNull xpc_connection_copy_bundle_id on the underlying XPC connection (via PKService.defaultService.personalities[…]) → returns NULL NSXPCConnection.processBundleIdentifier on extensionContext._extensionHostProxy._connection → returns nil proc_pidpath(hostPID, …) → EPERM from the keyboard sandbox LSApplicationWorkspace.frontmostApplication → selector unavailable from the extension RBSProcessHandle.handleForIdentifier:error: → returns an RBSServiceErrorDomain error Without the host's bundle ID, the container app has no way to call LSApplicationWorkspace.openApplicationWithBundleID: (the technique that worked on iOS 25 and earlier). UIApplication.suspend() correctly sends the container to background, but iOS treats us as a "fresh launch" — it returns the user to the Home Screen instead of Safari, because the container app was launched by an extension, not directly by Safari. KeyboardKit's maintainer reached the same conclusion (issue #1014) and shipped 10.4 without the feature. My questions: Is there a public, App-Store-safe API in iOS 26+ for a custom keyboard extension to identify its host application, or for the container app (launched via the extension's openURL) to identify which app initially hosted the extension that opened it? UIOpenURLContext.options.sourceApplication reports the extension's own container, not the actual host. 2. Is there a public mechanism for "return to source app" when the container app was launched by an extension's openURL? Equivalent to the ← Source affordance iOS shows for normal inter-app openURL, but triggered programmatically by the launched app. 3. Some popular keyboards (e.g., 微信输入法 / WeChat Keyboard) still appear to round-trip through their container app on iOS 26.4 and return the user to the original host — including the iOS ← WeChat back affordance in the host's status bar afterward. What's the recommended approach to achieve this? If it requires a specific scene-activation flow, NSUserActivity pattern, or extension-context configuration, please point at the relevant docs. 4. If there is no public path today, is FB22247647 (or a related radar) the right place to track this? Should developers in this position migrate to in-extension audio capture (which has its own significant constraints in keyboard extensions)? I'd much rather not rely on private APIs. Concrete guidance — or even an acknowledgment of which direction Apple intends — would help thousands of custom-keyboard developers who currently have a degraded voice-input experience on iOS 26.4+. Tested on iPhone 12 Pro Max running iOS 26.4.2 (build 23E261), Xcode 26.x, Swift 5. Thanks!

Hello all, I had submitted an application for review on 9th of April and it is still not reviewed It has been 40 days today and I still haven’t received any status update on the app. I have created multiple support tickets but the customer Care executive keeps linking some other developers app to my account and it is very frustrating. I tried calling the Apple support but i there is not response. The IVR made me wait for 30 minutes before I decided to hang up. has anyone else faced such an issue before? what can I do here?

I want to share how I truly feel about this situation. I have spent years building every single app on my account before publishing anything on the App Store. Each one represents months of work, testing, and genuine effort to create something valuable for users. I am proud of what I built and I stand behind every app I have ever submitted. I honestly do not believe I deserve this decision. I have never intentionally violated any guideline. I have never tried to deceive Apple or users. I have always engaged with the review process in good faith, even when it was difficult and took months. The notice itself states that automation may have been used as part of the review process. I strongly believe this was an automated mistake. A human reviewer who looks carefully at my submission history and my apps will not find evidence of concept switching or hidden features; because there is none. I am a student in France. This account is how I support myself. Losing it overnight, after years of work, without a proper human review, is devastating. I am not asking for special treatment. I am asking for a fair human review of my case before a final decision is made. Thank you for reading this.

I am trying to submit a new app and now this message comes up: The items below are required to start the review process: English (Canada) - Privacy Policy URL - This field is required Arabic - Privacy Policy URL - This field is required Croatian - Privacy Policy URL - This field is required English (Australia) - Privacy Policy URL - This field is required Show Details What is it, and what to do? Dan Uff

I set up all the App Store details, including support info and other required information, but I’m having an issue when adding a build and trying to save. The Save button turns red, and I’m not sure why. It’s not showing what I’m missing in the setup.

Hello Apple Developer community, I am seeking help with a recurring App Store rejection under Guideline 2.1(a) - Performance - App Completeness. My app crashes on launch specifically on iOS 26.4.2 and I have confirmed this is a platform-level bug in React Native — not an issue with my application code. BACKGROUND My app is Highway Exit Food Finder — a navigation utility built with Expo SDK 55 / React Native 0.83. It has been in review for several weeks and has been rejected multiple times due to a crash on launch on iPad Air M3 and iPhone 17 Pro Max running iOS 26.4.2. THE CRASH Every crash log shows the same signature: Exception: EXC_CRASH (SIGABRT) Location: ObjCTurboModule::performVoidMethodInvocation Thread: com.meta.react.turbomodulemanager.queue The crash occurs during TurboModule initialization — BEFORE any JavaScript code runs. This means no application-level code change can fix it. CONFIRMED PLATFORM BUG This crash is documented in: github.com/facebook/react-native/issues/54859 github.com/expo/expo/issues/44680 These issues confirm that React Native's New Architecture TurboModule system throws an NSException during async void method invocation on iOS 26 that cannot be caught, causing SIGABRT. WHAT I HAVE TRIED Removed expo-notifications (possible crash source) Removed react-native-maps Simplified all screens to static components Set newArchEnabled: false in app.json Upgraded to Expo SDK 55 Submitted 17+ builds attempting to fix this Despite all these changes the crash signature remains identical across all builds because the crash happens at the platform level. MY QUESTIONS Has anyone successfully gotten a React Native Expo app approved on App Store Review while running iOS 26.4.2 on review devices? Is there a known working configuration for Expo SDK 55 that avoids the TurboModule crash on iOS 26? Has anyone successfully appealed a 2.1(a) rejection caused by a platform bug rather than app code? Can Apple review devices be updated to use a stable iOS version for reviewing React Native apps while the iOS 26 compatibility issues are resolved? DEVICE AND BUILD INFO Review device: iPad Air 11-inch M3 OS: iPadOS 26.4.2 Framework: Expo SDK 55 / React Native 0.83 Build tool: EAS Build All crash logs reference the identical TurboModule crash signature Any help or guidance from the community or Apple engineers who monitor these forums would be greatly appreciated. Thank you.

Hi, I've been developing and releasing apps on app store for a while now. Around 11 days ago, I sent my latest (3rd) application to review, soon enough got a rejection message with guidelines. It was normal for me because it happens on all applications, same day I addressed all issues. Uploaded a new build, wrote in review notes that what I did to fix these guideline issues. However since that time my app is stuck on "Waiting for Review" I would take that as normal but there is one strange point, when I go to "Subscription" page, my 3 subscriptions are stuck "In Review" for over 9 days. Is it because I tried to release the app directly with a subscription method included? I don't know. I can not remove the subscription now to update the app without any pro features either. Contacted Apple Developer Support, however no answers from there also. Did anyone else had a problem like this, and how did you reach to a fix? Thank you

Hi, My external TestFlight build has been waiting for review for over 2 days with no update or response. App details: App name: Propzo Bundle ID: com.propzo.ai Version: 1.0.0 Build 2 Developer Apple ID: eswarpropzo Submitted: May 14, 2026 I have also tried contacting Apple Developer Support via the contact form but the dropdowns are not working. Has anyone experienced this delay? Is there anything I can do to expedite the review? Thank you

Hi everyone, I’m looking for guidance from developers who have dealt with App Review for health-related apps. I have an app that presents users with a questionnaire using images and multiple-choice answers. Based on the responses, the app categorizes the user into a general diabetes risk category. A few important points about the app: The app does NOT provide a diagnosis. The app clearly states that it is informational/advisory only. We added disclaimers throughout the app. We included references to published research papers the methodology is based on. The app does not connect to medical devices or Apple Health. No treatment or medication recommendations are provided. However, the app keeps getting rejected during App Review. Apple is asking us to provide documentation/approval from health regulatory authorities for every country where the app will be distributed. This is where I’m confused: Is this actually required for apps like this? Are reviewers classifying this as a regulated medical device? How are similar diabetes risk / health risk apps on the App Store handling this? Is there a recommended way to position the app as wellness/educational instead of diagnostic? We’ve already tried: strengthening disclaimers, clarifying that it is not a diagnosis, removing strong medical claims, submitting from both personal and organization accounts. Still receiving the same type of rejection. Would really appreciate advice from anyone who has successfully navigated this type of review process. Thanks!

Hey everyone, We recently submitted our new dating app, Rove Dating, and it’s been rejected under Guideline 4.3(b) — “Design: Spam.” I’d really appreciate your insights, especially from anyone who’s faced something similar or has experience getting nuanced apps approved in a saturated category. Before building Rove, we spoke to dozens of users of existing dating platforms. We consistently heard the same thing: people are deeply dissatisfied with current apps. They’re overwhelmed, burned out by swiping, and frustrated by endless choices and low-quality interactions. It became clear that the problem isn’t that there are “too many” dating apps — it’s that most aren’t adapting to how people actually want to date in 2025. We designed Rove to address those pain points head-on, with a totally different approach to matching, message limits, and emotional safety. We believe our app meaningfully improves the dating experience — but we’re having trouble getting that across in the review process. Below is the explanation we’ve been submitting, which we feel strongly communicates how Rove is different. If anyone has tips, feedback, or even just a second set of eyes on how we’re presenting this, I’d be grateful! –– Response to Guideline 4.3(b) – Design – Spam We respectfully disagree with the assessment that Rove Dating duplicates existing apps. Rove is not a clone of existing dating apps — it introduces original interaction mechanics and novel safety features designed to address the growing frustration users feel toward current dating platforms. ⸻ What Makes Rove Dating Unique Rove Dating is a highly curated experience that intentionally limits user engagement to foster more meaningful, emotionally safe interactions: Key Differentiators: • No Swiping or Infinite Browsing: Users see a small, rotating selection instead of endless feeds. • Limited Conversations: Each user can have only 3 active conversations at a time. • “Shoot Your Shot” Mechanism: • Men can initiate contact with a limited set of women. • If a woman declines, the man can try with someone else — if not, he must wait. • Women can only receive inbound messages, helping prevent message fatigue. This constraint-based system: • Reduces inbox overload (especially for women). • Encourages higher-quality, intentional messages. • Mimics real-life social dynamics — where opportunities are limited and meaningful. ⸻ Innovative Safety System: MPAA-Style Behavior Ratings Rove also introduces a first-of-its-kind safety feature inspired by the MPAA film rating system: • Male users are assigned a community-informed behavioral safety rating (e.g., G, PG, R) based on in-app messaging analysis. • Women can quickly assess a match’s tone, trustworthiness, and vibe before engaging. • This system encourages respectful behavior and promotes a safer, more transparent dating environment. This type of behavioral transparency does not exist in any other dating app currently on the App Store. ⸻ Conclusion Rove is not another swipe-based clone. It is a thoughtfully reimagined dating platform built around scarcity, respect, and intentionality. Its mechanics — from conversation caps to safety scores — are fundamentally different from other offerings in the App Store’s dating category. We hope you’ll reconsider Rove on the merits of its original features, purpose-driven design, and unique safety innovations.

Hello, I'm posting again — and unfortunately, I already know how this thread is going to go. My app (ID: 6756186616) has now been stuck in "In Review" for 80 days. To save everyone time, here is the reply I expect to receive within a day or two, copy-pasted from the response on my last thread: "Thank you for your post. We're investigating and The App Review team will contact you in App Store Connect to provide further assistance. If you continue to experience issues during review, please contact us." Nothing actually happened after that reply last time. No follow-up in App Store Connect. No further communication. Just silence. When I escalated to Developer Support (case #20000111565861), I was told explicitly that Developer Support has no way to reach the App Review team and no authority to intervene on submissions stuck in review. So Developer Support points back to App Review, and the standard forum reply points back to "contact us" — which loops back to Developer Support. This is a closed loop that doesn't actually resolve anything for an independent developer. Concrete questions: Is there any real escalation path that doesn't end in an automated reply? Why has a submission been "In Review" for 80 days with zero communication? What should a solo developer do when both Developer Support and the forum response are dead ends? I'm not asking for special treatment. I'm asking for the review to actually move — in either direction. A rejection with feedback would be infinitely more useful than 80 days of silence. Thank you.