App Store privacy guidance

Submitting Privacy Details

When submitting your app to the Apple App Store, you will need to submit privacy details about your app. On each app’s product page, users will be able to see the data the app may collect, and whether that data is linked to them or used to track them. Apps should be submitted to the App Store in line with Apple’s privacy guidelines.

The following sections describe how the data is captured by BugSnag and how its usage relates to Apple’s policies.

Optional disclosure

The use of BugSnag does not meet the criteria for optional disclosure. The data collected by BugSnag is not wholly provided by the user in the app interface, and the frequency of reporting cannot be guaranteed to be below a set threshold.

Therefore, you will need to consider the types of data that you are sending to BugSnag from your application when completing your app’s privacy details.

Types of data

The automatically captured data page provides information on what data BugSnag captures by default, and guidance on preventing capture of each type of data. BugSnag can be configured to override any automatically captured data, and also send custom additional metadata. You should consider additional data you’ve configured BugSnag to send for your App Store privacy details.

The following table describes how Apple’s definition of data types relate to BugSnag’s automatically captured data, to aid providing privacy information for an app.

Data	Automatically captured by BugSnag
Contact Info
Name	No
Email address	No
Phone number	No
Physical address	No
Other user contact info	No
Health and Fitness
Health	No
Fitness	No
Financial Info
Payment info	No
Credit info	No
Other financial info	No
Location
Precise location	No
Coarse location	No
Sensitive Info
Sensitive info	No
Contacts
Contacts	No
User Content
Emails or text messages	No
Photos or videos	No
Audio data	No
Gameplay content	No
Customer support	No
Other user content	No
Browsing History
Browsing history	No
Search History
Search history	No
Identifiers
User ID	Yes. An overridable unique identifier is generated for the user.id value if no user data is set.
Device ID	Yes. An overridable unique identifier is generated for the device.id value.
Purchases
Purchase history	No
Usage Data
Product interaction	Yes. Breadcrumbs are stored and sent with each event report. You can configure which breadcrumb types are captured on iOS, macOS, tvOS, React Native, Cocos2d-x, Expo, Electron, Unity, or Unreal Engine. You can discard or ammend breadcrumbs on iOS, macOS, tvOS, React Native, Cocos2d-x, Expo, Electron, or Unreal Engine with an OnBreadcrumb callback. If your application uses React Native, Expo, or Electron: JavaScript breadcrumbs are additionally captured. User interaction and navigation type breadcrumbs include details of which selectors are clicked and their text value, so consider for your app whether these breadcrumbs contain any other types of data. You can configure which JavaScript enabledBreadcrumbTypes are captured in React Native, Expo, or Electron. You can amend or remove breadcrumbs in your native Cocoa layer, or with a JavaScript onBreadcrumb callback. Sessions are tracked by default with the BugSnag Cocoa notifier. You can disable automatic session tracking with the autoTrackSesssions configuration option on Cocoa, React Native, and Cocos2d-x. Or, for Expo, Electron, Unity, or Unreal Engine.
Advertising data	No
Other usage data	No
Diagnostics
Crash data	Yes. We also send “internal” crash reports when there is a crash in BugSnag library code. This can be disabled with the telemetry configuration option.
Performance data	Yes
Other diagnostic data	No
Other Data
Other data types	BugSnag additionally captures application information by default.

Data use

SmartBear does not use event data from customer applications for any of the purposes outlined by Apple. We processes data on behalf of each BugSnag customer to provide data analytics about crashes and application stability to that customer (the data controller).

However, by using BugSnag, you may be using data in the ways described below.

Data use	Applicable to your use of BugSnag?
Third-party advertising	No
Developer’s advertising or marketing	No
Analytics	You may consider that you use BugSnag for analytics purposes, such as planning new features, and measuring audience sizes.
Product personalization	No
App functionality	Yes. You can use BugSnag to minimize app crashes, and improve stability.
Other purposes	No

Data linked to the user

If you are setting user data, then you need to be aware that all reports sent to BugSnag can be linked to that individual user. By default BugSnag captures a unique user ID (based on the device) so that reports from the same user can be linked even if no user data is associated with the reports.

This unique ID can be removed by setting nil for each of the fields in setUser. Please note that there is also a device.id field which stores the same UUID that should also be removed to unlink a user from a report.

Tracking

Using BugSnag does not require user permission via the AppTrackingTransparency (ATT) framework as BugSnag does not track users according to Apple’s definition:

• BugSnag does not link user or device data with user or device data from any other source, for any purpose.
• BugSnag does not access the device’s advertising identifier.
• BugSnag does not act as a data broker.

Privacy

You will have the ability to add links on your product page to your app’s privacy policy and your privacy choices. Should you wish to reference our privacy policy this is available on the SmartBear website.

Declaring required reasons for API usage

Apple will soon require usage of certain APIs to be declared through the required reason API to reduce the ability for developers to misuse them for device fingerprinting.

The BugSnag SDK uses some of these APIs and so the following reasons should be entered in the Privacy manifest for your app:

Type	Reason	Justification
NSPrivacyAccessedAPI CategorySystemBootTime	35F9.1	We report the amount of time your app has spent in the foreground in app.durationInForeground. This uses mach_absolute_time to derive it from the system boot time, which is a permitted exception.
NSPrivacyAccessedAPI CategoryUserDefaults	CA92.1	We use the User Defaults API to store data between launches for inclusion in events. However we use standardUserDefaults which is stored in, and can only be accessed by, your app.
NSPrivacyAccessedAPI CategoryFileTimestamp	C617.1	We use fstat to check a crash file looks valid before opening it, to avoid a crash caused reading an older version of the file format. This is permitted as it’s within the app container.
NSPrivacyAccessedAPI CategoryFileTimestamp	disallowed	We currently use stat as part of our jailbreak detection code, which checks a path outside your app. We are working on alternatives for this in a future release which will be available before Apple’s restrictions come into full force.
NSPrivacyAccessedAPI CategoryDiskSpace	E174.1 (with workaround)	Our primary usage of statfs is to ensure space on the device before writing crash files, which is a permitted exception (E174.1). However we currently also use it to report device.freeDisk in our events being sent off device, which is not allowed. To avoid a violation now, you can use a delivery-time callback to remove this data. We are working on mitigating this restriction in a future release which will be available before Apple’s restrictions come into full force.