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.

Hello everyone, My app has been rejected under guideline 4.3(a) – Design – Spam. It is a padel sports-tracking app with: – Bluetooth sensor connection – live session tracking – AI-generated coaching feedback – community feed and notifications – video analysis features The review states that my app “shares a similar binary, metadata and/or concept as other apps with only minor differences”. However, this app is fully custom developed, not generated from any template, and not a reskinned clone. It is part of a larger project including custom hardware sensors and backend. I would like to better understand what exactly triggered the rejection: – Is it the design? – A specific feature? – The metadata / screenshots? – Or similarity detection with another app name or concept? My goal is to comply fully with Apple guidelines and improve the app if needed, but I need more concrete direction to do so. Any guidance from Apple engineers or other developers who have faced 4.3(a) would be appreciated. Thank you in advance 🙏

Hello, Our iOS app (Flutter + Swift) was rejected under Guideline 2.5.1 with the following message: The app uses or references the following non-public or deprecated APIs: Runner Classes: __SwiftValue From our investigation, __SwiftValue appears to be an internal Swift runtime class automatically generated by the Swift compiler for Swift–Objective-C bridging. It is not imported, referenced, or used directly in our source code. We verified that: The symbol exists only in the compiled Runner binary It is not referenced by any third-party framework explicitly It appears in standard Swift runtime behavior We previously removed a legitimate private API (PGHostedWindow) from a dependency and resubmitted, after which this new rejection appeared. Questions: Is __SwiftValue considered a private API usage by App Review, or is this a false positive? Are there recommended build settings or mitigations to prevent this symbol from being flagged? Should this be escalated for manual review? Any guidance from Apple engineers or developers who encountered similar rejections would be greatly appreciated. Thank you.

Our Application [7 Dawns: Echoes] was recently rejected by the App Store for Guideline 4.3 Apple ID:6753892922 Bundle ID:com.ark.jylhgl.ios Change of Operating Entity Our company, has obtained exclusive global operating rights (excluding Mainland China, Hong Kong, Macau, Taiwan, and certain regions of South Korea) from the copyright owner. The previous distributor’s version, Eternal Sword M (App ID 1369681345, Bundle ID com.emagroups.ea2), has been fully removed from the App Store. Our cooperation with them officially ended on December 29, 2023. New Version Updates This submission is not a duplicate, but a newly operated and updated version. We introduced new gameplay systems (7-day seasonal competitive mode, team-based PvP, dispatch and multi-pet strategy systems), optimized monetization and in-game economy, and improved performance and UI (including redesigned app icon and key interfaces). Evidence Submitted We have provided the Operating Authorization Letter and Software Copyright Certificate via App Store Connect and email to the review team. and we have submitted Review Support but no reply!

When I distribute my app, is it possible for it to be approved by apple when not complete, maybe with reduced levels. Once I add more levels, I release another update? Would apple approve my app with reduced levels, or would they say ot enough content.

Good afternoon, everyone! I received a notification that my app was rejected for the following reason: "We noticed that the user is taken to the default web browser to sign in or register for an account, which provides a poor user experience." The app is a directory of partners that offer a benefit to our members. So the intent of the app is for users that are already registered with our nonprofit to access their benefits using existing account credentials. (Note: The sign-in itself is handled within the app after the account is created.) Is there any way to make this compliant with guidelines without having to offer a duplicate registration form within the app and sync them?

I understand that private APIs are not permitted under Apple’s App Review Guidelines. However, our application requires I²C communication, and we are currently considering the following APIs: IOAVServiceReadI2C IOAVServiceWriteI2C IOI2CSendRequest Could you please confirm: Is there any provision to use these APIs in a Mac App Store–approved application? Are there public alternatives available for achieving I²C communication on macOS? Thank you for your guidance.

