An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

I am planning an iOS security and content-blocking app for unmanaged consumer iPhones. The app would not provide a traditional VPN service. It would not offer: Remote VPN servers Geographic location switching Access to a private corporate network IP-address masking as a service Anonymous browsing Instead, the app would allow the user to: View destination domains contacted by the device Classify destinations such as trackers, advertising, analytics, or potentially malicious domains Manually block selected domains Keep connection history and filtering decisions on the device I understand that NEFilterDataProvider and NEFilterControlProvider are the APIs intended for network content filtering. However, according to TN3134, these providers are not generally deployable for an unmanaged adult consumer iPhone. I also understand that TN3120 says NEPacketTunnelProvider should not be used as a general-purpose local content filter. This appears to leave a gap for an unmanaged consumer security app whose core feature is user-controlled, system-wide domain blocking. I am considering whether NETunnelProviderManager with an NEPacketTunnelProvider could support the feature, but I do not want to use the packet-tunnel API outside its supported purpose. My questions are: Is there currently a supported Network Extension architecture for system-wide, user-controlled domain blocking on an unmanaged adult consumer iPhone? Can an app with this purpose use NEPacketTunnelProvider, or would that necessarily be considered the unsupported general-purpose filtering use described in TN3120? If such an architecture is supported, could an app with this purpose be treated as an approved security or content-blocking provider under Guideline 5.4 rather than as an app offering a traditional VPN service? App Review Guideline 5.4 states that apps offering VPN services must be submitted by developers enrolled as organizations. It also states that parental-control, content-blocking, and security apps from approved providers may use NEVPNManager. For an app that does not provide a remote VPN service but uses Apple’s VPN configuration infrastructure only for local security and user-controlled blocking, must the developer still enroll as an organization, or may an individual Apple Developer Program member submit it?

Hello App Review team, My app (App ID: 6745896828) was rejected on Friday, July 17. I addressed the points raised and resubmitted the same day. Since then, the build has stayed in "Waiting for Review" with no update or response. This is highly unusual for our account: I have shipped regular updates for over a year, and every single review has been completed within 24 hours. Something appears to be stuck on this specific submission. This is a major version that our partner venues are actively waiting on for a business-critical feature (in-app reservations), so the delay has a direct impact on us. Could the App Review team please look into why this submission is stalled? Case ID: [102945425814] Thank you.

Hi everyone, I'm looking for advice regarding an unusually long App Review process. Our app was initially submitted on July 7, 2026. During the review, Apple rejected the app under Guideline 2.1 – Information Needed because the demo account was not available due to a backend deployment ("User not found"). We immediately resolved the issue by creating and verifying the demo account, replied to the App Review team with the working credentials, and requested an expedited review. However, after providing the updated credentials, our app has remained in the review queue for several days without any further updates. We have also contacted Apple Developer Support and followed up multiple times through the App Review thread, but we have not yet received any information about the current status or whether there are any remaining blockers. This is our first App Store release, and the continued delay is affecting our planned public launch, business commitments, and customer onboarding. Has anyone experienced a similar situation after resolving a Guideline 2.1 issue? Is there any additional action we can take to help move the review forward, or is waiting the only option at this stage? Any guidance or suggestions from the community or Apple engineers would be greatly appreciated. Thank you!

Dear App Review Team, First, I must admit my mistake and sincerely apologize for wasting your time. After my app was previously rejected under Guideline 5.6, I filed an appeal, which was subsequently approved. You instructed me to submit a new binary for review. Due to an error on my part, I submitted a new version and removed the previous submission record; consequently, the new submission was not linked to the ID associated with the approved appeal. I am writing today to provide the ID for my new submission: 0760b84f-00b6-4c77-a1a3-ab9040143c06 The submission ID associated with the approved appeal was: fb5b0474-3ed0-4a38-82c8-3e7553743d1f My App Apple ID : 6764726742

