iOS: What restrictions are there on data gathering from within an app? - ios

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.

Related

Apple contact usage policy

I am building a native social app in Android and iOS
I am using contacts from users phonebook to determine if his target friends are on our app or not and send the events accordingly
I recently came across this news that Apple is banning apps to send contacts to the server, which is the backbone of my app in order to function
How should I approach this problem? How do apps like WhatsApp which sync contacts (whole phonebook) to their server manage through this?
Do I need apple review of the app to access phonebook permission?
From This article I quote
But the phone maker didn’t publicly mention updated App Store Review
Guidelines that now bar developers from making databases of address
book information they gather from iPhone users. Sharing and selling
that database with third parties is also now forbidden. And an app
can’t get a user’s contact list, say it’s being used for one thing,
and then use it for something else -- unless the developer gets
consent again. Anyone caught breaking the rules may be banned.
Since the question is quite general let's dive into it a bit.
Looking into the App Store Review Guidelines there are three places mentioning that users' contacts should not be collected.
First and second, users should not be forced to provide their address book in exchange for app functionality (paying with contacts; highlights were added, a similar phrase is used for app subscriptions):
Apps should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, […]
Third, uploading and/or storing contacts to/on a server has an impact on users' privacy and is prohibited for the following use-cases:
Do not use information from Contacts, Photos, or other APIs that access user data to build a contact database for your own use or for sale/distribution to third parties, and don’t collect information about which other apps are installed on a user’s device for the purposes of analytics or advertising/marketing.
This does not exclude using contacts for creating a social graph for the benefit of your users. However, collecting all contacts might violate the principle of data minimization. So Instead of just uploading all contacts, Apple recommends to use a contact picker (see ContactsUI), where the app only gets access to the contacts the user selected:
Data Minimization: Apps should only request access to data relevant to the core functionality of the app and should only collect and use data that is required to accomplish the relevant task. Where possible, use the out-of-process picker or a share sheet rather than requesting full access to protected resources like Photos or Contacts.
The Art. 32 of the GDPR requires you to take the
[…] the state of the art, the costs of implementation and the nature, scope, context and purposes of processing […]
into account.
I think that the process has to be made transparent (as in comprehensibly explained to the user):
The user should have control over which contacts are used for discovery. All would be a valid choice – selected contacts (through the contact picker) or manually entering contact information (phone number, email – whatever is used for your contact discovery process) would be valid choices as well.
The app should function even if the user denies access to the contacts. In that case you can still offer a contact picker, or manual entering.
You must describe the process, including what information is used and for what purpose, in your privacy policy.
You should at least hash the processed values, as you do not need the actual phone numbers or email addresses for contact discovery and hashing comes without much effort and cost. However, be aware that hashing of personally identifiable information is not sufficient for "anonymising" these values – which is a common misconception.
For more advanced protection, you can take a look at the blog post by the authors of the Signal app, where they describe technical details on how they protect their contact discovery process.

Privacy Policy for Apps that do not collect datas

I am currently in the process of bringing an app to the iOS app store. It's just a small app I made in my free time. It is workout-related, so the app requires access to location and health data from the user. The data, however, is only stored on user devices. My app does not send this data anywhere (except for iCloud sync), no login is required, and I also do not implement any tracking frameworks except for the built-in Apple one that you have to agree to when setting up iOS.
Now the app store requires me to link to a privacy policy (probably because health data is potentially sensitive information). I searched for privacy policy generators online, but all I could find just seem to assume that you collect personal data. They include statements such as:
We collect several different types of information for various purposes to provide and improve our Service to you.
or
Your information, including Personal Data, may be transferred to — and maintained on — computers located outside of your state, province, country or other governmental jurisdiction where the data protection laws may differ than those from your jurisdiction.
I am afraid this might confuse users, since I explicitly state on my app store description that the data is not stored on my servers. Should I keep this in the policy nonetheless to be on the safe side legally? Or can anyone point me into the right direction what I need to include in my policy if I actually do not collect personal user data?
You collect + use personal data (location data + health data) in your app, regardless of the method of storage: on your own servers, locally on user's device, and so on. The only difference is that you do not send the collected data anywhere else (except iCloud sync).
If you don't use the collected data, simply disclose it in your Privacy Policy. Disclose that the data you collect is not store outside the user's device (except for iCloud).
Ecquire has an example of Privacy Policy for "no collection of data":

