Protect user privacy by securing personal data and respecting the user's wishes with how data is used.
Designing for user privacy is important. Most Apple devices contain personal data that the user might not want to expose to apps or to external entities. If your app accesses or uses data inappropriately, the user might stop using your app or even delete it from their device.
Access user or device data only with the user’s informed consent obtained in accordance with applicable law. In addition, take appropriate steps to protect user and device data and be transparent about how you use it. Here are some best practices that you can follow:
Review guidelines from government or industry sources, including the following documents:
The Federal Trade Commission’s report on mobile privacy: Mobile Privacy Disclosures: Building Trust Through Transparency
The EU Data Protection Commissioners’ Opinion on data protection for Mobile Apps: http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2013/wp202_en.pdf
The California State Attorney General’s recommendations for mobile privacy: Privacy on the Go: Recommendations for the Mobile Ecosystem
The Japanese Ministry of Internal Affairs and Communications’ Smartphone Privacy Initiatives:
Smartphone Privacy Initiative (2012). English version: http://www.soumu.go.jp/main_sosiki/joho_tsusin/eng/presentation/pdf/Initiative.pdf. Japanese version: http://www.soumu.go.jp/main_content/000171225.pdf.
Smartphone Privacy Initiative II (2013). English version: http://www.soumu.go.jp/main_sosiki/joho_tsusin/eng/presentation/pdf/Summary_II.pdf. Japanese version: http://www.soumu.go.jp/main_content/000247654.pdf
Request access to sensitive user or device data, which is protected by the iOS system authorization settings, at the time your app needs the data. You must supply a purpose string (sometimes called a usage description string) in your app’s Info.plist file explaining why your app needs the data or resource you are attempting to access. Data protected by iOS system authorization settings includes location, contacts, calendar events, reminders, photos, media, and many other types as well. Provide reasonable fallback behavior in situations where the user does not grant access to the requested data.
Give the user control over their user or device data. Provide settings so that the user can disable access to certain types of sensitive information as needed.
Request and use the minimum amount of user or device data needed to accomplish a given task. Do not seek access to or collect data for non obvious reasons, for unnecessary reasons, or because you think it might be useful later.
Take reasonable steps to protect the user and device data that you collect in your apps. When storing such information locally, try to use the iOS data protection feature (described in Protecting Data Using On-Disk Encryption) to store it in an encrypted format. Use App Transport Security (as described in NSAppTransportSecurity) when sending user or device data over the network.
If your app uses the
ASIdentifierclass, you must respect the value of its
isproperty. And if that property is set to a NO/a by the user, then use the
Advertising Tracking Enabled
ASIdentifierclass only for Limited Advertising Purposes. “Limited Advertising Purposes” means frequency capping, attribution, conversion events, estimating the number of unique users, advertising fraud detection, debugging for advertising purposes only, and other uses for advertising that may be permitted by Apple in Documentation for the Ad Support APIs.
If your app supports audio input, configure your audio session for recording only at the point where you actually plan to begin recording. Do not configure your audio session for recording at launch time if you do not plan to record right away. The system alerts users when apps configure their audio session for recording and gives the user the option to disable recording for your app.
Requesting Authorization to Use System Features
For some protected data and resources, iOS frameworks provide dedicated API for checking and requesting authorization. When using these features, you must request and receive authorization before using the corresponding feature. Attempting to use a feature for which you do not have authorization is a programmer error.
Table 1 lists the data and resources protected by system authorization settings. The purpose string associated with each entry is the key that you must add to your app's
Info file with a description of how you intend to use the data. Use the specified APIs to request authorization to use the data or resource.
Data or resource
Use the state property of the
When your app first attempts to access a property of the
Check for a
Music and the media library
Use the checkAccessStatus(options:completionHandler:) method of the
Because a user can change authorization at any time by using Settings, check the authorization status of a feature before accessing it. (Some features, notably motion and HomeKit, do not provide dedicated API for checking system authorization status.)