Reasons
2.16: Multitasking Apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc.
17.5: Apps that include account registration or access a user’s existing account must include a privacy policy or they will be rejected
----- 2.16 -----
We found that your app uses a background mode but does not include functionality that requires that mode to run persistently. This behavior is not in compliance with the App Store Review Guidelines.
We noticed your app declares support for location in the UIBackgroundModes key in your Info.plist but does not include features that require persistent location. specifically, it would be appropriate to
revise your app to use significant-change location services to achieve the functionality you have described.
Since your application does not require persistent, real-time location updates, we recommend using the significant-change location service or the region monitoring location service.
For more information on these options, please see the "Starting the Significant-Change Location Service" and "Monitoring Shape-Based Regions" sections in the Location Awareness Programming Guide.
If you choose to add features that use the Location Background Mode, please include the following battery use disclaimer in your Application Description:
"Continued use of GPS running in the background can dramatically decrease battery life."
----- 17.5 -----
We also noticed that your app includes account registration or access to users’ existing accounts but does not include a privacy policy, which does not comply with the App Store Review Guidelines.
Please update your app metadata to include a privacy policy and ensure that the privacy policy URL you provide directs the user to the intended destination.
If your iTunes Connect Application State is Rejected, a new binary will be required. Make the desired metadata changes when you upload the new binary.
NOTE: Please be sure to make any metadata changes to all App Localizations by selecting each specific localization and making appropriate changes.
For discrete code-level questions, you may wish to consult with Apple Developer Technical Support. When the DTS engineer follows up with you, please be ready to provide:
1. In 2.16 what are the thing I need to do before re-submitting the app to store?
2. Currently I have included the privacy policy in it, even though they rejected, any clue?
For 2.16
As per, App Store Review Guidelines I can say that you are using Location Service or any another service in background which is not consistently used in app. So why to put load in background process? Decide your flow and based on that use those services on pro-active basis. Do not run or use any background services. Sometime background process stops automatically by malfunctioning of other app or memory related issues.
e.g. Let's say I want to use GPS for location based service. Why should i invoke the service call until I want Longitude and Latitude by writing it in background services? I am using it whenever I need the GPS data.
For 17.5, I guess you have uploaded Privacy Policy so it's fine.
So,make the change accordingly and upload the build again.
Best of luck.
Need to Specify the Key in plist for the Backgroundmode. Example If you are tracking users location in foreground and used backgroundmode in capabilities then your app may get rejected in binary testing.
Make sure that you use Both the functionalities and Plist key for the background which you are using.
I've thoroughly reviewed the reason for 2.16 mentioned above - which looks similar to what we had for one of our apps.
In our scenario - it was meta data rejected. We simply added this line at the end of the description.
Disclaimer: Continued use of GPS running in the background can dramatically decrease battery life.
If in you case - if you were asked to upload a new binary. Along with above line also follow the above suggestions for modifying UIBackgroundModes and ensure how that will effect your app feature.
For 17.5 - app should be accessible with very limited information to register - instead of lengthy fields - and more over it should clearly mention which field is mandatory and optional.
Please mention why you need such information in privacy policy. Also review some sample privacy policies of other apps what they have included.
Hope this answer helps someone. Happy coding.
Related
I keep getting my iOS app submission rejected by apple with the following message:
Guideline 5.1.2 - Legal - Privacy - Data Use and Sharing
The app privacy information you provided in App Store Connect still
indicates you collect data in order to track the user, including User
ID and Product Interaction. However, you do not use App Tracking
Transparency to request the user's permission before tracking their
activity.
Starting with iOS 14.5, apps on the App Store need to receive the
user’s permission through the AppTrackingTransparency framework before
collecting data used to track them. This requirement protects the
privacy of App Store users.
Next Steps
Here are two ways to resolve this issue:
If you do not currently track, or decide to stop tracking, update your app privacy information in App Store Connect. You must have the
Account Holder or Admin role to update app privacy information.
If you track users, you must implement App Tracking Transparency and request permission before collecting data used to track. When you
resubmit, indicate in the Review Notes where the permission request is
located.
Resources
Tracking is linking data collected from your app with third-party data for advertising purposes, or sharing the collected data with a
data broker. Learn more about tracking.
See Frequently Asked Questions about the new requirements for apps that track users.
Learn more about designing appropriate permission requests.
I already updated my app not to use any IDFA calls (including all the facebook and other SDKs) https://developer.apple.com/documentation/adsupport/asidentifiermanager/1614151-advertisingidentifier
When I try to set the checkboxes in App Privacy section of the app they can't be completely uncheck (i.e. at least one of the options has to be selected) so I can't state that my app is no using device id even though the codebase doesn't make advertisingidentifier at all.
Does App Tracking Transparency really mean that we can't track anything, even user clicks on buttons and screen views???? If so that's insane!
The main issue is that I want to have a better user experience for my users by not showing them an unnecessary ATT prompt.
You need to do the following 2 things:
Update the Data Types section to remove the Device Id. You can find it on the top of the privacy section, then hit Edit, navigate through till the last Nexts and uncheck the Device Id
Update the User ID and Product Interaction sections to uncheck - No, we do not track the user. You can find it at the end of the privacy section, then hit Edit, navigate through till the lastNexts and uncheck the above-mentioned box.
Submit the app again for review.
We were facing same issue when we removed Tracking from application and NSUserTrackingUsageDescription key from app.
Our app was already live on store with tracking enabled. In new version we faced this issue. When app was rejected we just replied them that we are not using this anymore in our application so we removed tracking authentication popup. We also told them that we were not able to update in App privacy because live version have tracking enabled.
After that reply they approved.
Sample Answer to apple when we removed from existing app:
"we have removed NSUserTrackingUsageDescription and tracking from this version, so we also removed Tracking Permission Popup from this version. We tried to remove it from App Privacy, but we could not change the Privacy data types in the Appstore connect because the current live version does use that permission. Please review our request and approve our application submission"
I distributed an iOS app on AppStore, but the app was rejected because we are requesting permission for user location in background.
I already answered the reviewer many times explaining why we need to use background location for our users, and I also added a disclaimer in the application description as stated on other questions here on stack overflow informing the user that the usage of GPS in background can increase battery depletion speed. But the app is still being rejected for the same reason that is Apple performance guideline 2.5.4.
2.5.4 Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc. If your app uses location background mode, include a reminder that doing so may dramatically decrease battery life.
I noticed that apps that request user location in background have an additional Information field called Location.
App with Location field
But my app does not contain that field
App without Location field
So I presume, that instead of adding that disclaimer on the app description on iTunes Connect form, I should place it somewhere else, but looking at my iTunes Connect account on App Information session there is no text field where I can input that information. And consulting Apple Docs I also wasn't able to find where I should input that.
So my question is where I can set that information that is shown on iTunes, via iTunes Connect?
So my question is where I can set that information that is shown on iTunes, via iTunes Connect?
Nowhere. Apple adds that, not you.
I already answered the reviewer many times explaining why we need to use background location for our users
Well, that is what you need to attend to. You are evidently trying to use background location in some skanky way, and you are busted. So use background location legitimately or not at all.
From Apple
2. 5 Performance: Software Requirements
Guideline 2.5.4 - Performance - Software Requirements
We noticed that your app declares support for location in the UIBackgroundModes key in your Info.plist file but does not have any features that require persistent location. Specifically, your app uses location background mode for the sole purpose of tracking employees, which is not appropriate on the App Store.
Next Steps
To resolve this issue, please revise your 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.
If tracking your employees' locations is your only intended use of background location, it would be more appropriate to distribute and sell your app as a custom B2B app, directly to CBS Clean, through the Volume Purchase Program. Additional information about the Volume Purchase Program and the Custom B2B Store is also available in iTunes Connect Developer Help.
Request a phone call from App Review
At your request, we can arrange for an Apple Representative to call you within the next three business days to discuss your App Review issue.
To request a call and ensure we have accurate contact information, reply directly to this message with a contact name and direct phone number to reach you.
i have developed a app for cleaners..cleaners location should be fetch in background for their payroll calculations and safety measurements..and also cleaners can view their worked places in mapview...but my app gets rejected..now what should i do..how to deal with this issue
Have a look here.
You can include the functionality and methods for the location services if your app needs Location services or remove the Location Updates from the UIBackgroundMode key in info.plist, So that your app will be approved by App Store.
I think you are using
locationManager.requestAlwaysAuthorization()
use this locationManager.requestWhenInUseAuthorization() instead.
I am creating an iPhone app that will be free with the purchase of a set of headphones. The idea at this point is that a passcode will be included with the headphones that will let the user enable the app which is a DSP app with filter settings specifically for the headphones. The passcode only needs to be entered once and then the app will be permanently enabled. I assume that I will have to use my own server to check the passcode and return an authorization to the device. Does anyone have any advice on how to implement this functionality?
You could easily/quickly implement this feature using one of the PaaS (Platform as a Service) providers out there. Parse, StackMob, Azure, etc. They provide the database in the cloud and the REST API to access it, and you simply make a read on the password table to see if the entry exists (using the provider API). These services are very inexpensive and you could use the free tier until you get meaningful volume.
However, note my previous comment, that this would not be approved as an app for violating the App Store Guidelines.
Apps that arbitrarily restrict which users may use the App, such as by
location or carrier, may be rejected
Apps that unlock or enable additional features or functionality with
mechanisms other than the App Store will be rejected
I have an app that I did as a proof of concept and put on the app store just to gain experience going through the process but it turns out, it gets quite a few downloads, probably 30 a week. No Angry Birds but the app is very specific on the data it provides. It's a free app and what I would like to do now is gather some data on the users - how often they use it, where they are, what information they are searching and saving. I have no intention of touching personal data but I'd like to be able to aggregate what all the users are doing and see if there's any value in that.
Is this permitted in an iOS app? I see reports where apps are gathering more data than that (like Path pulling all your contacts) and I would think what I am looking to do is pretty standard.
Any advice is appreciated.
Check the App Store approval guidelines. That is the best resource you have.
https://developer.apple.com/appstore/resources/approval/guidelines.html
A few excerpts that may be relevant to you:
Location
4.1 Apps that do not notify and obtain user consent before collecting, transmitting, or using location data will be rejected
4.2 Apps that use location-based APIs for automatic or autonomous control of vehicles, aircraft, or other devices will be rejected
4.3 Apps that use location-based APIs for dispatch, fleet management, or emergency services will be rejected
4.4 Location data can only be used when directly relevant to the features and services provided by the App to the user or to support
approved advertising uses
Privacy
17.1 Apps cannot transmit data about a user without obtaining the user's prior permission and providing the user with access to
information about how and where the data will be used
17.2 Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
17.3 Apps that target minors for data collection will be rejected
Independent of what the guideline says, you should be mindful of your users privacy. As long as you don't pin the information you collect to individual users, I guess you might be fine.
Regarding location data, the guideline states you can't collect for analytical purposes if it is not relevant to the app's usage. However, it is referring to the gps data. You can obtain location for analytical purposes through network access information.