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.

Here are some tips from App Review for a smooth review experience. We’ve split them into two categories: Before You Submit and After You Submit. We’ve also made an easy-to-follow Submission Guide you can save and reference at any point on your App Store journey. Before You Submit Tips Enable a complete review. Make sure you’ve provided demo accounts or implemented an account demonstration mode before you submit. We’ll need to review the entire app experience, both with and without an account. Provide up-to-date demo account login credentials in the App Review Information section on the app version page in App Store Connect. If your app has multiple account types (such as admin and general users), use the Notes field to provide additional demo account credentials for each account type. If your app requires an authentication code in addition to the login credentials, provide the code in advance in the Notes field. Otherwise, a call may be required to complete the review. Apps that handle sensitive user information, or operate in highly regulated industries, can implement demonstration modes that exhibit full features and functionality while using demonstration data. Use the Notes field in App Store Connect to provide information to App Review. The App Review Information section of App Store Connect includes a Notes field. Provide any information that could be relevant to your submission’s review: Submitting a new app? Tell us about your app's concept, business model, and if your app is designed to only operate in certain locations. Submitting an update? Tell us about what’s changed and where to locate significant new content or features. Connecting to hardware? Attach a video, not a screen recording, that shows both the hardware and the app running on a physical Apple device as they pair and interact. Test your app on physical devices before submitting for review. Use TestFlight to distribute your app for beta testing. App Review evaluates apps the way your users will use them: installed on real devices and connected to networks with real-world conditions. Make sure your pre-submission testing includes running the app on each device platform where it could be used. Users expect the app to function on all the devices where it’s available. TestFlight will help you do quality assurance and beta testing on real devices. Share your beta app with internal testers on your Apple Developer Program account or to external users via an email invite or public link. Configure In-App Purchases for review in the sandbox environment. App Review assesses In-App Purchases in the same sandbox environment Apple provides for testing them. The sandbox lets us use real product data and server-to-server transactions, without incurring any financial charges. Take these steps to prepare your In-App Purchases for review: Accept the Paid Applications Agreement in App Store Connect. Submit the In-App Purchases in App Store Connect that you’d like reviewed. Follow the steps in TN3186: Troubleshooting In-App Purchases availability in the sandbox if your app fails to display your In-App Purchases. Note: In-App Purchases don’t need prior approval from App Review to function in review. Join a Meet with Apple event if you need assistance before you submit for review. Request an App Review appointment through Meet with Apple to chat with an App Review expert about how to prepare for review, ask questions about specific guidelines, and discuss other topics related to the review process. Appointments are subject to availability during your local business hours on Tuesdays and Thursdays. After You Submit Tips Contact App Review if you need assistance with an ongoing submission. If your submission doesn’t pass review and you have questions, contact App Review directly by clicking Reply to App Review in App Store Connect. You’ll receive a reply from a review specialist who’s familiar with your app. You can also use the Reply to App Review message window to request a call with an Apple representative. Include your preferred time and language for the call and we’ll do our best to accommodate your requests. Use the Bug Fix Submissions process to quickly deliver bug fixes and resolve other issues on the next submission. If an update includes bug fixes and is rejected, you will be given the option to resolve the issues on your next submission, as long as there are no legal or safety concerns. App Review will let you know if your submission is eligible by including this note at the top of the rejection message: Bug Fix Submissions The issues we've identified below are eligible to be resolved on your next update. To accept this offer, simply reply to the rejection message in App Store Connect and let App Review know you’ll resolve the issues on the next submission. Share ideas with Apple about how to improve or clarify the App Review Guidelines by submitting guideline feedback. Just as the App Store is always changing and improving to keep up with the needs of customers, the App Review Guidelines may be revised to provide new and updated guidance. If you have ideas for improving or clarifying our requirements you can suggest guideline changes. If your submission was rejected but you believe it follows the App Review Guidelines, consider submitting an appeal to the App Review Board. If your submission didn’t pass review but you have reason to believe it follows the App Review Guidelines, you can submit an appeal to the App Review Board. You can also file an appeal if you think we misunderstood your app or the review was unfair. The App Review Board will contact you as soon as they complete their investigation.

