Hello everyone, quick question. I have an app with subscriptions that limit some functionality until you subscribe. The app detects if you have an active subscription and if you do not, when choosing a functionality that is behind the paywall, you get redirected to the upgrade screen where the subscriptions are located. The reviewer replied "We have started the review of your app, but we are not able to continue because we cannot locate the in-app purchases. To help us proceed with the review of your app, please reply to this message providing the steps for locating the in-app purchases in your app." I think the issue is that the app was tested before by the review team with a sandbox account, and now the app is not displaying that upgrade screen anymore because it detects that sandbox account as having an active subscription. And now the reviewer can't get to that screen anymore. Has anyone encountered this type of issue in the past? If you erase purchase history from that particular sandbox account, you log out and log back into the sandbox account it works, but I'm not sure if the reviewers do that.

Start by refining your metadata with keyword-rich titles, subtitles, and descriptions that match user intent. Use high-quality screenshots, app previews, and localized content to improve visibility. Focus on user engagement through regular updates, positive reviews, and consistent installs. Higher retention and active user signals naturally help your app climb the App Store rankings.

I can't pass rule 4.3b. I'm practicing horoscope. How do you think I should proceed? Is it possible to publish this application?

Dear App Review Team, Our app – Apple ID 6749515097 has been stuck in the “Waiting for Review” status for more than 1 month (since October 14, 2025). Normally, reviews begin within a few days, but in our case, it seems unusually delayed. Could you please investigate and help with this. Thank you very much for your time and assistance.

Hello, I first submitted my app on September 14, and it has been stuck in the “Waiting for Review” status for almost three months now. This is the first version of the app, and it has never been reviewed before. I’ve already contacted Apple via email, but I only received the standard response stating that everything is fine. Is there anything else I can do? Thanks!

Hello, Our app was rejected under App Store Review Guideline 1.4.1 for providing “medical-related data, health-related measurements, diagnoses or treatment advice without appropriate regulatory clearance.” However, the features in question are not intended for medical use, and we have already: Added clear disclaimers that the feature is wellness-only, Explicitly stated it is not clinically validated, Indicated that it is not intended for diagnoses or medical purposes, Avoid all medical wording in UI, Added references similar to other wellness apps (e.g., breathing, stress, HRV-style indicators), Updated Terms of Service and Privacy Policy accordingly. The app provides non-medical, wellness-oriented visual indicators, similar to many other wellness apps (breathing record, stress reference, basic heart rate ranges), but no medical interpretation, no diagnosis, and no treatment advice. Still, the review response continues to classify the features as “medical-related data” and asks for regulatory approval. My Questions I understand that Apple cannot comment on specific app review decisions, so I would like to ask for clarification on the general interpretation of Guideline 1.4.1: Under what conditions does a wellness feature become classified as “medical” under 1.4.1? Examples: If the UI shows only relative ranges (e.g., “slow / average / fast”), If we avoid numeric medical measurements, If we avoid clinical wording, If the feature is based on general wellness indicators (like stress trends, breathing rhythm, etc.) Are disclaimers + non-clinical UI enough to classify the content as wellness? We added disclaimers in the UI that match Apple’s guidelines: “This feature provides wellness-only information and is not intended for medical use.” Yet it still appears to be treated as medical. Is there any additional requirement for wellness-only apps to avoid being considered medical devices? For example: Specific wording we must avoid? Required UI changes? Required documentation in App Review Information? Differences between “wellness”, “health”, and “medical” in the context of 1.4.1? If similar apps on the App Store provide wellness-style visualizations (stress, breathing, HRV trends), what distinguishes them from medical use? We would like to understand how to align with the Human Interface Guidelines and App Review Guidelines correctly. Goal The goal is not to bypass regulations but to correctly classify our features as wellness-only. If there is any general guidance for how to structure such features so that they clearly fall under the wellness category, that would be very helpful. Thank you in advance for any clarification or guidance.

This app was developed with NFC functionality enabled, and distribution was intended to utilize the iOS app by replacing the provisioning profile and certificate issued under a separate Apple Developer account. However, since NFC cannot be enabled under the separate Apple Developer account, it is now required that the iOS app can be used with the standalone ipa file. If we create our own provisioning profile and certificate to enable standalone operation of the ipa file, we need to confirm where this might conflict with Apple's licenses or policies.

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.

I have two questions regarding releasing an app that uses an in-app browser (WKWebView) on the App Store worldwide. Question 1: Encryption usage Our app uses WKWebView and relies on standard encryption. Should this be declared as using encryption during the App Store submission? Question 2: If the answer to Question 1 is YES If it must be declared as using encryption, do we need to prepare and upload additional documentation when submitting the app in France? Also, would this require us to redo the entire build and upload process, even for an app version that has already been uploaded? Goal / request: We want to release an app using WKWebView worldwide, including France. We would like to understand all the necessary steps and requirements for completing the App Store release without unexpected rework. Best regards, P.S.: A similar question was posted a few years ago, but it seems there was no response. https://developer.apple.com/forums/thread/725047 Sadao

