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, I recently was rejected for the following reason: However, your app does not comply with: Legal 5.1.1 We noticed that your app requires users to register with personal information to access the app’s content and purchase in-app purchase products that are not account based. Apps cannot require user registration prior to allowing access to app content and features that are not associated specifically to the user. User registration that requires the sharing of personal information must be optional or tied to account-specific functionality. To resolve this issue, please revise your app to not require users to register before purchasing in-app purchase products that are not account based. You may explain to the user that registering will enable them to access the purchased content from any of their iOS devices and provide them a way to register at any time, if they wish to later extend access to additional devices. Resources See guideline 5.1.1(v) - Account Sign-In to learn more about our requirements for apps with account-based content and features. I replied: We require the user to login/sign up because it relates directly to the core functionality of our App. If the user deletes the App and chooses to reinstall it, his data will be saved on our server because the sign up system allows their data to be saved. This allows the User to restore all his in-app purchases and for our database to always keep track of the User’ in-app purchased consumable items. Apple requires a restore feature for in app purchases and we allow the user to restore his in app purchases by tying their account to an email or social media login. The login is required to prevent users from hacking the app. The diamond and coin systems are stored on our back end database servers. Once a user logins in, the back end stores how much coins and diamonds are associated with that account. This prevents users from manually altering how many coins or diamonds they have. It preserves the integrity of the app and the Apple App Store itself. Our servers store all user progression and data. Without the login / sign up system, we cannot sync the back end database. The login / sign up feature is crucial to the functionality of the app to prevent hacking and to keep track of the users database and more importantly, keep account and restore capabilities available for any in app purchases. To which the review board responded with: Although requesting that users register to for tracking users’ purchases and game progresses is acceptable, requiring users to fully register for an account before entering the game is not. Users should be allowed to access none account-based features before registration and login. You may also choose to alert users that accessing game without binding an account may result in losing game progress or in-app purchase items. To resolve this issue, please revise your app to let users freely access your app’s non account-based features, such as accessing the game, prior to registration or login. Once the user decides to use account-based features, the app may present the registration or login feature at that time. My understanding is this... I need to implement a "play as guest" mode where Users do not need to register. This will automatically generate an account for that User. However, am I allowed to require the user to register before conducting any in-app purchases, or other activities on the app?? What is this asking for? Do I need to allow the guest user to be able to purchase and do all the things a registered user can?

Hi there. I work for a company that develops a SaaS service. Users have to register before using the SaaS as all the data they save in the application must be linked to their account. Why that? Because it is a multi-platform SaaS currently running on web and Android, so, the user must have access to his/her contents on every platform he/she intends to use. Also, some features depend on our back-end system to process the data and return an analysis based on them. That said, Apple is rejecting our app claiming that we should not require the user to register an account before purchasing a subscription. The problem is: how can the user store their data in our servers without an account? We do offer a free tier account, but the users must be logged in to have access to their data and have the analysis performed by the back-end service. Does anybody have gone through a similar issue? I need clarifications on how to solve this. Thanks in advance.

Hi Apple Staff / App Review Team, We’re following up because we haven’t received a substantive reply to our previous forum post or our messages in App Store Connect. Context (unchanged): Our last update focused on performance/stability, bug fixes, and numeric balance tuning (difficulty/rewards). We also added a small, user-initiated News panel (globe icon in the main menu) that displays one static announcement image and can be closed at any time. There are no links, no navigation, no login/UGC/ads, and no executable content in that panel. We don’t collect personal data (no IDFA/ATT). Safeguards already in place: Post-release changes are restricted to numeric balance values only (no feature toggles, no navigation changes). The announcement is strictly read-only (one static asset from our own domain) with an offline fallback. Internal release policy forbids any post-review feature switches or concept changes. What we’re asking for: Specific guidance on what observation(s) led to the 3.2(f) determination. Whether a resubmission under the constraints above is acceptable (we can tighten further if preferred). We’re ready to provide any materials immediately and submit a new build as soon as we receive direction. Thank you for your help—could you please escalate or advise on next steps?

My app updates are repeatedly rejected under Guideline 2.3.6 – Accurate Metadata, with a request to remove “Age Assurance” unless the feature can be located. However, the app does include age assurance. During onboarding, users must enter their date of birth, and users under 16 are blocked from completing registration and using the app. The app contains a women’s health blog and a community Q&A feature (similar to Reddit), where users can ask and answer health-related questions. For this reason, I am considering restricting access to users 18 and older. Each time I explain this to the review team and provide a screenshot of the DOB screen, the app is approved. What is the correct way to document or surface this in App Store Connect so reviewers can easily find it and avoid repeated rejections? Is a DOB gate sufficient for Apple’s definition of Age Assurance?