We're hitting a submission deadlock with a Capacitor-based iOS app that I suspect will affect any app using Capacitor/Cordova (or similar frameworks distributed as prebuilt binaries) once Xcode 27 ships. Setup: App built with the current Xcode, targeting the current SDK. Embeds Capacitor.framework and Cordova.framework (via ionic-team/capacitor-swift-pm). The loop: Using Ionic's latest official release: these prebuilt frameworks are still built against an older Xcode/iOS SDK. App Store Connect rejects the upload with ITMS-90111 (stale SDK), even though the app's own target and every other embedded framework are current. To fix that, we rebuilt Capacitor.framework/Cordova.framework from Capacitor's open-source iOS source (MIT-licensed, same version as the official release) using the current Xcode — confirmed via archive that every framework now reports the current SDK. That upload is then rejected with ITMS-91065 (missing signature) — the rebuilt frameworks lack an Apple SDK signature that (as far as we can tell) only Ionic's own build pipeline can produce. So: official release → current-SDK check fails. Self-rebuilt release → signature check fails. We verified this isn't a fluke with an isolated throwaway-archive test swapping only the framework source. Questions for anyone who's solved this: Is ITMS-91065's "Apple SDK signature" requirement satisfiable by re-signing a self-built .framework with our own Distribution certificate during export, or does it specifically require Apple's own build-time signature that third parties can't reproduce? Has anyone shipped a Capacitor/Cordova app successfully against a new major Xcode/SDK before Ionic cut a matching signed release? If so, how? Also filed with Ionic: ionic-team/capacitor#8537 (https://github.com/ionic-team/capacitor/issues/8537) — no response yet as of 2026-07-23.

Hi everyone, I submitted an app update for review on July 16, and the status has been stuck at "Waiting for Review" for a full week now (7 days and counting). The app is not in a sensitive category (not health, finance, VPN, or gambling related), and there are no legal or export compliance issues that I'm aware of. A bit of background: App type: update (not a new app) Submission date: July 16, 2026 Apple Developer Program membership: active and in good standing No messages in Resolution Center or App Store Connect inbox No changes made to the submission during this period (no metadata edits, no new builds uploaded) I understand review times can fluctuate, but 7+ days in "Waiting for Review" — not even "In Review" — without any communication seems unusually long, especially for a routine update. Has anyone else experienced similar delays recently? Is there anything suggested beyond withdrawing and resubmitting (which I'd like to avoid)? Thanks in advance!

