DEV Community: Amol Srivastava

iCloud Key-Value Store vs CloudKit: A Decision Guide for Solo iOS Developers

Amol Srivastava — Fri, 28 Aug 2026 15:00:00 +0000

Every local-first iOS app eventually hits the same question: the user has the app on their phone and their iPad, and they want their data on both. Apple gives you two very different tools for this, and picking the wrong one costs you a rewrite. Here's the actual decision, stripped of marketing language.

NSUbiquitousKeyValueStore: for settings, not data

NSUbiquitousKeyValueStore is the iCloud equivalent of UserDefaults — a small, syncing key-value dictionary, capped at 1MB total and 1024 keys. It syncs automatically, requires almost no setup beyond enabling the iCloud capability, and has no query API because it isn't a database. You get a dictionary that happens to sync.

let store = NSUbiquitousKeyValueStore.default
store.set(true, forKey: "hasSeenOnboarding")
store.synchronize()

This is the right tool when what you're syncing is small, singular, and doesn't need to be queried — feature flags, a selected theme, the last-viewed tab, a handful of user preferences. It is emphatically the wrong tool the moment you're tempted to store an array of user-created objects in it, even a short one, because you'll hit the size ceiling faster than you expect and you'll have no way to sync partial updates — every write replaces the whole value for that key.

CloudKit: for actual data

CloudKit is a real database — records, record types, queries, relationships, subscriptions for push-based sync, and a private database scoped per user with no server code required on your end. The setup cost is real: you're defining a schema, thinking about CKRecord conflict resolution, and probably reaching for NSPersistentCloudKitContainer if you want Core Data to handle the sync plumbing for you.

let container = NSPersistentCloudKitContainer(name: "Model")
container.loadPersistentStores { _, error in
    if let error { fatalError("Unresolved error \(error)") }
}

This is the right tool the moment your data has more than one instance of anything — a list of items, notes, sessions, whatever your app's core object is. It's also the right tool if you need the data to survive a reinstall or show up on a second device without the user manually re-entering it.

The decision in one line

If you can describe what you're syncing as "a value," reach for NSUbiquitousKeyValueStore. If you'd describe it as "records" or "a list," reach for CloudKit. Don't let CloudKit's setup overhead push you toward cramming real data into the key-value store — the 1MB ceiling and lack of conflict resolution at the field level will bite you later, usually right when a user has enough data in the app for it to actually matter. Pick based on shape, not based on which one sounds like less work today.

StoreKit 2 for Solo Developers: Subscription Patterns That Don't Need a Backend

Amol Srivastava — Thu, 27 Aug 2026 15:00:00 +0000

Apple's StoreKit 2 examples tend to be written for teams that have a backend to validate receipts against and a server-side subscription-status source of truth. If you're a solo developer shipping a handful of small apps, that entire layer is usually unnecessary — StoreKit 2 was designed to let the client be the source of truth safely, and most of the "just use RevenueCat" advice skips over how solid the built-in tools actually are once you understand them.

Transaction.currentEntitlements is the whole trick

The single most useful API in StoreKit 2 is Transaction.currentEntitlements, an async sequence that yields every transaction the current user has an active, unexpired entitlement for — already verified, already deduplicated across devices via App Store server state. You don't reconstruct subscription status from a purchase event you cached; you just ask the App Store what's currently true.

func currentSubscriptionStatus() async -> Bool {
    for await result in Transaction.currentEntitlements {
        guard case .verified(let transaction) = result else { continue }
        if transaction.productID == "com.example.pro.monthly" {
            return true
        }
    }
    return false
}

Call this on launch and whenever you need a fresh read — it's cheap, it's local where possible, and it already accounts for expiration, refunds, and family sharing without you writing any of that logic yourself.

Listen for transaction updates, don't poll

Alongside currentEntitlements, StoreKit 2 gives you Transaction.updates, a long-lived async sequence that fires whenever a transaction changes state — a renewal, a refund, a family-sharing grant, a purchase made on another device. Start listening for this as early as possible, ideally before your first UI even renders, so you never miss a state change that happens while your app is in the background.

let updateTask = Task.detached {
    for await result in Transaction.updates {
        guard case .verified(let transaction) = result else { continue }
        await transaction.finish()
        await refreshEntitlements()
    }
}

