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. 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.

Most ASO tools I’ve found, like Appfigures, are effective but too expensive for my current app income. I’m exploring cheaper alternatives such as Astro—has anyone used it or compared it with tools like Appfigures or Appvector?

My app has been stuck on 'Waiting for review' for over 4 days. Unlike before, I will get feedback within 48 hours, but now I have been 4 days in and no one seems to have checked the app at all. Any advice?

This is my first iOS app release and I’m a bit confused. The initial version was reviewed in under 12 hours (rejected), and the corrected version was approved just as quickly. But my Product Page Optimization with only screenshots has been stuck in “Waiting for Review” for four days. Do these get reviewed only with new versions, or should I just wait it out?

It's been more than a week since the App was validated and published. Yet, the IAP (subscriptions) are still waiting for review. I've sent an email to Apple 5 days ago on the topic and i'm still waitinf or an answer. I have to ship a complete version to my client quickly, can anyone do something, like an admin passing by by any chance ? Or does anyone have a tips/trick to unstuck me ? :') Note : I've tried to send another version with a note saying "please review my IAP", the version got accepted but the IAP are still not reviewed... Thanks in advance, Have a good day.

Hi, We’re reaching out to the community because we’re stuck in a situation that’s becoming critical for our launch timeline and could really use some advice. We submitted our app on August 11, 2025. Over the following days, we worked closely with App Review, made revisions, and provided every piece of information they requested. On August 19, 2025, we finally received this message: “Your submission’s review will require additional time as we take this new information into account. We do not require any further information at this time. Once we have thoroughly reviewed your submission, we will either contact you in App Store Connect to communicate any issues found, or your submission will be approved.” We followed up days later and got this response: “We apologize for the delay. Your submission is still in review but is requiring additional time. We will provide further status updates as soon as we are able.” It’s been 12+ days with no updates, and the app is still stuck in “Unresolved Issue” status. This delay has now pushed us past our launch deadline, and we’re unsure why the process is taking so long. We completely understand that expedited reviews aren’t always possible, but given the urgency and importance of this project, we’re doing everything we can to move forward. If anyone from App Review happens to see this, or if any developers have gone through something similar and can share advice, we’d really appreciate it. Thanks in advance!

Hello everyone, I’ve been struggling with App Store Review regarding my delivery app, and I’m hoping someone here can shed light on whether my app actually requires In-App Purchase (IAP) under Apple’s guidelines. Here’s my situation: My app connects riders with delivery jobs. We have two rider payment models: Commission Plan (10%) – Riders don’t pay upfront, but 10% is deducted per completed delivery. Fixed Subscription Plan – Riders pay a fixed monthly fee in advance, which allows them to keep 100% of their delivery earnings. The challenge: Apple Review has rejected my app multiple times, insisting that I must use IAP for these payments. I’ve written back and forth with them several times explaining that: The commission plan isn’t a digital feature, it’s simply a revenue share from physical delivery work. The fixed plan is more like a business service fee for using the platform, not for unlocking content or digital features. Despite this, the Review Team continues to state that my app “requires IAP.” My questions are: Based on Apple’s official guidelines, do apps like mine (delivery/logistics with commission/subscription for riders) really fall under IAP rules? Has anyone here had a similar issue with a marketplace or service-based app? If this does require IAP, what’s the reasoning — since the payments are tied to real-world services, not digital content? I’d appreciate advice, shared experiences, or even clarification from someone who has successfully passed review with a similar model. Thanks in advance!

