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.

Dear Community, We are facing an issue in our production App where we recently upgraded app min version from iOS 12 to iOS 17 in order to integrate a private API Entitlement. Due to upgrade, app review is rejecting the same app citing syscall presence like mentioned below : • syscall: open_dprotected_np • syscall: getsockname • syscall: fork • syscall: modwatch They suggested using strings command and otool command to find such syscalls presence but we were not able to find any such syscall presence. We are on Cordova platform (hybrid application) and are using Mobile First Platform (MFP8). If anyone has faced such an issue, please help us in finding these syscalls so that we can take action on them. Regards, Aditya

Dear App Review! We are a tax software that undergoes regular iterations and is updated with new features every month. We have currently uploaded versions for review and have been in a “pending review” state for almost 2 days now. During this wait, we have taken the following actions but have been unable to get into the review process: We requested an expedited review and were told it was successful, but no progress has been made; Contacted "App Review Status" via email; "Please let us know everything is fine and wait for review; Rejected on its own, resubmit for review; Our users have been anxiously asking us when there will be new features and they are eager to use them Apple app ID: 6744107833 Looking forward to hearing from you, thank you!

Hello, I’m developing an iOS app focused on B2B scenarios, specifically for certain companies to track their employees’ real-time (live update) locations. Because the app continuously updates location data in the background (and can re-enable tracking after a force quit), battery usage can sometimes be relatively high. The app is not intended for the general public and is only meant for these specific companies and their employees. Therefore, I’m not considering a fully public App Store release. With that in mind, I’d appreciate some advice on: The most suitable distribution method for an app intended for multiple organizations but restricted to a closed group (e.g., Apple Business Manager - Custom Apps?). Any particular guidelines or best practices regarding continuous background location tracking, especially in terms of battery impact. Additional permissions or disclaimers Apple may require for re-enabling location tracking after a force quit. Thank you in advance!

Hello Developers, I submitted my app Score + for review on March 15, and it has been stuck in review for over 20 days with no progress. On March 22, I contacted Apple Developer Support, and they assured me that my app would receive an expedited review, but nothing has changed in the past two weeks. After waiting 20 days, I thought there might be a technical issue preventing my app from being reviewed, so I incremented the version number and resubmitted it. However, it is still not being reviewed. I am wondering if my app is: ❌ Stuck in the queue due to a system error ❌ Blacklisted for some unknown reason ❌ Delayed due to a backlog of reviews Has anyone else experienced such a long delay? What can I do to escalate this issue further? Any advice would be greatly appreciated! Thank you! Erdinç Ayvaz

Hi all, I’ve been working on an innovative dating app — it focuses on short videos and AI-powered recommendations, rather than static profiles/images and swipe interactions. It includes: Short-form video feeds instead of pictures AI-generated summaries from uploaded videos (hobbies, personality, etc.) AI-driven feed recommendations based on user "like" behavior Free, unlimited messaging between mutually interested users Inclusive for all genders, non-swipe-based UI Despite these features, the app has been repeatedly rejected under Guideline 4.3(b): Design – Spam. The review feedback refers to "duplicative functionality in a saturated category." I’ve filed an appeal and previously raised this in the forums — where I received helpful feedback. I would love any insights, examples, or advice from others who’ve built in saturated categories while navigating this rule. I genuinely believe the app brings something innovation and unique experience to dating app users on iPhone. And it's bringing some freshness to this saturated category. If any Apple team member is monitoring this thread, I’d greatly appreciate guidance or further clarification. Thank you!

