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

App Store Connect displays the In-App Purchases and Subscriptions section on your app's version page when your app has an In-App Purchase or subscription with a Ready to Submit status. To locate the In-App Purchases and Subscriptions section: In Apps, select the app you want to view. In the sidebar, select the app version. On the version page, scroll down to the In-App Purchases and Subscriptions section. For more information, see Submit an In-App Purchase.

I have a very embarrassing problem. that I can't transfer my macOS app to another account. and above is wrong picture. I already tried to delete the apps group. but it doesn't work. this transfer is very important for our team. if anyone can tell me how to do, I will be very grateful.

The Screenshot specifications page lists iPhone Duo as an iPhone screenshot size: Outer display: 1398 × 2034 and 2034 × 1398 Inner display: 2007 × 2853 and 2853 × 2007 https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications I cannot find a way to upload them. In App Store Connect, the App Previews and Screenshots device selector on my app's version page does not list iPhone Duo. The only iPhone options are the existing display sizes. In the App Store Connect API, ScreenshotDisplayType has no Duo case. The largest iPhone case is still APP_IPHONE_67. I checked the current reference: https://developer.apple.com/documentation/appstoreconnectapi/screenshotdisplaytype My questions: Where in App Store Connect do I upload iPhone Duo screenshots? If the option is not open yet, is there a ScreenshotDisplayType case for Duo that I should use through the API instead? Thanks.

Hello, I am looking for guidance on a submission that has been in review for an unusually long time, and to ask whether other developers are seeing the same thing. App: Kids Coloring & Learning Games Apple ID: 6754971485 Platform: iOS Support case: 20000144299546 Timeline: 14 Aug 2026 — submitted, entered Waiting for Review 14–24 Aug — no movement (10 days), never entered In Review 25 Aug — cancelled and resubmitted the identical build ~3 Sept — entered In Review Today — still In Review That is 35 days since first submission and about 17 days in In Review. I have contacted Developer Support and my expedited review request was accepted and confirmed. Despite that, there has been no further movement and no communication. There are no messages in Resolution Center and the review team has not asked me for anything. This is an update to an app already live on the App Store, in the Kids Category with in-app subscriptions. The build itself is unchanged from a version that was previously approved. My questions: Is there a way to find out whether something specific is blocking this review, as opposed to it simply being queued? Are other developers currently seeing extended In Review times, particularly for Kids Category apps with subscriptions? Is there anything further I should do, or is waiting the only option at this point? I would rather fix a problem on my side than keep waiting if something is actually wrong. Any guidance would be appreciated. Thank you.

Hello Apple Developer Community, I am an independent developer and I have reached a point where I genuinely do not understand what the correct path forward is. I have invested a very significant amount of personal time and money into Zivoo. The app has never been released on the App Store. Every time App Review provided feedback, I tried to address it seriously and substantially redesign the product instead of simply resubmitting the same application. The first versions of Zivoo focused on real-time social communication. Later, the app was rejected under Guideline 4.3(b) because Apple considered the experience too similar to existing dating apps. In response, we substantially redesigned the product again. Profile browsing, swipes, likes, skips and mutual-like mechanics were removed. The current Zivoo is focused on language learning and real-time language practice through active conversation rooms, AI-assisted room discovery, entry requests, live conversations, voice/video messages, reactions, shared mini-games and invitations for future practice. The application-specific code, backend, UI system, custom assets, product logic and more than 35 custom animations were developed specifically for Zivoo. We have never purchased a white-label app, cloned another application, purchased an app template or repackaged another developer's product. We do use standard third-party SDKs such as Yandex Mobile Ads, mediation SDKs, Firebase, AppMetrica, Lottie and others. During this process, we may also have made an important mistake. Previous Zivoo submissions used: confident.zivoo, ru.zivoo.social The current submission uses: ru.zivoo.talk All of these Bundle IDs belong to the same Apple Developer Team. Zivoo has never been published on the App Store, and multiple versions of Zivoo have never been publicly distributed at the same time. After previous rejections and major redesigns, we removed previous App Store records. Because the concept had changed significantly, we mistakenly believed that the redesigned product should be submitted under a new App Store record and Bundle ID. This was never intended to bypass App Review or distribute multiple copies of the same app. The current submission has now been rejected under Guideline 4.3(a), stating that it shares a similar binary, metadata and/or concept with apps submitted by us or other developers. The most difficult part of this process is that we are never clearly told what exactly is considered wrong. With each rejection, we receive a broad guideline reference, but not a specific explanation of which code, asset, metadata element, feature or concept triggered the decision. We currently see two possible explanations: Apple's systems may be matching the current submission against our own previous Zivoo submissions under different Bundle IDs. Shared third-party SDK components may be contributing to the binary similarity signal. Our technical analysis shows that standard third-party libraries represent a substantial portion of the measured build. We fully understand that this does not prove that the SDKs caused the rejection. At this point, however, I am afraid to simply make random changes and resubmit again, especially because the latest rejection also includes an Extended Review warning. I am not asking for automatic approval or special treatment. I simply want to understand what Apple actually expects us to fix. Can 4.3(a) be triggered by a developer's own previous submissions under different Bundle IDs, even if none of them were ever released? Can common third-party SDKs contribute to the similarity determination? And if Apple believes our application-specific code, assets or concept are similar to another developer's app, how can we verify or address that? I am prepared to provide client and backend source code, Git history, original design files, dependency information, build details and a live demonstration. If anyone has experienced a similar case, especially after removing previous app records and submitting a substantially redesigned version under a new Bundle ID, I would greatly appreciate hearing how it was resolved. If Apple Staff sees this post, I would be extremely grateful for concrete guidance on what exactly we should do next. Thank you.