This listener is also where refunds show up. A support ticket like "I was charged but the app still says I'm not subscribed" almost always turns out to be a missed transaction update rather than a StoreKit bug — the fix is making sure this task is alive for the entire lifetime of the app, not just while a particular screen is on screen.

Offer codes and introductory pricing don't need a promo server

For solo apps running occasional discounts, it's tempting to reach for a server that mints signed promotional offers. For most cases you don't need one — App Store Connect lets you create offer codes directly, generate redeemable links, and StoreKit's own .redeemCodes() presentation handles the whole flow through Apple's UI. You get the discount logic, the redemption UI, and the fraud prevention for free, and your app never sees a raw price or discount percentage it has to enforce itself.

The pattern across all of this is the same one that shows up everywhere in local-first iOS development: the platform already solved the hard, security-sensitive part of the problem. The job left for you is reading its state correctly and reacting to it — not rebuilding a smaller, buggier version of App Store server infrastructure on your own backend.

Building Home Screen Widgets Without a Backend: A WidgetKit Field Guide

Amol Srivastava — Wed, 26 Aug 2026 15:00:00 +0000

WidgetKit is one of the more deceptively simple frameworks Apple ships. The sample code makes it look like you just declare a TimelineProvider, return some entries, and you're done. The reality, once you're building a widget that has to be useful and not just a demo, is a lot more interesting — mostly because a widget process is not your app process, and everything about how you architect data has to respect that.

The widget extension is a stranger to your app

A widget extension runs out-of-process from your main app. It doesn't share memory, it doesn't share your ObservableObjects, and it has a much stricter memory ceiling than your app does — a few tens of megabytes before the system kills it. This means the first design decision on any widget project isn't "what does it look like," it's "how does data get from the app to the extension without a server in between."

For anything local-first, the answer is almost always an App Group. You configure a shared container, both targets get access to it, and you write to it from the app and read from it in the extension:

let store = UserDefaults(suiteName: "group.com.example.myapp")
store?.set(encodedSnapshot, forKey: "widgetSnapshot")

The snapshot should be small and pre-computed. Don't hand the widget your entire model graph and expect it to compute a summary — do the summarizing in the app, where you have memory and time to spare, and hand the widget exactly the bytes it needs to render.

Timelines are a scheduling problem, not a data problem

The part that trips people up is TimelineProvider.getTimeline. It's tempting to think of it as "fetch the current data," but it's actually "describe the next N states of the world and when each one becomes current." If your widget shows a countdown, you don't refresh every minute — you generate entries for every relevant minute up front and let the system swap them in on schedule, all without waking your process again.

func getTimeline(in context: Context, completion: @escaping (Timeline<Entry>) -> Void) {
    let now = Date()
    let entries = (0..<60).map { minuteOffset in
        Entry(date: Calendar.current.date(byAdding: .minute, value: minuteOffset, to: now)!)
    }
    completion(Timeline(entries: entries, policy: .after(entries.last!.date)))
}

This reframing matters because widget refresh budget is a scarce, system-managed resource. iOS decides how often your extension actually gets to run based on how often the user looks at the widget, battery state, and a bunch of heuristics you don't get to see. Front-loading state changes into a single timeline computation works with that constraint instead of fighting it.

Deep links are the only "interaction" you really get

Widgets aren't fully interactive in the way a normal view is — even with the newer interactive widget APIs, most of what you're building is still "tap here to open the app to this exact place." Design the widget's tap targets around widgetURL or Link destinations that map to specific in-app states, and make sure your app's URL handling can reconstruct that state without a network round trip:

.widgetURL(URL(string: "myapp://item/\(entry.itemID)"))

The apps that get widgets right treat them as a second, constrained rendering surface for state that already exists locally — not a new feature that needs its own backend, its own sync layer, or its own source of truth. Once the shared container and the timeline are right, the actual SwiftUI view code is the easy 20%.

Building a Reliable Text-to-Speech Experience with AVSpeechSynthesizer

Amol Srivastava — Tue, 25 Aug 2026 15:00:00 +0000

AVSpeechSynthesizer looks trivial from the API surface — instantiate an utterance, hand it to a synthesizer, done. It stays trivial right up until you ship it in a real app with a real UI around it: a pause button that doesn't pause, a voice picker with two hundred entries and no obvious default, a rate slider whose numbers mean nothing to a user. The gap between the demo and a good implementation is entirely in the details nobody puts in the "hello world."

The three lines everyone starts with

import AVFoundation

