Adding analytics does not mean you have to ask for permission to track.

What does it take to add an analytics SDK to an Expo app?

A development build, for most of them. Expo documents the constraint in one line on its analytics guide: most analytics SDKs require custom native code to be configured, native code cannot be configured in Expo Go, and a development build lets you use any of the services listed. So the first decision is not which provider. It is whether you are ready to build and install your own binary, because until you are, the shortlist shrinks.

Expo lists eight services on that page as of its 14 August 2026 revision: Google Firebase Analytics through the React Native Firebase library, Segment, Amplitude, AWS Amplify, Aptabase, Astrolytics, PostHog and Dreambase. Three carry a note saying they work with Expo Go: Aptabase, Astrolytics and PostHog. If you want numbers today without a build pipeline, that note is the whole shortlist. Expo links out to each vendor for the install steps and does not ship an analytics SDK of its own.

Screen views are the one event worth wiring properly, and Expo Router has a documented way to do it. Expo describes an experimental performance integration you turn on before the root layout mounts, after which the router records performance marks for navigation and you observe the one named page-focused and forward its pathname, params and screen ID to your provider. The guide notes that a preloaded screen produces no focus mark until somebody navigates to it, that each mark carries a start time in milliseconds measured from the performance time origin, and that the API is experimental and the names may change. That page was last modified on 14 October 2026, which is recent enough that you should re-read it rather than copy an older snippet.

Expo, React Native analytics SDKs and libraries, last modified 14 August 2026, read 22 October 2026

Does adding analytics require App Tracking Transparency?

No, and this is the sentence most articles get wrong. Apple puts the trigger in one place. On iOS 14.5, iPadOS 14.5 and tvOS 14.5 or later you need permission through the App Tracking Transparency framework in order to track somebody, or to read their device advertising identifier. That is the whole trigger. The word analytics does not appear in it.

Tracking has a published meaning, and it is narrower than the everyday use of the word. Apple defines it as linking data your app collected about a person or a device with data about them collected from other companies apps, websites or offline properties, for targeted advertising or advertising measurement. Sharing data about a person or a device with a data broker also counts, with no advertising needed. Counting how many people opened your booking screen last week, in your own account, joined to nothing, is outside both halves.

The vendor is the thing to worry about. Apple says that putting a third-party SDK in your app which pools your users data with users data from other developers apps to target advertising or measure its efficiency is tracking even if you do not use the SDK for that, and the example Apple reaches for is an analytics SDK whose owner repurposes what it collects to run targeted ads in other developers apps. That is the question to put to a provider before you install it, in writing. Apple also says, twice and in plain language, that you are responsible for all code in your app, so an answer you did not get is still your problem at review time.

Now the other side of the line. Apple publishes three cases that are not tracking: data joined with third-party data only on the device and never sent off it in a way that could identify the person or the device, a broker that uses what you share solely for fraud detection, fraud prevention or security, and a consumer reporting agency receiving it for creditworthiness reporting or a specific credit decision. Then there is the carve-out worth more than the other three to a small developer: the identifier for vendor may be used for analytics across apps from the same content provider, and Apple states that the framework is not required in that case, as long as the IDFV is not combined with other data to follow somebody across apps and websites that other companies own.

If you do need the prompt, Expo has the library. The expo-tracking-transparency package requests the permission and returns the advertising identifier, and it is included in Expo Go. Expo warns that you must add the tracking usage description to your Info.plist to explain how the person will be tracked or Apple will reject the app, and its config plugin sets that string for you with a default of its own. That string needs translating as well, and Expo documents how: leave the plugin value at its default and put the key in each locale file, which Expo writes into the iOS strings file during prebuild, and the same mechanics show up again when you add localization to the rest of the app. On Android the library adds the Google Play services advertising ID permission by itself, which Expo notes is required for apps that target Android 13, API level 33, or higher and use that advertising ID. Two results will confuse you while testing: the advertising identifier comes back as null in the iOS simulator whatever the settings say, and without permission on a device it comes back as zeros.

One change with a date on it. Apple says that from iOS 27.2 and iPadOS 27.2 developers can use an alternative version of the tracking prompt in the European Union, worded and formatted differently, with an optional text button labelled Additional Information. In Germany, France, Italy, Poland and Romania only the alternative version is available. Apple states in the same paragraph that the requirements for when you must seek permission stay the same, so nothing above changes. EU users can also be asked again a year after their last answer, and the device setting is renamed there.

Apple, User Privacy and Data Use, read 22 October 2026

What do you have to declare on the privacy nutrition label?