Hello, my app "YOGO Loops" (Apple ID: 6799279746) has been approved and is "Ready for Distribution", but it is unavailable in all 27 EU countries. App Store Connect > Business > Compliance shows: Digital Services Act | 27 countries or regions | Last Updated: 11 Aug 2026 | Status: In Review Pricing and Availability shows "Trader status not provided" / "Cannot sell" for all EU territories. Everything else is Active: Tax forms (W-8BEN): Active Administrative Cooperation Directive (7th amendment): Enabled Trader information (address, phone, email): submitted I am an individual developer based in Germany, so my main market is completely blocked. Apple states a review time of about 5 business days, I am now at day 38. I have already filed a support request with Apple. Has anyone had a DSA verification unstuck after a delay like this? Is there an escalation path beyond the standard support form? Thank you.

Hi everyone, I would like to ask if anyone else has experienced a longer-than-usual "In Review" phase recently. Here is the timeline for our app, App ID: 6800282515: Submitted for Review: Sep 14 at 05:00 Pacific Time Checked and found status in "In Review": Sep 14 at 19:00 Current Status: Still "In Review" (as of Sep 17, 19:00+) It has been in the "In Review" state for over 3 full days without any updates, rejection notices, or requests for additional info. Has anyone run into a similar issue lately? Is there any recommended way to handle this, or should we just wait a bit longer? Any advice would be greatly appreciated!

Hello Apple Developer Support, My Apple Developer Program membership was terminated under Section 3.2(f), and I would like to petition the App Review Board for reinstatement. However, I am unable to access the Developer Support / reinstatement process. When I select “Get Started,” I am asked to sign in. After successfully signing in with the Apple Account associated with my developer membership, the page redirects and enters a login loop, so I cannot submit a request. My account currently appears as CLOSED in App Store Connect. Could Apple Developer Support please advise how I can submit my reinstatement petition, or assist with creating a support case for my terminated membership? Thank you.

Our app, Roll (Apple ID: 6797953438), has received two Guideline 4.3(a) spam rejections. Our responses have gone unanswered for almost 3 weeks, and then we got an account warning. August 27: First rejection. We replied requesting clarification, explaining the app’s functionality, and supplied a walkthrough video. September 14: After almost three weeks without clarification, we submitted a substantially revised build with new functionality. We included an explanation directly in the App Review notes. September 15: The exact same rejection, still without identifying the issue or addressing our notes to them. This time, it included a warning about account removal for repeated noncompliance. It seems Apple is refusing to read our replies. Instead, they got back to us with the same rejection and a warning. For what? Doing as we were told and writing a reply? Note that thus far, NONE of our replies have even been acknowledged. Has anyone resolved a similar 4.3(a) rejection? What helped you get specific clarification or a call with App Review?