let synthesizer = AVSpeechSynthesizer()
let utterance = AVSpeechUtterance(string: "Text goes here")
synthesizer.speak(utterance)

This works. It's also missing every control a real feature needs: voice selection, rate, pitch, and any way to know when speech starts or finishes.

Picking a voice that isn't arbitrary

AVSpeechSynthesisVoice.speechVoices() returns every installed voice on the device — on a modern iPhone, that's often 50 or more once you count every language and variant. Don't default to the first one in the array; it's not sorted meaningfully. Default to the voice matching the user's actual device language:

func defaultVoice() -> AVSpeechSynthesisVoice? {
    let preferredLanguage = Locale.preferredLanguages.first ?? "en-US"
    return AVSpeechSynthesisVoice(language: preferredLanguage)
        ?? AVSpeechSynthesisVoice(language: "en-US")
}

If you're exposing voice choice in your UI, group by language first, then let users pick a specific voice within their language — a flat alphabetical list of fifty voice names is not a feature, it's a wall of text.

Rate and pitch: use the constants, not raw guesses

let utterance = AVSpeechUtterance(string: text)
utterance.voice = defaultVoice()
utterance.rate = AVSpeechUtteranceDefaultSpeechRate // not a raw Float you guessed at
utterance.pitchMultiplier = 1.0 // range is 0.5 to 2.0
utterance.preUtteranceDelay = 0.0

AVSpeechUtteranceDefaultSpeechRate exists because Apple already tuned it against real listening comprehension. If you're building a speed slider, treat that constant as your slider's midpoint and let users move a bounded amount in either direction — don't let the raw rate value go anywhere near its technical minimum or maximum, both of which are close to unintelligible.

Actually knowing what the synthesizer is doing

This is the part almost every "hello world" skips, and it's the part your UI actually needs:

final class SpeechController: NSObject, ObservableObject {
    @Published var isSpeaking = false
    private let synthesizer = AVSpeechSynthesizer()

    override init() {
        super.init()
        synthesizer.delegate = self
    }

    func speak(_ text: String) {
        let utterance = AVSpeechUtterance(string: text)
        utterance.voice = defaultVoice()
        synthesizer.speak(utterance)
    }

    func stop() {
        synthesizer.stopSpeaking(at: .immediate)
    }
}

extension SpeechController: AVSpeechSynthesizerDelegate {
    func speechSynthesizer(_ synthesizer: AVSpeechSynthesizer, didStart utterance: AVSpeechUtterance) {
        DispatchQueue.main.async { self.isSpeaking = true }
    }

    func speechSynthesizer(_ synthesizer: AVSpeechSynthesizer, didFinish utterance: AVSpeechUtterance) {
        DispatchQueue.main.async { self.isSpeaking = false }
    }

    func speechSynthesizer(_ synthesizer: AVSpeechSynthesizer, didCancel utterance: AVSpeechUtterance) {
        DispatchQueue.main.async { self.isSpeaking = false }
    }
}

Without wiring the delegate, your play button has no way of knowing whether it should currently say "Play" or "Stop" — a surprisingly common bug in TTS features that were only ever tested by their own developer, who always remembers the internal state because they just clicked the button themselves.

Things that bite you in production

stopSpeaking(at:) takes a boundary parameter, and .immediate versus .word matters. Stopping .immediate cuts off mid-syllable, which sounds broken. Stopping .word finishes the current word first and sounds like a deliberate pause. Default to .word for anything user-facing.

Audio session category determines whether speech ducks other audio or fights it. If you don't explicitly configure AVAudioSession, you'll get inconsistent behavior around background music, other apps, and silent mode depending on the device state. Set your category deliberately — .playback with the .duckOthers option is the right default for most utility apps that speak occasionally rather than continuously.

Long text needs chunking, not one giant utterance. A single AVSpeechUtterance built from several paragraphs works, but a user has no way to skip forward a sentence, and a mid-read interruption loses your place entirely. Splitting text into sentence-level utterances queued sequentially costs a little extra bookkeeping and buys you skip-forward, skip-back, and resume-from-here almost for free.

Test with VoiceOver actually running. If your app has any other spoken content or accessibility announcements, a badly scoped TTS feature will compete with VoiceOver for the same audio output and produce genuinely confusing overlapping speech. This is easy to miss if you never test with VoiceOver on, and it's exactly the audience most likely to depend on your TTS feature actually working correctly.

