Visit Website →
← Back to blog

Export iOS App Data: Parse Tabs, Keep Raw Files for App Managers

October 16, 2026
Export iOS App Data: Parse Tabs, Keep Raw Files for App Managers

You can export App Store data two ways: manual downloads from App Store Connect for ad-hoc needs, or programmatic exports through the App Store Connect API for scheduled ingestion. Either way, Apple delivers compressed .gz archives that contain tab-delimited .txt files, so you must decompress and parse on tabs, not commas. Keep the raw file, along with its vendor and reporting period, before you transform anything.

TL;DR:

  • Use Sales and Trends for aggregated units and downloads, Payments and Financial Reports for payout reconciliation, and Analytics reports for sessions, retention, or conversion.
  • Apple delivers compressed GZIP archives containing text files separated by tabs; decompress them, parse tabs rather than commas, and preserve each untouched archive.
  • For Analytics ingestion, track request and report IDs, poll for availability, retrieve every segment, and mark completed work to prevent missed rows or duplicate loads.
  • Before trusting totals, verify the vendor ID and reporting dates, compare figures with App Store Connect, and check date alignment, schema, and missing segments.
Obsidianridgelabs
Keep Your Notes Private
Obsidian Ridge Labs builds private AI apps for Apple devices, with on-device processing that keeps personal data off the cloud.
Visit Obsidian Ridge Labs

Table of Contents

How do you export data from iOS apps manually in App Store Connect?

The manual route suits quick audits, one-off questions from a stakeholder, and small teams that have no pipeline yet. Apple documents the flow on its download and view reports help page: you select Trends, open Sales and Trends Reports, choose a vendor and a date or reporting period, and download. What arrives is a compressed GZIP archive holding a tab-delimited text file, not a ready-made spreadsheet.

Here is the sequence we follow when we export by hand:

  1. Sign in to App Store Connect with a role that can see sales and reporting data.
  2. Open the Trends area and choose Sales and Trends Reports.
  3. Pick the vendor account if your team manages more than one. This choice matters later, because the vendor identifies whose numbers you are looking at.
  4. Select the report period you need: a single day, a week, a month, or a fiscal period, depending on what the interface offers for that report.
  5. Click Download and save the .gz archive somewhere you control, not the default downloads folder you clear every month.
  6. Unzip the archive with your operating system's extractor or a command line tool such as gunzip.
  7. Open the resulting .txt file in Excel, Numbers, or Google Sheets, and tell the application that the delimiter is a tab.

That last step trips up many people. Double-clicking the file may produce a single column of crowded text because the application guessed a comma delimiter. Use the import dialog and set the delimiter explicitly. In Google Sheets, File, then Import, then "Tab" under separator type, handles it cleanly.

When manual downloads are the right call

Pick the UI when the question is narrow and one-time: "Did last Tuesday's promotion move downloads?" or "What did we earn from in-app purchases in the last reporting period?" A manual export takes a few minutes, needs no credentials beyond your normal login, and leaves nothing to maintain. The moment you catch yourself repeating the same download every Monday, that is the signal to move to the API covered further down.

A short checklist after every download

Before you analyze anything, run through four checks:

  • Vendor ID: confirm the file belongs to the vendor account you intended.
  • Reporting period: confirm the dates match what you selected, since a wrong date range is the most common reason a total looks off.
  • File integrity: make sure the archive unzipped without errors and the text file is not empty or truncated.
  • Raw file preserved: copy the original .gz into an archive folder before you open or edit anything. Spreadsheet applications can silently change number formats, strip leading zeros from identifiers, and reinterpret dates. The raw file is your reproducible source of truth.

Name the stored file so the metadata travels with it, for example vendor ID, report type, and period in the filename. Later, "report (3).txt" tells nobody anything.

A final note on where the data lives: exports from App Store Connect describe your app's business performance, not individual user content on a device. If your goal is instead to move files off a phone, Apple's Technical Note TN2152 on document transfer strategies covers the file-transfer approaches apps use to exchange data with a computer. That is a different task from pulling sales and analytics reports, and the two should not be confused in your planning.

Choosing the wrong report is a slower mistake than a bad download, because the numbers can look plausible while answering a different question. Apple splits reporting into families, and each has a job.

Sales and Trends covers aggregated sales and download activity. The Summary Sales Report shows aggregated sales and download data from the App Store for apps and in-app purchases, with defined field formats and column types. Its Title field, for instance, allows up to 4000 characters, which is a detail that matters when you set up parsing. Use this family for product performance and trend tracking.

