You install a flashlight app. Your phone, without ceremony or notification, builds a wall around it.
Not a firewall in the network sense. Something tighter and stranger: the app gets its own private room inside the operating system, handed keys to exactly what it needs and nothing else. That room is a sandbox. The reason your phone doesn't become a brick of malware within six months of downloading random apps is almost entirely down to how well that room holds.
What the room actually looks like
Every app on iOS or Android runs inside an isolated process. The OS assigns it a unique user ID, the same primitive Unix mechanism that stops one user account from reading another's files on a shared computer. From the kernel's point of view, your banking app and that flashlight app are strangers who happen to live in the same building. They can't knock on each other's doors.
Each sandbox gets its own slice of storage, its own memory space, and a tightly curated list of system calls it's permitted to make. On iOS, Apple enforces this through a kernel extension called Sandbox (nicknamed "Seatbelt" in early macOS versions internally), which checks every system call against a policy profile before letting it through. Android uses a Linux feature called seccomp-bpf, a programmable filter that intercepts system calls and kills any that aren't on the allow-list. The app doesn't negotiate. It asks. The kernel answers yes or no.
Here's a concrete way to feel this: imagine an app wants to read your contacts. It can't just reach into the contacts database directly. It has to ask the OS, which surfaces a permission dialog. If you say no, the kernel never gives the app a file path it could use. The data isn't hidden from the app so much as structurally unreachable, the way a room with no door isn't locked so much as it's solid wall.
Why it doesn't drag the whole device down
This is the part that surprises most people. You might expect all that checking and filtering to eat serious CPU cycles.
It doesn't, for two reasons.
First, the policy checks happen at the kernel level, which is fast. A seccomp-bpf filter on a modern ARM chip adds something in the range of a few hundred nanoseconds per system call. Apps don't make millions of system calls per second during normal use. The overhead is genuinely negligible, drowned out by the cost of the actual work being done.
Second, and this is the part that gets undersold: the sandbox is set up once, at launch, not re-evaluated continuously. Think of it less like a security guard checking every bag at the door and more like a building constructed with no windows on certain sides. The constraint is baked into the architecture. No ongoing patrol, no runtime toll.
Take two people who bought the same mid-range Android phone on the same day. One installs thirty apps from sketchy third-party sources. So does the other. Neither notices a performance difference attributable to sandboxing, because the sandbox isn't a runtime tax. It's a structural fact about how the process was created.
What sandboxing quietly can't do
This is where a lesser explainer would stop and leave you falsely reassured. It shouldn't.
Sandboxing contains code. It doesn't evaluate intent. If you grant an app permission to your microphone because it's a voice recorder, the sandbox dutifully allows microphone access. Whether the app uses that access to record your grocery list or your private conversations is a question the sandbox has no opinion on whatsoever. You handed it the key. The room is now open.
Sandbox escapes also exist. Rare and expensive, but a kernel vulnerability can let malicious code crawl out of its process and touch memory it has no business touching. This is why OS updates that patch kernel exploits matter so much, far more than most people treat them. The room is only as solid as the building it's built in.
And sandboxing does nothing about what an app sends over the network once it has legitimately collected data. The wall faces inward, toward the OS. Outward, toward the internet, you need other tools entirely.
So here's a question that should make you a little uncomfortable: when did you last actually check your app permissions? Settings, apps, permissions, sorted by category. A game with location access. A keyboard that requested your contacts. That's the sandbox working exactly as designed, and also exactly as exploitable as you've made it.
The sandbox is one of the smartest structural ideas in modern computing. It is also, ultimately, a locked room whose keys you keep giving away.