I use import * as StoreReview from 'expo-store-review'; In my onboarding I do: const requestAppRating = async () => { try { console.log('Requesting app rating via StoreReview'); if (await StoreReview.isAvailableAsync()) { console.log('Store review is available, requesting rating'); await StoreReview.requestReview(); } else { console.log('Store review not available on this device'); // Fallback: show alert encouraging manual rating Alert.alert( 'Rate Oddible', 'Enjoying the app? Please take a moment to rate us on the App Store!', [ { text: 'Maybe Later', style: 'cancel' }, { text: 'Rate Now', onPress: () => { console.log('User chose to rate manually'); // You can add a link to the App Store here if needed }} ] ); } } catch (error) { console.error('Error requesting app rating:', error); } }; This works perfectly in my development build but my production build in the app store does not pop up to request a review from a user. Any idea why this could be the case?

Hi everyone, I currently have two apps stuck in TestFlight beta review for over 30 days without any progress: App ID: 6749024874 — Case ID: 102673603146 App ID: 6749025418 — Case ID: 102673604516 I contacted Apple Support, but they told me this situation is “normal.” From my experience, TestFlight reviews usually take a day or two, sometimes up to a week, but not this long. Has anyone else experienced such long delays with TestFlight beta reviews? Is there anything I should do (cancel and resubmit, escalate further, or just wait)? I would also like to request support from the App Review team to look into these case IDs and provide clarification. Thank you.

I’m working on an iOS app and need help with ASO to find the best keywords for title, subtitle, description, and keyword field. Can anyone suggest free tools that show keyword volume, difficulty, and competitor keywords?

A 1.69% App Store conversion rate could be due to factors like unclear value proposition, unoptimized screenshots, or lack of strong reviews. Improving visuals, refining your app description, and gathering positive ratings can help boost installs.

Hi everyone, I’m relatively new to the App Store and currently navigating a review situation. I’d really appreciate any advice or perspective. Here’s the timeline: Aug 11: I submitted version 1.3.0 of my app (App ID: 6742771536). Aug 12: The status moved from “Waiting for Review” to “In Review.” Since then, it has remained in In Review for about 13 working days without further updates. In the past, my submissions have typically moved through review more quickly, so I’m wondering if there’s anything I might be overlooking. I do have a pre-order release scheduled for Sept 2, 2025, so I want to make sure everything is on track. ❓ My questions: -Is it normal for some apps to remain in “In Review” for this long? My previous version was approved within a few hours. -Should I cancel the review and resubmit? I saw folks here mentioned that is a bad idea. -Could there be any metadata or review note details I should double-check? -For newer developers, is this something that occasionally just happens as part of the process? Thanks in advance for any guidance — I’d love to learn from the experience of others here.

When submitting an app for review, will any unreviewed auto-renewing subscriptions within the app be reviewed simultaneously? I own an app that has passed review and offers an auto-renewing subscription A within the app that has also passed review. To test a new service, I plan to create a new auto-renewing subscription B, which I do not intend to submit for review. After creating Subscription B, I plan to submit the app for review as part of an app update. In that case, is there a possibility that Subscription B will also be reviewed?

Dear Apple Review Team, The app I submitted has been pending for several days and hasn't entered the review process yet. Could you please help check if there is any issue causing this delay? APP Name:小马AI美术 BundleID:com.hangzhouyq.art.xmai

I understand how frustrating ASO can be when progress feels slow. To grow beyond keyword optimization, it helps to learn from indie developer resources, communities, and guides that focus on practical app marketing strategies and visibility.

The app I submitted has been waiting for review. APP Name:小马AI美术 BundleID:com.hangzhouyq.art.xmai

Our app was recently rejected during review under the Guideline 2.5.1 - Performance - Software Requirements, with the reason that we’re using a non-public API: "pacga" However, based on our investigation: We are not explicitly calling this API in our code or in any linked frameworks. We ran the suggested checks (strings, otool) on the app binary and included frameworks, and found no private API usage. From what we understand, "pacga" is not an API at all, but an ARM64e instruction (Pointer Authentication Code Generate Address) automatically generated by the compiler for devices with ARM64e support (A12 and newer). This is part of Apple’s Pointer Authentication (PAC) security mechanism introduced in iOS 12. Sharing a few references: https://developer.apple.com/documentation/security/preparing-your-app-to-work-with-pointer-authentication https://www.usenix.org/system/files/usenixsecurity23-cai-zechao.pdf https://clang.llvm.org/docs/PointerAuthentication.html#id9 Given this, we suspect the rejection might be a false positive triggered by the presence of this instruction in the compiled binary rather than actual private API usage. Has anyone else run into a similar rejection recently? If so, how did you resolve it with App Review? Thanks in advance.

Hi, I have an iOS app that only makes GET requests to my own API (hosted on Cloudflare Workers). The app only receives information for its settings (like whether to show a coupon code). It does not send, collect, track, or share any user data, and I do not store or process any personal information. I understand that technical details (like IP address, user-agent, device information, etc.) are automatically sent as part of the internet protocol. Since I don’t log or use this data, I’m unsure if it counts as “data collection.” However, it is possible that Cloudflare collects this information for security purposes and deletes it after some time. Question: In this case, can I select “No data collected” in the App Privacy section of App Store Connect? Thanks!

Description: Hello, I recently received the following email from Apple: We're writing to inform you that your company isn't in compliance with the Apple Developer Program License Agreement (DPLA). Section 11.2 (Termination) states: (g) if You engage, or encourage others to engage, in any misleading, fraudulent, improper, unlawful or dishonest act relating to this Agreement, including, but not limited to, misrepresenting the nature of Your Application (e.g., hiding or trying to hide functionality from Apple’s review, falsifying consumer reviews for Your Application, engaging in payment fraud, etc.). Be aware that manipulating App Store chart rankings, user reviews or search index may result in the loss of your developer program membership. Please address this issue promptly. I’m trying to understand how other developers handled this warning. Could you please share your experience: Did you identify what triggered the warning? Did you need to remove or change anything in your apps? Did Apple require a formal response or evidence? How did you confirm that the issue was resolved? Any guidance would be greatly appreciated.

Should you rely only on organic installs, or would a mix of strategies work better? Isn’t optimizing keywords and refining creatives essential for higher visibility? Would running Apple Search Ads not further amplify reach? And doesn’t encouraging strong reviews ultimately help in improving both ranking and credibility?

Hello All, It’s been almost a month, and I’m trying to submit my app’s first version, but I keep getting rejections with the reason “App Completeness – No Connectivity.” Here’s the timeline: • Initially, the app was rejected for app completeness. • I scheduled a review appointment, and during that session, the reviewer confirmed the app was working fine. • The reviewer only asked for permission policy changes, which I implemented and resubmitted. • After resubmission, the app was rejected again with the same “App Completeness – No Connectivity” issue. The reviewer in the first session mentioned it might have been a connectivity issue on the device during testing. So, I scheduled another review appointment, but that appointment request was declined. To date, I have made 13 submissions, and 10 were rejected for the same reason. I have also raised multiple appeals, but haven’t received any response. The app works perfectly on multiple devices and iOS versions, and TestFlight testing is successful. Has anyone faced this issue before? How can I resolve this and prevent repeated rejections? Any suggestions would be appreciated. Thank you.