DEV Community: Yoshiaki Hirokawa

StoreKit 2 subscriptions + a screenshot mode that bypasses purchases

Yoshiaki Hirokawa — Sat, 27 Jun 2026 09:00:46 +0000

Two things every paid iOS app needs but nobody enjoys building:

A correct subscription manager (purchase, restore, entitlement checks, transaction updates).
A way to capture App Store screenshots of the paid screens — without having a live sandbox purchase every time.

Here's how FishGo does both, with the second piece deliberately punching a hole through the first.

A compact StoreKit 2 manager

StoreKit 2 is async/await-native, so the whole manager fits in one observable class. We use @Observable (iOS 17+) so SwiftUI views react to isPro changes:

@Observable
final class StoreManager {
    static let shared = StoreManager()

    private(set) var isPro = false
    private(set) var products: [Product] = []
    private(set) var purchaseError: String?

    private let productIDs = ["pro_monthly", "pro_yearly"]
    private var transactionListener: Task<Void, Never>?
}

Loading products

func loadProducts() async {
    do {
        let storeProducts = try await Product.products(for: productIDs)
        products = storeProducts.sorted { $0.price < $1.price }
    } catch {
        purchaseError = "商品情報の取得に失敗しました"
    }
}

Purchasing, with verification

The important part of StoreKit 2 is that every result is a VerificationResult you must check:

func purchase(_ product: Product) async {
    purchaseError = nil
    do {
        let result = try await product.purchase()
        switch result {
        case .success(let verification):
            let transaction = try checkVerified(verification)
            await transaction.finish()
            await updatePurchaseStatus()
        case .userCancelled:
            break
        case .pending:
            purchaseError = "購入処理が保留中です"
        @unknown default:
            break
        }
    } catch {
        purchaseError = "購入に失敗しました: \(error.localizedDescription)"
    }
}

nonisolated private func checkVerified<T>(_ result: VerificationResult<T>) throws -> T {
    switch result {
    case .unverified:
        throw StoreError.failedVerification
    case .verified(let safe):
        return safe
    }
}

Listening for transactions out-of-band

Purchases can arrive outside your purchase flow (Ask to Buy approvals, renewals, another device). A long-lived listener keeps isPro correct:

private func listenForTransactions() -> Task<Void, Never> {
    Task.detached { [weak self] in
        for await result in Transaction.updates {
            if let transaction = try? self?.checkVerified(result) {
                await transaction.finish()
                await self?.updatePurchaseStatus()
            }
        }
    }
}

And the source of truth for entitlement is Transaction.currentEntitlements:

private func updatePurchaseStatus() async {
    var hasEntitlement = false
    for await result in Transaction.currentEntitlements {
        if let transaction = try? checkVerified(result),
           productIDs.contains(transaction.productID) {
            hasEntitlement = true
            break
        }
    }
    isPro = hasEntitlement
}

The hole: a screenshot "shot mode"

Now the App Store screenshot problem. The paywall and the Pro-only screens look best when isPro == true, but you don't want to depend on a sandbox purchase succeeding during an automated screenshot run.

So StoreManager's initializer short-circuits when a launch flag is set:

init() {
    // Shot mode: pin Pro state without touching StoreKit
    if ShotMode.isEnabled && ShotMode.isPro {
        isPro = true
        return
    }
    transactionListener = listenForTransactions()
    Task { await updatePurchaseStatus() }
}

ShotMode is just a thin reader over launch arguments / UserDefaults:

enum ShotMode {
    static var isEnabled: Bool { UserDefaults.standard.bool(forKey: "SHOT_MODE") }
    static var isPro: Bool { UserDefaults.standard.bool(forKey: "SHOT_PRO") }
}

Run the UI test with -SHOT_MODE 1 -SHOT_PRO 1 and the app boots straight into a deterministic Pro state — no network, no store, no flaky purchase. Combined with mocked forecast data, every screenshot is identical run-to-run.

Pitfalls

Always finish() a verified transaction. Unfinished transactions get replayed forever via Transaction.updates.
@unknown default is mandatory on the purchase-result switch — StoreKit can add cases.
Keep the shot-mode bypass narrow. It only forces isPro; it never fakes a real Transaction. The real verification path stays untouched for actual users.
Guard the bypass behind a launch argument, not a build flag you might ship. It only activates when explicitly passed at launch.