Our app has been stuck in "Waiting for Review" with no movement for 10 days. Timeline: July 13: Submitted version 2.0.1 (App ID 6584518186, a stability release) July 18: Resubmitted as 2.0.2 (build 133) with additional crash fixes — same app, same metadata Since then: no review start, no rejection, no metadata request, nothing. What we have already tried: Five (5) expedited review requests — all with concrete justification, zero response A status inquiry through Contact Us (App Review) — no response Review notes and a working demo account are fully provided and verified end-to-end Why this is urgent: this is a critical stability release. Firebase Crashlytics shows our crash-free user rate on the live version dropped to 55% — nearly half of our daily active users experience crashes (1,400+ crash events per 24 hours). The fixes are all in the waiting build. Every day of delay directly harms real users. Questions: Is there any way to find out whether a submission is simply queued vs. placed on an internal hold? App Store Connect shows only "Waiting for Review" either way. Is anyone else currently seeing 7+ day waits? (I've found several similar threads from February and May 2026 with no resolution posted.) Is there any escalation path left when expedite requests and Contact Us both go unanswered? App ID: 6584518186 Any guidance would be greatly appreciated.

Hello, I'm experiencing a serious issue with my Apple Developer account. Every app I submit stays in "Waiting for Review" for more than a month. This is not happening with just one app—it affects every app I submit. Here are the details: Every submission remains in Waiting for Review for over a month. The status never changes to In Review. I have already contacted Apple Developer Support. I also submitted an Expedited Review request, but the apps are still waiting. The apps fully comply with the App Store Review Guidelines and are complete and functional. At this point, I'm trying to understand whether there could be an issue with my developer account or if there is another reason causing all of my submissions to remain stuck in the queue. Has anyone experienced the same issue recently? If an Apple engineer sees this post, I would greatly appreciate any guidance or if my account could be checked. Thank you.

Hi all, Our latest submission has been sitting in "In Review" for 11 days with no movement, and I'm hoping someone here (or App Review staff) can advise. Details: App: utapp App ID: 6767597442 Bundle ID: com.bounced Status: In Review since July 10 What we've already tried: Expedited App Review Request submitted on July 17 (no response). App Review Status submitted on July 21 (no response). Is anyone else seeing 10+ day "In Review" times right now? And is there anything we should be doing on our side, or is this an internal processing delay? If any App Review staff sees this, could you please confirm whether any action is needed from us? Thanks in advance.

Hello! My app beFamily (version 1.0.0) is already live on the App Store and has active users. I have developed and completed the subscription functionality, but I have been unable to release it because my auto-renewable subscriptions have been stuck in review for more than a month. The current state is inconsistent: The subscription group "beFamily Plans" is marked as In Review. Both subscriptions remain Waiting for Review. There is no active App Review submission containing these subscriptions. My app version 1.0.1 is in Prepare for Submission, but the "In-App Purchases and Subscriptions" section is missing, preventing me from attaching the subscriptions to the app version. If I submit the app without them, it is rejected under Guideline 2.1(b) because the reviewer cannot locate the subscriptions. This issue has now been blocking my subscription launch for over a month, preventing my users from purchasing subscriptions and preventing my business from generating subscription revenue. I have already: Opened a Developer Support case. Submitted Feedback Assistant report FB23817386. Posted the issue on the Apple Developer Forums. Performed all recommended troubleshooting steps without success.

Our app — a screen-time / focus app — has had no App Review activity for two weeks, and we believe the trigger was an automated Guideline 2.5.1 check that froze an otherwise actively progressing review. (This forum account is linked to the developer account in question; we can provide the App ID, bundle IDs, submission IDs, and support case numbers through any private channel on request.) Context: Jul 2–5: Our first submission (Version 1.0.0) was under active review. We went through several ordinary metadata / paywall-related iterations, and the reviewer responded within roughly 24 hours each time. Nothing related to Screen Time was raised in these human reviews of builds 9 and 10. Jul 8: After we submitted build 11 — which addressed the remaining human-review feedback — we received an automated Guideline 2.5.1 (Performance: Software Requirements) message stating that the app uses the Screen Time API but has not been submitted with the Family Controls entitlement, and that review of the submission cannot proceed. All reviewer activity stopped at that point, and there has been none since. What we verified: The Family Controls (Distribution) entitlement is granted to our account and assigned to all four bundle IDs (the main app plus its DeviceActivityMonitor, ShieldAction, and ShieldConfiguration extensions). We verified with codesign that com.apple.developer.family-controls = true is present in the code signature and embedded provisioning profile of every one of the four executables in the submitted IPA — so the entitlement named in the automated message is present in the flagged build. For context: builds 9 and 10, with an identical Screen Time API surface and identical entitlements (verified at the binary level with nm against the submitted artifacts), had been human-reviewed on Jul 2–5 with no Screen Time-related objection. We recognize those builds may simply not have reached the automated analysis stage before being superseded, so we do not draw firm conclusions from that. What we did anyway (build 12, submitted Jul 9): In case the automated check actually concerns the separate com.apple.developer.family-controls.app-and-website-usage entitlement (which we do not request and do not need), we removed every reference from our main app to the APIs associated with it: AuthorizationStatus.approvedWithDataAccess, ManagedSettings.Application.bundleIdentifier, ManagedSettings.Application.localizedDisplayName, ManagedSettings.ActivityCategory.localizedDisplayName, and ManagedSettings.WebDomain.domain. We verified with nm that none of the four executables in the build 12 IPA reference these APIs. The app does not use FamilyActivityData, DeviceActivityReport, app usage events, web usage events, or App and Website Usage data access. No automated message has appeared for build 12. What has happened since: Jul 9–14: No reviewer activity on build 12. We filed an expedited review request and opened two Developer Support cases (Jul 8 and Jul 14). No response to any of them. Around Jul 15: Hoping to clear the frozen state, we cancelled and resubmitted the same Version 1.0.0 / build 12. Around Jul 17: Filed a second expedited review request for the new submission. Jul 22 (today): The new submission has been in "Waiting for Review" since Jul 15, with no reviewer activity and no reply to either support case or either expedite request. What we are asking: Could someone check whether the Jul 8 automated flag is still attached to the app record and blocking reviewer assignment, and help get the current submission assigned to a reviewer? If the automated check flags build 12 again, could the message specify which entitlement and which binary / API references triggered it, so we can address it precisely? We can provide codesign output, entitlement plists, provisioning profile dumps, and nm symbol listings on request. Thank you.

Hello Apple Developer Support, My app has been in the "Waiting for Review" status since July 3, and I am concerned because the update has not yet been reviewed. App Name: Trading Insights - AI Charts This update is important, and I would like to make it available to my users as soon as possible. So far, I have: Submitted an Expedited App Review request. Contacted Apple Developer Support regarding the delay. Unfortunately, the app is still waiting for review, and I have not received any indication of whether there is an issue with my submission. Could you please check if there is any problem with my app or my submission that is preventing the review from starting? If there is anything I need to fix or provide, I would be happy to do so immediately. I would greatly appreciate any assistance or guidance. Thank you for your time and support. Kind regards, Jawad

I have been rejected twice under Guideline 2.1(b) because my In-App Purchase subscriptions are not submitted for review. I cannot figure out how to attach them to my submission. Here is my situation: I have 6 auto-renewable subscriptions fully configured in App Store Connect under "Barrel Pro Subscriptions" — all have screenshots, pricing, descriptions, and review notes My app is iOS only, built with React Native/Expo My current version is 1.1, Build 10 (1.1.0) The problem: The "In-App Purchases and Subscriptions" section does not appear anywhere on my version page. I have scrolled to the very bottom and it is not there. I cannot find any way to attach my subscriptions to my submission before clicking "Submit for Review." The blue info box on the Subscriptions page says: "Your first subscription must be submitted with a new app version. Select it from the app's In-App Purchases and Subscriptions section on the version page." But that section does not exist on my version page. What I have tried: Cancelling the rejected submission and starting fresh Creating a new version (1.1) manually Uploading a new build (Build 10) Checking both "In-App Purchases" and "Subscriptions" sections in the sidebar Has Apple removed this section from the version page? How do I attach my subscriptions to my submission in 2026? Any help is greatly appreciated. Thank you.

I need to vent some real frustration with App Review. Our app "AlphaOmega" has been live on the App Store since July 6, 2026. We submitted a routine update (version 1.0.4, not a new app) on July 11. It sat untouched in the review queue for 10 full days before anyone even looked at it. For an update to an already-approved, already-live app, that's not acceptable. And when it finally got reviewed on July 21, we got rejected under Guideline 4.1(a) "Copycats," with this justification: "Specifically, the app's icons include references to Omegle." That's it. No screenshot comparison, no explanation of what "reference" means. I put our icon next to Omegle's actual icon myself (attached below): Ours: white Greek letters Α/Ω overlapped, purple gradient background Omegle's: a blue background with a white comma-shaped swirl They share nothing — not color, not shape, not any design element. Our app name comes from the Christian phrase "Alpha and Omega," has nothing to do with "Omegle" beyond a partial spelling overlap. This isn't a borderline case that needs interpretation — it's just wrong. We've already replied to the review message with this clarification and separately submitted a formal appeal to the App Review Board. We also requested an expedited review — it made no difference. What makes this especially hard is that we built this app so our church community could finally have it. People have been anxiously checking in day after day, hoping to be able to use it together. This is how the cycle usually goes for us: submit, sit in the queue for days waiting for a reviewer to even look at it, sit in "In Review" for days more, then get rejected for a reason that doesn't hold up to two minutes of scrutiny — fix it, resubmit, and start the whole cycle again, with no guarantee the next rejection will even make sense. We've stayed up late more than once just to catch a review update, only for it to end exactly like this. Is this really how Apple treats developers? At this point I'm seriously reconsidering whether I want to keep building for iOS at all. So right now: 10 days to get a wrong answer, a canned one-line rejection with zero evidence, and I have to spend more time writing replies and appeals just to get a human to actually look at two icons side by side. Meanwhile the update sits blocked with no ETA. Is this the normal experience now? Anyone else dealing with 10+ day waits for simple updates, followed by rejections that don't hold up under two minutes of scrutiny? App Information: App Name: AlphaOmega Apple ID: 6783182206 Bundle ID: com.zoven.omega Platform: iOS Version rejected: 1.0.4 (build 26)

Hi all, I'm hoping someone has seen this before. My app's first submission was rejected, but I cannot find the rejection reason anywhere. What I see: The app-level status shows "Rejected". Under App Review, the submission itself still shows "In Review". There is no reviewer message / no Resolution Center message anywhere, and the in-app purchases are all marked as rejected too. The rejection email only says to visit the App Review page, but the link just opens the App Store Connect root (appstoreconnect.apple.com) with no details. What I already tried: App Store Connect on web (Safari/macOS and Firefox/Windows) and the App Store Connect iOS app — all three show the exact same state. Hard reload, private window, sign out / sign back in. Opened an App Review contact request asking for the specific reasons — no response until now. So the app is clearly rejected, but the submission status and the reviewer feedback never propagated on my end. It looks like a backend status/desync issue. Questions: Has anyone experienced this "rejected but stuck on In Review with no message" state? Where else can the rejection details appear, or is it purely a matter of waiting for the backend to sync? Roughly how long did it take to resolve for you? App: CountTally Submission ID: e9bf771c-a5a2-471f-9db4-7b7038d4ebf9 Thanks a lot for any pointers!

Hello, I'm looking for advice from other developers who may have experienced unusually long App Review times. Here is my situation: • I submitted five apps on March 2, 2026. • They remained in Waiting for Review until the end of April. • They have now been In Review for several months. • I also submitted CampusGo Connect on May 14, 2026, and it is still Waiting for Review. I have contacted Apple Developer Support several times. They confirmed that my apps are still in the review process, but there have been no updates or requests for additional information. I have also verified that my Apple Developer Program membership is active, all agreements are accepted, and my App Store Connect account is functioning normally. Has anyone experienced review times this long? If so: • How long did your review eventually take? • Was there anything you did that helped? • Is there anything else I should try besides continuing to work with Developer Support? Thank you for any advice.

Hello, My first App Store submission (Apple ID 6769883617) has been stuck in "Waiting for Review" since July 12. Timeline: July 12: Submitted for review. July 18: Expedited review requested and approved. July 19: Contacted App Review through Contact Us / App Review Status. July 21: Still no status change and no response. I understand that review times can vary, but over 9 days in "Waiting for Review", an approved expedited request, and no reply from App Review no longer seems like a normal review timeline. Has anyone experienced this recently? Is there another way to reach the App Review team or verify that my submission isn't stuck? Any guidance would be appreciated. Thank you.

Hello, Our app submission has remained in “Waiting for Review” since 7/14. App: Skald: Odyssey Apple ID: 6790579937 Version: iOS 0.1.0 Support case: 102944762837 We contacted Developer Support on 7/17 and submitted the App Review status/contact form on 7/21, but have not received a response. App Store Connect does not show any action required from us. The submission metadata, review notes, contact information, demo credentials, and backend access are complete and available. Could an Apple representative please confirm that the submission is correctly queued and escalate the case if necessary? This delay is now significantly longer than our usual review times, and we have been unable to get a status update through the normal support channels. We would appreciate confirmation that the submission is not stuck and that no action is required from us. Thank you.

Hi my app is still "Waiting for Review" since almost a week now. Is it normal? Thank you!

Hi, I just wanted to post to see if anyone else is experiencing extremely poor customer support from Apple. I have sent emails regarding the delay for the app review and heard nothing back, I have tried to call the worldwide support but get stuck in queues for over 3 hours before being disconnected. Has it always been this poor? My app has been stuck in review now for over a week despite it saying 48 hours, and whenever I try to reach out for help I receive no response. Could anyone please advise. Thank you!