Start with the part people get backwards. The label is not something analytics switches on. Apple requires privacy information in App Store Connect to submit a new app or an app update, full stop, and that requirement covers the practices of third-party partners whose code you integrate. Apple names analytics tools, advertising networks, third-party SDKs and other outside vendors as those partners. An app with no analytics at all still answers the questions. What analytics changes is how many rows you tick.

The word doing the work is collect, and Apple defines it tightly on its App Privacy Details page: transmitting data off the device in a way that lets you or your third-party partners reach it for longer than is needed to serve that request in real time. A counter that lives on the phone and is shown to the person is not collection. A pageview sitting in a dashboard for ninety days is. Apple adds that data collected for reasons other than analytics or advertising still has to be declared, with App Functionality as the purpose, so collecting an email address only to sign somebody in is a row on the label.

There is an optional disclosure route and ordinary analytics does not qualify for it. A data type can be left off only if it meets every one of four conditions, and two of them rule out event tracking on their own: collection has to happen in infrequent cases outside the primary purpose of the app and be optional for the person, and the data has to be something they type into your interface each time, with their own name or account name shown beside it. Apple says a type meeting some but not all of the criteria must be disclosed, and that data collected on an ongoing basis after an initial permission request must be disclosed. The example Apple gives of what can be left off is an optional feedback form or a customer service request unrelated to what the app is for. A screen-view counter is neither.

One narrow carve-out is worth knowing, because it describes an opt-in you could actually build. Apple lists a Product Improvement Programs exception with seven conditions, all of which must hold: the data is only used to improve your app and its services, the person opts in through a choice presented in the interface with one clear option to share and one not to, that choice changes no feature and no price, it can be changed later through an accessible setting, the data is not linked to their identity, it is not used for tracking, and it is not used for advertising, marketing, product personalisation or anything else. Build the opt-in honestly and you earn a shorter label. Fail one condition and you declare it like everybody else.

Two more details catch people out. Apple says data from an app is often linked to a person's identity unless you strip direct identifiers before collection and break the link so it cannot be rebuilt, and afterwards never attempt to re-link it or join it to a dataset that would. And if you store IP addresses, Apple tells you to declare the data types that match how you use them, which could be precise location, coarse location, device ID or diagnostics. Most analytics providers see an IP address whether you asked for it or not. Answers can be updated at any time in App Store Connect without shipping an app update, which is the one forgiving part of this. The sequence around it is in publish to app store.

Separately from the label, third-party code has to declare itself in a privacy manifest. Apple says that if your app uses third-party code such as advertising or analytics SDKs, that code must describe what it collects, how it is used and whether it tracks, and Xcode combines every manifest into one report when you prepare to distribute. Expo supports this through a privacy manifests field in the app config and warns that Apple does not correctly parse all the manifest files shipped inside static CocoaPods dependencies, so you may have to repeat a library's required reasons in your own. Expo also points out the cheap way to find out whether you missed one: submit a build, including to TestFlight external review, and Apple emails you within minutes if a required reason is absent.

Apple, User Privacy and Data Use, on Privacy Nutrition Labels and privacy manifests, read 22 October 2026

What should you actually measure first?

Screen views and one completed action. That is the whole first version. If you run a shop, the completed action is a booking or an order. The pair answers the only question a new app has, which is whether anybody gets from the first screen to the thing the app is for, and it tells you which screen they stop on. Add events after somebody asks a question your numbers cannot answer, not before.

Resist a second SDK. Every provider you add is another set of answers on your label, another privacy manifest that may need its required reasons copied into yours, and another company whose data practices you have signed up for without reading. One analytics provider and one crash reporter is a sane shape, and they are genuinely different tools: crash logs and performance figures sit under the diagnostics data types rather than usage data, so the label rows differ too. The install side of that is in add crash reporting.

Newly builds the app this all applies to. You describe what you want in plain English and it writes a real React Native and Expo project that you own, with two-way GitHub sync, so adding a provider is an ordinary dependency and an ordinary config change rather than a support ticket. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It costs $25 a month and there is no free tier. It does not press submit on the App Store for you, because Apple requires the owner of the content to submit, and the privacy answers are part of what the owner signs off.

A closing note on honesty, since it is cheaper than a correction. Write down what each event is for before you send it. If you cannot name the decision a number would change, the event is costing you a row on your privacy label and buying nothing. The apps with the shortest labels are usually the ones whose owners thought about this for an hour, and a short label is something a buyer can read.

Expo, React Native analytics SDKs and libraries, the provider list and the development build note, read 22 October 2026