iOS & Mobile

Last updated Sep 2026

Project Q&A

Overview

PixScan is an iPhone app for getting through a camera roll that has grown past the point of browsing. Photos are presented one at a time and dismissed with a swipe: keep, delete, or read the text off the photo first and let the photo go. Text recognition runs on-device through Apple's Vision framework, and the app makes no network requests of its own. The interesting engineering problem is not the swiping — it is that a real camera roll is mostly not on the device, and behaving correctly against a partially-resident, iCloud-backed library is where most of the work went.

Problem Solved

Camera rolls accumulate screenshots taken for a single piece of information — a confirmation number, a wifi password, a total owed — and then never get opened again. Browsing them is unrewarding enough that the backlog grows indefinitely. PixScan reduces the decision to one gesture per photo, and removes the reason to keep many of them at all by extracting the text first.

Target Users

Anyone with a years-old library — a way to make progress in short sessions, with position saved between them
People who screenshot as note-taking — receipts, confirmations and whiteboards become searchable text that outlives the image
Privacy-conscious users — no account, no server, and no network requests originating from the app

Key Features

Four-direction triage

Swipe right to keep, left to delete, up or down to extract text before deciding. Double tap undoes the last decision, and a long press opens the photo full screen with pinch-to-zoom.

Deletion you confirm, not deletion that happens

Swiping left marks a photo rather than deleting it. Deletion runs as a batch through PHPhotoLibrary.performChanges, so iOS presents its own confirmation and the photos remain recoverable in Recently Deleted for 30 days. The queue shows how much space the batch will reclaim before anything is committed.

A searchable text library

Every extraction records the photo it came from and shows its thumbnail. Search highlights matches in place, entries sort by date or length, swipe actions are user-remappable, and the whole library exports as a .txt file.

Running totals

After a batch deletion, the app reports what that batch removed and what has been removed across the app's lifetime — photos deleted, space freed, photos reviewed and text extractions.

Usable without sight

The four decisions and undo are exposed as named accessibility actions, so the app's primary task is completable with VoiceOver, and addressable by name with Voice Control.

Technical Highlights

Modelling PhotoKit's result dictionary instead of discarding it

PHImageManager.requestImage reports its outcome through an info dictionary carrying degraded, in-cloud, cancelled and error flags. Collapsing that to a bare UIImage? makes four distinct outcomes indistinguishable, and under .opportunistic delivery — which invokes the handler more than once — a later nil silently overwrites an already-good image. ImageRequestResult in PhotoImageLoader.swift captures every flag, and the loader maps them onto an explicit state machine whose partial case means "we have something usable and could not get better". That case is what lets an offline device keep showing the cached thumbnail it genuinely has, instead of drawing an error over a perfectly good picture.

Making prefetch actually hit

PHCachingImageManager only serves a prefetched result when the target size, content mode and options of the live request match what the prefetch was primed with. Priming with options: nil while requesting with a configured object means every lookup misses, and the prefetch becomes pure cost. Both paths in PhotoViewModel.swift now build options from one factory, and the prefetch window is bounded and released as it slides rather than growing for the length of the session.

Measuring before destroying

Reporting freed space requires the size of assets that are about to stop existing. processBatchDeletion measures the batch to completion on a background queue before issuing the change request; an earlier version ran the two concurrently and the deletion regularly won, reporting zero bytes freed. Sizes come from AssetSizeReader, which probes for a KVC-only property through the Objective-C runtime before touching it — value(forKey:) raises an ObjC exception on a missing key, which Swift cannot catch, so the unguarded version would crash rather than degrade.

Giving a gesture-driven app a non-gesture path

Every decision routed exclusively through DragGesture, and VoiceOver consumes swipes for its own navigation, so the app's primary task could not be completed with it running. The photo card in ContentView.swift now exposes Keep, Delete, both extract variants and Undo as named accessibility actions that call the same handlers the gestures call, rather than a parallel implementation that would drift out of step.

Engineering Decisions

On-device recognition over a cloud OCR service

Constraint: The product's central claim is that photos never leave the device
Options: A hosted OCR API with better accuracy on hard inputs, or Apple's Vision framework
Choice: Vision, at .accurate with language correction
Why: A cloud call would require uploading the photo, which contradicts the reason to install the app. It also removes the entire surface of an API key, rate limits and an offline failure mode.

UserDefaults over Core Data or SwiftData

