DEV Community: Maxwell

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.