DEV Community: Todd Sullivan

The iOS 26 Deep-Link Bug That Only Happened When the App Was Already Open

Todd Sullivan — Tue, 02 Jun 2026 08:04:23 +0000

I spent a chunk of this week chasing a bug that looked like auth, then routing, then Supabase, then Expo Router.

Actual root cause: iOS 26 was receiving the magic link, but the running app never got the warm-start URL in JavaScript.

Cold start worked:

app not running
tap myapp://auth/callback?code=...
iOS launches the app
Expo Router mounts auth/callback
PKCE code exchange succeeds

Warm start failed:

app already open
tap the same magic link
app comes foreground
no JS Linking event
user is still logged out

No crash. No useful exception. Just a login flow that works from killed state and fails from running state, which is exactly the kind of mobile bug that eats a day.

The Native Part: SceneDelegate Still Matters

On iOS 26, warm-start URLs are delivered through the scene lifecycle:

func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
  for context in URLContexts {
    forwardURL(context.url)
  }
}

The Expo app already had an AppDelegate, but warm-start delivery needed a UIWindowSceneDelegate as well. The slightly non-obvious bit was how to forward the URL.

Calling RCTLinkingManager directly looked reasonable, but it only posts the React Native URL notification. expo-linking was not listening to that path in this app. Routing through AppDelegate.application(_:open:options:) let ExpoAppDelegate forward the URL to all of its subscribers, including Expo's linking module:

private func forwardURL(_ url: URL) {
  let app = UIApplication.shared
  if let appDelegate = app.delegate as? AppDelegate {
    _ = appDelegate.application(app, open: url, options: [:])
  } else {
    RCTLinkingManager.application(app, open: url, options: [:])
  }
}

That got the URL into JS.

Then iOS 26 added one more trap.

The Key Window Trap

The system log had the clue: key window is null.

The app creates its UIWindow in didFinishLaunchingWithOptions, before the UIWindowScene exists. startReactNative calls makeKeyAndVisible(), but at that point the window is not attached to a scene yet.

On iOS 26, that meant scene:openURLContexts: never fired for warm-start links.

The fix was to associate the existing window with the scene and call makeKeyAndVisible() again after windowScene is set:

func scene(
  _ scene: UIScene,
  willConnectTo session: UISceneSession,
  options connectionOptions: UIScene.ConnectionOptions
) {
  guard let windowScene = scene as? UIWindowScene else { return }

  if let appDelegate = UIApplication.shared.delegate as? AppDelegate,
     let window = appDelegate.window {
    window.windowScene = windowScene
    window.makeKeyAndVisible()
  }
}

After that, scene:openURLContexts: fired reliably. Verified on the iOS 26 simulator: native SceneDelegate log, AppDelegate openURL log, then the JS linking handler.

The JS Part: Don't Route During Foreground Animation

Once the URL reached JS, the first instinct was to navigate to /auth/callback and let that screen do the exchange.

That was fragile for two reasons.

First, during warm start the app is still moving through UISceneActivationStateForegroundInactive. I saw the URL arrive at 10:56:09.749; foreground transition finished at 10:56:10.140. Navigation commands during that window can be silently dropped.

Second, auth/callback may already be mounted. A useEffect([]) on that screen will not re-run just because another link arrived.

So I moved warm-start exchange into the always-mounted root layout:

const linkSub = Linking.addEventListener("url", ({ url }) => {
  const parsed = Linking.parse(url);
  const code = typeof parsed.queryParams?.code === "string"
    ? parsed.queryParams.code
    : null;

  if (code) {
    supabase.auth.exchangeCodeForSession(code).catch(() => {});

    const unsub = useAuthStore.subscribe(({ session, signingIn }) => {
      if (session && !signingIn) {
        unsub();
        router.replace("/");
      }
    });

    setTimeout(unsub, 30_000);
  }
});

The important part is the split:

native code guarantees warm-start URLs reach Expo linking
root layout handles every warm-start URL event
auth callback remains as the cold-start/race fallback
navigation waits until the auth store has a settled session

The Takeaway

Deep links are not one flow. They are at least two:

cold start: launch app into a URL
warm start: deliver URL into an already-running app

If you only test the cold path, your auth flow can look perfect while the common real-world case is broken.

For Expo + React Native apps on newer iOS versions, I now treat warm-start deep links as their own integration test: app open, link tapped, native URL delivery observed, JS Linking event observed, auth state settled, navigation after state settle.

That is more ceremony than a one-line Linking.addEventListener, but it is the difference between a demo login flow and a production one.

Source: Recent Expo / React Native auth work: iOS 26 warm-start deep-link fix, SceneDelegate URL forwarding, PKCE exchange moved to root layout.
Tags: ios, reactnative, devops, javascript

The Silent Code Path: When Your AI Runs on Camera But Not on Gallery

Todd Sullivan — Fri, 29 May 2026 08:17:16 +0000

Here's a bug that's easy to miss and harder to debug: your AI runs perfectly on one input path, silently does nothing on another, and there's no error — just missing results.

I hit this recently in an on-device inspection app. The flow is straightforward: capture a photo (camera or photo library), run AI hazard detection, overlay bounding boxes, trigger violation alerts if needed.

Camera captures worked great. Gallery picks saved the photo fine. But no bounding boxes appeared, no alerts fired. The AI was just... not running.

