⬡ Dev Tools/2026-07-04Advanced

Your Rork Max App Loses the Photos a User Picked After Relaunch — The Trap of Holding Onto URLs Under Limited Photo Access

In a native Swift app generated by Rork Max, photos picked via PHPickerViewController become unreadable after relaunch — because holding onto a URL or PHAsset no longer works in the age of limited access. Here's a design that copies the actual bytes into your own storage the instant they're picked.

Rork Max²³⁵PHPickerViewControllerPhotoKitlimited accessSwift⁴⁸ iOS¹¹⁵

✦ Premium Article

I was adding a feature to a Rork Max app that just uses a few user-picked photos for a collage. Photos chosen through PHPickerViewController displayed fine on the spot and edits worked. But relaunch the app, and the photos I'd just picked came back black or failed to load. Pick them again and it's fixed, but the state I thought I'd saved was broken — that's the shape of the reports. Nothing that looks like an error appears.

The cause was holding onto the temporary reference PHPicker returns, thinking "I'll just read it later." On today's iOS, where limited access is the norm, you have to design on the assumption that a URL or PHAsset identifier valid at selection time won't be readable next time. As an indie developer who's worked on photo apps for a long time, I've learned that missing this "valid only at the moment of selection" nature of limited access means data quietly goes missing in production. This walks through adding photo import to a Rork Max native app with the smallest diff: how to avoid the holding-on trap, and an import layer you can use as-is.

What PHPicker hands you instead of "not asking for permission"

The big advantage of PHPickerViewController is that it works without the photo-library permission dialog. Only the photos the user selects inside the system UI reach the app, so the app holds no access to the whole library. That's the decisive difference from the older UIImagePickerController.

What arrives is a spout, not the bytes

The NSItemProvider PHPicker returns isn't the photo itself — it's "a spout you can draw from right now." You can read it on the spot with loadFileRepresentation or loadDataRepresentation, but the temporary file URL you get back expires after the callback returns. Think "I'll save the URL and open it later" and you drop into an unreadable state on next launch.

A PHAsset identifier is no guarantee of persistence either

You can configure preferredAssetRepresentationMode on PHPickerConfiguration to reach a PHAsset, but under limited access there's no guarantee the asset the app could see then will be visible next time. If the user later changes their selection, the identifier remains but you can no longer resolve it to the bytes. Running photo apps, I've moved away from any design that leans on persisting asset identifiers.

The core of the fix: copy the bytes the moment they're picked

Stop trying to hold on. Inside the selection callback, copy the bytes fully into your own persistent area (like Application Support). Reference only that local file afterward. This is the straightforward design for the limited-access era. Pay the cost once at import, then treat it as your own file — and URL expiry and selection changes become irrelevant.

import PhotosUI
import UniformTypeIdentifiers
import os
 
let picLog = Logger(subsystem: "net.rorklab.sample", category: "photo")
 
enum PhotoImportError: Error { case noImageRep, copyFailed }
 
final class PhotoImporter {
    private let dir: URL = {
        let base = FileManager.default.urls(for: .applicationSupportDirectory,
                                            in: .userDomainMask)[0]
        let d = base.appendingPathComponent("imported", isDirectory: true)
        try? FileManager.default.createDirectory(at: d, withIntermediateDirectories: true)
        return d
    }()
 
    // Take PHPicker results, return an array of persistent paths
    func importItems(_ results: [PHPickerResult]) async -> [URL] {
        var saved: [URL] = []
        for result in results {
            do {
                let url = try await copyToLocal(result.itemProvider)
                saved.append(url)
                picLog.info("imported: \(url.lastPathComponent)")
            } catch {
                picLog.error("import failed: \(error.localizedDescription)")
            }
        }
        return saved
    }
}

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦You can isolate why PHPicker photos vanish after relaunch: limited access, temporary-URL expiry, or the non-persistence of PHAsset

✦You get an import layer that copies the bytes into the app's persistent area right after selection and references only local files afterward, ready to drop into Rork Max's generated code

✦You'll keep PHPicker's strength of not requesting library permission while getting the export, orientation, and size details right for production

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Finish the copy before you ever grab the temporary URL

The temporary URL loadFileRepresentation hands you disappears the instant the closure returns. If you kick off an async copy and return only the URL first, the bytes vanish before the copy completes and it fails. I finish the file copy synchronously inside the loadFileRepresentation closure before returning.

extension PhotoImporter {
    func copyToLocal(_ provider: NSItemProvider) async throws -> URL {
        try await withCheckedThrowingContinuation { continuation in
            let type = UTType.image.identifier
            guard provider.hasItemConformingToTypeIdentifier(type) else {
                continuation.resume(throwing: PhotoImportError.noImageRep); return
            }
            provider.loadFileRepresentation(forTypeIdentifier: type) { [weak self] tmpURL, error in
                guard let self else {
                    continuation.resume(throwing: PhotoImportError.copyFailed); return
                }
                if let error {
                    continuation.resume(throwing: error); return
                }
                guard let tmpURL else {
                    continuation.resume(throwing: PhotoImportError.copyFailed); return
                }
                // finish the copy before leaving the closure
                let dest = self.dir.appendingPathComponent(UUID().uuidString + ".img")
                do {
                    try FileManager.default.copyItem(at: tmpURL, to: dest)
                    continuation.resume(returning: dest)
                } catch {
                    continuation.resume(throwing: PhotoImportError.copyFailed)
                }
            }
        }
    }
}

loadFileRepresentation is more memory-frugal than loadDataRepresentation and keeps peak memory down even for large photos. For importing many at once, like a collage of dozens, I consider flowing file-to-file copies more robust in production than loading Data fully into memory.

Lock in orientation and extension at save time

Stop at just copying and you'll hit the "renders sideways" problem later. Save a HEIC, or a JPEG carrying an Exif Orientation, as-is, and the rendering side interprets orientation inconsistently. I write it out upright once at import so the file no longer needs orientation handling. Deciding the extension from the actual UTI here too keeps re-reading stable later. Pushing this small step into the import layer lets editing, sharing, and thumbnail generation all work off the same assumption, which cuts branches in production operation.

Where to touch Rork Max's generated code

Rork Max generates presenting PHPicker and receiving the selection well from natural language. But the "persist the picked bytes" layer, as generated, tends to stuff the temporary URL straight into state — squarely the trap that vanishes on relaunch. Swapping that for the PhotoImporter above is the minimal-diff move.

On top of that, if you lean into limited access, a word on Info.plist. When you complete everything with PHPicker alone, you can arrange a setup that doesn't even need NSPhotoLibraryUsageDescription. The less you request whole-library permission, the lower the user's psychological hurdle, and the lighter your burden of explanation in App Store review. When I add a photo feature, I first ask "is PHPicker alone enough?" and recommend not requesting library permission until you actually need it. Even in the wallpaper apps I run at Dolice Labs, this approach ended up causing the fewest problems.

Reproduce "vanishes on relaunch" to confirm

This bug never reproduces within a session. My routine: import a few photos to build a saved state, fully terminate the app (task-swipe), relaunch, and check that the real files under the imported directory remain and are readable. If the local files read here, you're in a state utterly unaffected by URL expiry or selection changes.

For your next step, find where Rork Max's generated code holds photos in state and replace it with the return value of PhotoImporter.importItems (persistent URLs). Just shifting to a design that pays the one-time cost of import makes the silent data loss from limited access all but disappear.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.