Apple platforms make it easy to distribute your app to a variety of compatible devices, so it’s important to maximize your app experience on each platform you support. Here are some tips from App Review to help you understand how device compatibility impacts your app’s distribution — and how to make sure your apps shine on every platform they’re on. Understand device compatibility There are many ways an app built for one Apple device can run on other Apple devices: Apps designed for iPhone can run on iPad devices in compatibility mode if there are no dependencies on iPhone device capabilities. Compatible iPhone and iPad apps can run unmodified on Macs with Apple Silicon. Compatible iPhone and iPad apps can run unmodified on Apple Vision Pro. Xcode provides options to configure settings for apps on multiple platforms. You can specify which platforms your app’s target supports in the Supported Destination field. However, it’s important to note: People may still be able to run your app on a device even if you remove it or don't include it as a Supported Destination in Xcode. For example, as long as an app designed for iPhone doesn’t depend on a capability that’s only available on iPhone, it can be downloaded from the App Store onto iPad. Adding or removing iPad as a Supported Destination in Xcode won’t change that app’s availability on iPad. To view examples of cases where it's appropriate to restrict availability, see Restrict device distribution below. Follow compatibility best practices 1. Plan and test for compatibility modes so your app works on every device where it can be downloaded. Do: Use Xcode simulators to verify basic functionality across different device types. Leverage TestFlight with external testers who have access to a wide range of Apple devices. Don't: Don’t submit for review without testing your app’s behavior in compatibility modes. Don’t assume removing a supported destination in Xcode prevents distribution to that device type. 2. Build adaptive interfaces that work across device variations. Do: Build interfaces that respond to different screen sizes and orientations. Adapt features based on available hardware, providing alternatives for a consistent experience. Don't: Don’t design rigid interfaces that assume only one type of device or input method. Don’t let your app crash or become unusable when optional hardware is unavailable. Restrict device distribution Wherever possible, it’s best to make your app available on multiple platforms to increase its reach and provide people with a consistent experience across devices. But there are cases where it does makes sense to restrict an app’s availability. For example: iPhone apps that rely on iPhone-specific hardware won’t function as expected on iPad. Use the UIRequiredDeviceCapabilities key in the information property list file to specify hardware dependencies. Note: Apps should only use the UIRequiredDeviceCapabilities key for genuine hardware dependencies, not to indicate distribution preferences. Navigation- or camera-based apps are not well suited for visionOS. Learn more about managing availability of iPhone and iPad apps on Apple Vision Pro. Apps that rely heavily on touch inputs that can’t be replicated on a keyboard are not well suited for macOS. Learn more about restricting distribution to Apple Silicon devices. Learn more about how to configure multiplatform apps in Xcode. Support If you need more assistance, explore these support options: 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 through Meet with Apple. Appointments are available during local business hours on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board.

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!

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)

We are adding tap2pay as a payment method to our existing POS app. Our app is distributed business to business via Custom Apps. To get a production entitlement there's a checklist, in this checklist there are several sections. For Section 3, "Requirements for Enabling Tap to Pay on iPhone" there's a paragraph: If you distribute your app with programs such as Unlisted apps, Custom apps, or the Apple Developer Enterprise Program (ADEP) these requirements are applicable only if users are expected to accept terms and conditions using an Apple Account on the iPhone. We are using Custom Apps but its unclear what 'terms and conditions' refer to, does this refer to our own t&cs and not Apple's t&cs?