I am submitting an app to the App Store and want to understand the best way to handle keywords that include special characters. If a keyword has accents like coração and users may search for coracao without accents, should I include both versions or rely on Apple to match them automatically?

Hello, We have completed the Age Rating confirmation form and submitted it successfully. Additionally, we increased the app version, rebuilt, and uploaded a new build as recommended. However, we still received the email stating that “Your app requires additional information”. Could you please confirm whether any further action is required on our side, or if this is a known issue on App Store Connect? Thank you.

Hi everyone, We just received another App Store rejection under Guideline 3.1.3 - Business - Payments - Other Purchase Methods, stating that we are using in-app purchases to sell physical goods — specifically, a physical QR code sent to the user. However, in our latest build, this issue was already addressed: All physical QR code purchases are now handled entirely through Stripe Checkout, outside of the app. No consumable IAPs are used for physical goods. The purchase flow is completely optional - users can tap “Continue” to skip it and still use the app without ever engaging with Stripe or purchasing anything physical. We’re a small team trying to launch and are stuck in a loop where it seems like the rejection feedback might not reflect the latest build with not clear feedback from Apple. Has anyone experienced something similar? Would really appreciate any guidance or insight — or if anyone from Apple is here, we’re happy to jump on a call to clarify. Thanks in advance!

Hello, I’m preparing a macOS app for App Store submission, and I have a question regarding whether including an extra executable inside the app bundle is permitted under the App Store Review Guidelines. My app would include a command-line tool placed inside the bundle, such as: MyApp.app/Contents/MacOS/ or MyApp.app/Contents/Resources/ The purpose of this tool is to help users collect hardware/system information for troubleshooting or error reporting. Importantly: The app never launches this executable automatically. It never runs in the background. It is intended to run only when the user chooses to run it manually. The intended workflow is: The executable is shipped inside the app bundle. When needed, the app simply informs the user where the tool is located. The user manually executes it—either by double-clicking in Finder or by running it from Terminal. The executable runs independently, and the app does not trigger, spawn, or control the process. My questions are: Is this approach allowed under the macOS App Store Review Guidelines? Could this be considered “executing external code,” a sandbox violation, or otherwise lead to rejection during App Review? Does App Review allow a tool that is bundled with the app but executed manually by the user outside of the app itself? Additionally, if there is any official documentation or guideline from Apple that specifically addresses this scenario—or similar restrictions around including executables inside a macOS App Store app bundle—I would greatly appreciate a link. If anyone has experience with this or knows how App Review typically handles this type of setup, I’d be grateful for any insight. Thank you!

I have a watch only app that display an open/close park status and the current temperature with a current condition icon. That's it. On second submission the watch app was rejected due to no WeatherKit attribution. I have a lack of clarity of what's needed. With my single view that display my content I don't want WeatherKit attribution to overwhelm what's being presented to the user. I've tried looking for watch apps in the store that provide attribution and I'm not finding any. Looking for advice on how to meet this requirement without attribution overpowering my content.

A month ago, a company filed a false complaint against one of my apps. I contacted Apple and informed them that this was untrue, uploading videos and screenshots proving that my account and apps comply with Apple's policies and that the complaint was baseless. Despite this, I was surprised to find all my apps deleted and my account flagged for deletion in the following days. What should I do? I've been wronged, and I've submitted numerous complaints and contacted technical support by phone and email, but so far, I haven't received any response or attention.

It's been a week waiting for the review Despite requesting a quick review and contacting technical support via email, there has been no change so far. What can I do? Apple ID: 6756184295

