You add CSV export to an app in three steps: build the text, write a file, share it.

The three steps, and where the file actually goes

Step one is the text. Put the column names in the first row, run every value through one escaping function, join each row with commas and the rows with line breaks. Step two is the file. Write that string into the app's own storage under a name carrying the date, like invoices-2026-10-01.csv, because the filename is the only label the person ever sees. Step three is the hand-off, and on a phone that means the share sheet.

That third step is where mobile differs from the web. A browser downloads a file and the system files it away. A phone app writes inside a sandbox, then asks the system to pass the file to another app: Files, Mail, Drive, a messaging app. Sharing a local file by its URI works on iOS and Android, but not on the web, where the file has to be hosted first. None of that is specific to exports, so build the add share sheet plumbing once and point the export at it.

Pick the directory deliberately. A cache directory suits a file about to be sent onward, because the system may reclaim it later. A documents directory keeps the file until you delete it, and quietly fills a phone with copies of the same table. Either way you may learn which app was chosen, and never whether the file was kept, mailed on or deleted that evening.

Writing values so a spreadsheet opens them correctly

The format has a published specification and it is short. RFC 4180 states that each record sits on a separate line delimited by a line break, that an optional header line may appear first with the same format as normal record lines, that fields containing line breaks, double quotes and commas should be enclosed in double quotes, and that a double quote appearing inside a quoted field must be escaped by preceding it with another double quote. It also registers text/csv as the media type.

In code that is one small function, and every value should go through it. Deciding case by case which values look risky is how a customer named Smith, Jones and Partners shifts every column after it by one, and nobody notices for a month.

What the spreadsheet does next is a separate problem your file cannot control, because a CSV carries no types. Leading zeros on phone numbers and postal codes vanish when a column is read as a number. Long identifiers become scientific notation. Dates are read by the reader's locale, so one file can mean two different days in two offices. Write dates year first in the ISO 8601 style, and write UTF-8. A byte order mark makes accented names survive a double click in Excel on Windows, and shows up as stray characters in some other parsers, so decide it by where the file is going. One last trap: where the comma is the decimal separator, spreadsheets commonly expect a semicolon between fields.

RFC 4180, common format and MIME type for CSV files

name,note,amount
"Fry, Jane ""JJ""","Left at side door
Ring twice","'=1+1"

How big an export can get before it needs a server

When you export data from an app on the phone, the whole file exists as a string in memory, then again as bytes on disk. For the list on the current screen that is nothing. For every record the account has ever held, it is a crash on an old handset that you never see, because your test device is new. No platform publishes a row limit worth quoting, so measure the string your own data produces before you offer an export everything button.

The app also has to hold the data before it can export it. Anything that pages through results holds a screen or two at a time, so exporting the lot means downloading the lot first or asking the server to assemble the file. Which of those is cheap depends on how the rows are stored and indexed, which makes it a mobile app database design question. A server that streams a query into a file has no size ceiling.

For a first version, let people export what they are already looking at, with the filters they already applied, instead of one button meaning everything. Less code, a smaller and more useful file, and how much is too much becomes a choice the person already made.

An export is a data protection event

The moment somebody exports, a controlled dataset becomes an ordinary file on a device you do not manage. Nothing about the button says so, which is why the record matters. Log who exported, when, which dataset, the filter that was applied, which columns were included, how many rows came out, and the role that person held at that moment. Log the app version too, because columns change.

Two rules about the log itself. Keep it on the server, not the device, so the exporter cannot edit it. And record the query and the counts rather than the rows, because a log holding the exported data is a second copy of the same problem. Under the EU breach notification rules a controller is asked to describe the categories and approximate number of records concerned, without undue delay and where feasible within 72 hours. Whether those rules cover you is a question for your own legal advice. Either way the log is what lets you answer with a number instead of a guess.

There is a second problem inside the file. OWASP calls it CSV injection, or formula injection, and describes it as what happens when untrusted input is embedded in a CSV file. It lists equals, plus, minus, at sign, tab, carriage return and line feed as leading characters that can make a value run as a formula. Its mitigations are to wrap each cell field in double quotes or prepend each one with a single quote, and it is candid that both can fail in Excel after a save and reopen. The cheapest defence is to refuse those leading characters at the point of entry.

Last, the export button is a permission and not a screen. Anyone who can see one record can now carry ten thousand out in a single file, which changes what read access means. Settle who may export before you build the button, and enforce it where the rows are assembled.

OWASP, CSV injection