Hi everyone, I recently switched my Apple Developer Program membership from Individual to Organization. Following the change, App Store Connect is asking me to complete Form W-9. I am not a U.S. resident, and I believe I need a different tax form for my situation. On September 3, I emailed Apple Support asking them to review this and make the appropriate form available. It has now been two weeks, and I still haven’t received a response. Has anyone experienced a similar issue after converting their account to an Organization? If you managed to resolve it, which support team or contact channel helped, and how long did it take? Is there a way to follow up or escalate the existing request? If anyone from Apple is reading this, I would appreciate guidance on the next steps. Thank you for your help!

Hello, We would appreciate some guidance regarding an unexpected StoreKit currency result in a TestFlight build. Our iPhone language and region are both set to France. The Sandbox tester is also configured for France, and our subscription products have French availability and pricing configured in App Store Connect. In the TestFlight build we diagnosed, StoreKit reports the current storefront as France with EUR: storefront=FRA/143442/EUR However, all 10 subscription products are returned with USD product metadata: products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE Example: formatCurrency=USD locale=fr_US_currency_USD localeCurrency=USD display=1,99 $US price=1.99 We first observed this through Flutter's in_app_purchase integration. To determine whether the Flutter plugin was involved, we added a native StoreKit 2 diagnostic to the same TestFlight build. The native result was identical: receipt=sandboxReceipt storefront before=FRA/143442/EUR storefront after=FRA/143442/EUR products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE The issue appears specific to the TestFlight distribution. When the application is installed directly from the development computer, prices are returned in euros on the same device. We also tested with the regular Media & Purchases account signed out and a French Sandbox tester connected. Once the products loaded successfully, StoreKit still returned USD metadata. In another configuration, the application displayed the USD price while Apple's purchase sheet displayed the price in euros. We are using the price and formatting information returned directly by StoreKit. We do not want to infer the currency from the device region or perform a client-side currency conversion, because StoreKit should remain the authoritative source. Could you please help us understand: Is it expected for Storefront.current to report FRA/EUR while Product.priceFormatStyle.currencyCode, its locale currency, and Product.displayPrice use USD? Could a TestFlight or App Store Connect configuration cause product metadata to use a different currency from the current storefront? Is there another account, availability, pricing or distribution setting that we should verify? Is there a recommended way to refresh or invalidate the product metadata used by a TestFlight installation? We have already filed Feedback Assistant report FB24723329, which is currently under investigation. Thank you very much for any clarification or additional diagnostic steps you can suggest.

Recently I was trying to update my app to detect and support the latest Series 12 and Ultra 4 watches, as there is an element in the app that draws on the corners of the watch, hence corner radiuses must be matched with the device. That is a very small change, and I was still using Xcode 26.6 to build that app, as the app still supports watchOS 8.4 and above for now. However, the binary was rejected with the following in App Store Connect: 90389: Size limit exceeded. The size of the watchOS variant at “/Payload/Pigeon.app” is 105MB, which exceeds the maximum allowable size of 75MB after app thinning. For details about reducing your app’s size, view: https://developer.apple.com/documentation/xcode/reducing-your-app-s-size. Considering that the recent prior builds (the last being from Sep 7) all uploaded and processed fine, with pretty much similar contents and sizes, just minor fixes and minor feature changes for TestFlight users, I don't see why this latest build should be rejected, unless there is a change in how it is calculated under the hood. My prior presumption was that the size limit was calculated based on each architecture slice, so as long as no slices exceed 75MB, it should be alright. (and it appears to be the case for the past years) My guess here is that, since the uploaded binary still contained an armv7k slice, it fails the validation, as perhaps something was changed in the backend to not consider it, but rather to consider as a whole, which resulted in the rejection. The requirement to have a minimum SDK of 27/Xcode 27 only starts on April 2027, so until then, I don't see why there should be a change in this calculation or premature size limitation for app updates that still target watchOS 8. I've tried to recompile the app with an updated minimum OS deployment of watchOS 9 via Xcode 27, which drops armv7k, and sure enough, App Store Connect takes it. I've filed this as FB24807214. I assume it's a bug. Let me know if it isn't. Thank you. PS: Food for thought, its 2026, all watches that supports the latest watchOS 27 comes with 64GB of storage, up from 8/16GB of storage, in 2017, when the watchOS app size limit was last increased from 50MB to 75MB. Maybe its time for a fresh review?

