DEV Community: Maxwell

Stitching Photos into One Long Image in Swift: Common Width, a Height Cap, and One Photo in Memory at a Time

Maxwell — Sat, 14 Nov 2026 02:01:02 +0000

A long image is the simplest way to post a set of photos as one thing: a trip, a recipe, a product from every angle. Stack the photos top to bottom, export one file, done. The first version most of us write is also simple: load every photo as a UIImage, add up the heights, draw them into a UIGraphicsImageRenderer, save.

It works on the simulator with five screenshots. Then someone picks twelve 48-megapixel photos, two of them shot sideways, and the app either dies or produces a 9,000 × 60,000 pixel file that no social app will show at full size.

I build BatchMark, an on-device photo app for iPhone, and its Photo Stories feature joins a set of finished photos into one long image. This post is a teaching extract of the problems you hit when you build that kind of stitcher, not the app's source. Everything here is ImageIO and Core Graphics, no third-party code.

The approach has four parts:

Read each photo's pixel size without decoding it.
Plan the layout: one common width, heights scaled to match, total height capped.
Draw each photo into a single bitmap context, decoding one at a time at the size it will actually appear.
Encode the result, or split it into parts if it's still too tall.

1. Read sizes without decoding

You need every photo's aspect ratio before you can plan anything. Loading full images just to read their size is the most expensive way to get two integers. ImageIO can read them from the file header:

import ImageIO
import CoreGraphics
import UniformTypeIdentifiers

func displaySize(of url: URL) -> CGSize? {
    guard let source = CGImageSourceCreateWithURL(url as CFURL, nil),
          let props = CGImageSourceCopyPropertiesAtIndex(source, 0, nil) as? [CFString: Any],
          let w = props[kCGImagePropertyPixelWidth] as? Int,
          let h = props[kCGImagePropertyPixelHeight] as? Int
    else { return nil }

    // Orientations 5...8 are rotated by 90 degrees, so width and height swap on screen.
    let orientation = props[kCGImagePropertyOrientation] as? UInt32 ?? 1
    return (5...8).contains(orientation)
        ? CGSize(width: h, height: w)
        : CGSize(width: w, height: h)
}

The orientation check is the bit people skip. A portrait photo from an iPhone is often stored as a landscape bitmap plus an orientation flag. If you plan with the stored size, your sideways photo gets a slot that's the wrong shape, and the draw step squashes it.

2. Plan the layout before touching pixels

Every photo gets the same width. Its height follows from its aspect ratio. Then you check the total against a cap and, if it's over, shrink the width until it fits.

struct StitchPlan {
    let width: Int
    let heights: [Int]
    let spacing: Int

    var totalHeight: Int {
        heights.reduce(0, +) + spacing * max(0, heights.count - 1)
    }
}

func makePlan(sizes: [CGSize],
              preferredWidth: Int,
              spacing: Int,
              maxTotalHeight: Int) -> StitchPlan? {
    guard !sizes.isEmpty else { return nil }

    func heights(at width: Int) -> [Int] {
        sizes.map { Int((Double(width) * Double($0.height / $0.width)).rounded()) }
    }

    var width = preferredWidth
    var hs = heights(at: width)
    let gaps = spacing * (sizes.count - 1)
    let imageHeight = hs.reduce(0, +)

    if imageHeight + gaps > maxTotalHeight {
        let available = Double(maxTotalHeight - gaps)
        guard available > 0 else { return nil }
        width = Int((Double(width) * available / Double(imageHeight)).rounded(.down))
        hs = heights(at: width)
    }
    return StitchPlan(width: width, heights: hs, spacing: spacing)
}

Why cap the height at all? Three reasons:

Memory. An 8-bit RGBA bitmap costs width × height × 4 bytes. At 1,080 × 16,000 that's about 69 MB, which is fine. At 4,000 × 60,000 it's close to a gigabyte, which is not.
Format limits. JPEG stores width and height as 16-bit values, so 65,535 pixels is a hard wall. You'll hit memory trouble long before that, but it's worth knowing the wall exists.
Where it's going. Social apps and chat apps resize large images on upload. A long image that's only 400 pixels wide after their resize is unreadable. Check the current limits of wherever you're posting rather than trusting a number from a blog post, including this one.

Pick a sensible preferred width (around the width of the screens people will scroll it on) and a cap that keeps memory comfortable. The plan is just integers, so you can show it in the UI ("12 photos, 1,080 × 15,400") before doing any real work.

3. Draw one photo at a time

The core idea: allocate one bitmap of the final size, then decode each source photo at its final size straight into it. Never hold more than one decoded photo at once.

ImageIO's thumbnail API does the downsampled decode. I covered why this matters for memory in an earlier post on batch exports, so here's just the function:

func decode(_ url: URL, longSide: Int) -> CGImage? {
    let sourceOptions = [kCGImageSourceShouldCache: false] as CFDictionary
    guard let source = CGImageSourceCreateWithURL(url as CFURL, sourceOptions) else { return nil }

    let options: [CFString: Any] = [
        kCGImageSourceCreateThumbnailFromImageAlways: true,
        kCGImageSourceCreateThumbnailWithTransform: true,   // applies the orientation for us
        kCGImageSourceShouldCacheImmediately: true,
        kCGImageSourceThumbnailMaxPixelSize: longSide
    ]
    return CGImageSourceCreateThumbnailAtIndex(source, 0, options as CFDictionary)
}

kCGImageSourceCreateThumbnailWithTransform rotates the result upright, which is why step 1 had to plan with the rotated size.

Now the stitcher:

func stitch(urls: [URL], plan: StitchPlan, background: CGColor) -> CGImage? {
    guard urls.count == plan.heights.count,
          let space = CGColorSpace(name: CGColorSpace.sRGB),
          let ctx = CGContext(data: nil,
                              width: plan.width,
                              height: plan.totalHeight,
                              bitsPerComponent: 8,
                              bytesPerRow: 0,
                              space: space,
                              bitmapInfo: CGImageAlphaInfo.noneSkipLast.rawValue)
    else { return nil }

    ctx.interpolationQuality = .high
    ctx.setFillColor(background)
    ctx.fill(CGRect(x: 0, y: 0, width: plan.width, height: plan.totalHeight))

    var top = 0
    for (url, height) in zip(urls, plan.heights) {
        autoreleasepool {
            let longSide = max(plan.width, height)
            if let image = decode(url, longSide: longSide) {
                // Core Graphics puts the origin at the bottom-left; the layout is top-down.
                let y = plan.totalHeight - top - height
                ctx.draw(image, in: CGRect(x: 0, y: y, width: plan.width, height: height))
            }
        }
        top += height + plan.spacing
    }
    return ctx.makeImage()
}

A few details that are easy to get wrong:

The y flip. A raw CGContext is bottom-up. If you forget, photo 1 ends up at the bottom and your story reads backwards. Converting from a top-down top offset at the moment you draw keeps the layout code readable.
longSide. The thumbnail API takes the longest edge, not the width. For a portrait photo the longest edge is its height in the plan, so max(width, height) is right for both orientations.
Colour space. I've used sRGB here because the output is headed for social apps. If you want to keep wide-gamut colour, create the context in Display P3 instead and make sure the encoder writes the profile. Mixing them silently is how reds go flat.
autoreleasepool. ImageIO hands back objects that can sit in an autorelease pool until the loop ends. Draining each iteration keeps peak memory near "one bitmap plus one photo" instead of "one bitmap plus all photos".

4. Encode, or split

Encoding a CGImage with ImageIO:

func writeJPEG(_ image: CGImage, to url: URL, quality: Double = 0.88) -> Bool {
    guard let dest = CGImageDestinationCreateWithURL(
        url as CFURL, UTType.jpeg.identifier as CFString, 1, nil) else { return false }
    let props = [kCGImageDestinationLossyCompressionQuality: quality] as CFDictionary
    CGImageDestinationAddImage(dest, image, props)
    return CGImageDestinationFinalize(dest)
}

