Subject: Concern Regarding App Removal and Account Termination Under Guideline 3.2(f)
Dear Apple Developer Team,
I recently received a notification that my application is being removed from the App Store and my developer account is being terminated under Guideline 3.2(f). Despite submitting detailed, clear, and solution-oriented appeals, I have consistently received the same automated response.
My application featured unique, high-quality, and professionally crafted content, adhering to Apple’s guidelines. I believe this decision may stem from some misunderstandings. However, I have been unable to connect with anyone for further clarification, and my appeals seem to be overlooked in favor of a standard response.
As a developer, I have always prioritized compliance with Apple’s policies. In fact, during previous reviews, I explicitly ensured that my app met all requirements, even consulting Apple before implementing certain features. I am concerned that this decision may not fully reflect the effort and care I’ve put into adhering to Apple’s standards.
I understand the high volume of appeals Apple receives and the pressure to make swift decisions. However, I strongly believe that a thorough review of my appeal would reveal that any potential issues have already been addressed.
I urge Apple to approach this situation with the professionalism and fairness that the developer community expects. Recognizing and addressing such concerns would reinforce the trust and collaboration between developers and Apple.
Thank you for your time and understanding. I sincerely hope for an opportunity to resolve this issue and continue contributing to the App Store ecosystem.
Best regards,
App Review
RSS for tagUnderstand the technical and content review process for submitting apps to the App Store.
Post
Replies
Boosts
Views
Activity
Hi everyone,
I’m encountering a recurring issue with my app submission, and I’d appreciate your insights. My app has been rejected due to Guideline 2.5.4 with the following feedback:
Guideline 2.5.4 - Performance - Software Requirements
The app continues to declare support for location in the UIBackgroundModes key in your Info.plist file but we are unable to locate any features besides employee tracking that require persistent location.
Using the location background mode for the sole purpose of tracking employees is not appropriate.
Please note we located the features of the app but the location background tracking of employees is not appropriate with this guideline.
Next Steps
If the app has a feature besides tracking employees that requires persistent location, reply to this message and let us know how to locate this feature. Otherwise, it would be appropriate to revise the app to include additional features for your users that require the persistent use of real-time location updates while the app is in the background
My App’s Use Case:
The app is designed to support events where users can check in and check out. Persistent location tracking is essential for the following:
1. During Events:
• Tracking users’ real-time location ensures they remain within the event boundaries.
• If a user exits the designated area, the system logs the occurrence for compliance and security purposes.
2. Workforce Monitoring:
• For work events, the app records working hours based on their presence within the event area.
• This ensures accurate logging of attendance and work durations.
Steps I’ve Taken:
• Limited Scope of Tracking: Persistent location tracking is active only during event check-in and check-out periods. Outside of these periods, tracking is disabled.
• User Consent: I’ve implemented clear permission requests and a privacy policy to explain how location data is used.
• Info.plist Configuration: I’ve declared the UIBackgroundModes key with location to support background tracking.
Despite these measures, my app continues to be rejected with the feedback above. I believe my app’s features align with the guidelines as the location tracking is directly tied to event functionality and user benefit.
Questions:
1. How can I better explain this use case to Apple’s review team to demonstrate compliance?
2. Are there any additional features or adjustments I should consider to ensure my app meets the guidelines?
3. Has anyone faced a similar issue with persistent location tracking, and how did you resolve it?
Thank you for your guidance and support!
We're seeking guidance regarding our latest app review (ID: fa69f469-2043-4069-a8be-249916c564ed) which raises concerns about our location services implementation. While we have submitted an appeal to the App Review Board, we'd greatly appreciate any community insights while we await their response.
Key Issues:
Our app calculates Islamic prayer times and Qibla direction - both requiring location services for religious accuracy
Review suggests making the app work without location, which would prevent:
Calculating accurate prayer times based on location
Determining Qibla direction (mandatory prayer direction towards Mecca)
Current Implementation:
Two-step location permission process with proper iOS system prompts
ATT framework properly implemented (screenshots provided)
Non-location features (Quran, etc.) accessible without location/login
Clear user communication about location requirements
Previous Steps Taken:
Provided screenshots showing ATT implementation
Demonstrated proper location permission flows
Explained religious requirements for location services
Made non-location features accessible without permissions
Question: How have other religious/prayer apps handled similar requirements where core functionality (prayer times, direction) inherently requires location services?
I've attached a screen recording demonstrating:
Two-step location permission process
[Video Demo]
Any guidance would be greatly appreciated, especially regarding best practices for implementing essential location services while meeting App Store guidelines.
Hello
My app got rejected with the message "We noticed your app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences."
In short, my app is a vpn app built entirely by me. In Russia almost all vpn protocols are blocked: wireguard, openvpn etc. And the only protocol they could not block was vless. It was hard to implement it, i spent like 3 weeks on it writing my own package on flutter. The app first was uploaded to android and shared through testflight with some of my friends. And everyone switched to my app, because it works perfect for their needs: accessing instagram, twitter etc. Those apps are blocked here.
So on my first attempt publishing i got 2 errors:
Vpn should be published on the account that is organization
Spam rejection
I registered a company and switched from individual account to a company.
I also changed the ui of the app (although i agree most vpns share the same concept design).
I got rejected again with only "Guideline 4.3(a) - Design - Spam".
I appealed with a question why was it it rejected, explaining that the app was built by me, and of course, i use some libraries. I got the same roboting response.
After that i added some features:
Built in private browser
Network connection speed
Today submitted the new version hoping it would pass, but yet again got "Guideline 4.3(a) - Design - Spam".
I'm really frustrated, because i spent 3 months developing the app.
I understand there are dozens of vpns. But vpn is not exactly the simple feature app. Some are bad, some are good, and some doesn't work at all.
My app doesn't have any ads and paid subscriptions.
I also renamed my app to "Incognito - Browser, VPN". But can't get pass.
Would like to get some advices. Please help
P.S. Sorry for my bad grammar
Hi,
I am trying to connect and use the App Store Connect API so that I can download app reviews remotely. I have read the documentation and have used the API address as stated in the documentation:
GET https://api.appstoreconnect.apple.com/v1/apps/{id}/customerReviews.
I keep on receiving a 403 error:
"errors" : [ {
"id" : "fbe7b837-2023-4f60-8fa0-88b50368f4cc",
"status" : "403",
"code" : "FORBIDDEN_ERROR",
"title" : "This request is forbidden for security reasons",
"detail" : "The API key in use does not allow this request"
}
I am using the same keys and headers that I use to connect to obtain sales reports info, which works absolutely fine, using the below link:
https://api.appstoreconnect.apple.com/v1/salesReports
Is there anything extra that I need to set up before I can access the reviews or am I missing something.
Thanks.
I recently tried to upload my first app to the app store, but it got rejected, and I do not know how I can fix it.
It got rejected because:
The landing page of our app includes a URL that directs users to external mechanisms for purchases or subscriptions to be used in the app.
The app includes an account registration feature for businesses and organizations, which is considered access to external mechanisms for purchases or subscriptions to be used in the app.
But this app is an extension of our web application (Galantis). Galantis contains various features, including one called "MyTime". When a customer purchases this feature, their employees gain access to our app. This feature can only be purchased by one of our customers and not their employees.
The credentials of these employees are created directly within our website because they need to be managed by their team leader.
Anyone an idea of how I would fix this?
Build the archive, validating and uploading it to App Store Connect - TestFlight is successful from Xcode (16.0, macOS 15.1.1). Although after that the build is rejected stating :
ITMS-90429: Invalid Swift Support - The files libswiftCoreFoundation.dylib, libswiftCoreData.dylib, libswiftCore.dylib, libswiftFoundation.dylib, libswift_Concurrency.dylib, libswiftObjectiveC.dylib aren’t at the expected location /Payload/Runner.app/Frameworks. Move the file to the expected location, rebuild your app using the current public (GM) version of Xcode, and resubmit it.
Cross checked the Archive and .ipa file, where we found that the mentioned .dylib files are actually present inside the "/Payload/Runner.app/Frameworks" folder, and all the ".dylib" files are also present in the "SwiftSupport/iphoneos" folder.
Scenario : using tdLib compilation "libtdjson.xcframework" (embedded & signed) for ios arm64 placed under "Framworks", in my Flutter application, calling methods via "Method Channels", interacting with AppDelegate.swift file where the tdLib methods are being called from the compiled library.
All "swift support settings" are enabled in Xcode while archiving and building the application.
My app is completely unique and i dont know why apple is giving me spam error. There is no similar app to mine and i am 100% sure of it. I brainstormed this idea myself for over a week to create such a game.
And every code i have done is my own and i have not used any templates.
Please help guys i am very confused why my app is getting spam rejection.
Why is the application we developed from scratch directly judged as Guideline 4.3(a) - Design - Spam?
Anyone else experiencing longer than normal review times? Right now it's five days and counting. I surmise that maybe ppl may be taking early Christmas vacations.
Hi everyone,
I’m seeking advice and insights regarding an ongoing issue with the App Store review process for my app.
Our app is a platform that connects companies with users—companies can log in, add their services (e.g., real estate or engineering services), and users can explore, save, and compare those services. We don’t offer or market any services ourselves.
Despite explaining this multiple times during the review process, our app was rejected under Guideline 4.2.2: Minimum Functionality, with the reasoning that the app's "main functionality is to market your service."
Here’s what I’ve done so far:
I made a video that display part of my app which is cycle of company can add a new service and user can explore , save it and compare with another services
Shared Similar Apps: I highlighted examples of apps on the App Store that follow a similar model:
Thumbtack: https://apps.apple.com/us/app/thumbtack-home-service-pros/id852703300
Houzz: https://apps.apple.com/us/app/houzz-home-design-remodel/id399563465
Requested Feedback: I asked the reviewer how our app differs from these examples and what specific features we could add to align with App Store policies. I even proposed adding a chat feature between companies and users, which we’re already considering, but the response I received was, "We are not able to provide feedback."
This has been frustrating because I’ve followed their suggestions for clarity but keep receiving the same rejection with no actionable guidance.
Has anyone faced a similar situation? Any advice on how to proceed or examples of features that helped similar apps get approved?
Thanks in advance for your help!
my app link :
https://testflight.apple.com/join/9XvFv3gD
video i added to reviewer :
https://drive.google.com/file/d/1iKkfv7Mghf8_x9jCpZAOLyLP5hqTRS5e/view?usp=sharing
App review claimed they couldn't access the address we provided. However, after supplying this address to Google for review, it was accessible without any issues.
We suggested that the review change their network environment or attempt to access the address through a browser, but this request was denied. It's been half a month, and the review of our app has made no progress.
Hi everyone,
I’m reaching out for advice on how to address a rejection under guideline 1.1.6 for my app, Dog Translator Game for Dogs.
The app is meant to be a fun, interactive experience for dog owners. It offers playful features such as:
Playing pre-recorded dog sounds to see how dogs react.
Converting a user's voice into dog-like barks for entertaining interactions.
Recording a dog’s vocalizations and matching them to a library of sounds, giving users an idea of what their dog might be "saying" based on the tone and pitch.
To avoid any confusion, I’ve clearly presented the app as a game and for entertainment purposes only. I’ve even included “Game” in the app name and categorized it under Entertainment and Games in the App Store. The description explicitly states that the app isn’t scientifically accurate or designed to translate dog speech—it’s just a lighthearted way to interact with pets.
Despite all this, the app was rejected because it was deemed to have misleading or deceptive content. Below is the text from the rejection:
“Hello,
The issues we previously identified still need your attention.
If you have any questions, we are here to help. Reply to this message in App Store Connect and let us know.
Review Environment
Submission ID: [removed]
Review date: December 15, 2024
Version reviewed: 1.0.2
Guideline 1.1.6 - Safety - Objectionable Content
The app contains content or features that are misleading, intended to deceive users, or are otherwise fraudulent.
Specifically, translating for dogs.
Please note that adding a disclaimer to the app description is not sufficient if the rest of the metadata and the app are misleading.”
What I’ve Done to Address This:
Renamed the app to include Game in the title, emphasizing its purpose as a fun and entertaining tool.
Rewritten the description to explicitly clarify that the app is not a serious translation tool but a playful way to engage with dogs.
Ensured the app is listed in the Entertainment and Games categories.
It’s disappointing because the app is designed purely for fun, and I’ve gone to great lengths to communicate that to potential users.
My Question:
Have any of you faced a similar situation? What additional steps could I take to ensure reviewers understand that this app is meant for entertainment and not to mislead users?
I’m open to any suggestions or insights you might have to help me refine my approach before resubmitting.
Thanks in advance for your input!
Arda
when i try the app in debug and in testflight with iphone and with VPN it is working well but in the app review they cannot connect to the api the api is http i made in the info plist to allow arbitrary loads to allow the http but we got the same error message that in the photo
the api is in port 80 why it tells in that port
Hello,
My mobile game 'Wordilo' has been rejected due to Design: Copycats 4.1. I am reviewing the mentioned warnings, but my application does not contain any direct elements that could be considered a copy of a known game, apart from the core game mechanics.
The game mechanic is a crossword puzzle, and there are already many apps with this game logic on the App Store. For example, the rules and style of a backgammon game are well-established, and there are many similar games based on this.
I need more specific guidance in this regard.
Thank you.
I am using RevenueCat to dynamically show subscriptions using experiments.
I'm doing this to experiment with price and wording on the paywall.
However, apple is rejecting this because they can't find all the subscriptions. However it's literally not possible for a user to see them all. I tried explaining this in my first rejection but they rejected it again. Any ideas?
Guideline 2.1 - Information Needed
We have started the review of your app, but we are not able to continue because we cannot locate the in-app purchases within your app at this time.
Specifically, out of 9 only 3 were found during the review.
Next Steps
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.
Note that in-app purchases are reviewed in an Apple-provided sandbox environment. Make sure they have been appropriately configured for review in the Apple-provided sandbox environment.
If you are restricting access to in-app purchases based on factors such as storefront or device configurations, please include this information in your reply along with steps to enable the in-app purchases for our review.
Resources
Learn more about offering in-app purchases.
Learn more about testing in sandbox.
Support
Reply to this message in your preferred language if you need assistance. If you need additional support, use the Contact Us module.
Consult with fellow developers and Apple engineers on the Apple Developer Forums.
Provide feedback on this message and your review experience by completing a short survey.
Reply to App Review
Guideline 3.1.1 - Business - Payments - In-App Purchase
We found in our review that your app or its metadata provides access to mechanisms other than in-app purchase for purchases or subscriptions to be used in the app, which does not comply with the App Review Guidelines. Specifically:
Your app's Thanks window includes the following call-to-action and/or URL that directs users to external mechanisms for purchases or subscriptions to be used in the app:
After generating icons, a "Buy me a coffee" button is presented that goes to a website to make a purchase.
I literally just want my app to be able to take "tips" without going through apple in app purchases, because the cut they take is INSANE
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?
Seeking developer insights regarding a 4.3(a) review response citing "similar binary, metadata, and/or concept." Our app implements distinct community-focused features that fundamentally differentiate it from existing applications in this category.
Feature Implementation:
Our app introduces new technological approaches to faith-based applications:
Community System: Custom-built group participation with progress visualization
Engagement Features: Peer support system with achievement tracking
Progress Metrics: Proprietary points system for progress tracking
Group Progress Features: Shared accomplishment tracking
Achievement Architecture:
Progress continuity tracking
Performance metrics accumulation
Custom recognition system for personal and group milestones
Synchronized goal-setting framework
Market Analysis:
Our research indicates:
No existing apps with group-based progress features
No solutions combining community features with scheduling
No applications with similar group achievement systems
No platforms featuring synchronized progress tracking
Substantial user base requesting these features
Technical Questions:
How have developers effectively demonstrated feature differentiation?
What technical documentation best demonstrates unique implementations?
What strategies work for showing market demand for new features?
Best practices for documenting novel community features?
Implementation Context:
While core scheduling features necessarily overlap with existing solutions, our platform's focus on community engagement and achievement tracking represents a novel approach, validated through user research and community feedback.
Seeking insights from developers who have successfully implemented unique social features in established categories.
Hi. After a few attempts to submit my game, it is still rejected with the following reason: Guideline 4.1 - Design - Copycats
The submitted app is designed and developed 100% from the scratch, and I don't know the reason of the issue, as I can’t identify which part of the metadata is the issue.
After sending a messages to moderation team asking to specify which exactly part of the metadata is the issue, and which other app do they mean, I’m still getting the same template reply, referring to the “Guideline 4.1 - Design - Copycats”.
I have even updated the icon, believing that it was the reason of issue, but it was not a solution.
Now I don’t really know what to do?
Here is the full warning message:
—————— “Guideline 4.1 - Design - Copycats
This app or its metadata appears to be misrepresenting itself as another popular app or game already available on the App Store, from a developer's website or distribution source, or from a third-party platform.
Apps should be unique and should not attempt to deceive users into thinking they are downloading something they are not.”
Next Steps
Learn more about requirements to prevent apps from impersonating other apps or services in guideline 4.1.
Revise the app to comply with these requirements.
Once the app is fully compliant, resubmit the app for review.
——————
Thanks.