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.

Hello everyone, I submitted the first update for my app on April 14. On April 18, I canceled that submission and immediately resubmitted it the same day, as many people suggested that resubmitting might help speed up the review process. Today is June 4, and after 47 days, the update is still stuck in “Waiting for Review.” I’ve seen that many other developers are experiencing the same issue, but 47 days is a very long time for me, and I have no idea how much longer I should expect to wait. I hope we can all find a solution to this situation soon. Any advice, insights, or shared experiences would be greatly appreciated. Thank you all.

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.

Hi everyone, I’m based in Europe, and I’m trying to fully understand the current App Store payment rules for an iOS app that sells digital services or premium functionality used inside the app. My goal is not to bypass App Store rules, but to implement the correct, compliant payment flow depending on the user’s region and the App Store requirements that apply there. The app would offer things like premium features, credits, or access to digital functionality inside the iOS app. The payment flow I would ideally like to support, where allowed, is: iOS app -> Cloud ahndling -> Stripe Checkout page -> user pays -> Stripe handling -> my backend marks the user as premium What I’m trying to understand is whether this flow is allowed, restricted, or prohibited depending on the user’s App Store storefront / region. My questions are: For digital goods, subscriptions, credits, or premium features used inside an iOS app, is Apple In-App Purchase still required by default? In which regions, exactly, can an iOS app use or link to an external payment provider such as Stripe for digital services used inside the app? For users in the United States, after the Epic Games v. Apple changes, can an app show an external payment option such as “Subscribe on the web” or “Pay with Stripe”? If yes, what are the exact requirements, limitations, wording rules, Apple fees, or reporting obligations? For users in the European Union, under the DMA-related rules, does Apple allow external purchases through Stripe or a web checkout? If yes, do I need specific Apple entitlements, StoreKit External Purchase APIs, Apple approval, transaction reporting, or payment of Apple fees? For the rest of the world, should I assume that Apple IAP is mandatory for digital content, subscriptions, credits, and premium app functionality unless Apple has a specific regional program allowing external payments? What is the correct way to determine which payment flow a user should see? Should this be based on the user’s App Store storefront / StoreKit storefront, rather than IP address, device locale, billing address, or country selected manually by the user? Would a regional routing approach like this be compliant? if App Store storefront == US: show Apple-compliant external purchase link / Stripe option if allowed elif App Store storefront is in the EU and the app has the required Apple entitlement: show Apple-compliant external purchase flow else: show Apple In-App Purchase only If a user pays through Stripe or another external checkout in a region where external payments are allowed, can my backend unlock premium features inside the iOS app? Or are there restrictions on granting access inside the app when the purchase was not completed through Apple IAP? For a first App Store release, is the safest approach to launch with Apple IAP only, then later add external payment options only in regions where Apple explicitly allows them? For developers who have recently submitted apps with external payment links for digital services: Which countries or storefronts were accepted? Did App Review require special entitlements? Were there specific wording or UI requirements? Did Apple require transaction reporting or apply additional fees? Were there differences between the US, EU, and other regions? In short, I’m trying to understand the practical compliant architecture: iOS app = Apple IAP by default external Stripe / web checkout = only where regionally allowed by Apple backend = unlock premium access after valid payment, whether Apple IAP or approved external payment payment UI = adapted based on App Store storefront / region I would really appreciate answers from developers, App Review experiences, or anyone familiar with the current Apple rules after the Epic ruling, DMA changes, and Apple’s External Purchase Link / StoreKit External Purchase programs. Thanks!

Hello! My subscriptions have been stuck in review for a while. I have been chasing my tail trying to get the sandbox purchases to work but the subscriptions are not returning after "sale". Is this because the subscriptions are still in review? Will the purchase ever return a product in the sandbox environment if the products are still in review? How do we get the subscriptions approved? I have submitted them with the app multiple times. The app is rejected because I can't complete it without the subscriptions but the subscriptions are never reviewed. Help!