Sometimes the honest answer is that one file is the wrong output. If the cap forces the width down to something unreadable, split the set into parts instead. Splitting the plan, not the pixels, keeps whole photos together:

func split(sizes: [CGSize], width: Int, spacing: Int, maxPartHeight: Int) -> [Range<Int>] {
    var parts: [Range<Int>] = []
    var start = 0, running = 0
    for (i, size) in sizes.enumerated() {
        let h = Int((Double(width) * Double(size.height / size.width)).rounded())
        let added = (i == start ? h : h + spacing)
        if running + added > maxPartHeight, i > start {
            parts.append(start..<i)
            start = i
            running = h
        } else {
            running += added
        }
    }
    parts.append(start..<sizes.count)
    return parts
}

Each range becomes its own StitchPlan and its own file: "Part 1 of 3". No photo is ever cut in half across two images, which is what happens if you render one huge image and slice it.

Putting it together off the main thread

func makeLongImage(from urls: [URL], output: URL) async -> Bool {
    await Task.detached(priority: .userInitiated) {
        let sizes = urls.compactMap(displaySize(of:))
        guard sizes.count == urls.count,
              let plan = makePlan(sizes: sizes, preferredWidth: 1080,
                                  spacing: 24, maxTotalHeight: 16_000),
              let image = stitch(urls: urls, plan: plan,
                                 background: CGColor(gray: 1, alpha: 1))
        else { return false }
        return writeJPEG(image, to: output)
    }.value
}

If a size can't be read, this bails out rather than silently dropping a photo. In a story, a missing photo is worse than an error message, because the order is the point.

What I'd check before shipping

Mix portrait, landscape and square photos in one test set, including at least one stored sideways.
Test the biggest selection you allow, on the oldest device you support, and watch memory in Instruments rather than guessing.
Look at the output after uploading it somewhere real. A long image that looks great in your app and turns to mush after a chat app's resize isn't finished.

The stitching itself is twenty lines. The planning around it, what size, what cap, when to split, is where the real decisions are. If you're building something similar, I'd love to hear how you picked your numbers.

Loading 100 Photos from PHPicker Without Freezing: Order, Progress and Cancellation in Swift

Maxwell — Wed, 11 Nov 2026 02:00:21 +0000

Someone selects 80 photos in the system picker, taps Add, and your app goes quiet. No spinner, no count, just a frozen sheet while the item providers grind through iCloud downloads in whatever order they finish. When the results finally arrive, photo 37 is in slot 2, two files are missing, and nobody knows why.

PHPickerViewController is the right tool for picking photos on iOS: no full library permission, the system handles the UI, and it supports multi-select. But the part after picker(_:didFinishPicking:) is all yours, and that is where batch apps tend to go wrong. This post covers the loading side: keeping the user's order, copying files before they vanish, limiting concurrency, showing honest progress, and letting people cancel.

I build BatchMark, an on-device batch photo app, and this is the stage that runs before any batch watermark or filter touches a pixel. The code below is a teaching extract, not the app's source.

Configure the picker for a batch

import PhotosUI
import UniformTypeIdentifiers

func makeBatchPicker(limit: Int) -> PHPickerViewController {
    var config = PHPickerConfiguration(photoLibrary: .shared())
    config.filter = .images
    config.selectionLimit = limit          // 0 means "no limit"
    config.selection = .ordered            // iOS 15+: numbered badges, ordered results
    config.preferredAssetRepresentationMode = .current
    return PHPickerViewController(configuration: config)
}

Two settings carry most of the weight:

selection = .ordered shows numbered badges and gives you results in the order the user tapped. If your batch has a meaningful sequence (a story, a product set, a before/after pair), this is the order people expect back.
preferredAssetRepresentationMode = .current asks for the asset as it is stored instead of letting the system pick a "compatible" representation. With the default .automatic, a HEIC may be transcoded to JPEG on the way to you, which costs time and a generation of compression you didn't ask for.

Use PHPickerConfiguration(photoLibrary: .shared()) rather than the empty initializer if you might want assetIdentifier later. It doesn't grant library access by itself; it just fills in the identifier when one is available.

The file URL dies when the closure returns

NSItemProvider.loadFileRepresentation(forTypeIdentifier:completionHandler:) hands you a URL to a temporary file. The documentation is blunt about it: the file is deleted when the completion handler returns. If you dispatch to another queue and read it later, you are racing the cleanup.

So the first rule is: copy inside the handler, synchronously, into a folder you own.

enum PickerLoadError: Error {
    case noImageType
    case noFile
}

func preferredImageType(for provider: NSItemProvider) -> String? {
    provider.registeredTypeIdentifiers.first { identifier in
        UTType(identifier)?.conforms(to: .image) == true
    }
}

func makeBatchFolder() throws -> URL {
    let folder = FileManager.default.temporaryDirectory
        .appendingPathComponent("picked-\(UUID().uuidString)", isDirectory: true)
    try FileManager.default.createDirectory(at: folder, withIntermediateDirectories: true)
    return folder
}

preferredImageType(for:) picks the first registered image type, which is usually the stored format (for example public.heic). Falling back to UTType.image.identifier works too, but asking for the specific type avoids a conversion.

Wrap the load in async, with real cancellation

The load method returns a Progress. That object is useful twice: it reports bytes for slow iCloud downloads, and calling cancel() on it stops the load. To connect that to Swift concurrency, keep the progress somewhere the cancellation handler can reach.

final class LoadHandle: @unchecked Sendable {
    private let lock = NSLock()
    private var progress: Progress?
    private var cancelled = false

    func attach(_ progress: Progress) {
        lock.lock()
        self.progress = progress
        let shouldCancel = cancelled
        lock.unlock()
        if shouldCancel { progress.cancel() }
    }

    func cancel() {
        lock.lock()
        cancelled = true
        let current = progress
        lock.unlock()
        current?.cancel()
    }
}

func copyPickedImage(
    from provider: NSItemProvider,
    into folder: URL,
    parentProgress: Progress
) async throws -> URL {
    guard let typeIdentifier = preferredImageType(for: provider) else {
        throw PickerLoadError.noImageType
    }

    let handle = LoadHandle()

    return try await withTaskCancellationHandler {
        try await withCheckedThrowingContinuation { continuation in
            let progress = provider.loadFileRepresentation(
                forTypeIdentifier: typeIdentifier
            ) { url, error in
                if let error {
                    continuation.resume(throwing: error)
                    return
                }
                guard let url else {
                    continuation.resume(throwing: PickerLoadError.noFile)
                    return
                }
                do {
                    let destination = folder
                        .appendingPathComponent(UUID().uuidString)
                        .appendingPathExtension(url.pathExtension)
                    try FileManager.default.copyItem(at: url, to: destination)
                    continuation.resume(returning: destination)
                } catch {
                    continuation.resume(throwing: error)
                }
            }
            parentProgress.addChild(progress, withPendingUnitCount: 1)
            handle.attach(progress)
        }
    } onCancel: {
        handle.cancel()
    }
}

A few details worth calling out:

The copy happens inside the handler, before it returns. That is the whole point.
The destination name is a UUID plus the original extension. Don't trust the temporary file's name to be unique across providers; two photos can arrive as IMG_0001.heic from different sources.
LoadHandle exists because cancellation can arrive before loadFileRepresentation has even returned its Progress. The flag makes "cancel first, attach later" still cancel.
Each child progress counts as one unit of the parent. The parent then reports a fraction that moves smoothly during a slow download instead of jumping only when a file finishes.

Load a few at a time, keep the order

Firing 80 loads at once looks fast in a demo and behaves badly on a real phone: the iCloud queue thrashes, temp storage spikes, and the first results arrive no sooner. A small, fixed number of loads in flight is calmer. Four is a reasonable starting point; measure on your oldest supported device.

