Add video upload to an app and the transfer, not the camera, is the feature.

How big a minute of phone video actually is

Video is not a large photo, it is a stream of them, and the arithmetic is unforgiving. YouTube publishes the bitrates it wants uploads to arrive at: 8 Mbps for 1080p at a standard frame rate, and 35 to 45 Mbps for 2160p, which is 4K. Turn a bitrate into a file and a minute of 1080p is about 60 MB, while a minute of 4K is roughly 260 to 340 MB. A three minute 4K clip is close to a gigabyte.

Be honest about what that figure is. Those are recommended encoding targets for uploads, not a measurement of your phone, and neither Apple nor Google publishes a per minute size for default camera capture that we could find. The number is the right order of magnitude and nothing more. The check that settles it takes two minutes: record thirty seconds on the handset you care about and look at the file size.

The consequence is a product decision rather than an engineering one. A one minute cap keeps most uploads under 100 MB. A five minute cap at 4K means routinely moving a gigabyte from a phone, over a network you do not control, while the user waits. Capping length and defaulting to 1080p removes most of the problem before anybody writes an upload function.

It also changes what you can promise. Instant is achievable for a fifteen second clip on wifi. For anything longer the honest interface is a queue that says pending and finishes in the background, which is a different screen and a different data model.

YouTube, recommended upload encoding settings

The file should never pass through your own server

The first build almost everyone writes posts the video to their own API, which buffers it and forwards it to storage. It works on a laptop with a 6 MB test clip. In the field your server pays for the same bytes twice, a request timeout kills a twenty minute transfer at minute nineteen, and two simultaneous uploads are enough to notice.

The pattern that holds up is a signed URL. The app asks your backend for a short lived permission to write one object, then uploads to storage directly, and your API never touches the bytes. Big files go up in parts. Amazon's own guidance is to use multipart upload for objects of 100 MB or larger instead of a single operation, with part numbers anywhere from 1 to 10,000, and a failed part can be resent without affecting the others. That last property is the entire reason to bother.

Then plan for the upload that does not finish, because it is the common case and not the edge case. Write the file to local storage, record a row that says pending, retry when the network returns, and show a list the user can trust instead of a spinner that lies. This is the same discipline as any other offline app functionality, and video is where its absence shows up first.

Two details catch people out. Background transfers are a platform feature with platform rules, so read them before promising that uploads continue after the app closes. And a signed URL is a key: keep the expiry short, tie it to one object, and generate it on the server, never in the app.

Amazon S3 documentation, uploading and copying objects using multipart upload

What has to happen before anyone presses play

An uploaded file is not yet a playable video. It may be HEVC in a MOV container, shot in portrait with a rotation flag, at a bitrate nobody on mobile data can stream. Serve that original directly and every viewer pulls the whole file before the first frame, on your bandwidth bill.

So most apps transcode. That means one or more smaller renditions, a streaming playlist so the player can drop quality when the network does, and a thumbnail lifted from an early frame so your list is not a wall of grey rectangles. You can run this on your own worker with ffmpeg, or buy it from a managed video service that handles ingest, transcode, storage and delivery together. Either way it is a second system with its own queue, its own failure modes and its own bill.

Be clear about which product you are building. A clip recorded, uploaded and watched later is one thing. Watching while it is being recorded is a live streaming app, a different protocol stack and a different cost model. If the brief asks for both, ship the upload first and find out whether anyone really wanted live.

Moderation belongs in this section too, because it is the piece that gets skipped. The moment strangers can share video in app, somebody uploads something you have to remove. A delete button, a report action and a record of who uploaded what is the minimum, and it is far cheaper to build now than after the first complaint.

Build it, buy it or skip it

Skip it first, seriously. Let people paste a link to a video that already lives somewhere else and render it. No storage, no transcode, no moderation queue, no delivery cost. For a surprising number of apps that is the right answer for the first year, and it takes an afternoon.

Buy it next. A managed video service gives you an upload URL, the transcode, a player and the delivery, usually priced by minutes stored and minutes delivered. Read the current pricing page yourself before committing, because the delivered half of that bill scales with how popular a video becomes, not with how much work you did.

Build it when the video is the point of the app, when the clips must stay inside your own storage for legal or contractual reasons, or when volume makes per minute pricing worse than running a worker. Newly writes a real React Native and Expo project that you own, so the recorder, the pending queue and the retry logic are code you can read and change. It does not host or transcode video and it does not bundle a backend, so storage and playback are services you choose and pay for separately. Nobody should discover that after the demo.