After a 2.3.2 rejection (two promoted subscriptions had identical display name + description), I withdrew the review submission to edit the subscription metadata. The app version moved to "Developer Rejected," but both auto-renewable subscriptions stayed stuck in "In Review." There is no active review submission attached to them anymore, yet: The subscription metadata (display name / description) is locked / not editable. There is no "Remove from Review" control on the subscription page or the version page. The version page no longer shows an "In-App Purchases and Subscriptions" section. Has anyone hit this orphaned "In Review" state? Is there a developer-side way to release a subscription from review, or is contacting Developer Support the only path? Appreciate any pointers, I'm on a deadline. App: Mossly: Plant Care Journal - Apple ID 6770594348 Subscription Group: Mossly Premium - 22098178 Subscriptions, both stuck: Mossly Premium - Monthly - 6770598241 (com.mossly.app.monthly) Mossly Premium - Yearly - 6770599597 (com.mossly.app.annual1)

Hello Apple Developer Community, I'm encountering a persistent issue with my App Store Connect account where the bank account is stuck in "Processing" status, preventing me from fully activating the Paid Apps Agreement. This has been ongoing for several weeks, and despite following all recommended steps, including resubmitting tax forms, there's no progress, also contacting support who promise to reply in 48 hours but never do. This is urgent as I have 19,000 customers waiting for the app to launch, and the delay is causing significant business impact. I'm hoping someone here has experienced something similar and can offer advice, or perhaps Apple support can chime in to expedite. Account Details: Organization: Prosperity Bliss PTE Limited (Singapore-based PTE Ltd) Address: 2 Venture Drive, #19-21 Vision Exchange, Singapore, WILAYAH PERSEKUTUAN 608526 Account ID: 93410065 Agreements: Free Apps and Paid Apps Agreements are listed as Active (effective Dec 17, 2025 – Apr 18, 2026), but Paid Apps seems blocked due to banking. Bank Account: PROSPERITY BLISS (8256), Singapore, SGD currency, USD royalties. Tax Forms (all submitted Dec 15, 2025): U.S. Certificate of Foreign Status of Beneficial Owner: Active U.S. Substitute Form W-8BEN-E: Active Singapore Tax Questionnaire: Complete (resubmitted today, Dec 19, 2025, to try update the system) Issue Description: Initially, there was a yellow banner saying: "Your banking updates are processing, and you should see the changes in 24 hours. You won't be able to make any additional updates until then." This appeared weeks ago when I first added the bank details. Even after submitting all tax forms on Dec 15, the status remains "Processing," and the banner persists. I can't edit or add anything else in the Banking or Tax sections due to this lock. Steps I've Tried: Submitted all required tax forms on Dec 15, 2025 – they show as Active/Complete. Resubmitted the Singapore Tax Questionnaire today (Dec 19) as a potential fix, but no change yet. Logged out/in, cleared cache, tried different browsers/devices – no luck. Contacted Apple Developer Support via the web form (under Agreements, Tax, and Banking) multiple times over the past week – submitted tickets with screenshots and details, but no responses so far. Attempted phone support using regional numbers (+65 numbers for Singapore/Asia-Pacific), but got routed to general customer support instead of developer-specific. Requested a callback through developer.apple.com/contact/ – still waiting. From what I've read online (e.g., similar issues on Reddit and Apple Discussions), this seems like a common backend glitch, especially for non-US accounts, where the system gets into a loop (banking waiting on tax, but tax is done and locked by banking processing). Official docs say it should resolve in 24 hours, but it's been far longer. Has anyone else with a Singapore or international business account faced this and resolved it? Did you have to escalate to a specific team, or is there another workaround? Any tips on getting a faster response from support? I've attached screenshots of the Agreements page, Bank Accounts section (showing "Processing"), and Tax Forms for reference. Thanks in advance for any help – this is holding up my app distribution! Best, Frederik