Constraint: The persisted data is a set of identifiers, a list of text entries and a small totals record
Options: A managed store with migrations, or JSON-encoded values in UserDefaults
Choice: UserDefaults, with debounced writes and a hand-written decoder
Why: There is no relational shape to model, so a database would add a migration surface without buying anything. The decoder matters more than the store: Swift's synthesised one requires every key to be present, so adding a stat in a later release would fail to decode and silently discard the user's history. Decoding field by field with defaults removes that failure mode.

Counting events rather than deriving them

Constraint: Lifetime totals cannot be computed from current state — the delete queue empties on success and reviewed photos are cleared by "Start Over"
Options: Derive from live state, or persist counters incremented at the point of each event
Choice: Persisted counters, decremented on undo
Why: Derivation under-reports permanently and was already doing so: the progress bar's "deleted" figure was reading the queue's length, so it reset to zero the moment the queue was emptied.

One view model rather than several

Constraint: Deck state, delete queue, extracted text and totals all interact — deleting affects the queue, the deck and the totals at once
Options: Split by feature, or a single observable object
Choice: A single PhotoViewModel
Why: Splitting would require the pieces to observe each other for every cross-cutting operation. At this size the coupling is the honest description of the domain, and the seams that matter for testing were introduced as protocols instead.

Frequently Asked Questions

What happens when a photo is not downloaded from iCloud?

The app shows real download progress rather than a blank frame. If the device is offline, requests refuse network access so PhotoKit fails immediately with a "not downloaded" state rather than blocking on a transfer that cannot succeed — and any locally cached thumbnail is still shown. When connectivity returns, failed requests re-issue on their own.

Does swiping left delete a photo immediately?

No. It marks the photo. Deletion happens when you confirm a batch, runs through PHPhotoLibrary.performChanges so iOS presents its own confirmation, and the photos go to Recently Deleted where they stay recoverable for 30 days.

Can the app be used with VoiceOver?

Yes. The photo card exposes Keep, Delete, Extract text and keep, Extract text and delete, and Undo as named actions in the rotor, and Voice Control can address them by name. The first-run walkthrough offers a skip when VoiceOver is running, since its practice step advances only once each gesture has been performed.

How accurate is the reported space saved?

Sizes come from a property that iOS exposes only through key-value coding. Where it is available the number is measured; where it is not, the app estimates from pixel count and prefixes the figure with ~. A total is only presented as exact when every contributing size was.

Why does extracted text keep a thumbnail of the source photo?

So an extraction can be traced back to what produced it. Entries record the asset identifier at extraction time and resolve it when the library is displayed. If the source photo was deleted the thumbnail is simply absent — the text survives the photo, which is the point.

What is the screenshots-only filter matching on?

The PhotoKit media subtype photoScreenshot, so it reflects how iOS itself classifies the asset rather than guessing from dimensions. Reviewed photos are tracked by identifier across both modes, so switching filters never re-presents something already decided.

Does the app work without a network connection?

Entirely, for anything already on the device. Text recognition is local, persistence is local, and there is no server to reach. The only thing a connection affects is fetching full-resolution photos that live in iCloud.

How is it tested?

118 unit tests under Swift Testing cover the model, persistence, size and contrast arithmetic, and the accessibility surface, with protocol seams standing in for PhotoKit and the photo library. 25 UI tests drive the real app, and a separate suite generates the App Store screenshots by walking the running app rather than assembling them by hand.

Tech Stack

Core Technologies

Category	Technology	Version	Why this choice
Language	Swift	5.0 mode, Xcode 26 toolchain	Native platform language; the app is entirely framework-bound
UI	SwiftUI	iOS 17.6+	Declarative gesture handling and accessibility actions come for free
Photo access	PhotoKit	iOS 17.6+	The only sanctioned way to read, cache and delete library assets
Text recognition	Vision	iOS 17.6+	Runs on-device, which is the product's core privacy claim
Reachability	Network	iOS 17.6+	`NWPathMonitor` decides whether an iCloud round-trip is worth attempting
Persistence	UserDefaults	Native	The data is a set, a list and a totals record; no relational shape to model

No third-party dependencies. Zero Swift Package Manager packages — everything is a system framework.

Frontend

