Hi, I read your post and it sounds like an incredibly tough situation. I’ve been through a Pending Termination Notice myself, so I truly understand how stressful this can be. I’d like to share my experience just in case it might be of some help. At this stage, it might be more effective to focus less on defending the anti-virus app’s innovation and more on protecting your developer account and your livelihood. In my own case, focusing on a few specific points in my appeal seemed to make a difference: Clarify your intent: Since the app was flagged as malicious, you might want to clearly explain that you had absolutely no intention of misleading users. While your personal situation (such as losing your source of income) is completely understandable, Apple’s review process is guideline-driven, so I think it might be more effective to keep the tone as professional as possible. Write a concrete preventative measure: I mentioned this in another thread recently, but I believe including a clear preventative plan makes it much easier for Apple to accept your appeal. If you decide not to pursue the development of this app that caused the misunderstanding, stating that clearly might help strengthen your case—though of course that's ultimately your call. Establish good faith: You’ve been a developer since 2009—that’s a huge asset. Reminding them that your other apps follow the rules might help show that this was an isolated mistake, not a pattern of malicious behavior. In hindsight, it might have been better to appeal directly to the App Review Board when the app was first rejected. However, considering that the situation has already escalated after multiple exchanges with the regular App Review team, instead of continuing to argue about the app itself or the review process, I believe it might lead to a better outcome if you apologize for causing a misunderstanding and show a strong commitment to complying with the App Store Guidelines moving forward. I really hope things work out for you.

Hi, Don't worry, your app is actually available in the New Zealand App Store! I checked this and found that it seems to be a search ranking/indexing issue rather than an availability issue. As you can see in the attached screenshots, searching the full name "HeartBLE: Heart Rate Bluetooth" in the NZ App Store successfully returns your app, while the short keyword "HeartBLE" alone does not yet show it. Since your app is completely new (released on March 5), it might not be ranking high enough for the short keyword just yet.

Hi, In my case, it took 6 days (I submitted my enrollment on December 12, 2025, and received the welcome email on December 18, 2025). There were no requests for additional information. Based on information I found on the internet, I expected it to take about a month, so I was surprised by how quickly it was approved. I’ve attached screenshots for your reference.

Hi, You may have already tried this given the 10+ submissions, but my first thought is that your app may not function correctly in an IPv6-only environment. App Review Guideline 2.5.5 states, "Apps must be fully functional on IPv6-only networks." With that in mind, it may be worth checking the following: Hardcoded IPv4 Addresses: If you are using raw IPv4 addresses (like 192.168.x.x) in your code instead of hostnames (domains), NAT64/DNS64 cannot translate them, causing the connection to fail in an IPv6-only environment. Low-Level Networking APIs: If your app uses low-level BSD socket APIs directly instead of high-level networking APIs (like URLSession), it may fail to handle NAT64 correctly unless properly implemented for IPv6. If you want to test your app in an IPv6-only network, you can simulate this environment using your Mac's Internet Sharing feature with NAT64/DNS64 enabled as a hotspot. The section "Test for IPv6 DNS64/NAT64 Compatibility Regularly" in Apple's documentation "Supporting IPv6 DNS64/NAT64 Networks" explains the exact steps.

Hi, If you are using PNG files, it seems that screenshots with alpha channels (transparency) can fail to process correctly. This may be why the “uploads in progress” message stays visible even though the images seem to have uploaded fine. In that case, try exporting them as JPG to see if that fixes it. If you want to stay with PNG, you can remove the alpha channel using the built-in Preview app on macOS by unchecking the “Alpha” option during export. Hope this helps!