Dear Apple Developer Support Team, I am writing to urgently escalate my Apple Developer Program enrollment issue regarding Case Number 20000132030420. I have been trying to enroll in the Apple Developer Program for almost two months, but my enrollment is still pending. I have contacted Apple Support multiple times and followed the instructions provided, but unfortunately, I have not received any meaningful update or resolution. More than a month ago, I was asked to submit my government-issued ID for verification, which I submitted as requested. Since then, I have received no update regarding the status of my enrollment. I have also attempted to contact support regarding this case, but my messages have not received a response. This prolonged delay is extremely frustrating and is preventing me from moving forward with my development work and publishing plans. I have been patient and have followed every step requested by Apple, but after nearly two months without a resolution, I am requesting that this case be urgently escalated to the appropriate team and that my enrollment status be reviewed. Please provide me with: An update on the current status of my enrollment. Confirmation that my submitted government ID has been received and reviewed. The reason for the continued delay, if applicable. A clear timeline for when my Apple Developer Program enrollment will be completed. I sincerely hope @Apple @Support can look into this matter and resolve it as soon as possible. This is now my last option to reach out again for support, as I have already spent considerable time trying to resolve this through the existing support channels. I would greatly appreciate a prompt response and resolution to Case #20000132030420. Kind regards,

Logged a case (ID 102964944684) and concerned our business-critical app will be removed from our account as a result of our subscription failing to be renewed, despite the fact we renewed on Sep 11 and have record of the renewal charge on our card.

Hello App Review, Our iOS app was rejected under Guideline 5.6 (Developer Code of Conduct). The message states that the app appears to contain features intentionally hidden during review, and that this pattern is commonly associated with fraudulent activity. We want to address this correctly, but the current note does not identify the specific flow, screen, or behavior that was observed. Without that, we cannot investigate the exact issue. Could a member of App Review please follow up in App Store Connect with more concrete detail, or advise what we should check? @WWDR App name: Prime Cedi Loan Apple ID: 6808185084 Version: 1.1.0, Build 2 Guideline: 5.6 We have already replied in Resolution Center and are ready to provide test accounts, a demo video, or a phone call if that would help. Thank you.

Hi, our new app Amisoria (App ID 6805385809, Submission ID 95e40745-299b-4467-b9f6-8dd5ca907b02) was submitted Aug 29. On Aug 30 we received a Guideline 2.1 "Information Needed" message; we replied Aug 31 with all eight requested items including a screen recording, and followed up on Sep 3. We also opened Developer Support case 102955409950 on Sep 7. There has been no response of any kind since Aug 30. Could someone from App Review please take a look? The app is a client for a self-hosted AI gateway; a built-in demo mode lets reviewers test it without any server. Thank you.

Hello, I’m looking for some advice regarding a TestFlight Beta App Review issue. My app, MyStory, was rejected twice under Guideline 2.1(a) with the same general message: App Review was unable to successfully access all or part of the app. In the first review, Apple specifically asked us to provide a demo account with content demonstrating the app’s functionality. We followed those instructions for Build 3: • Created a dedicated demo account with sample content in all four sections. • Added the username and password under Beta App Review Information. • Added testing instructions. • Replied to App Review with the credentials and instructions. Build 3 was nevertheless rejected again under the same Guideline 2.1(a), without specifying which part of the app was inaccessible. We have tested the app and the demo account ourselves, and everything works as expected on our devices. The app can also be used without an account, and users can create an account directly within the app. We have now replied to App Review asking them to identify the specific screen, step, or functionality they were unable to access. We are currently waiting for a response. Has anyone experienced a similar situation? In particular, I would appreciate advice on how to get a more specific explanation from App Review, or whether there is an appropriate way to escalate the issue if they cannot identify what was inaccessible. I’m also wondering how reliable the 24-hour response timeframe is in practice. It has now been more than a day and a half since I replied to App Review. Should I expect a response within a few days, or can Resolution Center replies sometimes take considerably longer? Thank you.