What Actually Happened

Here's the stripped-down structure:

// Camera capture handler
const handleRequestCapture = async (uri: string) => {
  await savePhoto(uri);
  await detectAndSave(uri);   // ✅ AI runs
  checkViolationAlerts();
};

// Library pick handler  
const handleLibraryPick = async (uri: string) => {
  await savePhoto(uri);
  // ❌ detectAndSave was never called
};

The library path was added later, modelled on the save logic but not the full inference pipeline. No crash. No warning. Just missing detections.

The fix was six lines — copy the detectAndSave + alert block into the library handler. But finding it took longer than writing the fix.

Why This Pattern Is Easy To Ship

On-device AI inference tends to get wired in during the happy path. You build the camera flow first, the AI gets integrated there, everything works in demos. Then you add the gallery pick as a "nice to have" — and because you're only thinking about the file I/O, you copy the save logic but not the inference call.

There's no type error. No lint warning. The function name (handleLibraryPick) doesn't imply inference should happen. The photo saves successfully, so from the app's perspective, nothing broke.

Lessons From The Fix

1. Treat every input path as a first-class citizen.
If AI inference is core to your feature, it should run regardless of how the image arrived. Camera, gallery, deep link, background upload — all of them.

2. Extract inference into a shared pipeline.
After the fix I refactored toward a single processPhoto(uri) function that both handlers call. Now if the pipeline changes, it changes in one place.

const processPhoto = async (uri: string) => {
  await savePhoto(uri);
  await detectAndSave(uri);
  checkViolationAlerts();
};

const handleRequestCapture = (uri: string) => processPhoto(uri);
const handleLibraryPick = (uri: string) => processPhoto(uri);

3. End-to-end tests that cover input variants.
Unit tests on detectAndSave wouldn't have caught this — the function worked fine, it just wasn't being called. What you need is an integration test that exercises each entry point and asserts that inference results exist.

4. Visibility into what ran.
This is the sneaky part: when AI silently doesn't run, you need observability to know it happened. Adding a log line (AI inference: skipped | ran on <uri>) to your inference call sites makes this class of bug immediately obvious in development.

The Broader Pattern