my app in app store: https://apps.apple.com/cn/app/%E4%B8%89%E5%9B%BD%E6%88%98%E4%BA%89%E7%AD%96%E7%95%A5slg/id6741073714?ct=Tap725796 my app in android store: https://www.taptap.cn/app/725796?os=android Hello, Thank you for your response. Your app still provides the same feature set as other apps submitted to the App Store for review. Submitting similar or repackaged apps is a form of spam that creates clutter and makes it difficult for users to discover new apps. To resolve the issue it would be appropriate to revise your app to provide a unique experience or submit a new app that does not repackage the content and functionality of other apps on the App Store. You may also choose to post a question in the Apple Developer Forums. Best regards, App Review This is a cross-era slg game. Players can customize and create the generals' skills they want in the game. The game has been updated for half a year. After the basic functions of the slg game are realized, the game's special functions and custom skills are being developed. However, the previous audits have passed, but the latest audits have not passed. As far as I know, none of the current slg games support custom skills. If there are, I will no longer provide audits. Obviously, this is a unique game, but Apple's official auditors refused to pass the audit, which I cannot understand. I think Apple's official approach is very unprofessional. At present, our game has a considerable number of Apple players. If the first application was rejected for review a few months ago, I would not think there is any problem, but my application has been updated weekly for several months. Now the latest version of the app has not been approved. Some Apple users have been urging me to update the app. Obviously, this is a unique app. Otherwise, they can choose to play other similar apps that you think. The latest version of the app on Android has been continuously updated, which makes Apple users who cannot experience the latest version very anxious. I hope that Apple officials will have more sense of responsibility for Apple developers or Apple mobile phone users, and have practical solutions to problems. Obviously, I have said so much, just to seek a feasible solution, so please tell me, what should I do to pass the review? Why can the previous simple version pass the review? Why can't the innovative and unique SLG game with custom skills pass the review?

Revise the app's description to include a disclaimer reminding users to seek a doctor’s advice in addition to using this app and before making any medical decisions. The above is the review result of Apple. But I would like to know where the disclaimer should be added. Can I put it in the Privacy Policy?

My game has been updated steadily every week on the appstore for several months. When I submitted the updated version for review recently, it was rejected by 4.3, saying that my game has no characteristics. However, there is no other game with unique features such as custom skills on the appstore except my game, so I am puzzled and hope to be re-reviewed. There is another problem. My game has accumulated a part of users on the appstore user side. They are anxious because they cannot update to the latest version and urge me to solve the Apple version update problem quickly. I hope Apple can give me, an individual developer and Apple mobile phone users, a practical solution to this problem, instead of just a 4.3 rejection without specifying the specific reason.

We are an EU-based company and targeting only the EU market. According to the EU regulations, we should be able to use alternative payment systems. We decided to use Stripe SDK, as we already using Stripe on our web platform. However, when we sent the app for review, the reviewer asked us to add in-app purchases as a must in the app. We have the Alternative Terms Addendum for Apps Distributed in the European Union signed, but it seem it is igored by the reviewer. One more point, we would like to keep the payment process inside de app using Stripe SDK and not to send users out of the app via com.apple.developer.storekit.external-purchase, which is very wrong user experience. Anyway we can't find any clear documentation how to enrole and use the alternative payment options in the app. Please help.

I need to ship an urgent critical bug fix being experienced by paying users. AppName: Filters for Pictures: by LAVIE AppleID: 6743334853 My app has been in "In Review" status since a while -> I can see from our logs that the reviewer opened the app, went through first 4 onboarding screens and then quit the app without proceeding further. There has been no updates since then and app in just "In Review" state indefinitely. On App StoreConnect, I am also unable to "Remove From Review", I get Error with HTTP Status 409: STATE_ERROR.ENTITY_STATE_INVALID So, I cannot even remove the current build and push a new build for review. Our users are demanding a fix urgently so its critical to ship an update.

I'm getting my IAP rejected for: Guideline 3.1.1 - Business - Payments - In-App Purchase We have begun the review of your in-app purchase products but are not able to continue because you have submitted in-app purchase products for the Non-Consumable type, but you have not yet submitted an updated binary for review. Next Steps To resolve this issue, please upload a new binary and resubmit the in-app purchase products for review. I made a new binary and getting it ready to submit, but there is no option to include an IAP. From what I have read, you need the paid agreements signed and you have to have the IAP in the ready to submit phase to have the option to submit it on the new binary. I added notes to the IAP Submission: I'm unsure what to do here, as I have tried multiple times to create a new build and attach the IAP to the build. But the option to attach the IAP isn't there. From what I have read online, the IAP has to be in the Ready To Submit stat and paid agreements signed, which I do have signed. But I feel like the problem is that it's getting rejected because I need to attach it to a new binary, but that new binary doesn't have the option to attach because I don't have an IAP that is in a ready-to-submit state. It's a chicken before the egg problem. Hopefully it may get resolved with my notes to the review team. In the mean time is there something I am missing or should be doing?