Takeaways

StoreKit 2 lets you write a full subscription manager in ~100 lines with async/await + @Observable.
Check VerificationResult everywhere; trust nothing unverified.
Drive entitlement from Transaction.currentEntitlements and keep a Transaction.updates listener alive.
A tiny launch-flag bypass makes paid-screen screenshots deterministic — as long as it stays scoped to UI state, not real receipts.

FishGo is on the App Store: https://apps.apple.com/app/id6774428559

An actor + 1-hour cache: calling weather APIs safely from Swift Concurrency

Yoshiaki Hirokawa — Sat, 27 Jun 2026 08:32:41 +0000

When an app calls a remote API from many places — a view appears, the user taps refresh, a background reload kicks in — you face two problems at once:

Concurrency safety: multiple tasks touching the same cache can race.
Redundant calls: the same coordinate gets fetched over and over.

In FishGo (a fishing-conditions app), the weather layer hits two Open-Meteo endpoints per location — a regular forecast and a marine forecast. We solved both problems with one tool: a Swift actor holding a cache.

Why an actor

An actor serializes access to its mutable state. Only one task touches the cache at a time, so we get data-race safety for free — no locks, no queues. Just mark the type actor:

actor WeatherService {
    static let shared = WeatherService()

    private var cache: [String: (data: WeatherData, timestamp: Date)] = [:]
    private let cacheExpiry: TimeInterval = 3600  // 1 hour
}

cache is isolated to the actor. Any code calling fetchWeather from outside has to await, and the runtime guarantees serialized access.

The cache key: coordinate + day

Weather changes by location and by date, so the cache key combines both:

func fetchWeather(for coordinate: CLLocationCoordinate2D, date: Date = Date()) async throws -> WeatherData {
    let dateKey = Self.dateKey(date)
    let cacheKey = "\(coordinate.latitude),\(coordinate.longitude)_\(dateKey)"

    if let cached = cache[cacheKey], Date().timeIntervalSince(cached.timestamp) < cacheExpiry {
        return cached.data
    }
    // ... fetch, then store
}

The dateKey is a yyyy-MM-dd string in the Tokyo time zone, so "today's forecast for this spot" maps to one stable key regardless of the exact Date passed in:

private static func dateKey(_ date: Date) -> String {
    let f = DateFormatter()
    f.dateFormat = "yyyy-MM-dd"
    f.timeZone = TimeZone(identifier: "Asia/Tokyo")
    return f.string(from: date)
}

If a fresh entry exists (younger than an hour), we return it immediately and skip the network entirely.

Combining two endpoints

On a cache miss, we fetch the forecast and the marine data, plus compute astronomy locally, and merge everything into one WeatherData:

let forecast = try await fetchForecastData(coordinate: coordinate)
let marine = try await fetchMarineForecast(coordinate: coordinate)
let astronomyData = AstronomyCalculator.calculate(for: date, coordinate: coordinate)

Open-Meteo returns hourly arrays, so we pick the index for noon as the representative daytime value:

private func targetHourIndex(for date: Date, times: [String]) -> Int {
    let formatter = DateFormatter()
    formatter.dateFormat = "yyyy-MM-dd"
    formatter.timeZone = TimeZone(identifier: "Asia/Tokyo")
    let dateStr = formatter.string(from: date)
    let target = "\(dateStr)T12:00"

    if let index = times.firstIndex(of: target) { return index }
    if let index = times.firstIndex(where: { $0.hasPrefix(dateStr) }) { return index }
    return 0
}

A graceful fallback for the marine API

The marine endpoint is the flakier of the two (not every coordinate has marine coverage). Instead of letting a marine failure sink the whole request, we degrade gracefully:

private func fetchMarineForecast(coordinate: CLLocationCoordinate2D) async throws -> MarineForecastData {
    do {
        let (data, _) = try await URLSession.shared.data(from: url)
        let response = try JSONDecoder().decode(HourlyMarineResponse.self, from: data)
        return MarineForecastData(
            waveHeights: response.hourly.waveHeight,
            seaTemperatures: response.hourly.seaSurfaceTemperature
        )
    } catch {
        return MarineForecastData(waveHeights: [], seaTemperatures: [])  // empty, not fatal
    }
}

Downstream, missing wave/temperature data is handled with sensible defaults via indices.contains, so the app still produces a usable forecast.

