Why RAM Decides Which AI Models Your iPhone Can Run

Working memory is a key constraint for local image generation. Enough free storage lets you download a model; enough available RAM lets its pipeline run. Device compatibility also depends on the operating system, the engine, and the task. A RAM number alone is not a promise that a model will work.

Two gigabytes sounds like a small difference. It stops sounding small once you know three things about how iPhones handle memory. Every part of the chip draws from one shared pool. iOS keeps no swap file, so there is nothing to fall back on when that pool runs short. And iOS sets a hard limit for each app. An app that crosses it is shut down on the spot. This article walks through each one, then shows where the gigabytes go while an image-making model (a diffusion model) is running.

Storage is a library; RAM is a desk

A model sitting in storage costs you nothing but disk space. To generate an image, though, the numbers it learned during training (its weights) have to be loaded into RAM. That is where the processor can read them, billions of times per image. RAM is where the model lives while working, and it is usually much smaller than storage. A phone with 256 GB of storage and 6 GB of RAM can archive an enormous model it can never run.

On Apple silicon, that RAM is one physical pool shared by the CPU, the GPU, and everything else on the chip. Apple calls this unified memory. It is an advantage. The GPU can use most of the phone’s memory instead of a small graphics-only slice. Data also never has to be copied between CPU and GPU memory, because there is only one memory. The model also competes for that same pool with iOS itself, the display pipeline, and every app sitting in the background.

No swap, hard caps, and sudden death

Desktops and laptops hide memory pressure with a trick. When RAM fills up, the operating system parks inactive data on disk, and the machine slows down instead of failing. (The technical name is swap.) iOS does not do this for app memory. Flash storage wear and battery life are part of the reason. On an iPhone, RAM is a hard wall.

iOS also refuses to let any single app take the whole pool. Each app gets a memory ceiling well below the device’s total RAM. The system reserves a large share for itself and for keeping the rest of the phone responsive. An app that crosses its ceiling is terminated on the spot, mid-task, rather than throttled or paused. For an image-generating app, three things have to fit under a cap of a few gigabytes: the weights, the temporary working data, and the decoded image. They have to fit at every instant, including the worst moment.

A model that fits on one device can exceed the available budget on another. Resolution, model loading, and the implementation change the peak. That is why published minimum tiers need to be paired with tests of the actual generation and editing routes.

Where the gigabytes go

A running image model spends memory in two ways, and the two behave very differently.

Weights dominate. The learned numbers are the bulk of the footprint. That is why a prepared Stable Diffusion Turbo package is about 2 GB and an SDXL Turbo package about 3 GB. Those sizes hold even after a shrinking step has already cut them to a quarter of their original size. (That step is called quantization.) Weights are a fixed cost. They occupy the same memory whether you generate one image or one hundred. A shorter prompt or a smaller output does not shrink them.

Working data spikes. On top of the weights, the computation itself produces temporary results. These are called activations. While the model is cleaning up noise step by step (denoising), they stay modest. It works on a small compressed grid (a latent) rather than on full-resolution pixels. The dangerous moment is the last one, when that latent grid is expanded into a full image. The technical name for that final step is the VAE decode. Its layers rebuild every pixel (they are convolutional layers), so they briefly hold large full-resolution data. That causes a sharp memory spike right at the end of the run, when the app is already carrying its full weight load and has the least headroom.

Engineering inside the wall

An app must work within the memory budget the system grants it, so careful pipelines lower their peak. Two techniques do most of the work.

• Staged loading. An image pipeline is several networks that run in sequence. One reads your words (the text encoder), one does the main work (the backbone), and one turns the result into a picture (the decoder). An app can load each piece only when it is needed, then free it again. Peak memory then lands near the largest single piece plus its working data, rather than the sum of everything.
• Tiled VAE decoding. Rather than decoding the whole image at once, the app decodes overlapping tiles and blends them together. The decode spike now scales with the tile size instead of the image size. That flattens the worst moment in the whole run, and it costs only a little extra compute.

These two techniques explain why two apps running the same model can behave differently on the same phone: the model sets the floor and the engineering sets the peak. For the full pipeline view, see what it really takes to run Stable Diffusion on an iPhone.

What this is not about

Check operating-system support and the app’s per-model eligibility first. RAM is a major constraint, but chip and engine compatibility matter too. Some Onhand packages use the GPU through MLX; others use Core ML with CPU and Neural Engine execution. Storage capacity is a separate question.

How Onhand budgets for your phone

Onhand requires iOS or iPadOS 26. Its model catalog and device checks determine which packages are offered. The current catalog uses a 6 GB minimum tier for its listed models, including the approximately 3 GB Detailed Images package. A larger download does not automatically mean an 8 GB minimum, and a catalog gate is not a benchmark of every device.

The library includes MLX and Core ML routes with different memory behavior. Start with the recommended Turbo model and test the task you intend to use. Staged loading, tiled decoding where supported, and memory checks reduce pressure, but available memory and the task still affect success.

iPads follow the same rule; the AI image generator for iPad page covers what to check before installing. For an app that asks for at least 8 GB of memory for every model, see Onhand vs Private Diffusion.

Sources

Primary sources for the claims above, so you can check them rather than take our word for it.

• Apple, Improving your app’s performance. Apple’s guidance on memory footprint and termination.
• Apple, MLX documentation. Background on the unified-memory model this post describes.