The trick is to keep a sliding window in a TaskGroup and write each result into its original slot.

enum PickedItem: Sendable {
    case file(URL)
    case failed(index: Int)
}

func loadPickedImages(
    _ results: [PHPickerResult],
    into folder: URL,
    progress: Progress,
    maxConcurrent: Int = 4
) async -> [PickedItem] {
    progress.totalUnitCount = Int64(results.count)
    var slots = [PickedItem?](repeating: nil, count: results.count)

    // Builds the work for one slot. Returning a closure (instead of calling
    // group.addTask from a nested function) keeps the group out of captures.
    func operation(for index: Int) -> @Sendable () async -> (Int, PickedItem) {
        let provider = results[index].itemProvider
        return {
            do {
                let url = try await copyPickedImage(
                    from: provider,
                    into: folder,
                    parentProgress: progress
                )
                return (index, .file(url))
            } catch {
                return (index, .failed(index: index))
            }
        }
    }

    await withTaskGroup(of: (Int, PickedItem).self) { group in
        var nextIndex = 0

        while nextIndex < min(maxConcurrent, results.count) {
            group.addTask(operation: operation(for: nextIndex))
            nextIndex += 1
        }

        for await (index, item) in group {
            slots[index] = item
            if nextIndex < results.count, !Task.isCancelled {
                group.addTask(operation: operation(for: nextIndex))
                nextIndex += 1
            }
        }
    }

    return slots.enumerated().map { index, item in
        item ?? .failed(index: index)
    }
}

The window starts with maxConcurrent tasks, and every finished task makes room for exactly one more, so the number in flight never exceeds the limit. Results arrive in completion order, but each one carries its index, so slots ends up in the user's order. Under Swift 6 strict concurrency you'll get warnings about capturing NSItemProvider and Progress in a @Sendable closure; neither type is marked Sendable. Progress is designed to be updated from multiple threads, and each provider here is only touched by one task, so a small @unchecked Sendable wrapper is a reasonable way to say so explicitly.

Failures don't throw out of the batch. One photo that failed to download should not throw away the 79 that worked. Keep the slot, mark it failed, and show it.

Show progress people believe

On the UI side, observe fractionCompleted and show a count next to it. A bar alone feels vague; "Loading 23 of 80" tells someone the app is working and roughly how long to wait.

import Combine

@MainActor
final class PickerLoadModel: ObservableObject {
    @Published private(set) var fraction: Double = 0
    @Published private(set) var items: [PickedItem] = []

    private var loadTask: Task<Void, Never>?
    private var progressObservation: AnyCancellable?

    func start(with results: [PHPickerResult]) {
        let progress = Progress()
        progressObservation = progress
            .publisher(for: \.fractionCompleted)
            .receive(on: DispatchQueue.main)
            .sink { [weak self] value in self?.fraction = value }

        loadTask = Task {
            guard let folder = try? makeBatchFolder() else { return }
            let loaded = await loadPickedImages(results, into: folder, progress: progress)
            self.items = loaded
        }
    }

    func cancel() {
        loadTask?.cancel()
    }
}

Progress posts KVO changes on whatever thread updated it, so the receive(on:) hop matters. For the "23 of 80" label, count completed slots as results come back, or derive it from completedUnitCount once each child finishes.

Clean up after yourself

The batch folder is in temporaryDirectory, which the system may purge, but "may" isn't a plan. Delete the folder when the batch is exported or abandoned, and sweep old picked-* folders on launch in case the app was killed mid-batch.

func removeStaleBatchFolders(olderThan age: TimeInterval = 24 * 60 * 60) {
    let fm = FileManager.default
    let tmp = fm.temporaryDirectory
    guard let entries = try? fm.contentsOfDirectory(
        at: tmp,
        includingPropertiesForKeys: [.creationDateKey]
    ) else { return }

    let cutoff = Date().addingTimeInterval(-age)
    for url in entries where url.lastPathComponent.hasPrefix("picked-") {
        let created = (try? url.resourceValues(forKeys: [.creationDateKey]))?.creationDate
        if let created, created < cutoff {
            try? fm.removeItem(at: url)
        }
    }
}

The short version

Ask for .ordered selection and .current representation.
Copy the file inside the completion handler. It's gone afterwards.
Bridge the returned Progress into both your progress UI and task cancellation.
Load a few at a time with a sliding window, and write results back by index.
Mark failures per item instead of failing the batch.
Delete your temp folder, and sweep leftovers on launch.

None of this is glamorous, but it's the difference between a batch feature that feels solid and one where people pick 80 photos once and never try again. I'm Maxwell, and I wrote this down after rebuilding the loading step more times than I'd like to admit.

How to Stamp a Transparent PNG Logo Across a Batch of Photos in Swift

Maxwell — Sun, 08 Nov 2026 02:23:01 +0000

If you need the same logo on thirty photos, the boring bugs show up immediately: the mark looks huge on a 12-megapixel still and timid on a 48-megapixel one, the PNG’s transparent background turns into a grey box, or the edges of the logo go muddy because the alpha channel was applied twice.

This post walks through a small UIKit pipeline that loads a transparent PNG, draws each photo, then draws the logo at a size tied to the photo’s shorter side, inset by a percentage of the frame. I’m writing it from the seat of someone who builds BatchMark, an on-device batch photo app; the batch watermark path is where this idea lives in the product. The code below is a teaching extract, not a dump of the app.

What “the same logo” should mean

People say “put the logo in the corner” and mean three separate decisions:

How large is it, visually? Not “200 pixels,” because 200 pixels is a different object on a 4032-pixel-wide photo than on a 8064-pixel-wide one.
How far is it from the edges? A 40-point inset looks generous on a screenshot and lost on a full-resolution export.
How does it sit on top of the photo? The PNG already has transparency. You want that transparency, plus an optional fade, without flattening the logo first.

Get those three right once, store them as a spec, and run the spec across the batch. The photos can differ in size and orientation; the mark should still feel like the same stamp.

Load the PNG and keep its alpha

Load the logo as a UIImage from your bundle or from a file URL. UIImage preserves the PNG alpha channel. The thing not to do is round-trip the logo through JPEG, which has no alpha and will give you an opaque rectangle where the transparency used to be.

import UIKit

func loadLogoPNG(named name: String) -> UIImage? {
    // Asset catalogue or bundled PNG. Do not encode this as JPEG.
    UIImage(named: name)
}

func loadLogoPNG(from url: URL) -> UIImage? {
    UIImage(contentsOfFile: url.path)
}

If you support user-picked logos from the photo library, make sure you ask for the original file when you can. A preview JPEG from a share sheet is how transparent marks accidentally become stickers with a white mat.

Apple’s UIImage drawing methods composite that alpha for you, which is what we want in the next step.

Draw in pixel space

UIImage.size is in points. Export cares about pixels. Multiply by scale, and build a UIGraphicsImageRenderer whose point size equals the pixel canvas you want, with scale = 1. That way a 4032×3024 photo produces a 4032×3024 result, not a size that surprises you on a 3× device.

func pixelSize(of image: UIImage) -> CGSize {
    CGSize(
        width: image.size.width * image.scale,
        height: image.size.height * image.scale
    )
}

func makeRenderer(pixelSize: CGSize, opaque: Bool) -> UIGraphicsImageRenderer {
    let format = UIGraphicsImageRendererFormat.default()
    format.scale = 1
    format.opaque = opaque
    return UIGraphicsImageRenderer(size: pixelSize, format: format)
}

For finished photos the canvas is opaque, so opaque: true is correct and slightly cheaper. You would only set opaque to false if the output needed transparency, which a typical watermarked JPEG or HEIF export does not.

Drawing with UIImage.draw(in:) also respects image orientation, so you are laying the logo onto the picture the user actually sees, not onto a sideways pixel buffer.