Hi, I went through a very similar situation in February 2026 and was eventually able to get my account reinstated, so I wanted to share my experience in case it helps. To answer your questions first: In my case, it took 10 days total for my account to be reinstated, but the App Review Board responded just 3 days after I submitted a second appeal that correctly identified the actual root cause. Based on that, waiting more than 30 days does feel unusually long. It’s possible that your current appeal may not be addressing the specific issue Apple is concerned about. Regarding your case, metadata problems typically result in a standard App Rejection, not an account-level action — so I personally find it unlikely that subtitle keywords alone would trigger a Pending Termination Notice. Here is the timeline of what happened to me: Feb 11: I submitted an update for my published app (“App A”). Feb 14: I received Pending Termination Notices for all my apps. The notice was a generic template, and Apple did not explicitly point out the exact problem. Since I had just submitted an update for App A, I incorrectly assumed that update was the cause. I submitted an appeal specifically for App A, explaining its architecture to show there were no hidden features. I received no response. Feb 21: Prior to the termination notice, I had opened a regular Developer Support ticket for a different, unreleased app (“App B”), simply asking when its review would start. Support finally replied to that old ticket, stating: “After checking your app record, I can confirm a decision was made to your developer account...” Seeing App B mentioned in the context of an account decision made me suspect that this unreleased app might actually be the target. I then remembered leaving some experimental web browser features, along with in-development code for subscriptions and video conversion, in its codebase. Because it was a hassle to delete the code entirely, I had commented out the UI. Users couldn’t access it, but the code was still compiled in the binary. I immediately submitted a second appeal, this time focusing on App B. I proactively reported this leftover code as my hypothesis for the issue, admitted the oversight, and presented a concrete preventative plan. Feb 24: Just 3 days later, the App Review Board revoked my termination. App B was then rejected under Guideline 2.3.1 (Hidden Features). I removed the code and recently resubmitted it (still waiting for review). My developer account was restored, and my previously removed published apps returned to the App Store. Based on my experience, if there is a possibility that the issue lies in your binary rather than the metadata, here is what I would suggest: 1 . Inspect all apps under your account (including unreleased ones) Don’t just focus on the app you recently updated. Inspect the codebase of every app. If there are any apps you haven’t filed an appeal for yet, you might want to submit appeals for them as well. 2 . Proactively self-report if you find anything questionable If you discover unused code, leftover frameworks, or features with commented-out UIs, proactively self-report it in your appeal. You can clarify that there was no malicious intent (e.g., no UI execution path), explain why the code remained, and outline the exact steps you will take to prevent similar issues going forward. I recommend doing a deep audit of all your apps. If you already appealed for an app but later discover a more plausible root cause, submitting a new appeal with that specific information may help. I have attached screenshots of my notices for reference. I hope your situation gets resolved soon. *App A *App B *App B

Hi, Looking at your screenshot, I think there are a few UI patterns that might be triggering the Guideline 5.6 rejection. Here are my thoughts on what might be causing the issue: 1 . Misleading Purchase Flow (Default Selection & "Continue" Button) The timeline at the top emphasizes a “3-day free trial,” and the Yearly plan clearly shows a trial badge. However, the Monthly plan is selected by default and doesn't appear to include a trial. Because the screen heavily promotes a free trial, having a prominent "Continue" button while a non-trial plan is selected can give the false impression that tapping it starts a trial. I think this looks like a “bait-and-switch” pattern where users expect a trial but are charged immediately. Instead of selecting a plan by default, I think it would be better to have no plan selected initially, requiring the user to explicitly make a choice. 2 . Lack of Clear Feature Explanation “Reduce Uncertainty When Dining Out” is a nice headline, but I think the paywall needs to explicitly list what specific features are unlocked by the subscription. Without this context, reviewers might feel the screen is pushing users toward a purchase without clearly explaining what they are paying for. 3 . Missing Standard Subscription Disclosures I believe it is necessary to include standard auto-renewal fine print at the bottom of the screen, such as stating that subscriptions automatically renew unless canceled at least 24 hours before the end of the current period. Currently, this standard disclaimer text seems to be missing. For reference, I’m attaching a screenshot of my own app’s paywall. I designed it so that no plan is selected by default (the "Subscribe" button remains disabled until a choice is explicitly made), the premium features are clearly listed, and the standard disclosures are included at the bottom. Hope seeing a concrete example helps, and good luck with the resubmission!

I am in the exact same boat. I submitted a new app on Jan 25, and it is still stuck in "Waiting for Review". I reached out to Apple Support on Jan 30 and followed up on Feb 5. I finally received a reply yesterday (Feb 10) that might help you decide. They explicitly warned against rejecting and resubmitting: "When you reject and resubmit your binary, your expected review time will once again be 24 hours. We realize that there are circumstances which make it necessary to reject and then resubmit your binary, but doing so affects your overall review time." The email states that resubmitting resets the expected review time to "24 hours." If resubmitting actually guaranteed a 24-hour turnaround, I’d do it in a heartbeat! But I don't think we can trust that number right now. So, sticking with Option 1 seems like the safest bet. Good luck!

Apple hardly reviews apps over the weekend, so if you submitted it on Thursday, it has really only been about two business days. I think it’s still too early to be worried. Even updates can take three or four days, so delays can happen. For what it’s worth, I submitted a new app on January 25th and even contacted support, but I still haven’t received any response lol.

Sharing my situation as well. I submitted a new app on January 25, and it has remained in “Waiting for Review” since then. I contacted App Review Support on January 30, but I haven’t heard back yet, so I sent a follow-up today. I also submitted an app update on February 2, and that submission is still in “Waiting for Review” as well. I haven’t contacted support regarding the update submission.