Posting because I have run out of changes to make and Apple is still hitting me with the same guideline. I run Bot Binder (App Store ID 6771506484), a fan-built collection-tracking app for action-figure collectors. No Hasbro license. No trademarked wordmark in the app name or icon. One developer, paid account, side project. Three 4.1(a) Copycats rejections in six days. May 30, vc109 rejected. Subtitle "Transformers Collection Hub" and keywords led with "transformers." Acknowledged. I rewrote the subtitle, scrubbed the keywords, shipped vc114 with a Hasbro attribution disclaimer modeled on Dex and Yugipedia, plus a Resolution Center reply citing 15 live App Store comparables. June 1, vc114 rejected. Same guideline. Flagged screenshot was the dashboard hero, which still rendered marketing text and a Hasbro figure in the featured spot. Acknowledged. I gated every brand-bearing UI surface behind an iOS check, swapped the iOS feature pool to third-party and upgrade-kit figures only, replaced the original mascot in both the iOS app icon and the in-app head graphic with a new abstract design, regenerated the splash, and shipped vc132. The mascot replacement was a real concession. That mascot is the visual identity of the brand on web and Android. I changed it on iOS specifically because the reviewer signaled the icon area was in scope. June 4, vc132 submitted with full scorched-earth metadata. Description rewritten end to end, zero third-party brand/character/trademark references anywhere (verifiable in the live appStoreReviewDetail record). Promotional text and keywords generic. Screenshots reshot from the gated iOS build with no franchise overlays or characters in hero positions. In-app disclaimer footer on every iOS screen. Public support page hosts the same disclaimer. Age rating bumped 4+ to 12+. June 5, 1:41 AM. Rejected again. Two notes: 4.1(a): "The metadata appears to contain potentially misleading references to third-party content. Specifically, the metadata still includes content that resembles Transformers without the necessary authorization. … If you do not have the necessary rights to the third-party content, it would be appropriate to revise the metadata to remove the third-party content before resubmitting for review." 2.3.3: "The iPhone and iPad screenshots do not show the actual app in use in the majority of the screenshots. Marketing or promotional materials that do not reflect the UI of the app are not appropriate for screenshots." This is the third time the rejection has cited "the metadata" without naming a single specific field. After three rounds my description has zero third-party references, promotional text has none, keywords have none, and screenshots are stripped. There is nothing left in the listing to act on. Before redesigning the mascot for vc132 I sent App Review a direct question asking for any guidance on the icon and mascot direction. The full reply: Hello, We appreciate your efforts to comply with the App Review Guidelines. We are not able to provide feedback on app concepts or features, but we recommend evaluating your suggestions against the App Review Guidelines, the Apple Developer Program License Agreement, and the Human Interface Guidelines. Additionally, if you are considering implementing any of the following functionality, we recommend reviewing all associated reference material: Apple Developer Apple Copyright and Trademark Guidelines Game Center iCloud In-App Purchase You may also choose to post a question in the Apple Developer Forums. Best regards, App Review That reply, taken with three rejection notes that name no specific field, reads exactly like a large language model behind a developer-relations endpoint. Nothing app-specific. References functionality with no bearing on my submission (Game Center, iCloud, In-App Purchase). Closes by redirecting me to this forum, which is the only reason I am writing the post. The whole exchange feels like I am talking to a system, not a person. If a human reviewer is on the other end of this thread, I am asking you to engage as one. One sentence naming the specific flagged surface resolves this thread today. The two notes also contradict each other on remediation. 2.3.3 wants screenshots showing the actual app in use, not marketing. 4.1(a) wants third-party-resembling content removed from "the metadata." Once the listing copy is generic and the screenshots show the real UI, what those screenshots show is the in-app catalog. So the only third-party-resembling content the reviewer can still be pointing at is the catalog itself, a different scope than how metadata versus in-app content has historically been drawn. What that means in practice: Bot Binder has over 1000 active users with new collectors joining every day, and the in-app catalog contains more than 10,000 figures. If 4.1(a) is pointing at the catalog, the only remediation Apple's note is offering me is to remove that content, which isn't viable. The catalog is the product. Stripping 10,000 catalog entries invalidates the collections, wishlists, and trade data of every existing user. There is no version of this app that satisfies that interpretation and still functions. Either the scope is different than I'm reading, or 4.1(a) is being applied to a category of app that cannot exist on the App Store, in which case I need that stated directly so I can stop iterating. What I need. App Review staff, if a person is reading this: name the surface. Which field, which screenshot, which paragraph still flags as third-party-resembling? One sentence. If the answer is "the in-app catalog," say so and I will stop submitting. Developers running unlicensed-IP collector apps on the App Store, particularly iCollect Action Figures (656405076, "Transformers" in subtitle), The Ark TFC86 by Chris Sudac, My G.I. Joes (1606553734), Dex (1555489854), Yugipedia (1026470546), Brick by Brick (525328219), Pokellector (600580227). What got you through 4.1(a)? Disclaimer language, or did you have to remove franchise content from the iOS build itself? Asking because some of you are doing exactly what I am being rejected for and your apps are live. Anyone who has booked an App Review Appointment for 4.1(a): did you get surgical guidance, or the same template? Full submission timeline, build IDs, screenshots, and the appStoreReviewDetail record available on request. After six days of taking every revision step Apple has asked for and landing in the same place, I just need actual specificity from somebody.

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.