Size the logo from the shorter side

This is not a long essay about resolution-independent layout — just the one rule that keeps a batch looking even. Measure the photo in pixels, take the shorter side, and make the logo’s width a fraction of that length. A 12-megapixel shot and a 48-megapixel shot then get the same visual weight, because both marks occupy the same proportion of the frame.

struct LogoStampSpec {
    /// Logo width as a fraction of the photo's shorter side (for example 0.18).
    var relativeWidth: CGFloat
    /// Inset from the edges as a fraction of the matching photo dimension.
    var edgePadding: CGFloat
    var opacity: CGFloat
    var corner: Corner

    enum Corner {
        case topLeft, topRight, bottomLeft, bottomRight
    }

    static let `default` = LogoStampSpec(
        relativeWidth: 0.18,
        edgePadding: 0.04,
        opacity: 0.85,
        corner: .bottomRight
    )
}

func logoRect(
    in photoPixels: CGSize,
    logo: UIImage,
    spec: LogoStampSpec
) -> CGRect {
    let shorter = min(photoPixels.width, photoPixels.height)
    let width = shorter * spec.relativeWidth
    let aspect = logo.size.width / max(logo.size.height, 0.0001)
    let height = width / aspect

    let padX = photoPixels.width * spec.edgePadding
    let padY = photoPixels.height * spec.edgePadding

    let origin: CGPoint
    switch spec.corner {
    case .topLeft:
        origin = CGPoint(x: padX, y: padY)
    case .topRight:
        origin = CGPoint(x: photoPixels.width - padX - width, y: padY)
    case .bottomLeft:
        origin = CGPoint(x: padX, y: photoPixels.height - padY - height)
    case .bottomRight:
        origin = CGPoint(
            x: photoPixels.width - padX - width,
            y: photoPixels.height - padY - height
        )
    }

    return CGRect(origin: origin, size: CGSize(width: width, height: height))
}

Padding is a percentage of each dimension rather than a fixed pixel inset, for the same reason as the logo width: four percent of a wide landscape photo is a different number of pixels than four percent of a square, but it feels like the same margin. Using the photo’s width for the horizontal inset and the height for the vertical inset keeps the mark from kissing one edge when the aspect ratio is extreme.

Draw the photo, then the logo

Order matters. Paint the photograph first so it becomes the destination. Then composite the logo on top with .normal blending and a single opacity value.

func stampLogo(on photo: UIImage, logo: UIImage, spec: LogoStampSpec) -> UIImage {
    let canvas = pixelSize(of: photo)
    let renderer = makeRenderer(pixelSize: canvas, opaque: true)
    let markRect = logoRect(in: canvas, logo: logo, spec: spec)

    return renderer.image { _ in
        photo.draw(in: CGRect(origin: .zero, size: canvas))
        logo.draw(in: markRect, blendMode: .normal, alpha: spec.opacity)
    }
}

.normal plus the PNG’s own alpha is the combination you want for a regular logo. You are not replacing destination pixels (that would be .copy, which punches an opaque rectangle). You are not adding light (that would be something like .plusLighter, which makes pale logos glow and dark ones disappear).

Don’t double-premultiply the alpha

PNG bitmaps on iOS are typically stored premultiplied: the colour channels have already been multiplied by the alpha. UIImage.draw(in:blendMode:alpha:) knows that, and it knows how to apply your extra alpha fade on top without flattening the image first.

The muddy-edge bug usually comes from applying transparency twice:

Drawing the logo into an intermediate context with alpha already applied, then drawing that intermediate image with alpha again.
Calling cgContext.setAlpha and also passing alpha: into draw.
Expanding the logo yourself into straight (un-premultiplied) RGBA, then handing it to an API that expects premultiplied pixels. Dark fringes appear around antialiased type and around any soft shadow in the PNG.

The safe teaching version is: load once, draw once, pass the fade as the alpha argument a single time, and don’t pre-flatten the logo “to be helpful.” If you need a colour overlay on a monochrome mark, build that overlay in a separate step with a dedicated tint helper; don’t multiply the whole image by a colour and then fade it again.

Apply the same spec to many photos

Once stampLogo(on:logo:spec:) is a pure function of one photo and one spec, the batch is a loop. Keep the spec identical. That is what makes the set look like one shop rather than thirty separate design decisions.

func stampLogo(
    on photos: [UIImage],
    logo: UIImage,
    spec: LogoStampSpec
) -> [UIImage] {
    photos.map { stampLogo(on: $0, logo: logo, spec: spec) }
}

For large batches, prefer sequential mapping over fan-out parallelism. Each rendered photo is a full-resolution bitmap; creating many of them at once is how you run out of memory. If you export as you go — stamp, write JPEG or HEIF, drop the UIImage — the peak memory stays close to “one photo plus one logo” instead of “the whole album.”

A convenient call site looks like this:

guard let logo = loadLogoPNG(named: "studio-mark") else {
    return
}

let spec = LogoStampSpec(
    relativeWidth: 0.16,
    edgePadding: 0.045,
    opacity: 0.8,
    corner: .bottomRight
)

let stamped = stampLogo(on: pickedPhotos, logo: logo, spec: spec)

Same logo file, same relative size, same padding, same fade, every time.

A few edges worth handling

Very wide or very tall photos. Because width is tied to the shorter side, a panorama does not get a logo the size of its long edge. That is usually what you want. If the mark still feels lost on an extreme crop, raise relativeWidth slightly for that export preset rather than switching to an absolute pixel size.
Tiny source logos. A 64-pixel icon scaled up onto a 48-megapixel photo will look soft. Prefer a vector export rendered to a generously sized PNG, or a PDF/SVG pipeline if you already have one. The placer above assumes the logo has enough pixels to survive being scaled to relativeWidth.
Output format. The renderer produces a UIImage. Encode the photo as JPEG or HEIF as you normally would. Do not encode the logo that way before drawing.

None of this replaces design taste — a mark can still be too large, too opaque, or sitting on the product — but it does mean the implementation will not quietly change the design from one photo to the next.

I’m Maxwell. I build BatchMark as a longer-running experiment in making this class of finishing step usable on a phone, without uploading the files. The snippet above is the part I wish I had written down the first time a logo looked perfect on the first photo and wrong on the rest.

Crop Once, Post Everywhere: Batch Aspect-Ratio Crops for Social Images in Swift

Maxwell — Thu, 05 Nov 2026 02:24:23 +0000

If you ship photos from an iPhone app to more than one place, you eventually hit the same boring problem: Instagram wants 1:1 or 4:5, a shop banner wants 16:9, Stories want 9:16, and the camera roll is full of 4:3 and 3:4 stills. Doing that crop by hand for thirty product shots is how afternoons disappear.

This post walks through a small UIKit pipeline that takes one UIImage, a list of target aspect ratios, and returns one centre-weighted crop per ratio — suitable for running across a whole album. I’m writing it from the seat of someone who builds BatchMark, an on-device batch photo app, where “apply the same finishing step to many photos” is the whole product. The code below is a teaching extract, not a dump of the app.

What “same crop” should mean

People say “crop to 1:1” and mean two different things:

Aspect-fill crop: keep the photo’s resolution as high as possible, cut off the edges that don’t fit the ratio.
Aspect-fit pad: show the whole photo, add bars (or a mat) to reach the ratio.

For social uploads you almost always want (1). Padding changes the look of the feed thumbnail; a filled crop matches what creators already do in Instagram’s own editor.

Centre-weighted aspect-fill is a good default. Face-aware or subject-aware cropping is better for people photos, but it needs Vision and a policy for failure cases. Start with centre; add intelligence later.

The ratio list you’ll actually use

Keep ratios as width ÷ height in landscape-agnostic form, then decide orientation per photo:

import UIKit

struct SocialRatio: Hashable {
    let name: String
    let widthOverHeight: CGFloat

