Add image cropping to an app in an afternoon, or in a week.

What the system picker gives you, and what it refuses

If your app already opens the photo library or the camera, cropping is one option away. The Expo image picker exposes an editing flag that shows a UI for editing the image after it is picked. On Android the user can crop and rotate. On iOS they can crop only. Rotation being an Android-only affordance catches out anyone who tested on one platform and wrote the release notes from that.

The ratio limit is the one to design around. The picker accepts an aspect pair, but the documentation is explicit that this applies on Android only, because on iOS the crop rectangle is always a square. No option unlocks a 4:5 or 16:9 box in the iOS system editor. If your layout needs one, the system editor is out and no amount of configuration will bring it back.

Two more limits before you promise anything. Editing is mutually exclusive with multiple selection, so you cannot let somebody pick six photos and crop them in one pass. And the quality setting is not a guarantee: the docs warn that if the chosen image was already compressed, the output file can come out larger than the original. On iOS the quality value is ignored outright for a .bmp or .png picked from the library.

The docs also flag an iOS bug with high resolution images from the camera roll, where the crop rectangle values come back wrong because of the underlying system picker rather than anything in your code. Test with a full resolution photo from a real camera roll, not a screenshot, before you decide the flow works.

Expo, ImagePicker API reference

What cropping before upload is actually worth

Cropping on the device before upload changes three things: how long the upload takes on a phone network, how much you store, and how much you serve. The bandwidth argument is the strong one. The storage argument is weaker than it sounds, and it is worth doing the arithmetic rather than repeating the claim.

Take a published price. Cloudflare R2 standard storage is $0.015 per GB-month, the first 10 GB-month each month is free, and egress to the internet is not charged. Say your app takes 5,000 uploads a month. Measure your own files rather than guessing, but assume for now an original at 3 MB and a cropped, resized version at 300 KB.

Uncropped, that adds 15 GB every month. The free allowance is gone in month one, and by month twelve the bucket holds 180 GB and bills about $2.55 for that month alone. Summed across the first year it comes to roughly $15.75. Cropped, it adds 1.5 GB a month, stays inside the free allowance until month seven, and the whole first year costs about $0.38. The saving is real and it is about fifteen dollars. Write operations are noise at this size: 5,000 uploads sit well inside the million free write requests a month. Note that this provider does not bill egress, so on one that does, the serving side scales with file size too and you should check its own page.

Fifteen dollars a year is not why you crop. Upload time is. A 3 MB file on a weak mobile connection is the difference between a form that submits and a user who closes the app. Decide the crop on the experience, then check the storage line instead of assuming it. Whether you also keep the untouched original next to the crop is a schema decision, and it belongs with what gets stored.

Cloudflare R2 pricing

When you have to build the crop box yourself

The moment you need a ratio other than square on iOS, or a rotate handle, or a crop preview that matches the frame the photo will sit in, you are building a crop surface. It is a smaller job than it looks and a longer one than it sounds.

The parts are a preview that scales the image to fit, a rectangle the user drags that stays inside the image bounds, a pinch and pan pair, an optional ratio lock, and then the transform itself. The transform is a library call in most stacks: you give a top left corner plus a width and height, then resize and re-encode at a compression value you pick. The gesture layer is where the days go, because people judge a crop box by how it feels under a thumb.

The trap is memory. A photo is compressed on disk and uncompressed once decoded, at roughly four bytes per pixel, so a 4000 by 3000 image is about 48 MB in RAM before you have drawn anything. Hold two or three of those while a user drags a box and a mid-range Android phone will kill the screen. Preview from a downscaled copy, apply the final transform to the original once, and release what you are done with. That is standard app performance discipline rather than anything specific to cropping.

An avatar, a banner and a receipt want different crops

Cropping is not one feature. What the user is cropping decides the interface, and shipping a single crop screen for every case is why crop features so often feel wrong.

An avatar wants a fixed square or circle, a tight zoom, and no way to get it wrong. The system editor fits that exactly, and this is usually the crop people mean when they add user profiles. A banner or a listing photo wants a ratio locked to the slot it will render in, so the crop is really a framing tool and the preview should show the real frame, not a bare rectangle. A scanned document wants four draggable corners and a perspective correction, which is a different feature wearing the same word.

Pick which of the three you are building before you pick an approach. The square system editor answers the first case completely, the second case not at all, and the third case is not cropping in the first place.