Finally, store the merged result and return:

cache[cacheKey] = (data, Date())
return data

Pitfalls

Don't make the actor's methods nonisolated carelessly — that throws away the isolation that's protecting your cache.
Time zones bite. Keying by raw Date would scatter "the same day" across many keys. Normalize to a yyyy-MM-dd string in a fixed zone.
Hourly arrays need bounds checks. APIs can return shorter arrays than you expect; we guard every index access with indices.contains.
Decide your failure granularity. A secondary data source (marine) failing shouldn't kill the primary result — catch and degrade.

Takeaways

An actor gives you a thread-safe cache with zero locking ceremony.
Key the cache by what actually varies (coordinate + normalized day), not by raw objects.
Merge multiple endpoints behind one method so callers see a single WeatherData.
Degrade, don't crash, when a secondary source fails.

FishGo is on the App Store: https://apps.apple.com/app/id6774428559

Sharing Data Between Your iOS App and Its Widget with App Groups

Yoshiaki Hirokawa — Sat, 27 Jun 2026 08:32:19 +0000

A widget runs in a separate process from your main app. It has its own memory and its own sandbox, so you can't just hand it an object. If your widget needs data your app computed, you have to ship that data across the process boundary.

In FishGo, an iOS app that tells you whether the sea conditions are good enough to go fishing today, the widget is the product: the whole point is to glance at your home screen and see 🟢 / 🟡 / 🔴 without opening the app. So getting data into the widget reliably mattered a lot.

Here's the pattern we landed on.

The problem

The main app fetches weather, computes a verdict (go / caution / no_go), and renders the detail screen. The widget needs that same verdict — but it can't call the app's view model. The two targets don't share memory.

The solution: one App Group + one Codable type

An App Group gives multiple targets (app + widget extension) access to a shared UserDefaults suite. We define a single Codable struct that owns both the shape of the data and the read/write logic:

struct WidgetFishingData: Codable {
    let spotName: String
    let verdict: String       // "go", "caution", "no_go"
    let windSpeed: Double
    let waveHeight: Double
    let windDirection: String
    let tideType: String
    let updatedAt: Date

    static let appGroupID = "group.jp.netflowers.FishGo"

    static func save(_ data: WidgetFishingData) {
        guard let defaults = UserDefaults(suiteName: appGroupID) else { return }
        if let encoded = try? JSONEncoder().encode(data) {
            defaults.set(encoded, forKey: "widgetFishingData")
        }
    }

    static func load() -> WidgetFishingData? {
        guard let defaults = UserDefaults(suiteName: appGroupID),
              let data = defaults.data(forKey: "widgetFishingData"),
              let decoded = try? JSONDecoder().decode(WidgetFishingData.self, from: data) else {
            return nil
        }
        return decoded
    }
}

The key design choice: both targets import the same type, so there's exactly one definition of what "widget data" means. No drift between what the app writes and what the widget reads.

Writing from the app

After computing a forecast, the app encodes a WidgetFishingData and asks WidgetKit to refresh:

let widgetData = WidgetFishingData(
    spotName: spot.name,
    verdict: result.verdict.rawValue,
    windSpeed: weather.windSpeed,
    waveHeight: weather.waveHeight,
    windDirection: weather.windDirectionJapanese,
    tideType: weather.tideType,
    updatedAt: Date()
)
WidgetFishingData.save(widgetData)
WidgetCenter.shared.reloadAllTimelines()

reloadAllTimelines() tells the system the widget's data changed and it should rebuild its timeline.

Reading from the widget

The widget's TimelineProvider just calls load(). If nothing's there yet (fresh install), it falls back to a placeholder so the widget never renders blank:

func getTimeline(in context: Context, completion: @escaping (Timeline<FishGoEntry>) -> Void) {
    let data = WidgetFishingData.load() ?? .placeholder
    let entry = FishGoEntry(date: Date(), data: data)
    let nextUpdate = Calendar.current.date(byAdding: .minute, value: 30, to: Date())!
    let timeline = Timeline(entries: [entry], policy: .after(nextUpdate))
    completion(timeline)
}

Note the .after(nextUpdate) policy: even without the app running, the widget asks the system to refresh roughly every 30 minutes — a reasonable cadence that respects the battery.

Pitfalls we hit