    static let feedSquare = SocialRatio(name: "1:1", widthOverHeight: 1)
    static let feedPortrait = SocialRatio(name: "4:5", widthOverHeight: 4.0 / 5.0)
    static let story = SocialRatio(name: "9:16", widthOverHeight: 9.0 / 16.0)
    static let landscapeBanner = SocialRatio(name: "16:9", widthOverHeight: 16.0 / 9.0)
    static let fourThree = SocialRatio(name: "4:3", widthOverHeight: 4.0 / 3.0)
}

Store the name for export filenames (chair-blue-4x5.jpg). Store the math as a single CGFloat so you don’t thread two integers through every helper.

Pixel size, not point size

UIImage.size is in points. Drawing and JPEG export care about pixels. Multiply by scale, and prefer image.size over cgImage width/height so orientation flags are already respected in the size you lay out against:

func pixelSize(of image: UIImage) -> CGSize {
    CGSize(
        width: image.size.width * image.scale,
        height: image.size.height * image.scale
    )
}

Centre aspect-fill rect

Given a source pixel size and a target width/height ratio, compute the crop rectangle in the source’s pixel space:

func aspectFillCropRect(
    sourcePixels: CGSize,
    targetWidthOverHeight: CGFloat
) -> CGRect {
    let sourceRatio = sourcePixels.width / sourcePixels.height
    let targetRatio = targetWidthOverHeight

    var cropSize = sourcePixels
    if sourceRatio > targetRatio {
        // Source is wider than target: crop left/right.
        cropSize.width = sourcePixels.height * targetRatio
    } else {
        // Source is taller than target: crop top/bottom.
        cropSize.height = sourcePixels.width / targetRatio
    }

    let origin = CGPoint(
        x: (sourcePixels.width - cropSize.width) / 2,
        y: (sourcePixels.height - cropSize.height) / 2
    )
    return CGRect(origin: origin, size: cropSize)
}

That rect is the region of the oriented image you want to keep. Next you need to draw only that region into a new bitmap whose pixel size matches the crop.

Drawing the crop with UIGraphicsImageRenderer

A reliable approach: create a renderer whose pixel size equals the crop size, then draw the full image with an offset so the crop rect lands on the canvas.

func crop(_ image: UIImage, toWidthOverHeight ratio: CGFloat) -> UIImage {
    let srcPixels = pixelSize(of: image)
    let cropRect = aspectFillCropRect(
        sourcePixels: srcPixels,
        targetWidthOverHeight: ratio
    )

    let format = UIGraphicsImageRendererFormat.default()
    format.scale = 1
    format.opaque = true

    let renderer = UIGraphicsImageRenderer(size: cropRect.size, format: format)
    return renderer.image { _ in
        let drawRect = CGRect(
            x: -cropRect.origin.x,
            y: -cropRect.origin.y,
            width: srcPixels.width,
            height: srcPixels.height
        )
        image.draw(in: drawRect)
    }
}

Setting format.scale = 1 matters. The renderer’s size is in points; with scale 1, points equal pixels, so a 1080×1350 canvas really is 1080×1350 pixels. Leave the default screen scale and a 3× phone quietly multiplies memory and dimensions by nine.

Batching across a set

For a whole album, map each photo across the ratio list. Keep work off the main actor, and don’t hold every output in memory at once if the set is large:

struct CroppedExport: Hashable {
    let sourceIndex: Int
    let ratio: SocialRatio
    let image: UIImage
}

func cropBatch(
    images: [UIImage],
    ratios: [SocialRatio]
) async -> [CroppedExport] {
    var results: [CroppedExport] = []
    results.reserveCapacity(images.count * ratios.count)

    for (index, image) in images.enumerated() {
        for ratio in ratios {
            let cropped = crop(image, toWidthOverHeight: ratio.widthOverHeight)
            results.append(CroppedExport(sourceIndex: index, ratio: ratio, image: cropped))
        }
        // Optional: encode and write to disk here, then drop `cropped` /
        // prune `results` so peak memory stays flat on large albums.
    }
    return results
}

If you need parallelism, wrap the inner work in a TaskGroup, but cap concurrent renders (2–3 on older phones). Each render allocates a full bitmap; unbounded concurrency is a fast path to jetsam. A memory-budgeted exporter is a separate article — for this post, sequential per photo and parallel across a small capped group is enough.

Naming and exporting

Creators care about finding the right file later:

func filename(stem: String, ratio: SocialRatio) -> String {
    let safe = ratio.name.replacingOccurrences(of: ":", with: "x")
    return "\(stem)-\(safe).jpg"
}

func jpegData(_ image: UIImage, quality: CGFloat = 0.9) -> Data? {
    image.jpegData(compressionQuality: quality)
}

Use 0.85–0.92 for social JPEGs unless you have a print path. Re-encoding already-compressed camera JPEGs at 1.0 still loses generation quality and inflates files for no visible gain on a feed.

Edge cases worth handling early

Tiny sources. A 640×640 screenshot cannot invent a sharp 1080×1920 story frame. Either upscale deliberately (usually looks bad) or export at the cropped native size and let the destination scale.
Panoramas. Centre crop on a 16000×3400 panorama often lands on empty content. For ultra-wide sources, consider pinning the crop to a focus rect the user tapped once.
Portrait vs landscape banners. A 16:9 crop of a tall portrait keeps a thin horizontal band through the middle — technically correct, often useless. Offer “skip this ratio” when the source ratio is extremely far from the target.
Orientation. Drawing with UIImage.draw(in:) uses the oriented image. If you bypass that and slice cgImage directly, you’ll crop the upright photo using the sideways buffer. Stick to UIImage drawing unless you also apply the orientation transform.

A minimal call site

let ratios: [SocialRatio] = [
    .feedSquare,
    .feedPortrait,
    .story,
    .landscapeBanner
]

let exports = await cropBatch(images: pickedImages, ratios: ratios)
for item in exports {
    let name = filename(stem: "product-\(item.sourceIndex)", ratio: item.ratio)
    if let data = jpegData(item.image) {
        // write `data` to a temp URL named `name`
        _ = name
    }
}

Why this belongs in a batch tool

The interesting product decision is not the crop math — it’s doing the same finishing step across a set so a shop owner or a creator isn’t trapped in a per-photo editor. Aspect-ratio packs are one of those steps, alongside watermarks, filters, and frames. If you’re solving the same class of problem on device, the crop helper above is a solid first brick.

I’m Maxwell — I build BatchMark, an iPhone app for finishing photos in batches without uploading them. This article is about the UIKit approach; the app is the longer-running experiment in making that approach usable for non-developers.

Why Your Watermark Is Tiny on One Photo and Huge on the Next: Resolution-Independent Overlays in Swift

Maxwell — Mon, 02 Nov 2026 02:15:30 +0000

The obvious first version of batch watermark code has one setting that looks completely reasonable: a font size of 48.

On a screenshot that's enormous. On a 48-megapixel photo it's a speck in the corner you'd need to zoom in to find. On a portrait photo it sits at a different distance from the edge than on a landscape one. Every photo in the batch gets "the same" watermark, and no two of them look alike.

The bug isn't in any single line. It's the idea that a watermark has a size in points. When you're stamping a mixed set of images (phone photos, screenshots, crops, panoramas, images saved from chat apps), the only size that means anything is a size relative to the image. This post shows how to set that up in Swift with UIKit drawing, plus the few traps that are easy to miss.

The mixed set you actually get

If you let people pick photos from their library, assume the batch looks something like this:

4032 × 3024 (12 MP, landscape)
3024 × 4032 (the same camera, portrait)
8064 × 6048 (48 MP)
1179 × 2556 (a screenshot)
1080 × 1080 (an image saved from social media)
16000 × 3400 (a panorama)