This isn't unique to AI. Any side-effect that only gets wired to one code path — analytics events, permission checks, cache invalidation — can silently miss inputs added later. But with AI inference it's particularly painful because the failure mode is invisible and the debugging surface is narrow (you're looking at model output, not a thrown error).

Build the pipeline once, call it everywhere.

Wrapping Apple's LiDAR Room Scanner as a Native Expo Module

Todd Sullivan — Wed, 27 May 2026 08:08:52 +0000

Most property and field-service apps still ask users to manually enter room dimensions. Tape measure, pen, back to the app, mistype, repeat. It's tedious and it's lossy.

I've been building a property inspection app and this week I shipped a feature that replaces manual floor-area entry with a LiDAR scan. Walk around a room for 30 seconds, hit Done — the app returns floor area, wall count, door count, window dimensions, and a confidence score for each surface. No internet connection required. No server round-trips. All on-device.

Here's how I wired Apple's RoomPlan framework into a React Native / Expo app as a native module.

The Basic Idea

Apple's RoomPlan framework uses the LiDAR sensor on iPhone 12 Pro and later to build a structured 3D model of a room in real time. It gives you back typed objects: floors, walls, doors, windows — each with dimensions and a confidence rating (high, medium, low).

The challenge is surfacing this in a cross-platform Expo app without hacking around the JS/native boundary.

Building the Module

Expo's native module API makes this cleaner than the old React Native bridge approach. The module exposes two functions:

isAvailable() — synchronous check, returns true on LiDAR + iOS 17+
scanRoom() — async, presents a full-screen capture UI and resolves with structured results

AsyncFunction("scanRoom") { (promise: Promise) in
  guard RoomCaptureSession.isSupported else {
    promise.reject("UNSUPPORTED", "Requires a LiDAR-equipped device")
    return
  }
  // present RoomCaptureViewController...
}

The view controller runs captureSession.run(configuration:), delegates back through RoomCaptureSessionDelegate, and when the user hits Done it hands raw CapturedRoomData to RoomBuilder. The builder does a cleanup pass (with .beautifyObjects) and returns a CapturedRoom.

What Comes Back

let floorArea = room.floors
  .map { Double($0.dimensions.x) * Double($0.dimensions.y) }
  .reduce(0, +)

I map the result into a plain dictionary — area in m², per-surface dimensions, confidence string — and resolve the Expo promise. The JS side gets a typed object:

const result = await RoomPlan.scanRoom();
console.log(result.floorAreaM2); // e.g. 18.34
console.log(result.floors[0].confidence); // "high"

Graceful Degradation

Non-LiDAR devices get isAvailable() → false and fall through to a manual input form. No crashes, no confusing errors. The LiDAR path is an enhancement, not a hard dependency.

Why On-Device Matters Here

For property data, sending floor plans to a cloud service introduces latency, cost, and privacy concerns. Every scan happening fully on-device means no API bills per-scan, no waiting on a round-trip, and no floor plan leaving the phone until the user explicitly submits their report.

The practical result: floor area capture went from ~3 minutes (manual) to under 60 seconds with better accuracy than tape-measure entry. On iPhone Pro hardware, LiDAR readings are accurate to within a few centimetres on a normal rectangular room.

The Limitation Worth Knowing

RoomPlan requires a LiDAR sensor — iPhone 12 Pro and later, or iPad Pro. Most fieldwork happens on phones. For a consumer app targeting everyone, you need a fallback. For a professional tool where you control (or specify) the hardware, worth requiring it outright.

If you're building anything involving physical space measurement on iOS, RoomPlan is dramatically underused. Apple ships a full structured-capture pipeline and most apps still ask users to type numbers into a form.

When Your On-Device Model Decides How Often to Ping You

Todd Sullivan — Mon, 25 May 2026 08:03:36 +0000

Most notification systems are dumb. They fire on a fixed schedule decided by a developer who's never met the user. Every day at 9am. No matter what.

I've been building an iOS health app that does something different: the on-device ML model's training state drives notification frequency. The more the model knows about you, the less it needs to ask.

The Problem With Fixed Schedules

For a health tracking app, consistent data collection is everything — it's the training set. Early on, you need daily check-ins to bootstrap the model. But once the model is trained and the user has established patterns, daily prompts become noise. People turn off notifications. You lose signal entirely.

The naive fix is "let users choose their own frequency." That works until users pick "weekly" in week one when the model is still blind.

The better fix: make the frequency a function of the data itself.

The Logic

I built a NotificationFrequencyManager that recomputes check-in frequency after every engagement cycle and after every model training run. Three signals go in:

Data volume — how many days of logs exist
Logging consistency — what percentage of the last 14 days has at least one entry (≥70% threshold to step down)
ML training state — is the personalised model untrained, training, or trained?

The output maps to three frequencies:

enum NotificationFrequency: Int, Codable, Comparable {
    case high   = 1  // Daily — new users, untrained model
    case medium = 2  // Every 2 days — moderate data, some consistency
    case low    = 4  // Every 4 days — trained model, high consistency
}

There's a hard floor at 4 days. Even the most consistent user with a fully trained model gets nudged at least every 4 days. The model still needs new data to stay fresh. Silence would mean drift.

Closing the Loop

The clever part is that ML training completion directly triggers a frequency recalculation:

func update(logs: [DailyLog], trainingState: TrainingState) -> NotificationFrequency {
    let frequency = compute(logs: logs, trainingState: trainingState)
    currentFrequency = frequency
    storedFrequency = frequency  // persisted to App Group UserDefaults
    return frequency
}

So the flow is: user logs data → engagement manager runs → model retrains → frequency updates → next notification scheduled at new interval. The app literally quiets down as it learns.

Smooth Transitions

One thing I got wrong in early iterations: jumping straight from daily to every-4-days felt jarring in testing. The fix was requiring both consistency and data volume thresholds before stepping down. You can't hit low unless you've been on medium for at least a week.

// Only step from medium → low if model is trained AND consistency is high
if dataVolume >= 30 && consistency >= 0.7 && trainingState == .trained {
    return .low
}

Why This Matters

The insight generalises well beyond health apps. Any time you have an adaptive ML component, the model's confidence or training state is a signal you can use to drive other app behaviour. Frequency of prompts. Depth of UI. Whether to show explanations or trust the user already gets it.

The model knowing you means the app behaves differently for you. That's actually what "personalised AI" should mean — not just personalised outputs, but personalised interactions.

Training a Personalised ML Model On-Device with CreateMLComponents

Todd Sullivan — Fri, 22 May 2026 08:02:20 +0000

Most on-device AI content focuses on inference — you ship a pre-trained model in your app bundle and run it locally. That's well-covered ground. What's less talked about is training a personalised model on the device, from the user's own data, without any server involvement.

I built exactly that recently — a health tracking app that trains a flare risk predictor from each user's biometric history. Here's how it works and what I learned.

The Problem With Generic Models

Predicting health outcomes from biometrics is noisy. A drop in HRV means something different for a 25-year-old athlete than for someone tracking hormonal health. A universal model is mediocre for everyone. A personalised one, trained on your data, is actually useful.

The constraint: this data is sensitive. Shipping it to a server — even your own — is a non-starter for privacy-first health apps. So the model has to live and train on-device.

CreateMLComponents + CoreML

Apple's CreateMLComponents framework (iOS 16+) lets you train models programmatically at runtime. It's different from the Create ML app or the older MLDataTable APIs — it's composable, async, and designed for this kind of on-device training use case.

The core training loop is straightforward:

let regressor = LinearRegressor<Double>()
let fitted = try await regressor.fitted(to: examples)
try fitted.export(to: tempURL)
let compiled = try await MLModel.compileModel(at: tempURL)

examples is a sequence of AnnotatedFeature<MLShapedArray<Double>, Double> — features in, score out. The model trains in a background task, exports as an .mlpackage, compiles to a .mlmodelc, and gets saved to the App Group container so the widget can read it too.

Total training time on an iPhone: a few seconds for 30-90 days of daily logs.

Feature Engineering Matters More Than Model Choice

With limited data (30-90 rows), the model architecture barely matters. Feature quality does. A few things that made a difference:

Cyclical encoding for time. Day of week and cycle day aren't linear — day 7 is close to day 1, not far from it. Encoding them as sin/cos pairs prevents the model from treating time as an arbitrary number.

vec.cycleDaySin = sin(2 * .pi * Double(cycleDay) / 28.0)
vec.cycleDayCos = cos(2 * .pi * Double(cycleDay) / 28.0)

Delta features over raw values. Absolute HRV of 45ms might be fine for one person and low for another. But a 15% drop from your own 7-day rolling mean is meaningful regardless of baseline. I compute deltas for all continuous biometrics (HRV, resting HR, basal body temperature).

Log-normalise high-variance features. Step count varies by an order of magnitude — 800 steps on a sick day, 12,000 on an active one. Log normalisation keeps it from dominating the linear model.

The Confidence Gradient

New users have no data, so you can't run the model immediately. I handle this with a TrainingState enum:

enum TrainingState {
    case insufficient   // fewer than 30 days of data
    case idle
    case training
    case trained(Date)
    case fallback       // using rule-based scorer
}

Under 30 days, a rule-based fallback runs instead — simple thresholds on HRV, deep sleep, and resting HR. It's less accurate but honest about its limitations. The confidence label shown to the user goes from "Building" to "Moderate" to "High" as data accumulates.

Confidence is capped at a formula: min(1.0, 0.5 + (logCount - 30) / 120.0). You hit 100% confidence at 150 days of data. Honest and explainable.

Prediction to Notification Pipeline

Once the model runs, high-risk predictions trigger a local notification. No server involved at any stage — data never leaves the device:

DailyLog history -> FeatureVector -> MLModel.prediction() -> PredictionResult
-> WidgetKit reload + flare warning notification (if high risk)

The compiled model is stored in the App Group container so both the main app and the widget read the same model file.

What I'd Do Differently

Quantile regression instead of point estimates. A flare risk score with a confidence interval is more useful than a precise-sounding number.
Federated fine-tuning (for a population-level baseline, if needed later). Right now the model is purely individual — no shared signal at all.
More aggressive retrain scheduling. Currently retrains on app open when new logs exist. Background task scheduling would make it more consistent.

If you're building health or fitness apps that need personalised predictions and can't touch a server, CreateMLComponents is worth a serious look. The API is clean, async throughout, and the trained models drop straight into the standard CoreML inference path.

Running On-Device AI in a React Native App: Real-Time Hazard Detection with CoreML

Todd Sullivan — Wed, 20 May 2026 08:04:16 +0000

I've been building a field inspection app where the core differentiator is this: AI that works with zero internet. No cloud call, no latency, no "sorry, you're in a dead zone." The model runs on the device and that's the whole point.

This post is about shipping real-time on-device inference in a React Native (Expo) app — what the stack looks like, what actually tripped me up, and what the numbers look like so far.

The Setup

Safety inspection tool for construction sites. Inspectors walk a site, capture photos, and the AI flags PPE violations — missing hard hats, high-vis, etc. Construction sites often have zero connectivity. The AI has to work offline or it's useless.

Stack:

React Native / Expo SDK 52
CoreML for inference (iOS)
YOLOv8s converted to .mlpackage — under 50MB, bundled with the app
Swift Expo module wrapping the CoreML inference pipeline

The model is under 50MB — you can't ship a 400MB model and expect App Store approval or a sane user experience.

The Swift Module Bridge

The tricky part isn't CoreML inference itself — Apple's API is clean. The tricky part is bridging it into React Native without losing your mind.

I built a native Swift Expo module (PPEDetectorModule) that:

Loads the .mlpackage on init
Accepts a photo URI from JS
Runs synchronous inference and returns bounding boxes + confidence scores
Handles model load failures gracefully (falls back to "manual review required")

func detect(imageUri: String) -> [[String: Any]] {
    guard let model = detector,
          let image = CIImage(contentsOf: URL(string: imageUri)!) else {
        return []
    }
    let results = try? model.predict(image: image)
    return results?.map { box in
        ["label": box.label, "confidence": box.confidence,
         "x": box.rect.origin.x, "y": box.rect.origin.y,
         "width": box.rect.width, "height": box.rect.height]
    } ?? []
}

Results come back as plain JSON. The JS layer renders bounding boxes as an overlay using React Native's Animated + absolute positioning.

Real-Time Viewfinder Mode

Post-capture detection is useful but not magical. For the real "wow" moment I wanted live inference as the inspector points the camera — hazards flagged before the photo is even taken.

The camera screen runs inference every 750ms against the live feed. At 750ms you get ~1.3fps of AI updates — visually responsive without hammering the CPU.

useEffect(() => {
  const interval = setInterval(async () => {
    if (cameraRef.current && isDetecting) {
      const frame = await cameraRef.current.takePictureAsync({
        quality: 0.3, skipProcessing: true
      });
      const detections = await PPEDetectorModule.detect(frame.uri);
      setBoxes(detections);
    }
  }, 750);
  return () => clearInterval(interval);
}, [isDetecting]);

Quality 0.3 is intentional — inference accuracy doesn't need 12MP photos, and lower resolution dramatically cuts preprocessing time.

The Numbers (Sprint 2, iPhone 14 Pro)

Inference time (post-capture): ~280ms average
Viewfinder inference: ~320ms including frame capture overhead
Target SLA: <500ms — currently green ✅
Memory footprint: ~180MB at peak (well under 512MB budget)
Battery: Sprint 2 goal is <5% per shift — not fully measured yet

Model accuracy is the real open question. In simulator testing against construction site photos, hard-hat detection is solid. Field testing on actual sites is the Sprint 2 gate — target is 90%+ detection on hard-hat violations in real conditions.

Freemium Gate

Free tier gets 10 AI detections/month. This can't be bolted on after the fact — it has to be woven into the detection pipeline.

Every call to detectAndSave checks an entitlement store before firing inference. If the quota is hit, it emits a paywall event and the UI surfaces an upgrade prompt. RevenueCat handles the StoreKit 2 subscription state.

Lesson: build the gate into the data layer, not the UI layer. If you gate at the UI, someone will bypass it. Gate at the function that writes to your database.

What's Next

Tap-to-confirm UX for flagged hazards, App Store Connect subscription products, and the actual field test. Sprint 2 demo is at day 60 — success criteria is 90%+ hard-hat violation detection offline.

On-device AI is genuinely viable for production mobile apps right now. Models are small enough, hardware is fast enough, and the offline story is compelling in markets where connectivity is unreliable. If you're building in field service, construction, agriculture, or any domain where "no signal" is a real scenario — worth considering CoreML + a bundled model over a cloud API dependency.

On-Device AI for Construction Safety: Why I'm Skipping the Cloud Entirely

Todd Sullivan — Mon, 18 May 2026 08:02:04 +0000

I've been building a construction safety inspection app — GroundCheck — and from day one I made a decision that surprised a few people: no cloud AI. Every hazard detection runs on-device, offline, in under 50 MB.

Here's why that wasn't just a cost call — it was an engineering call.

The problem with cloud AI on a construction site

Construction sites are not Silicon Valley offices. Mid-size commercial builds — the beachhead market I'm targeting — often have patchy LTE at best, and active floors can be dead zones. A safety inspector can't pause a walkthrough because their hazard detection app is waiting on a round-trip to an API.

When I looked at the alternatives:

Cloud vision APIs — fast to build, $0.001–0.003/image at scale, but useless offline and creates a real liability question around who holds footage of an active construction site
On-device ML — more upfront work, but deterministic latency, zero connectivity dependency, and no data leaves the device

For safety tooling, determinism matters. If an inspector gets a false negative because the API timed out, that's not a UX bug — it's potentially a serious incident.

The model stack: keeping it under 50 MB

The target is YOLOv8s + MobileNetV3, combined under 50 MB. Here's why each choice:

YOLOv8s — the small variant sits around 22 MB as a CoreML model. Fast enough to run on-device without throttling the camera feed. The 's' variant trades some mAP against the nano (which would be faster but misses smaller objects — a real problem when you're detecting things like exposed rebar or missing PPE at distance).

MobileNetV3 — classification backbone for finer-grained scene understanding. Once YOLOv8s has found a detection region, MobileNetV3 does the heavy lifting on "is this person wearing a hard hat" vs. "is this person holding a hard hat." Two-stage pipeline, both on-device.

The total bundle target is <50 MB because that's the threshold where App Store cellular auto-download kicks in. Installers and safety managers shouldn't have to think about it.

Offline-first all the way down

The inspection flow is built on Drizzle ORM over expo-sqlite. Everything captures locally first — photos, GPS coordinates, hazard detections, inspection notes. A sync queue handles Supabase replication when connectivity returns.

This means the app works identically with zero bars as it does on a solid connection. Photo uploads are deferred, sync state is visible in the UI, and no part of the core inspection loop has a network dependency.

It's more upfront architecture work. But for a product that's supposed to replace $600/month SafetyCulture contracts, "it doesn't work if you're underground" isn't acceptable.

What I've learned so far

On-device AI is actually quite accessible now. CoreML tooling has matured significantly. Converting a YOLOv8 model to CoreML is mostly straightforward via coremltools; the sharp edges are around input preprocessing and getting confidence thresholds tuned for your domain (construction hazard detection ≠ COCO defaults).

Offline-first is a discipline, not a feature. It touches every layer — schema design, UI state, sync conflict resolution. You can't bolt it on after the fact. I scaffolded the sync queue before I wrote a single inspection screen.

The 50 MB budget forces good decisions. Model quantization, INT8 where it matters, careful layer pruning. Constraints produce better models than unlimited compute budgets.

If you're building for any domain where connectivity isn't guaranteed — field work, logistics, healthcare, agriculture — the on-device AI stack has never been more viable. The cloud-first assumption deserves to be challenged.

I Let Claude Code Do a Performance Review on My iOS App — Here's What It Found

Todd Sullivan — Fri, 15 May 2026 08:02:17 +0000

I've been building HerdCount — an offline-first iOS app that counts livestock from a photo using YOLOv8n on CoreML. No internet, no account, just the Neural Engine doing its thing.

The app was working, but after adding a share-card feature (a branded "proof of count" image you can send to buyers or vets), I noticed some jank. Tap Save and the UI would stutter. Scroll through results and frames would drop. Nothing catastrophic, but noticeable.

Instead of diving into Instruments myself, I dropped Claude Code into the repo with a performance review prompt and watched what happened.

What it was asked to do

Simple brief: review the codebase for iOS performance issues, particularly in the Result screen and inference path. No specific files called out, no hints. Just "here's the code, find what's slow."

What it found (and actually fixed)

1. Share card rendering on every SwiftUI body rebuild

The proof-of-count card — a UIGraphicsImageRenderer render of the annotated photo with branding — was being generated inside the view's state updates. Every time SwiftUI rebuilt the body (which it does a lot), it was re-running 300–500ms of image rendering work.

Fix: cache the rendered image in the ViewModel, keyed on the things that actually change (detections, count, label, notes). Only re-render when those values change. Obvious in retrospect. Easy to miss when you're building features.

2. Thumbnail generation blocking the main thread

Tapping Save triggered a thumbnail generation step before writing to SwiftData. That was happening synchronously on the main actor — hence the stutter on save.

Fix: Task.detached with pre-computed Data? handed off to the model layer, keeping UIKit on the main thread where it needs to be but doing the pixel work on a background thread.

3. Static formatters vs per-call allocation

DateFormatter and RelativeDateTimeFormatter were being instantiated per call in a few places — including inside the inference hot path. Each allocation is small, but in VisionService those run on every frame during detection.

Fix: promote to static properties. One allocation, reused forever.

4. Inference path allocations

In VisionService, the observation filtering was a filter followed by a map — two passes, two intermediate arrays per inference call. Collapsed to a single compactMap. In PresetCategory, label matching used an array literal (["dog", "cat", ...]) allocated on the heap each call. Replaced with || comparisons.

The PR

Claude committed all of this as a single structured PR with clear commit messages. The diff was clean, the explanations were accurate, and — importantly — it didn't make anything up. It found real issues, measured them correctly (citing the ms ranges from the actual rendering work), and fixed them without introducing regressions.

The follow-up commits were me fixing a crash it introduced by moving UIKit work off the main actor (classic async/await pitfall — it almost got it right) and a build error from curly quotes in a string literal. Two small misses out of a solid overall review.

The meta part

The app itself is an AI app — CoreML + Vision running YOLOv8n on the Neural Engine. I used an LLM to review and improve the code for an on-device ML app. There's something satisfying about that stack: AI tooling improving AI tooling.

More practically: this kind of review is exactly what Claude Code is good at. Pattern recognition across a codebase — "you're doing this expensive thing unnecessarily" — is tedious to do manually and easy to miss when you're close to the code. Having an external pass that doesn't know what you intended to write is genuinely useful.

The Instruments profiler would have found the same things eventually. But this was faster, and it wrote the fix too.

Tags: ios, swift, claudecode, ai, performance
Status: published
Source: herdcount-ios PR #1 (claude/performance-review)

HerdCount is Live on the App Store — From Blog Post to Shipped Product in Two Weeks

Todd Sullivan — Wed, 13 May 2026 10:31:32 +0000

Two weeks ago I wrote about building an offline-first livestock counter with YOLOv8 and CoreML. Today it's a real product on the App Store.

HerdCount — Count your flock, even offline

£3.99. No subscription. No cloud. No account. Pay once, use forever.

What It Does

Point your phone at livestock or plants. Tap a button. Get the count.

HerdCount uses on-device AI (YOLOv8 + CoreML) to detect and count chickens, sheep, cattle, and plants from a single photo — in under a second, with zero internet required.

Why I Built It

I work with on-device computer vision professionally — building Axsy Smart Vision, an AI-powered field inspection platform for Salesforce. Retail planogram detection, product identification, compliance scoring — all running on-device.

But the agricultural space has a simpler, more immediate problem: counting animals is tedious and error-prone. Farmers do it by eye, multiple times a day. Miss one sheep and you're searching hedgerows at dusk.

The same on-device ML pipeline I use for retail product detection works beautifully for livestock. So I built it.

The Technical Stack

YOLOv8 — trained on livestock datasets, converted to CoreML
On-device inference — runs on the iPhone's Neural Engine, no cloud round-trip
Offline-first — works in fields, barns, anywhere with no signal
Swift/SwiftUI — native iOS, 8.7 MB total
Export — CSV via AirDrop, email, or Files app

The model handles overlapping animals (tuned IoU threshold at 0.3 rather than the default 0.5) and lets you tap false positives to remove them. Manual +/− adjustment before saving.

What I Learned Shipping It

1. App Review is opinionated. Apple rejected the first submission because the category detection UI wasn't clear enough. Fair feedback — I redesigned it and it's better for it.

2. The model is the easy part. Training YOLOv8 and converting to CoreML took a weekend. The other 90% was UI polish, edge cases, CSV export formatting, and App Store screenshots.

3. Pricing matters. I went with £3.99 one-time purchase. No subscription, no ads, no data collection. Farmers are practical people — they'll pay for a tool that works but won't tolerate dark patterns.

4. On-device AI is a real differentiator. Every competing app I found requires internet. That's a non-starter for someone standing in a field in rural Wales.

From Blog to Product

The Dev.to post about the technical approach got genuine engagement — @gimi5555 asked about NMS strategies for clustered animals, which led to a good discussion about density estimation as a fallback.

That conversation validated the approach. Two weeks later, it's a shipped product.

If you're working with on-device ML and sitting on something useful — ship it. The App Store review process is less scary than it looks, and real users find real problems you'd never catch in development.

HerdCount on the App Store →

Built by RT Sullivan Consulting. I write about on-device AI, Salesforce field apps, and shipping real products at dev.to/toddsullivan.

Shipping to TestFlight Without Fastlane: Raw xcodebuild, Auto-Incrementing Builds, and One Neat Provisioning Trick

Todd Sullivan — Wed, 13 May 2026 08:01:59 +0000

Most iOS CI tutorials reach for Fastlane. It's the default assumption. And Fastlane is fine — but it's also another Ruby toolchain to maintain, another layer of abstraction between you and xcodebuild errors, and another thing that breaks when Xcode updates.

For a small side project, I wanted zero overhead. So I wrote a release script using plain xcodebuild and xcrun altool, and wired it into GitHub Actions. Here's what I learned.

The Setup

The app is a no-dependency iOS project (SwiftUI, SwiftData, zero SPM packages). One scheme, one target, distributes via the App Store. The goal: git push → trigger workflow → build, sign, upload to TestFlight.

Auto-incrementing build numbers for free:

BUILD_NUMBER="${1:-$(git -C "$REPO_ROOT" rev-list --count HEAD)}"

That's it. Every commit bumps the count. No build number file to commit, no race conditions in CI, no manual tracking. Pass it straight into xcodebuild:

xcodebuild archive \
  ...
  CURRENT_PROJECT_VERSION="$BUILD_NUMBER"

TestFlight requires monotonically increasing build numbers. Git commit count gives you that automatically. I've seen people use timestamps (too long), semver patch (manual), or a counter file in the repo (merge conflicts). Commit count is cleaner.

The Provisioning Problem — and the Fix

This is where most raw-xcodebuild scripts fall apart. The export step (xcodebuild -exportArchive) needs an ExportOptions.plist with the exact provisioning profile UUID. But the UUID changes every time you renew the profile.

The usual answer is "hardcode it in your plist and update manually." That's the kind of thing you forget for six months and then debug for two hours.

Better approach: extract the UUID from the archive you just built, then inject it at export time.

# Pull the embedded profile from the freshly-built archive
EMBEDDED="$ARCHIVE/Products/Applications/MyApp.app/embedded.mobileprovision"
PROFILE_UUID=$(security cms -D -i "$EMBEDDED" | plutil -extract UUID raw -)

# Copy it into the Provisioning Profiles directory (xcodebuild looks here)
cp -f "$EMBEDDED" "$HOME/Library/MobileDevice/Provisioning Profiles/$PROFILE_UUID.mobileprovision"

# Write a temp ExportOptions with the exact UUID from *this* archive
cp "$EXPORT_OPTIONS" "$EXPORT_OPTIONS_TMP"
plutil -replace "provisioningProfiles.com.example.myapp" \
  -string "$PROFILE_UUID" "$EXPORT_OPTIONS_TMP"

# Now export using that temp plist
xcodebuild -exportArchive \
  -archivePath "$ARCHIVE" \
  -exportPath "$EXPORT_DIR" \
  -exportOptionsPlist "$EXPORT_OPTIONS_TMP"

The profile UUID in your ExportOptions is always current, because it came from the archive itself. Renew the cert, re-download the profile, and nothing breaks.

GitHub Actions Signing

For CI, the certificate lives in a secret as a base64-encoded .p12. The workflow decodes it into a temporary keychain:

security create-keychain -p "$KEYCHAIN_PASS" build.keychain
security import /tmp/cert.p12 -k build.keychain -P "$P12_PASSWORD" \
  -T /usr/bin/codesign
security set-key-partition-list -S apple-tool:,apple: -s \
  -k "$KEYCHAIN_PASS" build.keychain

The -T /usr/bin/codesign flag is critical — without it, the keychain will prompt for a password interactively mid-build, which hangs CI forever. The set-key-partition-list step is what makes it work without prompts.

The Full Flow

workflow_dispatch
  → checkout (full depth for commit count)
  → import cert into ephemeral keychain
  → write App Store Connect API key
  → ./scripts/release.sh
      → xcodebuild archive
      → extract profile UUID from archive
      → inject UUID into ExportOptions
      → xcodebuild -exportArchive
      → xcrun altool --upload-app

About 8-12 minutes wall clock on a macos-26 runner. No Ruby, no gems, no Fastlane plugins.

When Fastlane Still Makes Sense

If you're managing multiple targets, schemes, environments, or a team with custom lanes — Fastlane earns its complexity. But for a single-target indie app? Raw xcodebuild is readable, debuggable, and requires no maintenance beyond "Xcode updated, did the flags change?"

The full script is about 70 lines of bash. That's the whole pipeline.

Building Personalised On-Device ML for Women's Health: No Cloud, No Population Averages

Todd Sullivan — Mon, 11 May 2026 13:22:24 +0000

Most health AI is built on population data. Your symptoms are averaged against thousands of other people, and you get a generalised prediction that fits nobody perfectly.

I took a different approach with Menopause Intelligence — an iOS app I've been building that predicts high-symptom days for women in perimenopause and menopause.

The entire model runs on-device, trained on the individual user's own data. No cloud, no population averages, no third-party data sharing.

The problem with cloud-based health AI

Population models work when you want average answers. But perimenopause is deeply individual. Two women with identical ages and similar symptom profiles can have completely different biometric triggers.

The app's job is to tell a user her patterns — not what typically happens to women like her.

The ML pipeline

Features: Seven signals per day, all from HealthKit/Apple Watch:

Basal body temperature delta vs 7-day mean
HRV (raw + delta from personal rolling average)
Sleep efficiency and deep sleep %
REM sleep %
Resting heart rate
Cycle day (if logged)

Key design decision: We use deltas from the user's personal baseline, not absolute values. A resting HR of 62 bpm means different things for different people. What matters is whether it's elevated for you.

Label: Composite symptom severity score for day D+1 (hot flashes, brain fog, fatigue, mood)

Model: CoreML + CreateML Components. Runs via a silent weekly background task (BGProcessingTask). The app retriggers training automatically as new data accumulates.

Cold start: The first 30 days use a rule-based weighted scorer as a fallback. Not as accurate, but keeps the app useful while data accumulates.

The data architecture

Everything is local:

HealthKit → DailyLog (SwiftData) → Feature engineering → CoreML inference

No backend. No analytics SDK. CloudKit sync between devices uses end-to-end encryption. Health data never touches our servers — because we don't have any.

This isn't just a privacy stance. It's architecturally simpler and removes a whole category of compliance risk. For a health app in this category, "no backend" is a feature you can market.

The feedback loop

User-reported symptoms feed back into the next training cycle. Every hot flash logged, every mood entry — they sharpen the model for that specific user.

This is the same feedback pattern I've used in other on-device vision work: user corrections become training data. The model gets more accurate over time for the individual, not just better at the general case.

What I've learned building personalised on-device ML

Minimum data is a real UX problem. 30 days before predictions activate feels long to a user who downloaded the app because she's struggling now. You have to be honest about why, and give her something useful in the meantime.

Baseline drift matters. A user's "normal" changes over the course of perimenopause. The rolling average window needs to adapt — a fixed 7-day mean becomes stale if someone's baseline HRV is trending down over months.

Privacy is the product. In women's health, trust is everything. "Your data never leaves your device" isn't a footnote — it's the headline. It changes the conversation with users who've been burned by other health apps.

The stack

UI: SwiftUI (iOS 17+)
Data: SwiftData + CloudKit
Biometrics: HealthKit
Prediction: CoreML + CreateML Components
Subscriptions: StoreKit 2
Watch: watchOS companion + WidgetKit

More on this as it gets closer to launch.

The Fastlane gym Export Options Trap (and Why Your Provisioning Profile Is Being Silently Ignored)

Todd Sullivan — Mon, 11 May 2026 08:01:51 +0000

Spent a few hours last week debugging a CI failure that had no right to be as subtle as it was. The build archived fine, but exportArchive kept dying with:

error: exportArchive: requires a provisioning profile with the App Groups feature.

The frustrating part: the AppStore provisioning profile was correct. I had just renewed it, decrypted it on the runner, and confirmed the App Group entitlement was in there. The keychain had it. So why was xcodebuild not finding it?

The Trap

The Fastlane gym action accepts export_options: in two forms:

A path to an existing .plist file
A Hash of options it will write to a temp plist

I was passing a Hash — and inside that Hash I had a plist: key pointing to my own plist file, thinking gym would merge or defer to it. It does not.

When you pass a Hash, gym writes that Hash to a temp plist and hands it directly to xcodebuild. The plist: key inside the Hash is not special — xcodebuild does not recognise it, ignores it silently, and you end up with a minimal plist that has no provisioningProfiles key at all.

The temp plist gym generated looked like this:

<dict>
  <key>method</key>
  <string>app-store</string>
  <key>uploadSymbols</key>
  <true/>
  <key>plist</key>
  <string>RELEASE_exportOptionsPlist_Store.plist</string>
</dict>

No provisioningProfiles. Under manual signing, xcodebuild fell back to automatic profile resolution at export time — which on a clean GitHub Actions runner cannot find the app-group-bearing profile you carefully installed. Build fails. Misleading error. Whole thing looks like a profile problem when the profile was never consulted.

The Fix

Pass export_options: as a path string, not a Hash:

gym(
  scheme: "MyApp",
  configuration: "Release",
  export_options: "./fastlane/RELEASE_exportOptionsPlist_Store.plist"
)

Your plist should include explicit provisioningProfiles:

<key>provisioningProfiles</key>
<dict>
  <key>com.example.myapp</key>
  <string>MyApp AppStore Profile</string>
</dict>

Gym passes the path straight to xcodebuild -exportOptionsPlist. Your file is read. No temp plist, no silent key stripping.

Why This Catches People Out

The Hash form is in basically every Fastlane tutorial. It looks clean. Gym does not warn you when it discards unrecognised keys. The only signal is in verbose gym output — if you compare the temp plist it writes against what you expected, the provisioningProfiles block is missing.

App Groups make the failure mode worse because they require an exact profile match. Without entitlements like App Groups, xcodebuild automatic selection might accidentally find something usable. With App Groups, it always fails hard.

What I Do Now

For any iOS app with entitlements — App Groups, Push Notifications, iCloud, anything — I keep an explicit export_options.plist checked into the repo and pass it as a path. The Hash form is fine for a basic app. The moment signing gets complicated, you want the plist under version control and gym out of the business of generating it.

One less thing the CI runner has to figure out on its own.