Framework: SwiftUI throughout; the only UIKit surfaces are UIImage for decoded assets and a UIColor dynamic provider for interface-style-aware colours
State Management: @StateObject / @EnvironmentObject over a single ObservableObject, with a @MainActor loader object per rendered asset
Sharing and export: ShareLink and .fileExporter rather than bridging UIActivityViewController
Gestures: DragGesture, TapGesture(count: 2), LongPressGesture, MagnifyGesture
Accessibility: Named .accessibilityAction entries, accessibilityReduceMotion, accessibilityVoiceOverEnabled, Dynamic Type, and a WCAG AA colour palette resolved per interface style
Layout: GeometryReader for size-dependent image requests

Platform

Target: iPhone only (TARGETED_DEVICE_FAMILY = 1), portrait
Deployment target: iOS 17.6
Distribution: App Store, signed with automatic provisioning
Privacy manifest: PrivacyInfo.xcprivacy, declaring UserDefaults access and no tracking

Infrastructure

Hosting: Native iOS app; no backend of any kind
Marketing site: Static HTML on Vercel, carrying the privacy policy the App Store requires to be publicly reachable
CI/CD: xcodebuild archive, export, validate and upload driven by an App Store Connect API key
Monitoring: None. No analytics, no crash reporting, no network requests of the app's own

Development Tools