Hi everyone, I am really not sure where else to go for a piece of mind because our recent review experience has been far from clear (and probably fair). We are a photo editing app developers who deal with AI models, effects and transformations on a constant basis. I believe last year we (like many other apps in the category) introduced effects that get two people in different photos and unite them in one cute/fun/cozy/emotional picture. Be it a couple, a mother and daughter - you name it. Of course all the templates are pre-set, there is no option for users to generate any scene by text-to-image or image-to-image model. Otherwise it would be unsafe. When submitting our app to review in May, 2025 we first faced the situation that this kind of effects are not welcome because of: Guideline 1.1 - Safety - Objectionable Content The app references or includes features that some users may find objectionable or could be used to create objectionable content. Specifically: The app includes templates for generating content showing people making intimate contact with each other, such as hugging, kissing, or other intimate templates. While these templates alone may not be objectionable, they could be used to create objectionable content. Apps on the App Store should be safe, appropriate for a general audience, and should not include features that are objectionable or could be used to create objectionable content. At that first time we saw it as new general requirement and rule and complied. It took us about a month to delete the "objectionable" content and finally get approved. Time passed and what we saw in the middle of summer was ALL the huge players in the market kept providing these "objectionable content" freely, both inside apps and as store graphics. So we re-added the content, submitted, and get approved like immediately. Was it a miracle or a matter of a particular reviewer, I cannot say, however after that we didn't get any reject for months. Then around October we submitted our app for another review and history repeated itself - same reject as in May for the same reason. Nothing helps us to get through. Nothing. 5-6 appeals about the review and 1-2 about unfair treatment, no response. Did I mention that all the huge players (like 5-6 apps) keep posting the same content freely? All of them released updates for Christmas last week with Group Photos / Shared shots / Photobooth Lab featuring exactly the same 1+1=united pic concept. Our latest appeal gets reply however, all the same: We understand your position and consideration of your app's compliance with Guideline 1.1. However, we found that the app references or includes features that some users may find objectionable or could be used to create objectionable content. The app includes templates for generating content showing people making intimate contact with each other, such as hugging, kissing, or other intimate templates. While these templates alone may not be objectionable, they could be used to create objectionable content. The strange thing is the screenshot attached wasn't even connected to the case itself, it was of a filter that was applied to photo that already contained two people. I don't see any logic in the responses any more: Not only the Guideline 1.1 - Safety - Objectionable Content quotes anything about the mentioned reasons for rejection. We have carefully reviewed the entire text of Guideline 1.1, including sections 1.1.1 through 1.1.7, and we are still unable to determine which specific part of the guideline the rejected templates violate. The note states that our “couple effects” (hugging, close poses, romantic themes) could be used to create objectionable content. However, when mapped against the text of Guideline 1.1, none of the listed categories appear to apply: The effects are not defamatory, discriminatory, or mean-spirited (1.1.1) They do not depict violence, harm, or abuse (1.1.2) They do not involve weapons or illegal activity (1.1.3) They do not contain sexual or pornographic material, nor explicit activity (1.1.4) They do not involve inflammatory religious commentary (1.1.5) They do not supply false information or trick functionality (1.1.6) They do not capitalize on harmful current events (1.1.7) And so on. As reply for our "Why other apps are allowed to have this content while we don't?" they returned with this: On occasion, there may be apps on the App Store that don't appear to be in compliance with the App Store Review Guidelines. We work hard to ensure that the apps on the App Store are in compliance, and we try to identify any apps currently on the App Store that may not be. It takes time to identify these occurrences, but another app being out of compliance is not a reason for your app to be. It has been 6 months since our first instance on the matter. None of the competitors removed such content from their apps while we are constantly being forced to do so. Does this imply them having another review experience? Or do they hide the mentioned features before review and get them back right after? It's a mystery... I will really appreciate any advice on how we should deal with this matter. Thank you in advance

My app's Custom Product Page (CPP) submission has been stuck in "Waiting for Review" since its initial submission on November 28th, for over two weeks now. Key Timeline and Troubleshooting: Initial Wait and Self-Check: Initially thought it was a normal queue, but there was no progress after several days. Comprehensive Troubleshooting: I have confirmed: Developer account agreements and tax status are normal/valid. This CPP is associated only with the live, published version of the app and is not linked to any pending new version. There are no "Issues to Resolve" prompts in the App Store Connect backend. Attempted Standard Solutions: I have tried "Withdraw and Resubmit" multiple times. The operation completes successfully, but the status always reverts to "Waiting for Review" and never progresses to "In Review". Contacted Official Support: I have reported this issue multiple times through the App Store Connect "Contact Us" form and via email, explaining the suspected technical fault. However, I have not received any substantive feedback. My Core Question: Could this possibly indicate that my account or this specific CPP submission has encountered some rare "lock" or data synchronization failure within the backend system?