My app stuck in "Waiting for Review" for over a month now. During this time I have published multiple updates on Android, and other platforms (Garmin). iOS users constantly asking me: where is the update? As a result, I receive a LOT of negative reviews on other platforms, because people are expecting iOS app and it missed all the possible deadlines and it's completely out of my hands. All of this, so Apple can cut 30% of my profits. I'm actually fed up. I can not rely on Apple anymore. I don't understand why we are paying $99 and for what. Just a quick browse through the forum, and I can see I am not the only one. Apple just don't care. "Nothing can be done, just pay and shut up" attitude should no longer be tolerated by Apple's developer community.

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

It has been weeks since our app update has moved forward in review. After waiting several days, we also submitted an expedited review request, but the issue remains unresolved. We have contacted App Review through review notes, Apple Developer Support calls, emails, and prior forum posts. After our second forum post, calls with Apple Developer Support, and two additional email requests, we are writing here one more time because we still have not received a clear update or resolution. As we have mentioned before, this is a financial app, and with that comes a responsibility to provide users with the most reliable and up-to-date version possible. Our pending update includes important fixes that our users are waiting for. We have also noticed other apps in our category continue moving through review and releasing updates recently, so we would appreciate any guidance on whether there is something specific blocking our review. app id is id 6753857720

I would like to explain the current situation regarding our subscriptions and ask a few clarification questions to ensure that our implementation fully complies with App Store requirements. Current Status We have successfully configured our subscriptions in App Store Connect. All subscription products currently appear as “Waiting for Review.” Paid Apps Agreement has been accepted and is active. Banking and tax information are completed and active. RevenueCat integration is working correctly. In TestFlight, the app is now able to: Fetch products successfully Display localized Turkish pricing Open the native Apple purchase sheet Start sandbox purchase flow successfully We can now see Apple’s native TestFlight subscription purchase popup with the correct products and prices, which indicates that StoreKit communication is functioning correctly. However, we are still confused about the review/submission relationship between: The app version submission The first subscription review Existing “Waiting for Review” subscription states Questions Since the subscriptions already show “Waiting for Review,” does this mean they are correctly attached to the currently reviewed app version? Or do we still need to create an entirely new app version submission and manually re-add all subscriptions from the “In-App Purchases and Subscriptions” section before review can continue? The subscriptions are already accessible in TestFlight sandbox purchase flow. Does this confirm that our StoreKit configuration is now technically valid for review? If there is still a configuration issue on our side, could you please clarify exactly which step is missing: attaching subscriptions to a specific binary, submitting the first subscription with a new app version, or another App Store Connect configuration requirement? Our goal is to fully comply with App Store policies and avoid submitting another incorrect review build.

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.

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

My app OneNest (App Store ID: 6762323106) has had in-app purchase localizations in "Waiting for Review" status for nearly 2 weeks. My subscriptions were approved but the localization for both the subscription and lifetime purchase IAPs remains pending. This is actively blocking customers from completing purchases in my live app. I have an open support ticket but have not received a response in 2 weeks. Has anyone experienced this? Is there a way to escalate IAP localization review specifically? Any guidance would be appreciated.

我测试了 1、通过xcode安装到模拟器 2、通过xcode安装到手表 3、通过testflight安装到手表 都可以找到内购产品id。 但是提交审核后，审核回馈的信息都是找不到产品ID，已经被拒好多次了。 我账户其它应用的内购都是正常交易的，我做了如下检查： bundle id 第一次提交要选择的内购产品 内购产品的状态也是“Waiting for Review” 代码也是反复检查的，上面3种测试都是正常的 我留意到有两个奇怪的问题是， 1、我的二进制包被拒后过了几个小时，我的内购产品会因为没有提供二进制包而被拒。 2、内购产品会出现“Developer Action Needed”的状态，但是没有指明我需要采取什么行动，只是内购的描述的状态是“Rejected” 我想请教一下这里的好心人，我还需要做什么检查和修改才能让审核的时候可以找到产品id？