Hello, I’m writing to seek help regarding a serious App Review issue that has been ongoing for over three months. Our app has been under review since July 29, and despite providing all required explanations, documentation, and updates, we have not received any meaningful feedback for over a month — only repeated messages stating that “additional review time is required.” Timeline Jul 29–Aug 1: Apple rejected the app for not meeting the External Purchase requirements (Modal Sheet, canMakePayments). Jul 30–Aug 1: We explained that these requirements apply only to digital content, while our app also includes offline offerings permitted for external payment. Aug 3: Apple requested additional review time → Aug 12: requested demo account → Aug 21: we submitted a detailed explanation video and PDF. Early September: Apple sent detailed follow-up questions about whether each product type was considered digital. Mid-Sep to mid-Oct: Apple repeatedly replied with “additional review time required” without further updates. To fully comply with Apple’s payment policies, we even modified all product flows in our app to meet StoreKit requirements — even for offline products — and resubmitted the new version accordingly. However, the latest submission has now been “In Review” for over a week with no reviewer contact or feedback, even after we requested an expedited review. Meanwhile, our users have been stuck on the old version of the app for over three months, experiencing major issues and dissatisfaction. This delay is now critically affecting our service and business operations. Has anyone experienced a similar situation — where an app review has been stalled for months, even after providing all requested materials and being granted expedited review? If there are any possible ways to escalate or resolve this, I would be very grateful for your guidance. Thank you for any insights or advice.

I recently had my Apple Developer Account removed from the App Store. I have spent 3 months trying to reach someone at Apple who can clarify the issue and help reinstate our developer status. No one has responded to us, explained the situation, or reviewed the case. I was able to get in contact with an old Apple App Store executive. After hearing the story, he agreed the situation seemed wrong. However, he no longer has connections at Apple, so he wasn’t able to help us. The app had millions of users and 50,000+ five-star reviews. Resolving this would allow us to restore the app and continue launching new products. Right now I’d appreciate anyone’s thoughts or guidance on this situation. Thanks!

"ASO in 2025 is more algorithm-driven, with a stronger focus on user engagement signals like retention and in-app actions. Keyword relevance still matters, but quality and user experience now play a bigger role in ranking boosts."

Hi all My radio streaming app (using Radio Browser API - open source, ODbL licensed) was approved for iOS but is being repeatedly rejected for macOS under Guideline 5.2.3 despite identical functionality. iOS version (approved): https://apps.apple.com/ch/app/pladio/id6747711658?l=en-GB Pladio Uses: radio-browser.info (community-maintained, ODbL license) Apple requests "documentary evidence" but hasn't clarified what form this should take for publicly broadcast radio streams. Other similar apps (TuneIn, Triode) are approved on both platforms. Has anyone successfully navigated a similar situation? What documentary evidence did you provide for publicly accessible content? Best regards, Patrick.

Hello everyone, I am writing to seek help with a critical App Review issue for a new application. My app has been in the "In Review" status for 29 consecutive days (since October 1st) without any change or feedback. This is on an experienced developer account with 5 other apps already live on the App Store. Here is the timeline of the current submission: Sep 30: Submitted new binary. Oct 1: Status changed to "In Review". Oct 9: After inquiring about the long delay, Developer Support kindly granted an expedited review (Case ID 102702095699). Oct 30 (Today): The app is still "In Review". It has now been 21 days since the expedited review was applied, and 29 days total. The core problem: My primary concern is that based on our server metrics, there has not been a single login attempt or health check from the App Review team since October 1st. This strongly suggests the app is technically "stuck" in the queue and has not even been opened or tested by a reviewer. We have been in constant contact with Developer Support, who have been very responsive and confirmed they escalated this internally with urgency. Unfortunately, despite these efforts, the app's status remains unchanged. This delay is now critical. We had firm, paid promotional integrations scheduled with partners for the first week of November, which were all dependent on an approval by our deadline of October 29th. We have now missed this deadline entirely, which is resulting in direct financial losses and reputational damage with our partners. Has anyone else experienced an app being "stuck" like this, where even an expedited review fails to get the app looked at? Is there any known technical glitch or a different path to get this specific blockage resolved? Thank you for any insights.

Hello everyone, I’m reaching out to seek guidance regarding an unusual delay in the App Review process. Two of our new apps have been in the “Waiting for Review” status since October 30, 2025, with no change or update from the review team. Both submissions were uploaded from an active, established developer account that already has multiple live apps on the App Store. We reached out to Apple Developer Support, and they kindly confirmed that the issue has been escalated under Case ID: 102741157121. However, as of today, both apps continue to remain in the same status without any progress. At this point, we’re concerned that the apps might be stuck in the queue due to some technical issue, since no review activity seems to have started yet. Has anyone else experienced a similar delay recently, or found any effective way to get such stuck submissions moving again? Any insights or advice would be greatly appreciated. Thank you in advance.