None of this is exotic. It's the difference between a feature that technically speaks text out loud and one that feels like a considered part of the app, and the whole gap closes with about an hour of deliberate work most tutorials skip.

On-Device OCR in SwiftUI: A Practical Guide to the Vision Framework

Amol Srivastava — Mon, 24 Aug 2026 15:00:00 +0000

Cloud OCR APIs are the default reach for text-in-image problems, and for most of what I build they're the wrong default: they add a network dependency, a per-request cost, and a round trip for something the phone in your hand can already do, offline, in under a second. The Vision framework's text recognition has been production-ready for years. Here's the version of the guide that skips the "hello world" and goes straight to the parts that actually matter in a shipping app.

The minimum viable request

import Vision

func recognizeText(in image: CGImage) async throws -> [String] {
    let request = VNRecognizeTextRequest()
    request.recognitionLevel = .accurate
    request.usesLanguageCorrection = true

    let handler = VNImageRequestHandler(cgImage: image, options: [:])
    try handler.perform([request])

    guard let observations = request.results else { return [] }

    return observations.compactMap { observation in
        observation.topCandidates(1).first?.string
    }
}

That's a working OCR pipeline in about fifteen lines. .recognitionLevel = .accurate matters — the .fast option trades meaningful accuracy for speed you usually don't need, since this whole pipeline typically finishes in well under a second on-device regardless.

Getting the region, not just the text

The naive version above throws away something you'll almost always want back: where on the image the text actually was. If you're building anything like a "draw a box, get the text in that box" feature, you need the bounding geometry, not just the string:

func recognizeText(in image: CGImage, croppedTo rect: CGRect? = nil) async throws -> [(text: String, box: CGRect)] {
    let request = VNRecognizeTextRequest()
    request.recognitionLevel = .accurate

    if let rect = rect {
        request.regionOfInterest = rect // normalized 0...1 coordinates, not pixels
    }

    let handler = VNImageRequestHandler(cgImage: image, options: [:])
    try handler.perform([request])

    return (request.results ?? []).compactMap { observation in
        guard let candidate = observation.topCandidates(1).first else { return nil }
        return (candidate.string, observation.boundingBox)
    }
}

regionOfInterest is the detail that makes a "select an area to scan" feature fast instead of slow — you're telling Vision to only process the part of the image you actually care about, rather than running full-frame recognition and discarding most of the output.

The coordinate system will get you once

boundingBox comes back in Vision's coordinate space: normalized 0 to 1, with the origin in the bottom-left. SwiftUI's coordinate space has its origin in the top-left. If you draw a box directly using Vision's raw values, it will appear vertically flipped and you will spend twenty minutes convinced your math is wrong before remembering this. The fix is a single flip on the y-axis:

func convert(_ boundingBox: CGRect, in viewSize: CGSize) -> CGRect {
    CGRect(
        x: boundingBox.minX * viewSize.width,
        y: (1 - boundingBox.maxY) * viewSize.height,
        width: boundingBox.width * viewSize.width,
        height: boundingBox.height * viewSize.height
    )
}

Write this helper once, and every future OCR overlay you build stops being a coordinate-math debugging session.

What actually matters once you ship this

Downsample large images before recognition. A full-resolution photo from a modern iPhone camera is far more pixels than text recognition needs. Resizing to roughly 2000px on the long edge before running the request cuts processing time meaningfully with no accuracy loss for normal document or screen text.

usesLanguageCorrection is not free. It improves accuracy on natural-language text by leaning on a language model, but it can actively hurt accuracy on short strings, codes, or anything that isn't real words — serial numbers, for instance. Turn it off for those cases specifically rather than leaving it on globally.

Handle the empty-result case as a real UI state, not an afterthought. Blurry screenshots, glare, text at a bad angle — recognition legitimately returns nothing sometimes. A "no text found, try again" state is not optional polish, it's the difference between a tool that feels reliable and one that feels broken the first time someone points it at a low-contrast label.

Test against real screens, not just documents. Text rendered on an LCD or OLED screen — which is a common target if you're building anything like a screen-capture-to-text tool — behaves differently than ink on paper: sub-pixel rendering, moiré patterns from photographing a screen, and anti-aliasing all degrade recognition in ways a flat scanned document never will. If that's your use case, test it directly instead of assuming document-OCR quality carries over.

