Build it: photo backup and file sync on Android and iOS

This page holds the build details behind the photo backup and file sync interview case. It covers:

• The schema and a REST sketch (the HTTP calls between app and server).
• The block upload code and change detection.
• Who runs the transfer, plus conflicts and failure handling.
• The iOS version.

None of it belongs in the 45 minutes. I draw it only if asked.

The snippets use Room 2.x (androidx.room, Android's local database library). The official Room guide now shows Room 3 (androidx.room3, KSP only, SQLiteDriver required). The design is the same either way.

1. Local schema (Room)

@Entity(tableName = "items", indices = [Index(value = ["localUri"], unique = true)])
data class ItemEntity(
    @PrimaryKey val itemId: String,       // client-generated UUID
    val localUri: String,                 // MediaStore content URI or file path
    val size: Long,
    val contentHash: String?,             // whole-file hash, filled after hashing
    val remoteFileId: String? = null,     // null until the server has created the file
    val baseVersion: Long? = null,        // version this edit is based on, for conflict checks
    val state: State,
) { enum class State { DETECTED, HASHING, UPLOADING, DONE, FAILED } }

@Entity(tableName = "blocks", primaryKeys = ["itemId", "index"])
data class BlockEntity(
    val itemId: String, val index: Int,
    val hash: String,                     // SHA-256 of the block bytes
    val length: Int,
    val state: BlockState,                // PENDING, PRESENT_ON_SERVER, UPLOADED
)

@Entity(tableName = "upload_sessions")
data class UploadSessionEntity(
    @PrimaryKey val itemId: String,
    val sessionUri: String,               // server-issued resumable session
    val expiresAt: Long,
)

A block is a fixed-size piece of a file. The server's missing list (the blocks it does not have) is the truth about what is stored. A block is UPLOADED only after the server confirmed it. Treat anything the server did not confirm as unsent.

2. REST (sketch)

POST /v1/files/{id}/uploads         body: { size, blockHashes: [...] }
     → { sessionUri, missing: [3, 4, 9] }          (blocks the server does not have)
PUT  <sessionUri>?block=3   Content-Range: bytes 12582912-16777215/52428800
     X-Block-Hash: <sha256>   → 200 { stored: true } | 422 (hash mismatch, resend)
POST /v1/files/{id}/uploads  again with the same body        (after a failure: returns the current missing list)
POST /v1/files/{id}/commit          body: { baseVersion, blockHashes }
     → 200 { version } | 409 { currentVersion }     (conflict)
                                                   (a retry with the same block list returns the version it already created)
GET  /v1/changes?cursor=<opaque>                   (what changed in the cloud; the server returns the next cursor)

The session borrows from Google's resumable upload model (a session URI, chunks with Content-Range) and from the tus protocol (an open resumable-upload protocol). I changed one thing.

Drive's resumable upload and core tus both take one continuous stream of bytes. After a failure they ask the server for its offset (a byte count). tus has a separate concatenation extension for parallel parts. This model cannot skip blocks the server already has.

So in my sketch each block is its own PUT into the session. The server owns the missing list instead of an offset. That is my design, not Google's or tus's behavior. Whichever shape you pick, say why: the server, not the client, decides what is stored.

A commit response can be lost like any other response. So I would make the commit idempotent: doing it twice has the same result as doing it once. The key is the hash of the block list. A retry with the same list returns the existing version. It does not reach the 409 branch.

3. Resumable block upload

The core flow, per item:

1. Detect the new or changed item and insert it as DETECTED (see section 4).
2. Split the file into blocks. Read it as a stream and hash each block (a hash is a short fingerprint of the data). Do not read the whole file into memory.
3. Send the block hashes. The server replies with the blocks it is missing. It already has some blocks, from this user or from an earlier version of the file. You never upload those.
4. Upload only the missing blocks, in order, one PUT each. Check that the block still has the hash you sent in step 3. After the server confirms each block, mark its BlockEntity UPLOADED.
5. Send a commit with the full list of block hashes and the baseVersion. Only the commit makes the new version visible.
6. Mark the item DONE.

// Sketch: upload only the blocks the server said it is missing. Constant memory: one reused buffer.
// Runs in a data-layer component called by the worker (never by a Composable or ViewModel); dispatcher injection and entity mapping omitted for brevity
suspend fun uploadMissing(item: ItemEntity, session: UploadSessionEntity, missing: List<Int>) {
    contentResolver.openInputStream(item.localUri.toUri())!!.use { input ->
        val buf = ByteArray(BLOCK_SIZE)                    // for example 4 MiB
        var pos = 0L                                       // where the stream is now
        for (index in missing.sorted()) {
            val block = dao.block(item.itemId, index)      // hash and length saved while hashing
            val start = index.toLong() * BLOCK_SIZE
            input.skipNBytes(start - pos)                  // API 33+; throws EOFException if the file shrank
            val n = input.readNBytes(buf, 0, block.length) // API 33+; on older versions loop on read()
            pos = start + n
            check(n == block.length && sha256(buf, n) == block.hash) { "file changed since hashing" }
            val ack = api.putBlock(session.sessionUri, index, buf, n, start, item.size)  // Content-Range
            check(ack.stored) { "server did not keep block $index" }
            dao.setBlockState(item.itemId, index, BlockState.UPLOADED)
        }
    }
}

What I would point out:

• A changed file fails with an error. The new hash before each PUT catches a photo edited after step 2. The sketch throws an error, the worker sets the item back to HASHING, and nothing is committed. If the file shrank, skipNBytes throws EOFException. It does not stop quietly.
• Block size is a trade-off. Small blocks dedupe better (identical data is stored once) and lose less on failure. They add cost for each request. A few MiB is a normal start. The 4 MiB in the sketch is only an example.
• Google's block rules. Google's resumable upload docs require chunks (the same as our blocks) in multiples of 256 KB, except the last one. They advise using the largest practical size. My block-per-request shape keeps that multiple.
• Fixed-size blocks fail when bytes are inserted. Add bytes near the start of a file and every later block hash changes. Content-defined chunking (a rolling hash chooses where each block ends) keeps most blocks the same. Photos and videos are rarely edited in place, so fixed blocks are usually enough. For documents, mention content-defined chunking.
• Verify what you sent. Send a checksum for each block (tus defines an Upload-Checksum extension). A corrupt block that is shared is corrupt for every file that uses it.
• Sessions expire. Google's resumable session URIs last one week. On 404, start a new session. Stored blocks cost nothing, because the server already has them.
• Cross-user dedupe has a privacy cost. If accounts share blocks, a hash probe shows whether someone already stored a given file. Say so. Also say that end-to-end encryption mostly defeats cross-user dedupe.

Block hashing, dedupe, resumable sessions and conflicted copies are common ideas in file-sync design. They are not anyone's confirmed internals. The Drive and tus pages in the reading list back the upload protocol. The rest is my own design reasoning. For the source of the write and conflict choices, see the offline-first guide. The lost-acknowledgement walkthrough is in the staff mobile loop guide.

Memory: never load a file into a ByteArray or Data. Stream it with one reused buffer and hash block by block. Then peak memory stays near the block size. The app reads the file twice, once to hash and once to upload the missing blocks. I accept that cost.

4. Finding what changed

The detector decides which items need upload. Checking the whole library again and again is slow and drains the battery.

Android: use MediaStore (Android's shared media database) change signals.

• MediaStore.getVersion() (API 29) tells you if the store changed a lot since your last sync. Check it when the process starts. If it changed, scan everything again.
• MediaStore.getGeneration() (API 30) returns a number that only goes up. Save it and compare it later to find items added or changed since then. Google's docs say generation numbers are more reliable than DATE_ADDED and DATE_MODIFIED. Those dates can change when apps or users change timestamps and clocks.
• Register a ContentObserver for live changes while the process is running. Run a catch-up scan on each scheduled run.

Android access. The photo picker protects privacy when the user selects items by hand. Automatic backup needs broad media access (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO). Play allows it only when the picker cannot provide your core function and you declare it in Play Console. Check that your use case qualifies under the photo and video permissions policy.

Partial access. On Android 14 and later, users can also allow only selected photos (READ_MEDIA_VISUAL_USER_SELECTED). Check this with checkSelfPermission on each run. The partial access docs say not to store the state. Show "backing up N selected items" instead of "library backed up".

iOS: register a PHPhotoLibraryChangeObserver for live changes. It reports only while your app runs.

So also save a PHPersistentChangeToken (a saved position in the change history). Call fetchPersistentChanges(since:) (iOS 16 and later; it can throw an error) on launch and on background runs. If it fails with persistentChangeTokenExpired, do a full sync again. Respect limited-library access. If the user shares only some photos, you back up only those, and the UI should say so.

The cloud can also send a push, but only as a hint. A push message can tell a device to fetch /v1/changes sooner. The push can be late or lost. So the cursor (a saved position) stays the source of truth. The push SDK case study covers this.

What counts as an item. A photo can be several resources: the original, an edited version, and a paired video for a Live Photo. I would decide early which of these are backed up and say so. The choice decides what "restore" and "delete" mean. That is my design decision, not a platform rule.

Do not trust modification dates alone. Check the size and date first, because that is cheap. Then confirm with a hash of the content. A renamed file with the same hash is a metadata update, not an upload.

5. Who runs the transfer

Android specifics. I choose by who started the upload. A backup the user did not just ask for uses ordinary constrained WorkManager jobs. A transfer the user starts uses a user-initiated data transfer (UIDT) job on API 34 and up. Below that, it uses a foreground worker.

• WorkManager is the default. An upload must survive process death, so it is never a viewModelScope coroutine. Hilt can inject the worker's dependencies (@HiltWorker). Constraints combine with AND, so all of them must be true. If one stops being true during a run, WorkManager stops the worker. It retries when all constraints hold again. So the upload must be able to resume at any moment.
• Long runs. WorkManager treats work that can run longer than about 10 minutes as long-running. It expects setForeground() with a notification. This runs the worker as a foreground service (a service with a visible notification). Apps targeting API 34 or higher must declare a foreground service type.
• The six-hour cap. A dataSync foreground service has a limit of 6 hours per 24 hours for apps targeting Android 15 or later. The system calls onTimeout(), and the service must stop. So each run must save its block states as it goes (a checkpoint) and expect to be scheduled again. See the timeout docs.
• UIDT jobs. Google notes that on Android 16 long-running workers can use up the app's job quota. It suggests UIDT jobs for transfers the user starts. You must schedule them while the app is visible. They need RUN_USER_INITIATED_JOBS and a notification. Standby bucket quotas do not limit them.
• UIDT limits. The system can still stop them. So save progress and expect onStartJob() to run again. No Jetpack library wraps UIDT. Use it only on API 34 and up, and use a foreground worker below that.
• Quotas still apply to ordinary jobs. Android 16 also ties the runtime quota of regular and expedited jobs to the standby bucket. So plain workers can also be stopped for quota. Log WorkInfo.getStopReason(). Keep blocks small so a quota stop costs one block.

Backoff and retries. Backoff means waiting longer after each failure. Result.retry() uses exponential backoff (the wait doubles each time; 30 seconds by default, 10 seconds at minimum).

• Temporary errors: IOException, 408, 429 and 5xx. Follow Retry-After when the server sends it.
• Permanent errors: other 4xx responses. The item becomes FAILED.
• Protocol cases: 404 on a session means start a new one. 409 on commit is a conflict (section 6).

iOS specifics. There are two transfer routes and two kinds of background task.

Photos background upload (iOS 26.1 and later). For library photos, Apple has a path built for this. It is a Photos background-upload extension. In it, you create PHAssetResourceUploadJobs for PHAssetResources. The system runs the extension when it can.

• PHAssetResourceUploadJob.jobLimit limits how many jobs run at once. The docs page states no value, and I could not find the entitlement requirements. Check them before you choose this route.
• The extension protocol is marked deprecated in the current docs. Confirm the replacement name for your target SDK.

Background URLSession. Use it for your own files and older OS versions. It hands the transfer to the system. The system continues it while your app is suspended or not running. It starts the app again to deliver events.

• In general, background uploads must come from a file (check the current docs for your target iOS version).
• Create the session again with the same identifier on launch, so the delegate receives pending results.
• Store the completion handler from application(_:handleEventsForBackgroundURLSession:completionHandler:). Call it on the main thread from urlSessionDidFinishEvents(forBackgroundURLSession:).
• Apple documents that a user force-quit cancels background transfers. The app does not start again until the user opens it.

BGProcessingTask. It is for work like hashing and planning. Apple says it runs only when the device is idle and may be interrupted. If you require power or network, it runs less often.

BGContinuedProcessingTask (iOS 26). It starts in the foreground and can continue in the background. Its progress shows in a Live Activity that the person can cancel.

• It should start from a user action.
• The system can still end it when resources are low.
• Closing the app from the app switcher cancels it, so report progress and save state.

It suits work the user starts, like a visible upload. It does not suit automatic backup. Say clearly that iOS gives no guarantee of when a backup finishes.

6. Conflicts and versioning

Backup has almost no conflicts, because the device is the only writer. File sync is different.

• Never overwrite without a warning. Every file has a server version. An edit commits with baseVersion. If the server's current version is newer, the commit returns 409.
• On conflict, keep both. The usual client answer is a conflicted copy (for example, report (Alex's conflicted copy).docx), so no edit is lost. Offer a merge only for formats you can merge.
• Keep old versions. Blocks never change, so a version is just a block list. Restoring is a metadata write. Delete unused blocks after a retention period (garbage collection).
• A delete must leave a marker. The marker (a tombstone) carries a version. Then an old upload from another device cannot bring the file back, and baseVersion checks still work.

7. Progress UI and security

• Progress comes from the database. Count confirmed blocks over total blocks. Limit UI and notification updates to a few per second. Dedupe makes progress jump, and that is fine.
• Show the state, not just a bar: waiting for Wi-Fi, waiting for charger, uploading, paused, failed with a reason. Show "backed up" only after the commit succeeds.
• Account limits. If the storage quota is full or the auth token expires during an upload, say so in the UI and pause. Do not waste retries. Refresh the token once and resume with the blocks still missing. A full quota is a state the user must fix, not an error to retry.
• Freeing space. Offer to delete local copies only for items that are committed and confirmed by the server, and ask first.
• In transit: use TLS everywhere. Treat resumable session URIs as bearer tokens (anyone who holds one can use it): short-lived and never logged. Keep the auth token in the Keystore or Keychain.
• At rest: encrypt blocks on the server with keys for each user or each file. End-to-end encryption breaks cross-user dedupe and server-side thumbnails and search. So raise it as a follow-up, not a default.

8. Failure modes and edge cases

9. Battery, data and platform limits

• Default to Wi-Fi and charging for bulk backup, with a cellular opt-in. Never check the library again and again. Use the change APIs from section 4.
• Upload the newest items first, so recent photos are safe within minutes. Let the old library fill in slowly after that.
• Limit parallel uploads to a few blocks. More parallel connections use more radio and memory for little gain.

10. Photo backup on iOS (Swift)

The design is the same: a local database of items, blocks and sessions, a missing list owned by the server, and a split between blocks and metadata. The platform tools change. The background URLSession sketch from the transfer step is here.

What really changes:

• The system owns the transfer, not you. Background URLSession tasks continue after your app is suspended, but you cannot count on running code between blocks. Plan blocks ahead, write them to files, and create several tasks. Do not loop in a coroutine.
• Uploads should come from files. Write each block to a temporary file. Delete it after the server confirms the block.
• Force-quit stops everything. Unlike WorkManager, nothing starts the app again. Say this in the interview and describe the recovery at the next launch.
• No guaranteed schedule. Do cheap work (detect, hash) at launch and in the foreground. Let the background session carry the bytes.
• Delegate setup. A SwiftUI-lifecycle app needs @UIApplicationDelegateAdaptor to receive application(_:handleEventsForBackgroundURLSession:completionHandler:).

This sketch uploads one block that was written to a temporary file in the background:

// One session per identifier, created once (for example in the SDK singleton), never per request.
static let backgroundSession: URLSession = {
    let config = URLSessionConfiguration.background(withIdentifier: "app.backup.uploads")
    config.isDiscretionary = true            // bulk backup: system may wait for Wi-Fi and power; applies to transfers started in the foreground. For a user-started upload set it to false
    // sessionSendsLaunchEvents already defaults to true for background configurations
    config.allowsCellularAccess = false      // user setting
    return URLSession(configuration: config, delegate: UploadDelegate.shared, delegateQueue: nil)
}()

func uploadBlock(sessionUri: URL, offset: Int, len: Int, total: Int, blockFileURL: URL) {
    var req = URLRequest(url: sessionUri)
    req.httpMethod = "PUT"
    req.setValue("bytes \(offset)-\(offset + len - 1)/\(total)", forHTTPHeaderField: "Content-Range")
    Self.backgroundSession.uploadTask(with: req, fromFile: blockFileURL).resume()
}

11. More practice prompts

1. How would you back up a 4 GB video on a flaky connection? (Block upload, server-owned missing list, constraints, foreground or UIDT work, progress in the database.)
2. How do you avoid re-uploading a photo the user already backed up from another device? (Whole-file hash lookup, then block-level dedupe.)
3. Two devices edit the same file offline. What happens? (baseVersion, 409, conflicted copy, no silent overwrite.)
4. How would you add end-to-end encryption? (Encrypt before upload, effect on dedupe, thumbnails, and search, key recovery.)
5. The user's storage fills halfway through a 4 GB upload. What do they see, and what does the uploader do? (Pause with a reason, no retry loop, resume with the blocks still missing.)
6. How would a "free up space" button decide what is safe to delete? (Only committed, server-confirmed items, with a confirmation.)
7. How do you show "backup complete" honestly? (Count only committed items; show reasons for the rest.)

Further reading (official docs)

• The interview part of this case: scope, decisions, failures, follow-ups and levels
• Data layer: repositories, data sources and work lifetimes (Android)
• Offline-first apps: write strategies and sync (Android)
• Define work requests, constraints, expedited work and backoff (Android)
• Foreground service timeouts, including dataSync (Android)
• Behavior changes in Android 16: job runtime quota (Android)
• Partial photo and video access (Android 14)
• Photo and video permissions policy (Google Play)
• Staged rollouts (Google Play Console help)
• Long-running workers in WorkManager (Android)
• User-initiated data transfer jobs (Android)
• Access media files from shared storage: MediaStore version and generation (Android)
• Manage uploads and resumable uploads (Google Drive API)
• Resumable upload protocol (tus)
• URLSessionConfiguration background(withIdentifier:) (Apple)
• BGTaskScheduler (Apple)
• PHPhotoLibraryChangeObserver (Apple)
• PHAssetResourceUploadJob (Apple)

Keep reading

• Design photo backup and file sync (Android and iOS): resumable uploads and conflicts
  The interview answer that this page builds on: scope, structure, failure modes and what to say at each level.
• The framework and every case study
  The five-step method and the other case studies.