Hi, I am new to Apple developer world. I am trying to publish my app. When I submit the app for review, i am getting a rejected status with unresolved issues. On the distribution page, i am getting "1.0 Invalid Binary". But no information about what the issue is that needs fixing, no email to tell me what the issue is. Has anyone seen this before? I have sent two emails to Apple, both unanswered and cannot get hold of them on the phone! As a paying member, i expect a bit more help and communication from Apple!!! app id: 6772153999

It has been 6 days since we submitted our app for review, and the status is still showing “Waiting for Review,” even though the guidelines mention reviews are usually completed within 48 hours. We also contacted support but have not received any response yet. Has anyone else experienced similar delays recently? Any advice would be appreciated.

I recently noticed that an app called Private Browsing Web Browser has been ranking at the top for the keyword “browser” on the App Store for a long time, even ahead of well-known browsers like Chrome, Firefox, and Safari. This is not only the case in the U.S.; it also appears to rank top in many other regions. This app has not been updated for a long time, and both its interface and feature set seem extremely basic. There also appears to be nobody to discuss it on the internet, and some of the App Store ratings look very suspicious. I previously reported this to the Apple team by email, and questioning about the algorithm, but they consistently responded: The App Store ranking system has no problem, and it's working as expected.” I wanted to ask everyone: Do you think it is normal for this app to rank number one for “browser” on the App Store? Also, the same developer has another very similar browser app called Snowbunny Private Web Browser, which also ranked high.

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.

Hello Apple Staff, I am writing again because my app review issue is still unresolved, and I am becoming increasingly concerned that the submission may not be properly moving through the normal App Review queue. App ID: 6760743106 Submission ID: 6950ecff-f833-404d-b04b-ac34ec552b85 Current status: Waiting for Review At first, I waited for approximately two days with no progress. Since the status did not move at all, I submitted a new build and resubmitted the app, thinking there may have been an issue with the previous submission. However, it has now been nearly one week since the resubmission, and the app is still stuck in Waiting for Review. The status has not moved to In Review. I have already tried multiple official support channels: I contacted Apple Developer Support by phone. I submitted an email support request. I posted on the Developer Forums. I submitted an expedited review request. Unfortunately, nothing has changed so far, and I have not received any clear confirmation that the current submission is properly queued for review. I fully understand that App Review times can vary, and I sincerely respect the work of the App Review team. However, this situation is becoming very serious for us. The update is important for our users, and the continued delay is creating significant operational and business impact. At this point, I am not asking to cancel the submission or resubmit the app again. I am asking whether Apple can please verify the following: Whether the current submission is properly queued for App Review. Whether there is any internal processing or queueing issue preventing the review from starting. Whether there is any action required from my side that is not visible in App Store Connect. If possible, could an Apple Staff member please escalate this case to the App Review team or confirm that the submission is correctly queued? I would be extremely grateful for any help or clarification. We are feeling very stuck because we have tried every support channel available to us, but the app remains in Waiting for Review with no progress. Thank you very much for your time and support.

To the Apple Review and Developer Support Teams, We are experiencing the same issue described in this thread: https://developer.apple.com/forums/thread/827016 Our application has been rejected under Guideline 2.1 - Performance because the subscription plans do not load during the App Review process. According to the review feedback, there's an error indicating that the In-App Purchases product list is empty. We are unable to reproduce this issue on our side. The subscription screen works correctly in TestFlight on multiple physical devices and with sandbox tester accounts. The paywall loads successfully, localized prices are returned correctly, and test purchases can be completed without errors. We have verified the following: All subscription products are attached to the submitted app version in App Store Connect. The product identifiers used in the application match the identifiers configured in App Store Connect. The relevant agreements, tax information, and banking details are active and up to date. The same build works correctly in TestFlight. The issue appears to occur exclusively in the App Review environment. This makes it difficult for us to diagnose the root cause or validate a fix. Could you please investigate whether there is an issue affecting StoreKit product retrieval during the review process? Any logs, diagnostics, or guidance on how to reproduce the App Review environment behavior would be helpful. Submission details: Date Submitted: Jun 1, 2026 at 2:01 PM Submission ID: 1260550e-ba11-4cbe-925a-7694f89ce715 Thank you for your assistance.

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