I'm an algo engineer-turned-entrepreneur. About two months ago, I signed up for the Apple Developer Program. Last month, I launched an AI avatar video calling app called Twome (pronounced "Two-me") on the App Store. But just a few days after launch, I used EAS Update (a React Native tool for hot updates) to push a quick bug fix, and soon after, I got hit with a "Pending Termination Notice." They said I violated the Apple Developer Agreement—my app got pulled, and my developer account was flagged for removal. (The App Review message was pretty vague: "App submissions from your account have engaged in concept or feature switch schemes to evade the review process." I'm guessing that's what triggered it.) I was totally shocked. I'd done my homework beforehand and seen tons of devs saying hot updates for bug fixes were fine. No choice but to appeal, so I filed one right away on the App Review Board. Then came the real nightmare: 28 whole days later, I finally got a response—and they upheld the rejection. The reasoning was even fuzzier this time; it felt like a copy-paste template. No specific evidence like before (at least the first notice had some details). Maybe they realized our update didn't actually change any features? Anyway, I'm trying another appeal now, but who knows when it'll come back. The waiting is brutal. We did a full internal audit and pinpointed just two things that might've raised red flags with App Review: Post-launch, we tested an unreleased "rate us" feature and posted a review using our developer account. We figured the App Store would know it was from the app owner and auto-remove it from public view. It was our only review, and we didn't think it'd count as misleading since Apple handles that stuff. The bug fix hot update I mentioned. Beyond that, our post-mortem showed zero other issues. All metadata, product descriptions, and screenshots are 100% compliant—no misleading claims, no dark patterns pushing payments, nothing. Before launch, friends were hyped, saying it'd blow up—it's the world's first realistic AI digital human real-time video calling app for everyday social/entertainment use, aimed at regular folks. But now we're tied up in knots with this appeal mess, desperate to get back on the Store ASAP. It's insane that appeals take a full month to get a response—especially when we didn't blatantly violate anything, or at worst, tripped over something unintentionally. We've already been down for over a month without even knowing the exact issue. Feels way too harsh. Posting here to ask: Has anyone dealt with something similar? Is a 28-day wait (or more) normal for appeals? Any ways to expedite the process? Any practical advice would be hugely appreciated!

Hello everyone, few days back I posted about how apple rejected my build and now after 3 days, they replied back in a very unclear, and I am not being able to understand what they really mean by that. Context :- In my app, when the user clicked on "export" button, it should show the export options, however, if the user is not on a lifetime plan, it should open the "premium" popup / modal to allow them to purchase. Now, this modal loades project based on storekit IN app purchases I added, and locally I tested using the `.storekit` file and everything worked fine. However, before archieveing the build for app store connect, I remove the local file form "edit" scema, and I thought it should load automatically based on the IAP, because I added the IAP to the app build in the console as well. But now, apple responded with this after 3 days :- Issue Description The app exhibited one or more bugs that would negatively impact App Store users. Bug description: "Export" button brings up an empty sheet that seems like a In-App Purchase. (Please see attached screenshot) Next Steps Test the app on supported devices to identify and resolve bugs and stability issues before submitting for review. If you are unable to reproduce the bug, try the following: - For new apps, uninstall all previous versions of your app from a device, then install and follow the steps to reproduce. - For app updates, install the new version as an update to the previous version, then follow the steps to reproduce. They are saying that the premium modal is showing empty. However, what am I suppose to do here? Its working as expected, it needs to show the IAP which I already added? Can someone please guide here a bit, I am on a verge of cry, after waiting for 3 days, they replied with no clear answer and probably gonna take another week ( because of weekend tommorow ) and I am not sure what they really mean by that? This is screenshot of loaded modal and without loaded modal :-

Guideline 2.5.1 - Performance - Software Requirements The app uses or references the following non-public or deprecated APIs: Iobmobile Classes: • __SwiftValue The use of non-public or deprecated APIs is not permitted, as they can lead to a poor user experience should these APIs change and are otherwise not supported on Apple platforms. Can anyone she some light as to what __SwiftValue even means?

Hello, My app (App ID: 1616628950) is currently in the Waiting for Review state after resubmission. The app was resubmitted on December 24 following a previous rejection related to in-app purchase labeling. The issue has been addressed, and the updated build was submitted accordingly. Normally, our app updates enter review within 1–2 days, so this delay seems slightly unusual. I understand that review times may vary, especially during the holiday period, but I wanted to check in here in case the submission might be stuck or require additional information from our side. There were no major functional or policy-related changes in this update aside from addressing the previously noted issue. Thank you very much for your time and assistance.

I would like to ask for clarification regarding my app submission with Submission ID: d293828f-8f9a-4a6d-b138-9650258ab3f3, which has been in “Waiting for Review” status for more than 7 days. I understand that review times may vary depending on queue volume and other factors. However, this extended waiting period is impacting our release timeline, and there have been no status updates or requests for additional information. Could you please help check the status of this submission or let us know if any further action is required from our side? Thank you for your time and support. I look forward to your response.

My application does not compete with the developer. It’s an extension which sits on top of their website. Its only use is to work with their website. Without using their name, the extension does not make any sense. The developer not only has no issue with it - some of their own employees use the extension. To get documentation from developer, that’s easy. However, two questions: Developer wants to know what needs to be provided? An email, A statement? How / what format would be required they are asking? How does such above documentation get submitted / included in subsequent updates to Not hinder approval? The app went through 8 positive reviews / approvals and then all of a sudden this happened out of no where. So not understanding what changed on Apples side and how/what is sufficient documentation (email, statement, PDF, ????) from developer? thanks.