IDE: Xcode 26
Unit testing: Swift Testing (@Test, #expect, @Suite(.serialized)) — 118 tests
UI testing: XCUITest with conditional skips — 25 tests, plus a suite that regenerates App Store screenshots by driving the real app
Screenshot generation: Headless Chrome rendering HTML canvases at App Store dimensions, so marketing layout stays editable text rather than a flattened image

Key Dependencies

All system frameworks; the table records what each is actually load-bearing for.

Framework	Purpose
`Photos` / `PhotosUI`	Asset fetching, `PHCachingImageManager` prefetch, change observation, batch deletion
`Vision`	`VNRecognizeTextRequest` at `.accurate` with language correction
`Network`	`NWPathMonitor` reachability, gating network access on image requests
`SwiftUI`	Entire UI, gesture and accessibility layer
`UniformTypeIdentifiers`	`FileDocument` conformance for `.txt` export
`StoreKit`	`SKStoreReviewController` review prompt after sustained use

Architecture

System Diagram

flowchart TD
    subgraph Entry
        APP[Photo_HelperApp]
        OB[OnboardingView]
    end

    subgraph Screens["Screens"]
        CV[ContentView]
        DQ[DeleteQueueView]
        OCRN[OCRNotesView]
        SUM[DeletionSummaryView]
        ABOUT[AboutView]
        FSPV[FullScreenPhotoView]
    end

    subgraph Imaging["Image pipeline"]
        LOADER[PhotoImageLoader]
        PIV[PhotoImageView]
        CARD[PhotoCard]
        THUMB[PhotoThumbnail]
        PREV[PhotoPreview]
    end

    subgraph Model["State"]
        PVM[PhotoViewModel]
        STATS[LifetimeStats]
        SIZE[AssetSize / AssetSizeReader]
    end

    subgraph Platform["System frameworks"]
        PK[(PhotoKit)]
        VIS[(Vision)]
        NET[(Network)]
        UD[(UserDefaults)]
    end

    APP -->|first launch| OB
    APP --> CV
    CV --> DQ & OCRN & ABOUT & CARD
    DQ --> SUM
    CARD --> PIV & FSPV
    THUMB --> PIV
    PREV --> PIV
    PIV --> LOADER
    FSPV --> LOADER
    LOADER --> PVM
    PVM --> PK & VIS & UD
    PVM --> STATS & SIZE
    NET -->|reachability| PVM
    DQ --> SIZE

Component Descriptions

PhotoViewModel

Purpose: Single source of truth for the photo deck, delete queue, extracted text and lifetime totals
Location: PixScan/PhotoViewModel.swift
Key responsibilities: Fetching and observing the photo library, issuing image requests, running text recognition, performing batch deletion, and persisting everything to UserDefaults

PhotoImageLoader

Purpose: Owns the request/cancel/retry lifecycle for one asset and models what PhotoKit is actually telling us
Location: PixScan/PhotoImageLoader.swift
Key responsibilities: Translating PhotoKit's result dictionary into an explicit state (loading, loaded, partial, failed), surfacing iCloud download progress, and re-requesting automatically when connectivity returns

PhotoImageView

Purpose: The one place an asset gets rendered, with placeholder, progress and failure chrome
Location: PixScan/PhotoImageView.swift
Key responsibilities: Rendering loader state at the right scale for its slot, and converting point sizes to the pixel target sizes PhotoKit expects

AssetSizeReader

Purpose: Byte sizes for photos, with an explicit measured-or-estimated flag
Location: PixScan/AssetSize.swift
Key responsibilities: Probing for a KVC-only size property through the Objective-C runtime before using it, and falling back to a pixel-count estimate when it is unavailable

LifetimeStats

Purpose: Running totals that survive resets and sessions
Location: PixScan/LifetimeStats.swift
Key responsibilities: Accumulating photos deleted, bytes freed, photos reviewed and text extractions, and decoding tolerantly so new fields cannot invalidate old records

NetworkMonitor

Purpose: Process-wide connectivity signal
Location: PixScan/NetworkMonitor.swift
Key responsibilities: Publishing reachability changes so image requests can refuse network access when offline and retry when it returns

Data Flow

The user swipes a photo card, or triggers the same decision through a VoiceOver action
ContentView routes the decision to one of four handlers on PhotoViewModel
Keep and delete mark the photo as reviewed; up and down first request a full-resolution image and run VNRecognizeTextRequest against it
Deletions accumulate in a queue rather than executing, and the user confirms the batch
Sizes are measured before the change request runs, because afterwards the assets no longer exist
PHPhotoLibrary.performChanges performs the deletion, iOS presents its own confirmation, and totals are folded into LifetimeStats

External Integrations

Service	Purpose	Notes
PhotoKit	Read, cache and delete photos	Deletion routed through `performChanges`, so iOS owns the confirmation and photos remain recoverable for 30 days
Vision	On-device text recognition	`.accurate` level with language correction; no network involved
Network framework	Reachability	Used to decide whether an iCloud round-trip is worth attempting
UserDefaults	Persistence	Small, structured records; no database dependency

Key Architectural Decisions

Model PhotoKit's result dictionary instead of collapsing it to an optional

Context: requestImage reports its outcome through an info dictionary carrying degraded, in-cloud, cancelled and error flags. Discarding it leaves an UIImage? that cannot distinguish "still loading" from "failed" from "cancelled".
Decision: ImageRequestResult captures every flag, and PhotoImageLoader maps them to an explicit state machine including a partial case for "we have something usable but could not get better".
Rationale: The alternative — treating any nil as failure — produces the exact bugs it looks like it avoids: a late nil overwrites a good thumbnail, and an offline device that does hold a cached thumbnail shows an error over a perfectly usable image.

Count events where they happen, not by deriving them from state

Context: Lifetime totals cannot be computed from the current model. The delete queue empties on success, and reviewed photos are cleared by "Start Over".
Decision: Increment persisted counters at the moment of the event, and decrement the review count on undo.
Rationale: Deriving from live state under-reports permanently. Decrementing on undo costs one branch and prevents re-swiping an undone photo from inflating the figure.

Give the primary interaction a non-gesture path

Context: Every decision was reachable only through DragGesture, and VoiceOver consumes swipes for its own navigation, so the app's primary task was impossible with it enabled.
Decision: Expose the four decisions and undo as named accessibility actions that call the same handlers the gestures call.
Rationale: A parallel implementation would drift. Routing both paths through one set of handlers keeps them identical by construction, and Voice Control gets addressable names for free.

Guard a KVC-only property behind a runtime probe

Context: A photo's byte size is only reachable through key-value coding on a non-public property. value(forKey:) raises an Objective-C exception when the key is absent, and Swift cannot catch those.
Decision: Probe once with instancesRespond(to:) and fall back to a pixel-count estimate, surfacing estimates with a ~ prefix.
Rationale: An as? cast handles a wrong-typed return but not a missing key, so the naive version would crash rather than degrade. The flag also stops an estimate being presented as a measurement on a screen that drives a destructive decision.

Persist with UserDefaults rather than a database

Context: The app stores a set of identifiers, a list of text entries, and a small totals record.
Decision: JSON-encoded values in UserDefaults, with debounced writes and a hand-written decoder that tolerates missing keys.
Rationale: Core Data or SwiftData would add a migration surface for data that has no relational shape. The hand-written decoder matters more than the store: Swift's synthesised one requires every key, so adding a field in a later release would fail to decode and silently discard a user's history.

Back to All Projects