Xcode version 26.6 (17F113) MyOwnKeyboard-PAD app looks OK using simulator iPad Air 11-inch(M4). It automatically reformats to all orientations using only left and right landscape selected in General, Deployment Info. The submitted app 1.9 (4) had the portrait checked which was an error. I tried to update to version to 1.10 without portrait and upside down, but Validation states it must have all orientations needed. I tried setting all orientations and the simulator cuts off the sides. I am using a new mini M4 with Tahoe 26.6.2 Converted from an older developer mini using Migration Assistant. After conversion Xcode could not find xcspace files and apps locked up. I had to create new apps with different bundles which got conflicted in AppConnects causing rejects. When new versions are submitted, old versions cannot be removed because of submission states. Causing similar binaries, design and scam. I got trapped in the process! I have replied to AppConnect ref. binaries, design and scam. I hope someone can straighten this mess out. The good new is the free MyOwnKeyboard-PHONE analytics look OK with 4,000 impressions and 38 downloads and 172 product page reviews. It's a start! Thank you. Charlie Coupe Designer/Coder 2026sep16

Has anyone successfully appealed an Apple Developer account termination under Section 3.2(f)? My individual developer account (about 50 live apps, all my own work, all revenue through StoreKit subscriptions) was terminated effective August 24, 2026 under Section 3.2(f) of the ADP Agreement. I believe it was triggered by internal tooling I built to automate my own App Store Connect workflow — metadata, build uploads, submissions — only on my own apps. I've filed an appeal through the official form, replied to the termination notice, and written to appstorenotices. For anyone who has been through this: Did your appeal succeed, and how long did Apple take to respond? Was the response you received a form letter or specific? Were you able to recover the withheld balance from legitimate sales, and through what channel? Is there any official channel I've missed beyond the appeal form, the termination-notice reply, and appstorenotices? Any firsthand experience would mean a lot. Thank you.

Hi everyone, I'm looking for some guidance from anyone who has dealt with a similar tax-form issue in App Store Connect. I am a non-US individual and the sole owner of a US single-member LLC. The LLC is treated as a disregarded entity for US federal tax purposes. In App Store Connect, under Tax Forms, I am only presented with the U.S. Form W-9. I am not presented with the questionnaire or any option to complete a W-8BEN. This is particularly confusing because Apple's documentation says that developers based outside the United States may be required to complete a W-8BEN, W-8BEN-E or W-8ECI, and that the appropriate form should be determined through the tax questions in App Store Connect. I contacted Apple Finance Support about this issue and received confirmation that my request had been received: I have an open case with Apple Finance Support since August 26, 2026. I followed up on August 31 and again on September 14, but I have not received any substantive response or update from the Finance/Tax team. I have also found other recent Apple Developer Forum posts describing essentially the same situation: a foreign-owned US single-member LLC where App Store Connect only presents the W-9 workflow and the issue has to be escalated to Apple's tax team. Has anyone here with a similar setup actually managed to get the W-8BEN workflow enabled in App Store Connect? If so: What did Apple ask you to provide? Which Apple team eventually resolved it? Was there a specific escalation path that worked? I am not looking for tax advice — I am mainly trying to understand how others got the App Store Connect tax-form workflow corrected. Thanks in advance.

Hello, I am a sole proprietor based in South Korea. My Apple Developer account was originally enrolled as an individual and was later changed to an organization account. When I try to provide new tax information in App Store Connect, the available form appears to treat my business as a corporation and asks me to complete documentation intended for a corporate entity. I do not want to submit a form that may be inappropriate for my actual tax status. I contacted Apple Media Services Finance Support about this issue through the website on September 4, 2026, and received an acknowledgment for Case-ID: 22018889. Because I had not received a substantive response, I submitted another inquiry about the same issue on September 8, 2026, and received Case-ID: 22076834. The second case was a follow-up to the first, not a separate tax issue. As of September 16, I have received only the automated acknowledgments, with no further update or request for information. I have not been able to arrange phone support from South Korea. The acknowledgment emails say I can update each request by replying with the same subject line. Is that the best way to reach the tax team or escalate this tax-form classification issue? If an Apple staff member sees this post, could you please check the status of both cases (22018889 and 22076834) and let me know whether further information is needed or what the next step should be? I would also appreciate hearing from anyone who has dealt with a similar individual-to-organization change as a Korean sole proprietor. I can provide business documents privately to Apple Support if needed. I will not post tax identifiers or account details publicly. Thank you.