Payments and Financial Reports are where payout and accounting figures live. When a finance team needs to reconcile what Apple paid against what the business recorded, this is the authoritative family, not the trends views. Sales and Trends tells you what activity occurred; the financial reports tell you what money moved. Treating the first as a stand-in for the second is a common source of month-end arguments.

Analytics reports go below the sales line to engagement. When the question is about sessions, retention, or conversion, this is the family you need. These reports are delivered through a separate API workflow, described in the next section.

Here is how the three line up in practice:

  • Product performance and trends: start with Sales and Trends. It answers "how many units, of what, on which devices."
  • Reconciliation and accounting: use Payments and Financial Reports. It answers "what was paid, and for which period."
  • Engagement and funnel questions: use Analytics reports. They answer "how do people use the app, and where do they drop off."
  • Mixed questions: export from more than one family and join them on app and period, rather than forcing one report to answer everything.

Dimensions you can expect

Apple's Sales and Trends metrics and dimensions reference lists the dimensions you can filter and group by: App, Client, Content, Content Type, Device, Parent App, Subscription, Transaction Type, and Version. Each maps to a common analysis task:

  • App and Parent App let you separate a standalone app from the bundle or parent product it belongs to.
  • Device supports questions about iPhone versus iPad share.
  • Version helps you see whether a release changed download or purchase behavior.
  • Transaction Type separates first-time purchases from other transaction kinds, which keeps revenue analysis honest.
  • Subscription isolates recurring products from one-time purchases.
  • Content and Content Type distinguish what was sold, such as an app versus an in-app item.
  • Client is useful when you need to see which client sold or surfaced the product.

A practical habit: before building any chart, write down which dimension answers your question and which report family exposes it. If a dimension you need is not in the report you opened, the answer is usually that you are in the wrong family, not that the data is missing.

How does the App Store Connect API handle report exports?

Once manual downloads become a recurring chore, the API replaces them. Apple's App Store Connect API overview explains that data can be retrieved programmatically: Sales and Trends reports use the sales-reports endpoint, while analytics reports follow the analytics-report workflow. The API exposes report-request, report, and segment resources for analytics retrieval, which supports scheduled ingestion instead of repeated manual downloads.

The key mental shift is that this is a lifecycle, not a single download URL. Apple's Analytics Reports API overview describes it as: create or identify a report request, inspect available reports, then retrieve report segments. A robust integration has to handle asynchronous availability, multiple segments, retries, and schema changes rather than assuming one permanent link.

Here is the flow, step by step:

  1. Create or identify a report request. This tells Apple which app and which kind of analytics data you want. You can read report request information to inspect its status later, so persist the request ID.
  2. List the reports for that request. Reading reports for a specific request returns the report resources that were produced. Store each report ID.
  3. Read the instances and their segments. When a report is large or split, the data comes back as multiple segments. Reading the segments for a report is how you find every piece. Missing a segment means silently losing rows.
  4. Download each segment and store it raw. Save the compressed segment exactly as delivered, tagged with the request ID, report ID, and reporting period.
  5. Decompress and parse in a separate step. Keep retrieval and parsing apart, so a parser bug never forces you to re-request data.
  6. Record completion. Mark the report and every segment as ingested, so a rerun can skip finished work.

For Sales and Trends, the path is shorter. Apple's documentation on downloading sales and trends reports details the sales-reports endpoint. Apple's Downloading Analytics Reports page explains how analytics reports are generated and how to retrieve them, and it is the right companion for the analytics side.

Implementation habits that save you later

Reports are not always ready the moment you ask. Poll with a backoff, so that you wait longer between attempts instead of hammering the endpoint. Persist every ID you receive. Plan for pagination wherever a listing returns more than one page, and for retries wherever a download can fail midway.

Pro Tip: Store the raw segment before you do anything else with it, and attach the request ID, report ID, and reporting period as metadata. When Apple changes a column or your parser has a bug, you reprocess from disk instead of waiting for data to be regenerated.

When automation pays off

Automate when the export repeats on a schedule: daily sales checks, weekly engagement summaries, or any feed that goes to a warehouse or dashboard. Consistent record-keeping is the second benefit people underrate. A pipeline leaves an audit trail of what was fetched and when, which a pile of manually saved files never does. If you only need an export a few times a year, the manual route remains perfectly sensible, and the API is not worth the maintenance.

What should you know about file formats and parsing?

Most broken ingestion jobs fail at the same place: someone assumed the file was a CSV. It is not. Apple's download and view reports page states that Sales and Trends downloads arrive as a compressed GZIP (.gz) archive containing a tab-delimited .txt file, and Apple's Analytics Reports API overview makes the same point for pipelines: decompress, parse tabs rather than commas, preserve the raw file, and record the vendor and reporting period.