A 48-pixel-tall line of text is about 1.6% of the short side of the 12 MP photo, 0.8% of the 48 MP one and 4% of the screenshot. That's the whole problem in three numbers.

Step 1: Work in pixels, not points

UIImage.size is in points and already accounts for orientation. Multiply by scale and you get the pixel size of the image as people see it, which is what we want to lay out against:

import UIKit

func pixelSize(of image: UIImage) -> CGSize {
    CGSize(width: image.size.width * image.scale,
           height: image.size.height * image.scale)
}

Don't use cgImage.width and cgImage.height for layout. A portrait photo from the camera is often stored as a landscape bitmap with an orientation flag, so the CGImage will happily tell you it's 4032 wide when the person is looking at something 3024 wide. Your "bottom-right corner" then lands on the wrong edge.

The renderer has the same trap in a different place. A UIGraphicsImageRenderer uses the screen's scale by default, so a 4032 × 3024 canvas on a 3x iPhone becomes a 12096 × 9072 bitmap. That's nine times the pixels, nine times the memory, and an output file nobody asked for. Set the scale explicitly:

let format = UIGraphicsImageRendererFormat()
format.scale = 1          // 1 point == 1 pixel; we already sized in pixels
format.opaque = true      // photos have no alpha; skip it if you accept PNGs with transparency
let renderer = UIGraphicsImageRenderer(size: pixelSize(of: image), format: format)

Step 2: Size against the short side

Once everything is in pixels, pick one dimension to measure against. I use the short side, min(width, height), for three reasons:

It's the same for the portrait and landscape versions of a photo, so rotating a picture doesn't change the size of the mark.
On a panorama, the long side is huge. Scaling to it would produce a watermark taller than the image's comfortable reading area.
On a tall screenshot, scaling to the long side makes text that's too wide for the narrow edge.

Then every measurement becomes a fraction: text height, margin, shadow blur, logo width.

struct WatermarkStyle {
    var text: String
    var relativeCapHeight: CGFloat = 0.035  // cap height as a fraction of the short side
    var relativeMargin: CGFloat = 0.03      // distance from the edges
    var maxWidthFraction: CGFloat = 0.8     // never wider than 80% of the image
    var opacity: CGFloat = 0.85
}

Step 3: Turn "how tall" into a font size

A font's point size isn't the height of its letters. It's roughly the height of the line box, which includes room for ascenders, descenders and some spacing. If you set the point size to 3.5% of the short side, the visible capitals end up noticeably smaller than that, and the ratio changes between fonts.

UIFont gives you capHeight, so you can solve for the point size that produces the letter height you want. The ratio is stable for a given font, so measure it once at a reference size:

func font(forCapHeight target: CGFloat,
          weight: UIFont.Weight = .semibold) -> UIFont {
    let reference = UIFont.systemFont(ofSize: 100, weight: weight)
    let capRatio = reference.capHeight / reference.pointSize   // about 0.7 for the system font
    return UIFont.systemFont(ofSize: target / capRatio, weight: weight)
}

Now "3.5% of the short side" means the capitals are that tall, whichever font the person picked.

Step 4: Shrink to fit, don't overflow

Long watermark text ("© Maxwell Studio · Do not reuse") can be wider than a narrow image, especially a portrait screenshot. Measure it and scale the font down if it's over the limit. One measurement and one proportional correction is enough, because text width scales linearly with point size:

func attributes(font: UIFont, opacity: CGFloat, shortSide: CGFloat)
    -> [NSAttributedString.Key: Any] {
    let shadow = NSShadow()
    shadow.shadowColor = UIColor.black.withAlphaComponent(0.35)
    shadow.shadowBlurRadius = shortSide * 0.004    // scales with the image too
    shadow.shadowOffset = CGSize(width: 0, height: shortSide * 0.001)
    return [
        .font: font,
        .foregroundColor: UIColor.white.withAlphaComponent(opacity),
        .shadow: shadow
    ]
}

func fittedFont(for text: String, style: WatermarkStyle, canvas: CGSize) -> UIFont {
    let shortSide = min(canvas.width, canvas.height)
    let start = font(forCapHeight: shortSide * style.relativeCapHeight)
    let width = (text as NSString).size(
        withAttributes: attributes(font: start, opacity: 1, shortSide: shortSide)
    ).width

    let maxWidth = canvas.width * style.maxWidthFraction
    guard width > maxWidth else { return start }
    return start.withSize(start.pointSize * maxWidth / width)
}

Notice the shadow. A fixed 4-point blur looks like a soft glow on a screenshot and like nothing at all on a 48 MP photo. Anything you'd set in points (blur, stroke width, corner radius of a backing plate) needs the same treatment as the font.

Step 5: Place it by the baseline, not the box

draw(at:withAttributes:) puts the top-left of the line box at the point you give it. If you place the box margin pixels from the bottom, the visible gap under the letters is bigger than margin, because the box includes descender space. Compared with the side margin, it looks like the text is floating.

Position by the baseline instead. The baseline sits font.ascender below the top of the line box, so:

func renderWatermark(on image: UIImage, style: WatermarkStyle) -> UIImage {
    let canvas = pixelSize(of: image)
    let shortSide = min(canvas.width, canvas.height)
    let font = fittedFont(for: style.text, style: style, canvas: canvas)
    let attrs = attributes(font: font, opacity: style.opacity, shortSide: shortSide)

    let text = style.text as NSString
    let textWidth = text.size(withAttributes: attrs).width
    let margin = shortSide * style.relativeMargin

    // Baseline exactly `margin` above the bottom edge, right edge `margin` from the side.
    let baselineY = canvas.height - margin
    let origin = CGPoint(x: canvas.width - margin - textWidth,
                         y: baselineY - font.ascender)

    let format = UIGraphicsImageRendererFormat()
    format.scale = 1
    format.opaque = true
    let renderer = UIGraphicsImageRenderer(size: canvas, format: format)

    return renderer.image { _ in
        image.draw(in: CGRect(origin: .zero, size: canvas))   // respects orientation
        text.draw(at: origin, withAttributes: attrs)
    }
}

Letters with descenders (g, y, p) will dip slightly into the margin. That's what typesetters do too; it looks aligned because the eye reads the baseline.

Logos: same rule, one extra check

A logo gets the same treatment. Size its longer side as a fraction of the image's short side, keep its aspect ratio, and use the same margin:

func logoRect(logo: UIImage, canvas: CGSize,
              relativeSize: CGFloat = 0.16,
              relativeMargin: CGFloat = 0.03) -> CGRect {
    let shortSide = min(canvas.width, canvas.height)
    let logoPixels = pixelSize(of: logo)
    let longest = max(logoPixels.width, logoPixels.height)
    let scale = (shortSide * relativeSize) / longest

    let size = CGSize(width: logoPixels.width * scale, height: logoPixels.height * scale)
    let margin = shortSide * relativeMargin
    return CGRect(x: canvas.width - margin - size.width,
                  y: canvas.height - margin - size.height,
                  width: size.width, height: size.height)
}

The extra check is upscaling. If scale comes out above 1, the logo bitmap is smaller than the space it's about to fill, and it will be soft on big photos. A 400-pixel PNG logo looks fine on a 1080 image and blurry on a 48 MP one. Either warn the person when scale > 1, or ask for a bigger logo file up front. A transparent PNG at 1000–2000 pixels on its long side covers almost everything a phone camera produces.

You might expect a logo to want a different reference than text. It doesn't need one: once both are tied to the short side, a text mark and a logo mark that look balanced on one photo keep the same proportions on every other photo in the set.

A quick way to test it

Make a test set with the six shapes from the start of this post. Solid-colour images are fine; you're testing geometry, not looks. Render each one, then scale every output to the same display height and lay them out side by side. If the system is right, the marks look identical: same apparent size, same distance from the corner, same softness of shadow.

Two edge cases worth adding:

Tiny images. A 300 × 300 thumbnail gives a cap height of about 10 pixels. Clamp to a minimum so the text stays legible.
Extreme panoramas. The short side keeps the size sensible, but a corner mark on a 16000-pixel-wide image can be a long way from where people look. That's a placement question rather than a sizing one, and it's worth deciding on purpose.

The rule, in one line

Never store a watermark size in points. Store fractions of the short side, convert to pixels per image at render time, and set the renderer's scale to 1 so a pixel stays a pixel.

I build an iPhone app called BatchMark that stamps text and logo marks on sets of up to 100 photos at once, and sizing everything relative to the photo is what lets one setting work across a mixed batch. If you're also thinking about where the mark should go so it doesn't get cropped out, I wrote up some notes on watermark placement. And if you've hit a sizing case I didn't cover, I'd like to hear about it in the comments.

Exporting 100 Photos on an iPhone Without Getting Killed: Memory Notes for Batch Image Processing in Swift

Maxwell — Fri, 30 Oct 2026 02:42:59 +0000

Processing one photo on an iPhone is easy. Processing a hundred in a row is where apps quietly die.

There's often no crash log in the usual sense. The app just vanishes partway through the batch, and if you're attached to Xcode you see "Terminated due to memory issue". iOS gives each app a memory budget, and when you go over it, the system ends the process. No exception, no second chance.

I work on an iPhone app that applies watermarks and filters to whole sets of photos, so batch export is the main path, not an edge case. These are the notes I wish I'd had at the start: why memory grows, and the handful of patterns that keep it flat.

The numbers that matter

A photo's file size tells you almost nothing about its memory cost. A HEIC from an iPhone might be 2–3 MB on disk, but once it's decoded into pixels, it costs width × height × 4 bytes (for 8-bit RGBA):

12 MP (4032 × 3024): about 49 MB
48 MP (8064 × 6048): about 195 MB

And that's one copy. A naive pipeline often holds several at once: the decoded source, an intermediate after the filter, the composited output, and the encoder's buffer. Do that for a few 48 MP photos at the same time and you've used a large slice of what the system will allow.

So the goal isn't to make each photo cheaper. It's to make sure only one photo's worth of memory is alive at any moment, and that it's released before the next one starts.

1. Process one photo at a time

It's tempting to fire off a TaskGroup and process the whole batch in parallel. On a desktop, maybe. On a phone, with full-resolution images, parallelism multiplies your peak memory by the number of photos in flight, and the GPU is already doing most of the heavy work anyway.

A plain sequential loop is the safest default. If you profile and find you're waiting on I/O, try two in flight, not ten.

2. Ask Photos for data, not a UIImage

PHImageManager.requestImage(for:targetSize:...) hands you a decoded UIImage. For thumbnails that's fine. For export, you want the encoded bytes so you control when and how decoding happens:

import Photos

func loadImageData(for asset: PHAsset) async throws -> Data {
    let options = PHImageRequestOptions()
    options.isNetworkAccessAllowed = true      // the original may be in iCloud
    options.deliveryMode = .highQualityFormat  // the handler is called once
    options.version = .current                 // include the user's edits

    return try await withCheckedThrowingContinuation { continuation in
        PHImageManager.default().requestImageDataAndOrientation(
            for: asset,
            options: options
        ) { data, _, _, info in
            if let data {
                continuation.resume(returning: data)
            } else {
                let error = info?[PHImageErrorKey] as? Error
                    ?? CocoaError(.fileReadUnknown)
                continuation.resume(throwing: error)
            }
        }
    }
}

.highQualityFormat matters for more than quality. With .opportunistic, the handler can be called twice (a degraded image first, then the full one), and resuming a continuation twice is a crash.

3. Use one CIContext for the whole batch

A CIContext is expensive to create. It sets up GPU resources and caches. Creating one per photo is a common mistake that costs both time and memory. Make one, keep it for the batch, and turn off intermediate caching, since you'll never render the same image twice:

import CoreImage
import ImageIO

final class BatchRenderer {
    private let context = CIContext(options: [.cacheIntermediates: false])

    func render(
        _ data: Data,
        apply: (CIImage) -> CIImage,
        to url: URL
    ) throws {
        try autoreleasepool {
            guard let input = CIImage(
                data: data,
                options: [.applyOrientationProperty: true]
            ) else {
                throw CocoaError(.fileReadCorruptFile)
            }

            let output = apply(input)
            let colorSpace = input.colorSpace
                ?? CGColorSpace(name: CGColorSpace.sRGB)!

            try context.writeHEIFRepresentation(
                of: output,
                to: url,
                format: .RGBA8,
                colorSpace: colorSpace,
                options: [
                    kCGImageDestinationLossyCompressionQuality as CIImageRepresentationOption: 0.9
                ]
            )
        }
    }
}

A few details in there are doing real work:

.applyOrientationProperty: true rotates the image upright when it's loaded. Without it, portrait photos come out sideways, and any watermark you position "bottom right" lands in the wrong corner.
Keeping the source colour space means a Display P3 photo stays Display P3 instead of being flattened to sRGB on export.
Writing straight to a file with writeHEIFRepresentation avoids holding the encoded output as a Data in memory and then writing it again.

4. Wrap each photo in autoreleasepool

Core Image, ImageIO and Photos still create a lot of autoreleased Objective-C objects under the hood. In a tight loop, those objects aren't freed until the pool drains, which may not happen until the loop ends. That's how memory climbs steadily across a batch even though your Swift code holds nothing.

autoreleasepool { } around each photo's work drains them every iteration. One catch: you can't await inside an autoreleasepool block, because the closure is synchronous. That's why the render function above is synchronous, and the async loading happens outside it:

func exportBatch(
    _ assets: [PHAsset],
    renderer: BatchRenderer,
    apply: (CIImage) -> CIImage,
    progress: (Int) -> Void
) async throws -> [URL] {
    let folder = FileManager.default.temporaryDirectory
        .appendingPathComponent(UUID().uuidString, isDirectory: true)
    try FileManager.default.createDirectory(
        at: folder,
        withIntermediateDirectories: true
    )

    var outputs: [URL] = []
    for (index, asset) in assets.enumerated() {
        try Task.checkCancellation()                     // let the user stop
        let data = try await loadImageData(for: asset)   // async, outside the pool
        let url = folder.appendingPathComponent("\(index).heic")
        try renderer.render(data, apply: apply, to: url) // sync, inside the pool
        outputs.append(url)
        progress(index + 1)
    }
    return outputs
}

The loop only keeps URLs, which are tiny. Each photo's Data goes out of scope at the end of its iteration.

5. Build the edit so it scales with the photo

The apply closure is where your actual feature lives. Here's a logo watermark that's sized relative to the photo's short side, so it looks the same on a 12 MP photo and a cropped 2 MP one:

func stampLogo(
    _ logo: CIImage,
    widthFraction: CGFloat = 0.18,
    marginFraction: CGFloat = 0.04
) -> (CIImage) -> CIImage {
    return { image in
        let extent = image.extent
        let shortSide = min(extent.width, extent.height)

        let scale = (shortSide * widthFraction) / logo.extent.width
        let scaled = logo.transformed(by: CGAffineTransform(scaleX: scale, y: scale))

        let inset = shortSide * marginFraction
        let x = extent.maxX - scaled.extent.width - inset
        let y = extent.minY + inset   // Core Image's origin is bottom-left

        let placed = scaled.transformed(by: CGAffineTransform(
            translationX: x - scaled.extent.minX,
            y: y - scaled.extent.minY
        ))
        return placed.composited(over: image).cropped(to: extent)
    }
}

Create the logo CIImage once, before the loop. Core Image is lazy, so this closure only builds a recipe. Nothing is rendered until writeHEIFRepresentation runs, which is why there's no extra full-size buffer per filter step.

6. Hand the files to Photos in chunks

