2008: the App Store opens, and every app you install is handed a sealed container it cannot reach out of. Eighteen years later, I still spend real time choosing the right sanctioned way to move one line of text between two iOS apps. This is that history, told oldest method first, by someone who has shipped most of it.
I build a small iOS app on my own, and its entire job is to get a thought you just typed out of itself and somewhere useful before you lose it. That makes "getting data out of the sandbox" less an abstraction for me than the whole product. So I have opinions about every door Apple has cut into that wall, and I know roughly when each one appeared.
TL;DR
- iOS has never let two apps share a filesystem. Every method below is a specific, Apple-sanctioned door punched through the sandbox wall, added one at a time.
- The doors moved in one clear direction over eighteen years: from invisible and automatic toward explicit and user-consented.
- Real file-level sharing did not exist until 2014. Everything before iOS 8 moved strings, not files.
- In 2026 I ship exactly two of these mechanisms, and they solve opposite problems.
Why was moving data ever hard?
On a desktop, "share data between two programs" is barely a sentence. Any process can read a file in your Documents folder, so the shared filesystem is the integration. iOS threw that assumption out on day one. Each app lives in its own container directory, walled off from every other app's storage, with no ambient shared folder and nothing resembling a common drive. The default is isolation, and it is a security feature, not an oversight.
So on iOS, "share data" has never been one thing. It has always been a narrower question: which specific, blessed bridge do I use to move this particular payload from my container into somewhere another app or the user can reach? The rest of this piece is those bridges, in the order Apple shipped them, and what each one was actually good for.
2009: strings escape first
Three ways out landed close together in iOS 3.0, and all three moved text, not files.
The first was the clipboard. UIPasteboard gave every app read and write access to a shared pasteboard, so a user could copy in app A and paste in app B. It was the crudest possible transfer and also the most universal, and for years it was completely silent: an app could read whatever you last copied without you knowing. Hold that thought, because it comes back to bite the whole model in 2020.
The second was custom URL schemes. An app registered something like myapp://, and any other app could hand it a small payload by opening that URL. It worked, and it was fragile in every direction. Any app could claim any scheme, so there was no ownership and no trust, and you could only pass what fit in a URL. It was duct tape, but it was the first way one app could deliberately poke another.
The third was email, through MFMailComposeViewController in the MessageUI framework. On the surface it is just a mail compose sheet you present inside your app. Underneath it is the strangest and most durable bridge on this list, because it is the only one that does not require the destination app to exist on the device at all. The data leaves the device entirely, lands on a server, and sits in a format that will still open in forty years. I will come back to why that turns out to matter more than it looks.
2010 to 2012: files start to move
iOS 3.2 (2010) gave us UIDocumentInteractionController, better known as the "Open in..." menu. For the first time you could hand a whole file to another app, matched by its type, and let the user pick a target that had registered for it. It was one-way, always user-initiated, and it copied the file into the other app's container rather than sharing it. But it was the first time the unit of transfer was a document instead of a string.
iOS 5.0 (2011) added something quieter that mattered enormously later: NSFileCoordinator and NSFilePresenter, which arrived alongside iCloud document storage. Their whole reason to exist is the idea that two processes might touch the same file, and that they need to take turns so nobody reads a half-written mess. Nobody demoed this at a keynote. It became load-bearing three years later.
iOS 6.0 (2012) standardized the mess of "Open in..." into UIActivityViewController, the share sheet. Instead of every app inventing its own export menu, there was now one system menu, and apps registered activities into it. It was still one payload at a time and still something the user had to start, but it turned a scattered set of one-off handoffs into a single, discoverable gesture that every iOS user now knows by heart.
2014: the year the sandbox grew real doors
If this history has a hinge, it is iOS 8. Three things shipped together that finally made file-level sharing real.
App Extensions let your code run inside another app's context: Share extensions, Action extensions, the Today widget, Document Provider extensions, and custom keyboards. Your app was no longer confined to its own window. App Groups gave your own apps and their extensions a genuinely shared container directory, the first sanctioned place two pieces of your own software could read and write the same files. Apple's own guidance came with a warning attached: when you write to that shared container, you must do it "in a coordinated manner to avoid data corruption." That is exactly why the sleepy 2011 file-coordination API suddenly showed up in everyone's code.
The third piece was iCloud Drive together with UIDocumentPickerViewController and security-scoped bookmarks. For the first time, an app could, with the user's explicit grant, reach into a folder living in another app's iCloud space and write there, then persist that permission across launches with a bookmark. This is the birth of the modern "append a line into another app's folder" path. I took that exact write path apart layer by layer in a separate teardown; here the point is smaller. Before 2014 it was not possible, and after 2014 it was the sanctioned way.
2015 to 2017: links grow up, files become visible
iOS 9 (2015) fixed the original sin of custom URL schemes with Universal Links: verified https links that open your app if it is installed and fall back to your website if it is not. Because the link is a real web address you have proven you own, another app can no longer quietly claim it. The 2009 duct tape finally grew an identity.
iOS 11 (2017) made the filesystem itself visible. The Files app and UIDocumentBrowserViewController gave users a place to see and navigate documents across apps and cloud providers, and the document picker got simpler to adopt. The sandbox was still standing, but now there was a shared, user-facing surface, folders, that several apps could point at and a person could actually reason about.
2020 to 2022: the tide turns toward consent
Then the direction reversed. iOS 14 (2020) made reading the pasteboard raise a banner, so the oldest and most invisible bridge on this list became the most conspicuous one. Apps that had been quietly sniffing the clipboard for years got caught on camera overnight.
iOS 16 (2022) went further with an explicit "allow paste" prompt and UIPasteControl, so an app reading the pasteboard without clear user intent now needs permission, and 16.1 added a per-app paste setting. For a decade Apple had spent its energy adding ways to move data. Now it was spending energy adding friction to the ones that moved data without you noticing. The wall was not getting shorter. The gates were getting louder.
Here is the whole eighteen years on one screen:
| Year (iOS) | Mechanism | What it moves | Who starts it | First-class in 2026? |
|---|---|---|---|---|
| 2009 (3.0) | UIPasteboard | A string or blob | User copies | Yes, but policed |
| 2009 (3.0) | Custom URL schemes | A small URL payload | Either app | Superseded by Universal Links |
| 2009 (3.0) | MFMailComposeViewController | A whole message, off device | User confirms send | Yes |
| 2010 (3.2) | UIDocumentInteractionController | One file, by type | User picks "Open in" | Mostly folded into the share sheet |
| 2011 (5.0) | NSFileCoordinator | Safe access to a shared file | Your code | Yes, under the hood |
| 2012 (6.0) | UIActivityViewController | One payload, anywhere | User opens share sheet | Yes |
| 2014 (8.0) | App Groups container | Files, between your own apps | Your code | Yes |
| 2014 (8.0) | iCloud Drive + document picker | Into a user-chosen folder | User grants, code writes | Yes |
| 2015 (9.0) | Universal Links | An https route into your app | Either app | Yes |
| 2017 (11.0) | Files app + document browser | Files, user-visible | User | Yes |
| 2020–22 (14–16) | Pasteboard consent, UIPasteControl | Gatekeeping, not transport | User consents | Yes |
So which of these do I still reach for?
Two of them, and they solve opposite problems.
The first is email, through MFMailComposeViewController, the bridge from 2009. I keep coming back to it because it is the only mechanism on the whole list that does not care whether the other app exists. The line leaves the device, lands in an inbox the user already checks every day, and sits there in a format nothing can deprecate. I wrap the send in a small offline queue so a failed attempt retries instead of evaporating, which is a whole design problem of its own that I wrote up as an offline-first outbox.
The second is the iCloud Drive document-picker path from 2014, for the case where the destination is a folder the user already owns on their own device. My app uses it to append a dated line to a Markdown vault, which is the one place Obsidian users tend to notice it, and the coordinated write is the only thing standing between "your note got appended" and "your file got corrupted."
Notice what the two survivors have in common. In both, the destination is the user's own storage or account, an inbox and a folder they control, not another app's private container. The bridges that tried to reach directly into someone else's sandbox are the ones I have quietly stopped using.
A few questions I get
Isn't email a strange way to move data between apps in 2026? It looks quaint right up until you notice it is the only mechanism here that works when the target app is not installed, works offline if you queue it, and leaves behind an artifact that will still open decades from now. Quaint and durable are not opposites.
Why not just use the clipboard for everything? Because after iOS 14 the clipboard is the most watched channel on the system. It is genuinely good for a user-initiated copy and genuinely wrong for anything your app does on its own. Treat the privacy banner as a design constraint you were handed, not a bug to route around.
Where do App Intents and Shortcuts fit? They are the newest door, and I left them off the timeline on purpose, because they move actions rather than just data and they deserve their own history. But they are plainly where the direction of travel points: user-authored automation over routes hard-wired by an app developer.
Where does this history go next?
The eighteen-year arc has one shape. Every generation of cross-app data movement added either user visibility or user consent to the generation before it. The invisible clipboard gave way to a discoverable share sheet, which gave way to an explicit document picker, which gave way to an outright paste prompt. Nothing on this list got easier to do silently. Almost everything got easier to do honestly.
If that trend holds, the next chapter is not another file API. It is intent, App Intents and Shortcuts and on-device models, working out where a piece of data should go and asking you to confirm, instead of an app quietly hard-wiring the route years in advance.
Which leaves me with a real question rather than a rhetorical one. What is the oldest cross-app mechanism you still ship in production, a custom URL scheme, an "Open in" handler, a raw pasteboard read, and what finally made you replace it, or decide that you never would? I am trying to sort out which of my own two survivors are principled choices and which are just habit wearing a nice coat, and your holdouts would help me tell the difference.
I'm the solo developer behind Simple Memo, an iOS app that turns a line you type into an email about a second later, and on the days I curate, appends that same line to a Markdown vault on iCloud. I write here about the unglamorous parts of building it alone. The vault side of that is documented at simplememofast.com/obsidian/.
Top comments (0)