App review rejection. How to use CloudKit? Or what is CloudKit for?

I am developing a chat app that uses CloudKit to authenticate the users, store data on the cloud and then exchange content between users.
Initially, according to the reviewer following guideline was breached when asking user to have an iCloud account setup on the device to make use of app entire set of functionality.
5.1 Privacy
5.1.1 Data collection and storage
(ii) If your app doesn’t include significant account-based features, let people use it without a log-in. Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law.
On a phone call I explained to him the app allows the user to open it, navigate around. But wont allow the user to create chat rooms or upload/share data within the rooms as it needs CloudKit authentication to store the data to then share it between users. According paragraph (ii) that was a significant account based feature to require authentication. He was fine with that.
Then he said he would still not be able to approve the app because CloudKit should only be used if the app intends to store data on the cloud. Data like, documents, photos, etc... according to him a chat app (WhatsApp a example) that stores images and text on the cloud to then share it between users is not actually storing data on the cloud and for that reason should not be using CloudKit and would be a definitive rejection.
Designing for CloudKit documentation says:
You can represent all the persistent model objects in your app using a CloudKit schema. However, the CloudKit framework should not be used to replace model objects in your app and should not be used for storing objects locally. It is a service for moving data to and from iCloud and sharing data between users of your app.
Not seeing where is my breach when the app:
only asks the user to authenticate when a core feature of the app is
called
uses the authentication to store messages, images, etc... in
the users iCloud account
uses the authentication to exchange this data that has been stored between users
After investing huge amounts of time and money in the app it is hard to accept a permanent rejection for such an odd reason. There is no documentation to sustain his argument or stop us from investing time/money with CloudKit wrongly.
Not sure where to go from here. Anyone with similar issue when using CloudKit?

How does HealthKit actually share data?

On the Apple's HealthKit Framework official site it says that
"The HealthKit data is not saved to iCloud or synced across multiple devices. The data is only kept locally on the user’s device."
If it's stored locally and never synced with a cloud then it means that I cannot share it with other users. But then Apple says that it's possible to share your data with your doctors as Epic and Mayo clinic are Apple's partners. How is this possible?
And also, how does the data come from wearable devices to the phone?
It's very confusing.
I would be grateful if anyone could explain that because Apple and others basically say the same things and no one explains how that really works.
HealthKit is a data repository that apps from the App Store use to share health data. The user may choose to authorize an app to read or write HealthKit data. For example, an app from Withings can write weight measurements from its wireless scale to HealthKit and then Strava may read those weight measurements to keep your profile on their site up-to-date. This is how apps share data using HealthKit.

Do I need to ask users whether or not I can track them with Mixpanel events - iOS

I'm developing iOS app, friends of mine suggested me to use some tracking system, to find out how "really" people are using my app, analyze result. And pivot if needed.
I decked to use Mixpanel system. Do I need to to ask user about permission ? I just wonder that somebody could be offended by tracking. On the other hand data is anonymous.
What Apple says about tracking ?
Can I easily disable Mixpanels's track method (https://mixpanel.com/site_media/doctyl/uploads/iPhone-spec/Classes/Mixpanel/index.html#//apple_ref/occ/instm/Mixpanel/track:properties:) or I need to check some flags myself ?
PS:
I also have some doubts about the fact, that my app don't use network connection at all (besides buying in app purchases). And I wonder that user could be not aware that I track his behaviour and send it to the serwer (using network conneciton)
According to the App Store Review Guidelines, you may not transmit data about a user without permission:
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
There is even a more specific guideline regarding collection information on minors:
17.4 Apps that collect, transmit, or have the capability to share personal information (e.g. name, address, email, location, photos, videos, drawings, the ability to chat, other personal data, or persistent identifiers used in combination with any of the above) from a minor must comply with applicable children's privacy statutes, and must include a privacy policy
I suspect this isn't the case here, but if you include location information, you must request permission for that, too:
4.1 Apps that do not notify and obtain user consent before collecting, transmitting, or using location data will be rejected
Whether you can collect non-identifying information (e.g. anonymous app usage information), is less clear. If you collect anything, though, your app should disclose its privacy policy regarding both identifying and non-identifying information.

Resources