I am experiencing a critical and frustrating delay with an internal business application review. I would highly appreciate any insights or advice from the community or the Apple team on how to move forward, as our business operations are heavily impacted. Here is the exact timeline of our submission process: May 14 & May 19: Submitted the initial builds. On both occasions, the app transitioned to In Review within 4 hours but was rejected due to specific metadata/compliance deficiencies. Resolution: We thoroughly addressed all the points mentioned in the rejection notes, completed the missing requirements, and prepared a fully compliant build. May 22: Resubmitted the corrected build. Unlike the previous quick turnarounds, the app became completely stuck in the queue (Waiting for Review) with zero communication or updates for over a week. June 1: Out of concern that the submission was caught in a system glitch, I canceled the review and resubmitted it. It is currently still waiting with no status change. Expedited Review: I submitted an Expedited Review request detailing our urgent operational needs, but we have received no response or acknowledgment yet. Business Impact & Context: This is an essential internal tool for our business operations. We currently have 20 employees utilizing it via Ad Hoc distribution, but we are actively onboarding new personnel who need immediate access to the app to perform their daily duties. The limitations and manual management of Ad Hoc distribution are now causing a severe bottleneck in our daily workflows. Given that the first two reviews started within hours, it feels like the app has been flagged or placed into a different administrative review queue after the rejections, but the complete silence is hurting our business. Has anyone dealt with a similar sudden freeze after fixing rejection points? Are there any alternative communication channels available when both App Store Connect and Expedited Review forms go completely unanswered? Thank you in advance for your time and help.

Does the App Review process have access to Apple-Hosted Asset Packs during review? My app uses Asset Packs to offer a library of data to the end-user (with a workaround, if unavailable), but I am frequently seeing the workaround screen in App Review with errors I haven't seen elsewhere. The latest error I encountered (via the App Review team's feedback) was: "A server with the specified hostname could not be found." thrown from (to my belief) AssetPackManager.shared.ensureLocalAvailability. This is unexpected to me, as both this code as well as the asset packs have already been released and are working reliably in production. Has anyone else experienced these issues?

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.

Hi all, At this point I'm pretty sure our app has fallen into some kind of review limbo, and I'm hoping someone here has seen this pattern before or can point me somewhere useful. Here's the full timeline: May 15: First submission of pipp money. Came back rejected. Shortly after: We addressed the feedback and resubmitted the updated build. The resubmission then sat in the queue for an unusually long time with no movement, so I started to suspect something might have gone wrong on the submission side. I cancelled the build myself, made a small update, and resubmitted again, hoping that would unstick it. Since then: Still no movement. The app has just been sitting in the review queue. In parallel: I've sent multiple support requests by email about the situation. Not a single one has received a response. I also posted on this forum earlier, and someone from App Review replied saying the case would be investigated. That was a while ago and I haven't heard anything since, and there's still no progress on the submission. We haven't been able to push a new version to our users since May 11, which is starting to seriously affect us. Given that the build has been in the queue this long, support emails are going unanswered, and even the forum escalation that was supposed to trigger an investigation has gone quiet, I have to assume the submission is stuck in some kind of broken state rather than just slow review. Has anyone else run into this? Is there a channel that actually gets a response in cases like this? Any pointers would be hugely appreciated. Thanks.

Hello everyone, our application version update (version 3.1.1) has been waiting for review for a long time without any progress or response to the support issues we raised. Application Apple ID: 6752632655 First submission date: April 17, 2026 Last resubmission date: May 28, 2026 Current status: awaiting review (never moved to 'under review') We have raised the issue with the developer support department, but have not received a response yet. We are not requesting special treatment, we are just requesting a status check or any indication of any obstacles. If anyone from App Review sees this, we would greatly appreciate it. If other developers see similar waiting this week, it would be helpful to know that this is a backlog rather than a flag on our account. Thank you.