Hello everyone, I’ll be honest with you, the kind of honesty that comes when you’ve run out of places to turn. My name is Donovan, I’m a French student, and I’m writing here because at this point, I truly don’t know what else to do Two years ago, I started a small project to learn mobile development. Nothing ambitious at first just a personal exercise, a way to grow. But after countless late nights, weekends sacrificed, and lines of code no one will ever see… that small project became a real application. I finished it. Refined it. Carried it like something that genuinely mattered. And for the past two months, I’ve been fighting with App Review. Always for the same reason: Guideline 4.3(b) – Design – Spam. Each time, I respond. Each time, I explain. But each time, the door closes with the same cold, impersonal message: “We encourage you to reconsider your app concept and submit a new app that provides a unique experience not already found on the App Store.” Unique. Such an easy word to use… especially when no one seems willing to look closely at what’s actually in front of them. My application is a dating app, yes. I know there are many on the App Store. But I implemented a feature that no other dating app currently provides, and more importantly: the app is 100% free, no paywallsno mandatory subscription. As far as I know, there is no completely free dating application on the App Store. I even added features that were never planned, just to avoid being dismissed as “spam.” But nothing has changed. Two years of work. Two years of progressing 4–5 hours per week, between classes, exams, and everything else life throws your way. And now, it feels like all of that can be wiped away by a single generic sentence. So here I am, turning to you, the developer community, the only people who truly understand what it means to run into an invisible wall. I need your help. Your advice, your experiences, your strategies. How can I get Apple to finally accept my app? How can I avoid throwing away two year of work because of a vague, unexplained guideline? Thank you in advance to anyone who takes the time to reply

Our application, Yunlen, was unexpectedly rejected after a minor UI update, despite having been live on the App Store for nearly a year. The rejection cites "Crypto related content," an issue we have repeatedly clarified with the Apple Review Team; frustratingly, we have been forced to provide the same detailed explanation three separate times in the same review thread, indicating our responses are being ignored and resulting in a protracted and frustrating 10-day delay to a simple update.

Hi - I've tried around 6/7 variants of the Description for 'Localization' and all have been rejected, can someone provide reasons why this one in particular has beenrejected and what may be accepted please? This is my app's description: Premium Subscription Required (14 day free trial) ADHD Acclaim is the daily focus coach built with and for neurodivergent minds. Track energy, capture “wins” in a tap, and celebrate the progress that actually keeps you moving forward. WHY YOU’LL LOVE ADHD ACCLAIM • Energy-level slider suggests quick wins that match how you feel right now. • Beautiful, low-distraction design with bold colour cues and gentle encouragement. • Points, streaks, and confetti moments keep motivation friendly—not overwhelming. • Cross-screen sync means every win appears instantly on Home, Wins, Calendar, and Rewards. CAPTURE WINS IN SECONDS • Scrollable Quick Wins carousel: tap “Add Win” to log a task and cheer yourself on. • Create custom wins with notes, boost level, and schedule options. • Active Wins list shows what’s next; swipe to complete or tidy up with a single tap. MAP YOUR WEEK • Calendar view highlights upcoming or completed wins with easy-to-spot dots. • Filter by day to review achievements or add new wins directly from selected dates. MOTIVATION THAT FEELS GOOD • Earn points for every win, then redeem them for rewards you define—tea break, walk, screen time, and more. • Progress stats surface total wins, energy trends, and milestone streaks without information overload. DESIGNED WITH ADHD IN MIND • Calmer typography, carefully tuned contrast, and purposeful colour accents reduce cognitive noise. • Positive microcopy, lightning-fast interactions, and accessible layouts support focus at any energy level. • Built-in celebration toast and confetti toggle let you control how much excitement you need. FREE TRIAL & PREMIUM Start with a 14-day free trial to explore everything. Stay on the free tier for core win tracking, or upgrade to ADHD Acclaim Premium to unlock unlimited rewards and advanced planning tools. Cancel anytime in Settings—no pressure, just support. SUBSCRIPTION & BILLING • Payment is charged to your Apple ID at confirmation. • Subscription renews automatically unless cancelled at least 24 hours before the end of the current period. • Manage or cancel anytime in your App Store account settings; refunds aren’t provided for unused portions. • Any unused portion of a free trial is forfeited if you purchase a subscription. Need a hand? Reach the team at xxxx —real humans ready to help. https://www.apple.com/legal/internet-services/itunes/dev/stdeula/