Apple supplies a compressed .gz archive containing a tab-delimited .txt file, so a pipeline must decompress it and split on tabs, not commas. That one sentence prevents most first-week parsing bugs.

Parsing practices that hold up

  • Decompress first, then parse. Treat decompression as its own step with its own error handling, so a corrupt archive is caught before the parser sees it.
  • Split on tabs with a real parser. Use a library configured for a tab delimiter instead of splitting strings by hand. Hand-rolled splitting breaks the first time a field contains something unexpected.
  • Preserve the raw .gz. Keep the untouched archive and attach the vendor ID, reporting period, and report ID to it. Everything downstream can be rebuilt from that file.
  • Expect long text fields. The Summary Sales Report allows a Title of up to 4000 characters, per Apple's report reference, so do not size database columns for short titles.
  • Watch for embedded oddities. Free-text fields can contain characters that confuse naive parsers, including stray tabs or line breaks. A robust library with quoting support, plus a row-count check, catches this early.
  • Use the right character encoding. Read and write text as UTF-8 unless you have a documented reason otherwise, and fail loudly on decoding errors instead of replacing characters silently.

Large files and validation

For big files, stream the data instead of loading everything into memory. Read row by row, write in batches, and you keep memory flat no matter how large an export becomes.

After parsing, validate. Check that the header matches the columns you expect, that the row count is plausible against the raw file's line count, that numeric columns contain numbers, and that dates fall inside the reporting period you requested. A validation step that fails fast with a clear message is far cheaper than a dashboard that quietly shows wrong numbers for a week.

How do you automate exports reliably?

A dependable pipeline assumes things will go wrong and makes that harmless. Apple's own guidance, in the Analytics Reports API overview, says a robust integration must handle asynchronous availability, multiple segments, retries, and schema changes instead of assuming one permanent download URL. These are the practices we build around that:

  1. Make the job idempotent. Record every report and segment ID you have processed. A rerun should recognize finished work and skip it, so you can safely retry after a crash without duplicating rows.
  2. Store raw segments before transforming. Raw storage decouples fetching from parsing. If your transformation logic changes, you replay from disk.
  3. Retry with backoff. When a report is not yet available or a call fails, wait, then try again with a growing delay. Cap the number of attempts so a permanent problem surfaces as an alert instead of an endless loop.
  4. Log failures with context. Every failed call should record the endpoint, the response code, and the IDs involved. Alert a person when the same step fails repeatedly.
  5. Validate the schema on every run. Compare the incoming header against the expected one. If a column was added, removed, or renamed, stop the load, keep the raw file, and write a clear audit entry. Failing fast beats loading shifted columns into the wrong fields.
  6. Lock down secrets and storage. Keep API keys out of source control, load them from a secrets manager or protected environment variables, encrypt exports at rest, and restrict who can read parsed outputs.

Scheduling patterns

Match the cadence to the report and the decision it supports:

  • Daily: sales and download activity that a team checks regularly, where freshness matters.
  • Weekly: engagement summaries and trend reviews, where daily noise obscures the pattern.
  • Monthly: financial and payout reconciliation, which follows the accounting calendar rather than the product calendar.

Remember that availability is asynchronous. A job scheduled at a fixed hour should treat "not ready yet" as a normal outcome, not an error, and check again later.

Pro Tip: Run a small "canary" check after each load: compare the day's row count and total units against the previous run's range. A sudden drop to zero or a spike far outside the usual range usually means a schema or availability problem, not a real business event.

Privacy in automated exports

Automation increases the number of copies of your data, and every copy is a place it can leak. Export only the fields you actually analyze, set retention limits so old raw files do not accumulate forever, and give each downstream consumer the narrowest access that works. If your reports ever touch sensitive user information, treat the stored files like any other sensitive dataset: encrypted, access-logged, and deleted on schedule. Our guide to encrypting exports first walks through privacy-first handling that applies to any exported dataset.

How do you get exported data into spreadsheets and BI tools?

Different audiences need different destinations. Here are the recipes we use most.

Quick spreadsheet check

  1. Decompress the .gz archive.
  2. Open the tab-delimited file through the application's import dialog, selecting tab as the delimiter.
  3. Set column types explicitly: text for identifiers, numbers for units and amounts, dates for the date columns.
  4. Build a quick pivot by app, version, or transaction type to sanity check the totals.

This takes minutes and is ideal when one person needs one answer.

Warehouse or BI pipeline