Hello, I have submitted my app for review what seems like countless times. With my first submission, i created five consumable in app purchases and submitted those for review alongside my build. My app keeps getting rejected because the reviewer cannot find the in app purchase in my app. I keep telling them that my app screen is dynamic and only shows available products. All of my submitted in app purchases are still in the "Waiting for Review" state and therefore do not show up. This is a chicken or the egg scenerio. I need the purchases approved so they show up in the app and can be tested by the reviewer but for whatever reason they are not being approved and the reviewer is only looking at my build and rejecting it. How do others get around this? This seems like a broken process (submitting in app purchases with builds instead of independently). I desperatly want to get out of this submit->rejection cycle.

Hello, Appeal Ticket: APL149985 Thank you for your patience as we considered your appeal. The App Review Board determined that the original rejection feedback was valid. Your app does not comply with: 4.3(a) - Design During our review, we found that this app duplicates the content and functionality of other apps submitted to the App Store, which is considered a form of spam and not appropriate for the App Store. Apps submitted to the App Store should be unique and should not duplicate other apps. We encourage you to create a unique app to submit to the App Store. For more information about developing apps for the App Store, visit the Develop section of the Apple Developer website. We appreciate your efforts to resolve this issue and look forward to reviewing your revised submission. Best regards, Leo App Review Board BlockQuote a Blockchain based slg game got 4.3 a, I think the reviewer should know some thing about blockchain. 您好，我已经重新提交了一个版本的应用，和之前版本已经不同了，目前游戏的所有代码都是我自己写的，第三方的所有代码都被我移除了，所以代码上重复了其他游戏的是完全不存在的。 至于游戏玩法上，新的自定义技能冲榜系统，玩家可以通过“抽卡-编辑阵容-连续挑战”的方式，在遇到瓶颈时自定义技能突破关卡，这个玩法绝对是开创性的，因为已知的所有slg游戏的技能都是官方设计决定的，但是在我设计的这个玩法上，理论上所有的技能都将由玩家设计出来，这差别之大，正如区块链开创了一种崭新的去中心化的时代，和原有中心化的模式是完全不同的，据我所知，目前市面上不存在任何一款去中心化的slg游戏。但是您，尊贵的审核人员居然认为这样一款开创性的游戏是和其他中心化游戏是一样的，类同的，我相信苹果作为全球最伟大的科技公司，官方工作人员都是很专业的，都是很有见识的，都是主张创新的，主张玩家能获得独特的高质量的体验，但是这个拒绝让我疑惑。

I don not need IAP integration for my app. My app is only using own specific country's payment service. And my app is rejected

When i try to publish the app. I am getting this Warning. ITMS-90725: SDK version issue - This app was built with the iOS 17.2 SDK. Starting April 24, 2025, all iOS and iPadOS apps must be built with the iOS 18 SDK or later, included in Xcode 16 or later, in order to be uploaded to App Store Connect or submitted for distribution. I have few clarification on this. How much time do we generally have to publish the apps. If i have a App that is successfully reviewed and certified from apple team and I have Chosen to "Manually release this Version". Is it possible to Publish the App built using SDK 17.x After 24th April 2024. If the app is reviewed and certified before the April 24th timeline. If so, how long can i hold the published & certified app and publish. Without the need to rebuild and re-apply for certification.