Context After our latest update we received a termination notice referencing 3.2(f) (feature/concept switching after review). The update itself included performance/stability improvements, bug fixes, numeric balance tuning, and a small user-initiated News panel (globe icon in the main menu) that displays a single static announcement image and can be closed at any time. There are no links, no navigation, no login/UGC/ads, and no executable content in that panel. We do not collect personal data (no IDFA/ATT). What we’ve done so far Restricted any post-release changes to numeric balance values only. The News panel remains strictly informational (one static image from our own domain with offline fallback). Prepared a short screen recording and code excerpts that demonstrate these constraints. Questions for the community Has anyone faced a 3.2(f) action in a similar scenario (read-only announcement panel)? What clarifications or evidence helped your appeal? Which additional safeguards (domain allow-list, redirect blocking, formal release checklists, etc.) proved most convincing to App Review? Is it helpful to provide a short video (tap globe → panel shows a single image → close) along with code snippets confirming there’s no navigation or executable content? References / Illustrations Main menu and News button: /mnt/data/62591a87-a516-499a-a743-86ace7e9e3a4.png Store creative preview: /mnt/data/337413b0-e5db-466c-bd04-28efa7fb6b52.png News panel mock (single image): /mnt/data/A_screenshot_of_a_mobile_game's_update_news_screen.png Any practical advice or precedents would be greatly appreciated. Thanks in advance!

Hello everyone, We received a Pending Termination Notice on Nov 4, 2025, flagging our developer account for removal under Section 3.2(f) of the Apple Developer Program License Agreement. The notice alleged that our app submissions "repeatedly violated the App Review Guidelines in an attempt to evade the review process." We unequivocally state that there was no intent to evade review or act dishonestly. The repeated submissions were actually a result of our efforts to resolve a trademark dispute regarding our app icon with a third party. We were in active legal negotiations to update our assets to a compliant design. The resubmissions were attempts to update the metadata to comply with these legal requests. Unfortunately, this overlapped with the App Review process and created the appearance of "evasion." Case Details: Case Number: 102748595474 App ID: 1599464287 Notice Date: Nov 4, 2025 Current Status: Appeal submitted; awaiting review. What we've done so far **Legal Resolution:** We are now in the final stages of a legal settlement with the third party. We have obtained a statement from our legal counsel and evidence of this settlement to demonstrate our Good Faith and commitment to the App Store Guidelines. **Appeals Submitted:** We have diligently followed standard procedures and submitted three formal appeals, with the latest one submitted on Nov 22. **Support Contact:** We have contacted Developer Support multiple times via email to follow up. Questions: * Given the expiration of the termination deadline, is there any way to confirm if our account is safe from automatic removal while the review is ongoing? * Are there any additional steps we should take to bring this to the App Review Board's attention? * Is there any other documentation we should submit to expedite the process? The 30-day appeal window ended on Dec 4, and this deadline has now passed. We are deeply concerned that our account may be automatically terminated despite our full cooperation and pending appeal. Having been a dedicated developer for over 8 years, we are eager to resolve this amicably. Thank you for your time and assistance.

Our solo traveler safety app has been rejected multiple times; for random reasons. Latest rejection demands "manual check-in each time" for location display — this requirement doesn't appear in published Guidelines 5.1.2 or 5.1.5. BUT!! We built the feature anyway: users invisible by default, must tap Check In to appear on map, auto-expires 24hrs. Submitted video proof, screenshots, detailed notes. Age rating set to 18+. (its not even adult but we did it anyway as to match our own policy) Comparable apps (Couchsurfing, Life360, Snap Map) approved without this requirement. Time-critical: investor meetings Bangkok Dec 11, flight Dec 10 11pm GMT - 15 months development. UK registered company. Has anyone dealt with unpublished requirements being applied inconsistently? Any advice appreciated - I cant get through to dev/app review team or senior advisors. And lovely call handlers in cork tried his. best but cannot do anything - ive not slept for near 24 hours due to unknown reasons - some minor make sense, and other just made - but we covered it anyway; im not sure what to do??? HELP

Hi! i have a problem with my app being rejected by spam, i believe this rejection may be a misunderstanding due to our account history This application provides unique and critical functionalities exclusively for our company's registered business partners. I suspect the "Spam" flag was triggered because we previously attempted to submit this app using an individual developer account During that review, your team correctly informed us that this app required an "Organization" account, not an "Individual" one. I try to delete the app from the old account and i have an error too "This app cant be deleted" That initial submission was never approved and never published on the App Store. Following your instructions, we spent the last three months securing our verified Organization account. This new submission is from the correct, official Organization account as you required. I try to appeal and i dont have an answer, recently i update another app with two new functionalitys and still rejected by spam. How can i fix that? The reviewers only says something "We still found the issue" and no help. We are a medical health company reconigzed in Uruguay and we need to make this app available for our clients. I cant request a call too explain because no option appear when i request support in the web. Please, tell me what can i do?