Land the raw files in storage first. Parse and validate the schema, then transform: normalize dates to a single format and time zone, map device values to readable names, and standardize currency fields. Load the cleaned rows to your warehouse, and point the BI tool at the warehouse table rather than at files. Keeping raw files plus a transformed table gives you both reproducibility and speed.

Raw exports move through validation into BI

Small-team automation

A modest setup works well without heavy infrastructure: a scheduled job exports reports to cloud storage, and a nightly script parses the newest file and updates a shared spreadsheet or dashboard. It is easy to understand, easy to hand over, and easy to extend later into a full warehouse load.

QA checklist before you trust the numbers

  • Row counts: compare the parsed row count against the raw file's line count.
  • Vendor totals: confirm the total units or amounts match the figures shown in the App Store Connect interface for the same vendor and period.
  • Dimension sanity: scan key dimensions such as device and transaction type for unexpected blanks or values you do not recognize.
  • Date coverage: verify that every day in the period appears and no day is duplicated.
  • Spot check: pick one app and one day and trace the number from the dashboard back to the raw row.

What do you do when numbers do not match or a file will not open?

Most export problems fall into a few patterns, and a short routine resolves nearly all of them:

  1. Confirm the vendor ID and reporting period. A file from the wrong vendor, or from an adjacent period, explains most "wrong totals" reports. Check the metadata you stored with the file.
  2. Verify the archive unzipped cleanly. If decompression errors out or yields an empty file, re-download. Interrupted transfers produce corrupt archives.
  3. Compare against the interface. Match your summary totals to what App Store Connect shows for the same vendor and date range. If they differ, look at time zone and date alignment between the report period and how your tool groups days.
  4. Check for schema changes or malformed rows. If the file unzips but parsing fails, inspect the header against your expected columns and look for rows with the wrong number of fields. When in doubt, re-download and compare.
  5. Read your logs. For API-based jobs, look at response codes, the timestamps showing when a report became available, and whether every expected segment is present. A missing segment is a common cause of totals that come in low.

If a problem persists after these checks, keep the raw file and the request IDs, because they make the issue reproducible for anyone helping you investigate.

Why we keep exports small, encrypted, and reproducible

Our view, after thinking about this workflow as a privacy-focused team, is that the most useful export is the narrowest one that still answers the question. Teams tend to pull every available field "just in case," and then discover they are storing, backing up, and securing data nobody ever looks at. Every extra column is extra exposure, and exposure costs more than the convenience of having it.

Why we keep exports small, encrypted, and reproducible — overview diagram

Preserve the raw files, and encrypt them. That pairing gives you reproducible analysis, because you can always rebuild a result from the original, and it protects the people behind the numbers. Raw plus encrypted beats cleaned plus unprotected nearly every time.

There is also a complementary idea worth considering for sensitive analytics: processing on the device instead of shipping data elsewhere. Exporting aggregate business reports is a different job from handling personal content, and it should carry only what the analysis needs. If you are auditing what your own apps collect before deciding what to export, our on-device checklist for app data collection and our walkthrough of the App Privacy Report on iPhone are good places to start.

— Alex

Keep your own notes private with Echo Chamber Pro

Exporting reports is the easy half of privacy-conscious work; the harder half is where your own recordings and thoughts go. Echo Chamber Pro, our private transcription app for Apple devices, does its core processing on the device itself, so what you say never has to travel to a remote server. Plans run $2.99 per month, $29.99 per year, or $79.99 one-off, all listed on the Echo Chamber Pro page. If you want to understand why local storage and on-device processing are not the same promise, read why stored locally is not the same as processed on-device, then try Echo Chamber Pro on your next recording.

FAQ

How do I transfer all apps and data to a new iPhone?

Use Apple's device-to-device transfer or an encrypted backup during setup of the new phone, which restores apps and their on-device data together. Business exports from App Store Connect are separate: they describe sales and analytics, not what sits on a user's device.

How can I see every app I have ever downloaded?

Your App Store account keeps a purchase history of the apps tied to your Apple Account, including ones you have since deleted. This is a consumer-side view of your own downloads, distinct from the developer-side reports discussed above.

How do I get App Store reports into a spreadsheet?

Download the report from App Store Connect, unzip the .gz archive, and import the resulting tab-delimited .txt file, choosing tab as the delimiter. Apple's help page on downloading reports describes this format, and the file is not a comma-separated CSV.

Should I use the API or manual downloads?

Use manual downloads for occasional, one-off checks and the API for anything that repeats on a schedule. The API follows a request, report, and segment lifecycle, as Apple's API overview explains, and it suits recurring ingestion into a warehouse or dashboard.

Sources