hello app review: My app was submitted for review at 11:07 PM on June 1st, and as of now, on the afternoon of June 4th, it has not yet entered the review process. Please urge the review team to proceed with the review as soon as possible. If there are any areas that need to be rectified, we will immediately make the necessary changes. Thank you

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.

Hi, I can sign in to my Apple ID, but my Apple Developer account shows a “closed” status and I’m unable to access App Store Connect features. My app is currently showing “Ready for Distribution,” so the account appears active, but developer access is restricted. I’ve already contacted Apple Developer Support and am waiting for their response. Also, I temporarily can’t access my primary email due to a verification issue, so I’ve provided an alternate contact email and phone number in my support request. Has anyone experienced a similar situation or knows possible reasons for a “closed” developer status while the app remains approved? Thanks.

Hello, I'm hoping someone from the App Review team can look into this situation, which has specific context that I believe makes it worth a careful look. Thank you in advance for your time. I'm hoping someone from the App Review team can look into this situation, which I believe has specific context that makes it worth a careful look. My app YADA: You've Already Met (App ID: 6759586097) has been in "Waiting for Review" since Wednesday May 6 at 7:44 PM ET - now over 96 hours. I have an open support case (20000112508151) filed Friday with no response yet. I'm not writing simply to flag the wait - I want to explain why this submission deserves a thoughtful second look on the merits. When YADA was submitted for TestFlight beta review, it was flagged under Guideline 4.3(b) for the same reason as the App Store rejection. I appealed, explained the differentiating mechanic, and an Apple reviewer evaluated the argument and approved the app for external testing. That approval is on record. I'm asking for consistency with that prior decision. YADA's core mechanic is genuinely unlike any dating app currently on the App Store. A user privately adds someone they already know to a list. That person receives no information about who added them. A match is only revealed when both people have independently and privately added each other. If the feeling isn't mutual, nothing is ever disclosed. There is no browsing of strangers, no algorithmic recommendations, no swiping, and no rejection possible because neither party knows they've been added until both have added each other simultaneously. Critically, YADA does not ask users to declare their gender or sexual preferences - because the mechanic doesn't require it. This makes YADA the only interest-discovery platform on the App Store that works entirely without those declarations, which creates a uniquely safe experience for LGBTQ+ users and young people who are not ready to publicly disclose their orientation. No equivalent experience exists on the App Store. The App Store rejection also included 5.1.1 and 2.1 issues, both of which I fully resolved - redesigning the contacts permission flow with a proper in-app explanation screen and directly answering Apple's question about data handling - with a new build submitted alongside my Resolution Center reply. I'm not asking for special treatment. I'm asking for the opportunity to have the full argument evaluated by a reviewer with the time to consider it, consistent with how the TestFlight review was handled. Support case: 20000112508151. App ID: 6759586097. Submission ID: abdf8b5b-5ea0-46a4-8a0b-fb58320fa701. 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, My first macOS app has been in “Waiting for Review” status since May 26. I have already checked my Apple Developer account, agreements, tax and banking information, app metadata, pricing, and in-app purchase configuration, and everything appears to be in order. Is there anything else I should check or do at this point, or is it normal for a first app review to remain in “Waiting for Review” for this long? Thank you.

My app is for a client that facilitates construction draws for construction companies. The app is stuck in a rejection loop for this reason: Guideline 3.2.1(viii) - Business - Other Business Model Issues - Acceptable Issue Description The app still provides loan services but does not meet all the requirements for apps providing these services. See below for additional information. These requirements give App Store users confidence that apps offering financial services are qualified to provide these services and will responsibly manage their data. Next Steps It would be appropriate to take the following steps to resolve this issue: The app facilitates loan or credit applications but you have not provided loan or business license documentation that demonstrates the app is authorized to provide these services. The client does not lend to consumers, nor individuals, and the client operates in states that do not require a lending license (including NMLS) to provide financing (such as construction draws) to construction companies. What documentation would app store review accept? I've tried written explanations in response to no avail.