My app was originally launched in 2019 and has accumulated around 200,000 users to date. I've been actively maintaining and updating the app for the past six years. Recently, I integrated some AI-related features using DeepSeek, but after submitting the update, the app was rejected with guideline 4.3(a) – spam or misleading content. I assumed the rejection was due to the AI functionality, so I removed all AI-related features and references, then resubmitted the app. However, the app was rejected again, still under 4.3(a). This has left me confused. The app has a long history, active users, and consistent updates. I don’t publish clones or multiple versions, and everything is original work. Has anyone experienced something similar? Could it be something else in the metadata, UI, or keywords that’s triggering the rejection? Any advice or insights would be really appreciated.

Dear App Review Team, My app has been under continuous development for 6 years since it first launched in 2019. It currently serves a loyal user base of over 200,000 users. I can confidently confirm that all the core functionality in the app is fully developed by me. While I do use a few third-party libraries, the overall app design, code, and feature set are entirely my own work. In my recent submission (Submission ID: c6ab3d17-4b1b-4c67-935e-c0f0c62973c6, reviewed on April 9, 2025, version 4.3.9), the app was rejected under guideline 4.3(a). I previously integrated AI features using DeepSeek, but after receiving a rejection, I completely removed all related AI components and metadata. However, the updated submission was still rejected with the same reason, and I was not given a clear explanation of what part of the app may be in violation. I deeply value this project, and so do my users who have accompanied me through this journey for years. I do not wish to give up on this app — it is meaningful to me and the community it serves. Please help me understand: What specific feature or part of the app is considered to be in violation of guideline 4.3(a)? Are there specific areas I can improve or change to meet App Store standards? I sincerely request guidance on how to resolve this issue and bring my app back to the App Store. I am fully committed to compliance and to improving the app experience. Thank you for your time and support. Best regards,

Hi everyone, I’ve been struggling for days to get my in-app subscriptions approved, and I could really use some clarity or guidance from other developers or Apple engineers. Everything works fine in development (debug builds with sandbox). The issue starts when testing via TestFlight or during App Store Review. When Apple reviewers attempt to subscribe, my backend returns: "transaction id not found" As a result, I keep getting rejected under Guideline 2.1 (App Completeness) with this note: “When tapped to make the purchase, an error still appeared... your server needs to handle a production-signed app getting receipts from Apple’s test environment...”

Hi, I submitted an app review on Apr 2, and soon got an rejection Guideline 2.3.1 Performance, meaning this app may contain hidden features, specifically it may contain real money gambling functionality. But, the app does not contain either hidden features or real money gambling functionality. I re-submitted a new version which removed possible misleading words on the same day, and the app review status remained waiting for review for 6 days. Long waiting made me feel it's weird. I tried to cancel submission and submitted app review again on Apr 8, and it's been waiting for review. Can you help check why my submission wait so long? Thanks a lot! Submission ID ff886851-1ddf-4508-9d39-303cdbb34ff8

Hi everyone, I’m hoping to get advice or hear from anyone with similar experiences. Our app Pixllove was originally rejected under Guideline 4.3 (“Spam”). We were later invited to an App Review call with Erica, who reviewed everything and confirmed verbally and in writing (April 8, 2025) that the spam classification was removed. She acknowledged that our app uses a unique concept and only required us to implement a pre-chat consent popup. We implemented exactly that: • A popup appears before any chat starts, displaying the match’s name, age, and distance. • Users must actively accept before the chat begins. • We show this clearly in our new demo video. • Full reporting/blocking/moderation is in place. However, after submitting the updated build, we were again rejected under a different interpretation of 1.2, with the reasoning that our app “connects users randomly.” This appears to be a misunderstanding, since no match occurred during their test – and it takes at least 2 users online for a match to happen. We explained this and even submitted a screenshot of the consent popup, which had been explicitly requested by Erica. Sadly, the reviewer ignored our message and Erica’s previous confirmation and labeled us as spam again. We replied and asked them to please review Erica’s note from April 8, but we haven’t received a response yet. We’re lucky to have a second review meeting scheduled for Tuesday, but this experience has been extremely frustrating and honestly, quite unprofessional — especially after being told the issue had been resolved. Has anyone experienced something similar? What can be done to ensure prior Apple Review decisions are respected by future reviewers? Thanks so much in advance, Emilija Pixllove Team