The App Group ID must match exactly in both targets' entitlements and in code (group.jp.netflowers.FishGo). A typo fails silently — UserDefaults(suiteName:) returns a suite that simply doesn't share anything.
reloadAllTimelines() is a request, not a command. WidgetKit batches and budgets refreshes. Don't expect instant updates on every call; design for eventual consistency.
Always have a placeholder. load() returns nil before the first save, so ?? .placeholder keeps the widget from looking broken on a fresh install.
Keep the shared payload small and flat. It's UserDefaults, not a database. We store only what the widget renders, not the full forecast model.

Takeaways

Use an App Group to share a UserDefaults suite across app + extension.
Put the shape and the save/load logic in one Codable type that both targets import — single source of truth.
Write from the app, then call WidgetCenter.shared.reloadAllTimelines().
Read in the TimelineProvider, always with a placeholder fallback.

This pattern is small, but it's the backbone of any app whose widget shows live, app-computed data.

FishGo is on the App Store: https://apps.apple.com/app/id6774428559

Adding Live Activities to a Pomodoro timer: what the docs don't tell you

Yoshiaki Hirokawa — Sat, 27 Jun 2026 04:59:46 +0000

A countdown timer is the perfect use case for Live Activities — and also a great way to discover everything the ActivityKit docs gloss over. When I added Live Activities to Cadento, my SwiftUI Pomodoro app, the "happy path" took an afternoon. The edge cases took a lot longer.

Here's the practical version: what actually matters when you put a focus timer on the lock screen and the Dynamic Island.

The mental model

A Live Activity has three things you define:

ActivityAttributes — the static data, fixed for the lifetime of the activity (e.g. the session's total duration, the task name).
ContentState — the dynamic data that changes over time (e.g. whether it's running or paused).
The SwiftUI views — lock screen, Dynamic Island expanded/compact/minimal.

struct TimerActivityAttributes: ActivityAttributes {
    // static for the whole activity
    let sessionName: String
    let endDate: Date

    struct ContentState: Codable, Hashable {
        // changes over time
        var isPaused: Bool
        var pausedRemaining: TimeInterval?
    }
}

The single biggest "aha" is the next section.

Don't push every second. Let the system count.

The instinct is to update the activity every second so the number ticks down. Don't. You'll hit update throttling and drain battery, and it's unnecessary.

Instead, hand SwiftUI a date range and let it render the countdown itself:

// in the lock screen / Dynamic Island view
Text(timerInterval: context.attributes.startDate...context.attributes.endDate,
     countsDownFrom: 0)
    .monospacedDigit()

Text(timerInterval:) renders a live-updating timer without any activity updates at all. You only push an update when something semantic changes — pause, resume, or finish. That turns "60 updates a minute" into "an update when the user actually does something."

For pause, you stop the auto-counting text and show the frozen remaining time from ContentState.pausedRemaining. That's the whole trick.

The Dynamic Island has four presentations, not one

You must provide all of these, and they're genuinely different layouts:

DynamicIsland {
    // EXPANDED — long-press / when it's the active activity
    DynamicIslandExpandedRegion(.leading)  { /* icon */ }
    DynamicIslandExpandedRegion(.trailing) { /* time  */ }
    DynamicIslandExpandedRegion(.center)   { /* label */ }
    DynamicIslandExpandedRegion(.bottom)   { /* progress */ }
} compactLeading: {
    Image(systemName: "timer")
} compactTrailing: {
    Text(timerInterval: range, countsDownFrom: 0).monospacedDigit()
} minimal: {
    Image(systemName: "timer")
}

Gotchas I hit:

Compact trailing has almost no width. A full mm:ss can clip next to other activities. Keep it tight, use .monospacedDigit(), and test with another Live Activity running.
Minimal is a single glyph. Don't try to fit text. It shows when multiple activities are active.
Tap targets: the whole thing deep-links into your app via widgetURL — wire it up so a tap opens the running timer, not the home screen.

Starting, updating, ending

// start
let activity = try Activity.request(
    attributes: attributes,
    content: .init(state: initialState, staleDate: nil),
    pushType: nil          // local; no push server needed for a timer
)

// update (only on pause/resume/etc.)
await activity.update(.init(state: newState, staleDate: nil))

// end — choose a dismissal policy
await activity.end(.init(state: finalState, staleDate: nil),
                   dismissalPolicy: .after(.now + 4))   // linger 4s, then clear

Notes from shipping it:

A timer is local — pushType: nil. You do not need a push server. (Push-driven Live Activities are for server-side events like delivery tracking.)
dismissalPolicy matters. .immediate yanks it the instant the session ends, which feels abrupt. A short .after(...) lets the user see "Done" before it disappears.
Reconnect on launch. When the app comes back, iterate Activity<TimerActivityAttributes>.activities to find and re-attach to an in-flight activity instead of orphaning it.

The things that actually bit me

Permission can be off. Users can disable Live Activities globally or per-app. Check ActivityAuthorizationInfo().areActivitiesEnabled and degrade gracefully — don't assume request() will succeed.
The widget extension is a separate target. Your Live Activity views live in the widget extension, so shared model code must be in a target both can see, or you'll duplicate types.
Background time is not yours. You can't run a precise in-app timer in the background to drive updates. The whole point of Text(timerInterval:) is that the system renders the countdown — lean on it instead of fighting the background execution model.
Localize it. Cadento ships in 39 languages; the Live Activity is on-screen text like any other UI, so "Focus" / "Break" / "Paused" all go through the String Catalog too. Easy to forget because it's not in the main app's view tree.

Was it worth it?

For a focus timer, absolutely — it's the feature that makes the app feel present. The session lives on your lock screen and in the Dynamic Island, so you glance and know exactly where you are without opening anything. That's the entire promise of a Pomodoro app, surfaced at the OS level.

The key shift in thinking: you're not driving an animation, you're declaring state and letting the system render time. Once that clicks, Live Activities stop fighting you.

I'm a solo iOS developer from Japan building small, deeply localized apps. Cadento (focus timer, 39 languages, with Live Activities, widgets and an Apple Watch app) is on the App Store. Questions welcome in the comments.

How I auto-generate 800+ App Store screenshots across 39 languages and 3 devices

Yoshiaki Hirokawa — Sat, 27 Jun 2026 04:53:54 +0000

App Store screenshots are the highest-leverage marketing asset an app has — and the most painful to maintain. Now multiply that pain by 39 languages and 3 device classes. Doing that by hand is not "tedious," it's impossible to keep in sync.

So I built a pipeline that turns one command into ~800 finished, captioned, device-correct screenshots for Cadento, my SwiftUI focus timer. Here's the architecture.

The scale problem

The output target:

Device	Shots per language	Languages	Total
iPhone 6.9"	10	39	390
iPad 13"	8	39	312
Apple Watch	3	39	117

That's 819 images, each needing the right language UI and the right localized caption. Change one screen design and every number above regenerates. Hand-editing is off the table — the only sane answer is "rebuild everything from source on demand."

The pipeline, end to end

XCUITest (per language)  →  raw localized PNGs
        ↓
extract from .xcresult
        ↓
Python + Pillow: compose background + device frame + caption
        ↓
AppStore画像/<device>/<lang>/1..N.png   (exact store dimensions)

Five stages. Each is independently re-runnable.

Stage 1 — Capture real localized screens with XCUITest

The key insight: don't fake screenshots, drive the real app. A UI test launches the app, forces a specific language/locale, navigates to each screen, and snapshots it.

Language and locale come in as environment variables so one test file covers every language:

let lang   = ProcessInfo.processInfo.environment["SHOT_LANG"]   ?? "en"
let locale = ProcessInfo.processInfo.environment["SHOT_LOCALE"] ?? "en_US"

app.launchArguments += ["-AppleLanguages", "(\(lang))"]
app.launchArguments += ["-AppleLocale", locale]
app.launch()

// navigate + snapshot each screen
let shot = XCTAttachment(screenshot: app.screenshot())
shot.lifetime = .keepAlways
add(shot)

A shell loop runs this once per language. Because it's the actual app, the screenshots are guaranteed to match what users see — including RTL flips for Arabic/Hebrew and text expansion in German.

Stage 2 — Extract PNGs from the .xcresult

XCUITest buries screenshots inside an .xcresult bundle. A small Python script walks the result and pulls out the raw PNGs into a flat per-language folder. Nothing clever — just plumbing so the next stage has clean inputs.

Stage 3 — Compose with Python + Pillow

This is where raw screens become marketing. For each shot, Pillow:

Draws the branded background (generated separately, app-themed gradients)
Places the device frame
Drops the raw screenshot into the frame at the correct offset
Renders the localized caption on top — pulled from a per-language strings map

The caption text is itself localized (39 languages of ASO copy), so the marketing message reads natively, not just the UI underneath it. Font fallback matters here: CJK, Arabic, Hebrew, Thai, and Devanagari all need the right font or you get tofu (□□□).

Stage 4 — Live Activity & Watch shots

Live Activity (Dynamic Island / lock screen) and Apple Watch screens are generated through their own paths and folded into the same compositor, so the final set is consistent across all surfaces.

Stage 5 — Output to exact store dimensions

Everything lands in a predictable tree at the exact pixel sizes App Store Connect requires:

AppStore画像/iPhone_6.9/<lang>/1..10.png   (1320×2868)
AppStore画像/iPad_13/<lang>/1..8.png       (2064×2752)
AppStore画像/AppleWatch/<lang>/1..3.png    (410×502)

From here it's a straight upload (I drive App Store Connect's API to swap a single device's set without touching the others — but that's another post).

Lessons from running it for real

Drive the real app, don't mock. The whole value is that screenshots can't lie about what the UI does in each language.
Environment variables > 39 test targets. One parameterized UI test beats copy-pasted code every time.
Font fallback is not optional. Test the hardest scripts (Arabic, Thai, Hindi, CJK) early or you'll ship boxes.
Make every stage idempotent. A design change should be one command away from 819 fresh images, not a weekend.
Separate UI capture from caption rendering. Redesign the screen? Re-run stage 1. Rewrite the marketing copy? Re-run stage 3. They shouldn't be coupled.

The payoff: when I change a screen or a tagline, I'm not dreading a manual marathon. I run the pipeline, and the entire localized store presence updates itself.

I'm a solo iOS developer from Japan building small, deeply localized apps. Cadento (focus timer, 39 languages) is on the App Store. Ask me anything about the pipeline in the comments.

I shipped a Pomodoro app in 39 languages as a solo dev — here's how i18n actually went

Yoshiaki Hirokawa — Sat, 27 Jun 2026 04:51:46 +0000

Most indie apps ship in English, maybe add a handful of "big" languages later, and call it done. I went the other way: Cadento, my SwiftUI Pomodoro/focus timer, launched in 39 languages on day one — including ones most apps never touch, like Catalan, Croatian, Malay, Hebrew, Thai, and Ukrainian.

This post is the honest version of how that went: the setup that made it possible, the things that broke, and whether it was worth it.

Cadento is built with SwiftUI + SwiftData, targets iOS 18 / watchOS 11, and has Live Activities, widgets, an Apple Watch app, an activity heatmap, and iCloud sync. App Store: https://apps.apple.com/app/id6784636854

Why 39 languages, not 5

The usual advice is "localize into the top languages and measure." That's reasonable. But for a focus timer, the UI vocabulary is small and stable — "Start", "Focus", "Break", "Tasks", "Today", "Streak". Once I had a clean localization pipeline, the marginal cost of language #20 was close to zero. And every additional language is a market where almost no competitor has a localized listing.

So the real question wasn't "is each language worth it?" — it was "can I make adding a language nearly free?" If yes, you do all of them.

The foundation: one `.xcstrings` file

The whole thing rests on Xcode's String Catalog (.xcstrings), introduced in Xcode 15. Instead of one Localizable.strings per language, you get a single JSON file with the source language and every translation nested under each key:

{
  "sourceLanguage" : "en",
  "strings" : {
    "timer.start" : {
      "localizations" : {
        "en" : { "stringUnit" : { "state" : "translated", "value" : "Start" } },
        "ja" : { "stringUnit" : { "state" : "translated", "value" : "開始" } },
        "ar" : { "stringUnit" : { "state" : "translated", "value" : "ابدأ" } }
      }
    }
  }
}

Why this matters for a solo dev:

One file is diffable, scriptable, and reviewable. No 39 files drifting out of sync.
Each translation carries a state — new vs translated — so you can programmatically find every untranslated key across all languages.
In code you just use the key. No NSLocalizedString boilerplate spread everywhere.

That state field turned out to be the single most useful thing in the entire workflow. It's a built-in to-do list.

The actual locale list

39 isn't a round marketing number — it maps to real App Store storefronts, including regional variants where the wording genuinely differs:

en, en-GB, en-AU,
ar, ca, cs, da, de, el, es, es-419, fi, fr, fr-CA, he, hi, hr, hu,
id, it, ja, ko, ms, nb, nl, pl, pt-BR, pt-PT, ro, ru, sk, sv,
th, tr, uk, vi, zh-Hans, zh-Hant, zh-HK

Note the regional splits: es vs es-419 (Spain vs Latin America), pt-BR vs pt-PT, zh-Hans/zh-Hant/zh-HK. These aren't vanity — a button label or a date phrasing that's correct in São Paulo can read slightly off in Lisbon.

What actually broke

Localizing isn't translating strings. It's everything around the strings.

1. Layout overflow. German and Finnish expand text by 30–40%. A button that fit "Start" in English clipped its label in German. The fix is boring but mandatory: stop hard-coding widths, let SwiftUI size to content, and test the longest language, not the shortest. German is your stress test.

2. Right-to-left. Arabic and Hebrew flip the entire layout. SwiftUI handles a lot automatically if you use leading/trailing instead of left/right — but custom drawing (progress rings, the heatmap) needed explicit attention so it didn't mirror into nonsense.

3. Dates, numbers, plurals. Never build a string like "\(count) sessions". Plural rules differ wildly (Arabic has six plural categories). String Catalog supports plural variations per language — use them, or your "1 sessions" will haunt you.

4. The "translated but wrong" trap. A state: translated flag means a translation exists, not a good one. For high-traffic UI I had key phrases reviewed; for the long tail I accepted "good enough and fixable." Being honest about that tradeoff is the only way 39 languages is sustainable solo.

Was it worth it?

For a focus timer with a small, stable vocabulary: yes, clearly. The cost was front-loaded into building the pipeline once. After that, the app shows up localized in storefronts where every competitor is English-only — and "this app speaks my language" is a real conversion lever in places the big apps ignore.

If your app has a sprawling, constantly-changing text surface (think a social app with dynamic content), the math is different and you should be more selective.

Takeaways

Use the String Catalog (.xcstrings). One file, scriptable, with per-string translation state.
Let the state field be your untranslated-work tracker.
Test German/Finnish for overflow, Arabic/Hebrew for RTL — those four catch most layout bugs.
Never concatenate counts into strings. Use plural variations.
Decide your quality bar per tier (core UI vs long tail) and be honest about it.

If you want the deeper writeup — including how I auto-generated localized App Store screenshots for all 39 languages — that's the next post.

I'm a solo iOS developer from Japan building small, deeply localized apps. Cadento (focus timer, 39 languages) is on the App Store. Happy to answer i18n questions in the comments.

DEV Community: Yoshiaki Hirokawa

StoreKit 2 subscriptions + a screenshot mode that bypasses purchases

A compact StoreKit 2 manager

Loading products

Purchasing, with verification

Listening for transactions out-of-band

The hole: a screenshot "shot mode"

Pitfalls

Takeaways

An actor + 1-hour cache: calling weather APIs safely from Swift Concurrency

Why an actor

The cache key: coordinate + day

Combining two endpoints

A graceful fallback for the marine API

Pitfalls

Takeaways

Sharing Data Between Your iOS App and Its Widget with App Groups

The problem

The solution: one App Group + one Codable type

Writing from the app

Reading from the widget

Pitfalls we hit

Takeaways

Adding Live Activities to a Pomodoro timer: what the docs don't tell you

The mental model

Don't push every second. Let the system count.

The Dynamic Island has four presentations, not one

Starting, updating, ending

The things that actually bit me

Was it worth it?

How I auto-generate 800+ App Store screenshots across 39 languages and 3 devices

The scale problem

The pipeline, end to end

Stage 1 — Capture real localized screens with XCUITest

Stage 2 — Extract PNGs from the .xcresult

Stage 3 — Compose with Python + Pillow

Stage 4 — Live Activity & Watch shots

Stage 5 — Output to exact store dimensions

Lessons from running it for real

I shipped a Pomodoro app in 39 languages as a solo dev — here's how i18n actually went

Why 39 languages, not 5

The foundation: one .xcstrings file

The actual locale list

What actually broke

Was it worth it?

Takeaways

The foundation: one `.xcstrings` file