Hello, World I built a deterministic safety layer for FoundationModels called Newton. It validates prompts before inference — if validation fails, generation never happens. It catches jailbreaks, hallucination traps, corrosive frames, and logical contradictions with 94% accuracy on adversarial inputs. All on-device, native Swift, no dependencies. Newton also has a front-facing Intelligent Partner named Ada, and given the incredible integration with FoundationModels and various census data and shape files, this is all available PRIVATE AND OFFLINE. Running on iOS 26 beta today. Happy to demo. https://github.com/jaredlewiswechs/ada-newton — Jared Lewis parcri.net

I wanted to add a new app and I’m having problems with it. When adding my previous apps or updating them, there were no issues at all. I submitted the app for review and waited two weeks without any response. I removed it and submitted it again, and now I’ve been waiting for several days once more. Is anyone able to help me? I don’t think there’s anything wrong with the app, as it’s just a simple game.

应用ID(id6754838125), A week has passed since I added in-app purchases to the already listed application, but it's still under review and I haven't received any result. I sent an email to inquire and asked me to keep waiting We used Contacts Us There is no result. 2. The call has been made for expedited review. It was submitted on December 11th and is still under review Previously, the result of the app review was available within 48 hours Now, I don't know what solutions can be made to this problem. The company is in a hurry and needs to use the App to release a new movie

One of the biggest ongoing frustrations with Apple’s App Review process is inconsistency across builds of the same app version. We regularly encounter the following situation: A build of a new version is reviewed and approved. Shortly after, we submit another build of the same version, often containing only a minor bug fix. This second build is suddenly rejected for an issue that was never mentioned in the previously approved build. After explaining the situation and resubmitting, the build is usually approved. While this may seem manageable on paper, in practice it causes unnecessary delays, especially for time-critical patches and hotfixes that need to reach users quickly. The core issue is predictability: If a guideline violation exists, it should be identified consistently across all builds of that version. If functionality is effectively unchanged, review outcomes should not vary based on reviewer interpretation. Developers should not have to lose hours—or days—explaining why a nearly identical build suddenly fails review. Apple’s review process is essential for platform quality, but lack of continuity between reviews creates avoidable friction for teams shipping live products. Consistent enforcement of guidelines across builds would significantly improve trust, efficiency, and developer experience—without lowering App Store standards. This is not about bypassing rules. It’s about clarity, consistency, and respecting the urgency of real-world software development.

Hello everyone, I’m looking for advice from developers who may have faced a similar situation, as we appear to be stuck in a long-running loop of Guideline 4.3(a) rejections on iOS with no actionable feedback from App Review. Over an extended period, our iOS app has been repeatedly rejected under Guideline 4.3(a) (“similar or repackaged”), regardless of the changes we make. The responses from App Review consistently use the same high-level language and do not indicate what specifically is considered problematic. Some relevant context: The app is built with Flutter using a single shared codebase. The macOS version, built from the same codebase with the same overall structure and UI, has been approved without issues. The iOS version, using that same implementation, continues to receive 4.3(a) rejections. We do not use purchased templates and do not operate multiple developer accounts. Like most apps, we use some third-party and open-source components where technically appropriate. Across multiple submissions, we have tried to address the feedback as best we can by making changes to UI/UX, assets, metadata, internal structure, and overall product quality. However, App Review has not provided clarification even at a high level (for example, whether the concern is primarily related to UI/UX, code structure, metadata, user flows, or overall product framing). Requests for any directional guidance have resulted in the same generic responses, both in review replies and via support. This leaves us making blind changes without a feedback loop. As a result, it’s difficult to understand whether the issue is realistically correctable, or whether the app is effectively blocked due to similarity clustering or other non-obvious review heuristics. Any firsthand experiences, practical steps, or lessons learned would be extremely helpful.

Strangely today, I suddenly found I was unable to submit a new build of my iOS app to the app store. It builds perfectly well in Xcode Cloud, launches from TestFlight without issue, but when attempting to submit the app for App Review, I get this error: "This build is using a beta version of Xcode and can’t be submitted." Of course, the version of Xcode I'm using is not Beta - and I tried this on both public releases of Xcode 16.1 and Xcode 16.2. Has anyone else seen this, and if so, did you figure out a workaround?

Hi all, I’m looking for a sanity check on review timelines. My iOS app is already submitted & has been sitting in “Ready for Review” for the past 2 weeks with no status changes. To avoid confusion, this is not a “how to submit” question. App status: Ready for Review (unchanged for 2 weeks).., for anyone who has shipped recently, what’s the longest you’ve seen an app remain in Ready for Review before it’s reasonable to assume it might be stuck and at what point would you reach out for an update, and what channel worked best (Developer Support / App Review contact / other)? Any real-world ranges (days/weeks) are really appreciated. Thanks so much.