Saving with UIImageWriteToSavedPhotosAlbum means decoding the image again into a UIImage. Instead, give Photos the file you already wrote, and let it move the file rather than copy it:

func saveToPhotos(_ urls: [URL], chunkSize: Int = 20) async throws {
    let chunks = stride(from: 0, to: urls.count, by: chunkSize).map {
        Array(urls[$0..<min($0 + chunkSize, urls.count)])
    }
    for chunk in chunks {
        try await PHPhotoLibrary.shared().performChanges {
            for url in chunk {
                let request = PHAssetCreationRequest.forAsset()
                let options = PHAssetResourceCreationOptions()
                options.shouldMoveFile = true
                request.addResource(with: .photo, fileURL: url, options: options)
            }
        }
    }
}

Chunks keep each change request small, and if something fails, you know roughly where. You only need add-only access for this, so request PHPhotoLibrary.requestAuthorization(for: .addOnly) rather than full library access. Users are more willing to say yes to that.

7. Previews are a separate problem

The grid of thumbnails at the top of a batch screen can use more memory than the export if every cell holds a full-size image. For previews, either ask PHImageManager for a targetSize that matches the cell, or downsample with ImageIO:

func thumbnail(from data: Data, maxPixelSize: Int) -> CGImage? {
    let sourceOptions = [kCGImageSourceShouldCache: false] as CFDictionary
    guard let source = CGImageSourceCreateWithData(data as CFData, sourceOptions) else {
        return nil
    }
    let options = [
        kCGImageSourceCreateThumbnailFromImageAlways: true,
        kCGImageSourceCreateThumbnailWithTransform: true,
        kCGImageSourceShouldCacheImmediately: true,
        kCGImageSourceThumbnailMaxPixelSize: maxPixelSize
    ] as CFDictionary
    return CGImageSourceCreateThumbnailAtIndex(source, 0, options)
}

This decodes straight to the small size. It never builds the full-resolution bitmap first.

How to check you've actually fixed it

Don't trust a feeling. Measure:

Xcode's memory gauge during a 100-photo export should look like a flat line with small bumps, not a staircase.
Instruments → Allocations, with "Mark Generation" between photos, shows exactly what survives each iteration.
os_proc_available_memory() (import os) tells you how much headroom you have left at runtime. Logging it every ten photos in a debug build is a cheap early warning.
Test on your oldest supported device, with 48 MP photos. A new Pro phone with a lot of RAM will hide problems your users will hit.

The short version

One photo at a time. Load data, not images. One CIContext. A sync render inside autoreleasepool. Write to disk, then let Photos move the file. Downsample previews.

None of these are clever, and that's the point. Batch processing on a phone is mostly about not doing extra work, and making sure what you do finishes before the next photo starts.

These notes come out of building BatchMark, where you set a text or logo watermark once and export a set of up to 100 photos on the device. If you want to see what that flow looks like from the user's side, here's the batch watermark page. And if you've found other memory traps in Core Image or PhotoKit, I'd like to hear about them in the comments.

Disclosure: I'm an independent developer, and BatchMark (灵感图像大师 in Chinese) is my own app. It's free to download on the App Store, with optional paid features.

Most Photos Never Get Finished. 6 Things I Learned Building a Photo App as a Solo Developer

Maxwell — Sat, 24 Oct 2026 01:09:43 +0000

I build a small photo app for iPhone, on my own. It's easy to assume the hard part of a photo app is the editing: better filters, smarter tools, more sliders.

It isn't. Sellers listing products, people sharing a trip, anyone sending a few pictures to a client or a group chat: they rarely struggle with one photo. They struggle with the set. Thirty shots that need the same logo. Twelve travel photos that should look like they belong together. A handful of pictures that are "nearly done" and stay that way for months.

Here are six things that shaped how I built the app, written for anyone with a camera roll full of almost-finished photos. None of it needs my app. Most of it works with whatever you already use.

1. People don't edit photos. They edit sets.

Most real photo jobs come in batches: a product listing, a weekend away, a portfolio update, a set of previews for a client. Editing them one by one is where people give up, because by photo nine you've forgotten what you did to photo two.

The fix is boring and it works: make your decisions once, then apply them to everything. Pick the watermark, the border, the size and the position on one photo. Then copy those exact settings to the rest instead of eyeballing each one.

That's why the app is built around batches. You set things up once and apply them to the whole group.

2. "Finished" mostly means consistent

Look at any shop page or portfolio that feels "professional" and the reason is rarely the editing. It's sameness. The same mark in the same corner, at the same size. The same kind of frame. The same amount of space around each picture.

Eight product photos. The frames differ, but each one sits centred on a plain wall with similar space around it, and that shared layout is what makes them read as one set.

A practical test: put your photos side by side in a grid before you post them. If your eye jumps around, something is inconsistent, usually the position or size of the text, or the crop.

3. A good watermark is readable, then forgettable

Most watermark advice is either "put your name in the corner" or "cover the whole thing". Both are right, for different jobs.

Showing off your work, like portfolio shots or social posts: a small mark in a consistent corner. People should be able to read it if they look for it and ignore it if they don't.
Protecting what you send, like product photos that tend to get copied or documents you share: repeat the text diagonally across the whole image, so there's no clean corner to crop away.
Pick a strength you can live with. Faint enough that the photo is still the point, strong enough that it survives a screenshot. Roughly 20 to 35 percent opacity is a good place to start.
Write something useful. A name or shop handle for your work. For a document, what it's for and the date, so the copy can't easily be reused for something else.

A tiled mark on a product photo. You can still see the product clearly, but there's no clean area to crop out.

4. A frame does more than a filter

A plain photo with a simple frame and some space around it often looks more finished than one with heavy colour edits. A border tells the viewer "this one was chosen". It turns a snapshot into something that looks ready to hang.

A simple frame, a wide matte and a plain wall behind it are enough to make an ordinary photo look finished.

If you try this yourself, keep two rules. Use the same frame for every photo in a set. And give the picture more space than feels natural, because a wide border almost always looks calmer than a thin one.

5. Colour is what ties a set together

Sets that look like they belong together usually share a few colours, not a filter. One exercise I like is a "colour walk": go out with one colour in mind, photograph only things in that colour, then pull out the main colour of each shot and line them up as small swatches.

It's a fun way to practise seeing, and it gives you a simple rule for choosing which photos to post together. Lay the colours out next to each other, and the ones that clash are the ones to leave out.

That idea became a feature in my app, Color Walk, which pulls out a photo's main colour and lays it out as a card for you.

6. Fewer choices, saved once

Every option you add to an app makes it a little harder to use, so I try to keep the list short. What most people need is to set things up once and reuse them next time: the same logo, the same corner, the same frame.

That's why the app saves a setup as a template, rather than offering anything clever. If you're doing this by hand, the equivalent is a note on your phone with your settings: font, size, opacity, position, border width. Next time, you copy instead of deciding again.

A small design decision that helped everything

One choice I made early: everything happens on the phone. The photos never leave it. The privacy side deserves its own post. The day-to-day benefit is simpler. There's no upload and no waiting, so a whole set is done in one pass, and it still works on a train with no signal.

A 10-minute routine for finishing a set

If you want to try this today, with any app:

Pick the set. Six to twelve photos is plenty, so choose fewer than feels comfortable.
Decide on one look: one frame or border, and one watermark position and size.
Apply it to all of them in one go, not one at a time.
Lay them out in a grid and look for anything that jumps out.
Save your settings somewhere so next time takes two minutes.

Over to you

If you build things: what did your users teach you that you didn't expect? If you just take a lot of photos: what's the step where yours stop getting finished?

I'm an independent developer, and the app I've been describing is mine: BatchMark (çµæ„Ÿå›¾åƒå¤§å¸ˆ in Chinese). It helps photos look complete and good-looking faster, with batch watermarks, art frames and Color Walk colour cards, so a whole set is sorted in one go.