Our app was rejected on October 23. After communicating with the App Review team on October 24, the decision was still the same, so we submitted an appeal to the App Review Board that day. It's over 17 days later, and we still haven’t received any update. We totally understand that the review process can take some time, but this new version includes a major self-developed feature that took us quite a while to build, and we’re really hoping to get it online for validation soon. Does anyone know how long it usually takes to get a response from the App Review Board? Or is it okay to follow up with them again at this point? Thank you for any insights.

I already created subscription in appstore connect with proper metadata still when I am using product id to purchase the subscription using flutter package in_app_purchase: ^3.2.3 it say's no subscription found with product id x. I observed everything minutely all seems fine than why ?? I try to test with storekit that works btw. I also have sandbox account and same signed in my iPhone 12 mini but much please look into this.. Flutter code : Future<void> _loadSubscriptions() async { Set<String> kSubscriptionIds = {'monthly_plan_test_iop_81'}; ProductDetailsResponse response = await _inAppPurchase.queryProductDetails(kSubscriptionIds); if (response.notFoundIDs.isNotEmpty) { kLog("Subscription IDs not found: ${response.notFoundIDs}"); } kLog("God it works seriously"); kLog(response.notFoundIDs); kLog(response.productDetails); kLog(response.error); subscriptions.value = response.productDetails; }

Hi, I want to consult about this: This is regarding [Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage] My client is asking if we can remove the new account registration through the iOS App, so we won't need to ask for mobile and birthdate. For iOS App users, new users will register through the website (or through a non-Apple related app). After registering through the website, they can access the iOS App using the credentials created through another method. Will that be a problem with Apple policies? My client said they need the Mobile number and birthdate for verification. Thanks in advance for the help and guidance. Best regards, Sophia

I hope you are doing well. I am reaching out to follow up regarding my app, which has been under App Review for an unusually long period of time. I have contacted Apple Developer Support several times through both phone calls and emails, but so far, there has been no effective resolution or progress. Below are the case references from the last few weeks: • Case ID: 102741157121 — App Store Connect Users and Roles • Case ID: 102745063464 — Program Enrolment • Case ID: 102744897406 — Other Membership or Account Questions • Case ID: 102742872512 — App Review Status • Case ID: 102742874797 — App Review Status • Case ID: 102743079324 — Developer Team Management • Case ID: 102738804525 — Feedback and Other Topics • Case ID: 102735998715 — Agreements and Contracts • Case ID: 102735996938 — App Review Status • Case ID: 102725767721 — Other App Review Questions • Case ID: 102725766192 — App Review Status • Case ID: 102729318336 — My Issue Is Not Listed • Case ID: 102723997813 — Program Enrolment As you can see, I have made numerous attempts to resolve this matter, yet I have not received any concrete response or outcome. My app continues to remain in the “In Review” state without any progress or communication from your team. This repeated delay is affecting my project timeline and business operations. I respectfully request that this issue be escalated to a senior App Review specialist or higher-level reviewer who can take direct action. Please review the above case history and provide a clear resolution or update at the earliest possible. Thank you for your attention and understanding.

Our iOS/iPad app is built with React Native. We use Axios as our HTTP client. Our app has been out on the app store for 2+ years and we've never had issues with reviews. Since iOS 26 came out, our app has been constantly getting rejected because the Apple tester keeps facing network timeout issues when our app makes requests to our API services. Our API stack is already configured to support IPv6 networks, and our regular user base does not run into the issues the Apple tester is seeing. None of our developers nor our internal testers have been able to reproduce the issue the Apple tester is facing. We've tried a number of things to debug the potential issue: Added a ping check on app startup. We used the native fetch present in React Native apps as well as our Axios client (with the default XHR/HTTP adapter). None of the pings make it to our API services. Added higher timeouts on app startup to let the Apple tester have more time to reach our services while their simulator device is able to connect. We've read that the environment that Apple testers use can sometimes take longer to establish an initial connection, even though packages like NetInfo from React Native report that they are connected to WiFi as soon as the app starts. Switched our Axios client adapter to use the native fetch. We did this since we noticed that Mixpanel, our tracking library, uses the native fetch in their React Native SDK and we've confirmed that requests on their end do make it through when the Apple tester is testing our app. We're running out of ideas since the issue is pretty obscure and we haven't been able to reproduce it yet, not even by following the Apple guide to set up a local IPv6 NAT64 network to be as close to their environment as possible. We've also tried testing the app while connected to VPNs from different locations to no avail. Like I said before, we noticed that this issues started for the Apple tester with the release of iOS 26, so we're wondering if there are known issues in the community that might relate to what we're experiencing. The most recent finding we've made is that some other developers report new issues with HTTP 3/QUIC on iOS. We've seen recommendations about turning off explicit support for HTTP 3 on our services, which seems to have helped other developers.