The whole pattern costs you an import and about thirty lines of real code, runs faster than any network call could, and never sends a user's document, screenshot, or handwritten note anywhere off their device. For most consumer OCR use cases, that's not a tradeoff — it's strictly better on every axis that matters.

Building Local Multiplayer iOS Experiences Without a Server

Amol Srivastava — Sun, 23 Aug 2026 10:10:22 +0000

Every "local multiplayer" tutorial you'll find assumes two devices on the same Wi-Fi network, then walks you through Bonjour service discovery. That's the easy 80%. The part nobody covers is what happens when there's no Wi-Fi at all — two phones, a restaurant with no guest network, both parties expecting the app to just work. That gap is where MultipeerConnectivity actually earns its keep, and it's the backbone of every phone-to-phone experience I've shipped.

Why MultipeerConnectivity over a backend

For a two-person local game or icebreaker app, a server buys you nothing. It adds latency, a cost line item, an account system nobody wants to sign up for, and a single point of failure for a feature that's fundamentally "two people in the same room." MultipeerConnectivity uses Bluetooth and peer-to-peer Wi-Fi automatically, falling back between them without you writing that logic yourself. No network required, no accounts, no server bill.

The three objects you actually need

import MultipeerConnectivity

final class LocalSession: NSObject, ObservableObject {
    private let myPeerID = MCPeerID(displayName: UIDevice.current.name)
    private let serviceType = "my-app-sync" // lowercase, 1-15 chars, no special chars beyond hyphen

    private lazy var session: MCSession = {
        let session = MCSession(peer: myPeerID, securityIdentity: nil, encryptionPreference: .required)
        session.delegate = self
        return session
    }()

    private lazy var advertiser = MCNearbyServiceAdvertiser(
        peer: myPeerID, discoveryInfo: nil, serviceType: serviceType
    )

    private lazy var browser = MCNearbyServiceBrowser(peer: myPeerID, serviceType: serviceType)

    @Published var connectedPeers: [MCPeerID] = []
}

MCSession is the actual pipe data flows through. MCNearbyServiceAdvertiser broadcasts "I'm here, invite me." MCNearbyServiceBrowser looks for those broadcasts. In practice, both devices run both roles simultaneously — you don't design a client and a host, you design two peers that happen to connect to each other.

The delegate methods that matter

Most of MCSessionDelegate is boilerplate you'll paste once and forget. Two callbacks are worth understanding properly:

extension LocalSession: MCSessionDelegate {
    func session(_ session: MCSession, peer peerID: MCPeerID, didChange state: MCSessionState) {
        DispatchQueue.main.async {
            switch state {
            case .connected:
                self.connectedPeers.append(peerID)
            case .notConnected:
                self.connectedPeers.removeAll { $0 == peerID }
            default:
                break
            }
        }
    }

    func session(_ session: MCSession, didReceive data: Data, fromPeer peerID: MCPeerID) {
        // Decode and publish into your app's state on the main thread.
        // This fires on a background queue — never touch @Published state
        // without hopping to main first, or SwiftUI will silently drop updates.
    }
}

The didChange callback is your entire connection-state model. Don't build a separate "is connected" flag elsewhere — derive everything from connectedPeers.

What actually breaks in production

Advertise and browse at the same time, always. Early versions of these apps had a "Host" and "Join" button. Users pick the wrong one, or one person's app is slow to open the browser and misses the advertisement window entirely. Have both devices advertise and browse simultaneously from the moment the feature screen opens — whichever one the OS connects first wins, and neither user has to make a choice that can be wrong.

Handle .connecting as a real UI state. There's a window — sometimes a couple of seconds — where a peer is found but not yet connected. If your UI jumps straight from "searching" to "connected," a slow handshake reads as a frozen app. Show a distinct "connecting to [name]..." state.

Data messages are unordered relative to each other unless you make them not. If you send two pieces of state in quick succession, don't assume they arrive in the order you sent them. Either send a single serialized snapshot of state per update instead of granular deltas, or include a sequence number and reconcile on the receiving end.

Test with Bluetooth off and on, and with both. Peer-to-peer Wi-Fi and Bluetooth have different range and reliability characteristics. An app that only gets tested on a desk with both radios full-strength will surprise you in a noisy real-world environment. Specifically test the case where discovery starts working, then drops mid-session — your reconnect logic is the part everyone forgets to build.

Once this pattern is in place, "local multiplayer" stops being a feature you dread building and becomes a five-minute addition to any two-person app idea — no backend ticket required.