r/SwiftUI

About Links, Images, and .widgetAccentRenderingMode().

The gist: Don't do it.

Title: How do you manage translation JSON files? (built a tool for my own pain points, curious if others hit the same walls)

I've been building a multilingual vocabulary app (iOS/macOS, SwiftUI + SwiftData) that ships in 30+ languages, and managing the translation JSON has been way more painful than I expected. Curious how other devs handle this, and whether the specific problems I ran into are universal or just my own workflow being weird.

The problems I kept hitting:

• Structural drift: With thousands of repeated objects like {"id": "...", "translations": {"en": "...", "ko": "...", ...}}, it's easy for one entry somewhere in the middle to silently lose a field, get a typo'd language key, or mismatch nesting — and standard JSON validators don't catch this, because the JSON is technically still valid, just structurally inconsistent with the rest of the file.
• Missing/empty language values: Standard validation says the file is fine even if half your language keys are empty strings. You don't find out until QA or a user report.
• Truncated files: If you're generating translations with an LLM and the output gets cut off mid-response, you end up with a JSON tail that's broken in very specific, recoverable ways — but a normal validator just gives you "unexpected end of input" with no path to fix it.
• camelCase ↔ snake_case round-tripping: If your app code uses camelCase but your pipeline/backend expects snake_case, converting back and forth loses information — going from snake_case back to camelCase is ambiguous (is it "userID" or "userId"?). I needed something that remembers the original casing per-project so round-trips are lossless.
• Merging new translations back in without breaking things: getting updated translations back — from a translator, an LLM, or myself editing a spreadsheet — and merging them into the existing file without silently clobbering good data or creating duplicate entries turned out to be its own problem.

What I built:

A macOS app that treats JSON translation files as a first-class problem instead of "just JSON":

• A syntax validator that recovers from smart quotes, markdown code fences, trailing commas — the common copy-paste mistakes when dealing with LLM output
• A "pattern stamp" engine that learns the structure of your repeated objects and flags entries that deviate, without caring about the actual values — just the shape
• Language coverage checking that detects missing keys and can auto-suggest which language a stray value probably belongs to
• A tail-repair engine specifically for truncated LLM output
• camelCase/snake_case conversion with per-project memory of original casing
• A paste-merge tool with conflict detection when combining translation batches

Why this changes how you use AI for translation (and saves tokens):

Most people I see doing this either paste the whole JSON file into an Xcode-integrated AI assistant, or hand-copy fragments into ChatGPT and hope the formatting survives the round trip. Both are wasteful in different ways.

Because this tool can isolate exactly the slice you need — a single language column, a single entry, a single group of entries missing a specific key — you don't have to send your whole dataset to any AI to get one thing translated or fixed. You extract just the piece you actually need, send that to whatever model you want (doesn't have to be the one tied into your IDE), and paste the result back. The merge engine handles conflict detection so pasting back in isn't a manual find-and-replace exercise — it tells you if something you're about to overwrite already differs from what's incoming, instead of silently clobbering it.

This matters more at maintenance time than at initial translation time. Say you're at 10 languages and you add 10 more. You don't need to regenerate all 20 — you extract the existing 10-language values as reference/context, send only the request for the 10 new languages, and merge the result back into the same objects without touching what's already correct. Later, if one specific language needs a wording fix across the whole file (a tone change, a terminology correction, whatever), you can pull out just that one language's values across every entry, hand that single column to an AI, and merge the corrected column back in — instead of re-sending 20 languages' worth of context just to fix one.

The net effect: the LLM call gets smaller and cheaper because you're not sending 19 languages of context to fix the 20th, and the merge step means you're not manually reconciling what came back against what you had.

Who I think this is for:

• Indie/solo devs doing i18n for their own app who don't want a full localization platform built for teams/CI pipelines (Lokalise, Localazy, etc.) when what they actually have is "a JSON file and a growing list of languages"
• Anyone generating or maintaining translations via LLM, since most of these failure modes (truncated output, inconsistent formatting, one language quietly missing, wasted context on unchanged languages) are specifically artifacts of an LLM-in-the-loop workflow
• Anyone who designed their own JSON schema for translations rather than using a framework's built-in i18n format (i18next, .strings, .arb, etc.)

Question for the thread: does this match how you handle i18n JSON and AI-assisted translation, or do you use a completely different structure/approach where these problems don't come up? Trying to figure out if I've been solving a self-inflicted problem or something more people run into.

The philosophy behind the app:
Ultimately, I wanted to build an app that gracefully handles almost every mistake and repetitive task that a beginner or indie developer encounters.
Sure, if you dig deep enough into VS Code, you can technically find all these features. But honestly, what did you think when you first opened VS Code? I remember looking at it and thinking, "Piloting a spaceship would probably be easier than navigating this." I wanted to build something that bypasses that friction entirely.

Please share your thoughts or experiences

I just spent an entire night tearing my hair out over this. I hit a really strange focus bug on iOS 26 and want to share it, both as a warning and in case someone knows what's actually going on under the hood.

Setup: a bottom "add item" bar living in .safeAreaBar(edge: .bottom), inside a NavigationStack that sits in a TabView. The bar shows a suggestions row above the text field, but only while the field has focus:

struct AddItemBar: View {
     var text: String
     private var isFocused: Bool

    var body: some View {
        VStack {
            if isFocused {
                SuggestionsView(...)   // horizontal ScrollView, .glassEffect()
            }

            HStack(spacing: 0) {
                TextField("1 kg tomatoes", text: $text)
                    .focused($isFocused)
                    .padding(.vertical, 12)
                    .padding(.horizontal)
                    .glassEffect()

                Button("Add", systemImage: "plus") { ... }
                    .buttonStyle(.glassProminent)
                    .buttonBorderShape(.circle)
            }
        }
        .animation(.default, value: isFocused)
    }
}

The bug: tap the field → keyboard comes up, typing works fine, but isFocused never becomes true. I put a debug Text(isFocused ? "FOCUS" : "NO FOCUS") in the bar: it says NO FOCUS the whole time the keyboard is up. So anything gated on the focus state (my suggestions row) simply never appears. No warnings, no console output, nothing.

What did NOT fix it:

• GlassEffectContainer + glassEffectID on every glass element (this is supposed to be the blessed way to handle dynamic glass shape sets). Bonus weirdness: with the container active, the text you type became invisible inside the field.
• Moving the glass off the field onto a background shape: .background { Capsule().glassEffect() }. Binding still never fires.
• Making the conditionally-inserted suggestions view non-glass (material background instead). Irrelevant, because the binding never fires in the first place; the conditional view isn't even inserted yet.

What DOES fix it (all verified on device):

• Putting any glass button before the TextField in the HStack. Moving my Add button to the left of the field: focus binding works instantly.
• Applying .glassEffect() to the whole HStack instead of the field itself (single capsule, compose-bar style): works.
• Funny enough, I only discovered the bug because I removed a glass Menu that used to sit left of the field. It had been masking the bug the entire time.

So the failing configuration is specifically: TextField as the first/leftmost glass element in a .safeAreaBar (under TabView), followed by a glass button. Reorder the elements and \@FocusState`` works; keep the field first and the binding is just dead, even though the keyboard and typing work normally.

I ended up shipping the "button on the left" layout. Has anyone else run into this? I'd love to understand the actual mechanism. My best guess is something about how Liquid Glass captures/hosts the field's content, but the container + glassEffectID route failing makes me think it's just a plain UIKit-bridging bug. Filing a Feedback either way.

Xcode 26.3, iOS 26.5, device

I'm trying to understand the correct architecture for shared post state in SwiftUI using the new Observation framework.

I have a simple example where both ContentView and SavedView display PostView.

Observable class Post {
    var id: Int
    var content: String
    var title: String
    var isLiked: Bool = false

    init(id: Int, content: String, title: String, isLiked: Bool) {
        self.id = id
        self.content = content
        self.title = title
        self.isLiked = isLiked
    }

    func toggleLike() {
        isLiked.toggle()
    }
}


struct PostView: View {
     var post: Post

    var body: some View {
        HStack {
            Text(post.title)
            Text(post.content)
            Spacer()
            Button(post.isLiked ? "Liked" : "Like") {
                post.toggleLike()
            }
        }
    }
}

ContentView

struct ContentView: View {
    @State private var posts : [Post] = [] 

    var body: some View {
        List(posts, id: \.id) { post in
            PostView(post: post)
        }
        .task {
            if posts.isEmpty {
                let examplePost = Post(
                    id: 1,
                    content: "examplecontent",
                    title: "exampletitle",
                    isLiked: false
                )
                posts.append(examplePost)
            }
        }
    }
}

SavedView

struct SavedView: View {
    @State private var posts: [Post] = []

    var body: some View {
        List(posts, id: \.id) { post in
            PostView(post: post)
        }
        .task {
            if posts.isEmpty {
                let examplePost = Post(
                    id: 1,
                    content: "examplecontent",
                    title: "exampletitle",
                    isLiked: false
                )
                posts.append(examplePost)
            }
        }
    }
}

If I like the post in ContentView, the same post in SavedView is still shown as not liked.

I understand that in this example each view creates its own Post instance, so they aren't actually sharing the same object.

My question is more about architecture:

• How is this typically solved in real apps?
• Do apps like Instagram or X (Twitter) maintain a single shared source of truth for every post?
• Is the common approach to have a central store/repository (similar to Redux/TCA) where every screen references the same Post object by ID?
• Or do they simply refetch the data whenever a user navigates between screens?
• With SwiftUI's new Observation framework, what would be considered the idiomatic architecture?

I'm interested in how large social media apps handle this problem rather than just fixing this sample.

I'm building a Flutter health app that tracks steps and sleep using HealthKit. I've also created WidgetKit widgets so users can view their latest step count and sleep data without opening the app.

On Android, I use WorkManager to update the widget approximately every 45 minutes, and that works well.

On iOS, however, once the app is terminated, background work is no longer reliable, so I can't periodically fetch HealthKit data and update the widget.

My main question is about live HealthKit data:

• How do health apps keep their step-count widgets updated while the app has been terminated for days?
• Can HKObserverQuery with HealthKit background delivery wake the app after it has been terminated, or does it stop working until the user launches the app again?
• Is there an Apple-recommended architecture for keeping HealthKit widgets reasonably up to date?
• Are BGTaskScheduler, WidgetKit timelines, or App Intents sufficient for this use case, or are there limitations that make truly live updates impossible?
• If you've built a HealthKit-based widget before, how do you keep the widget displaying the latest step count without requiring the user to open the app?

I'm looking for Apple's recommended approach and any real-world implementation experience. Any advice or links to relevant documentation would be greatly appreciated.

Ran into this in a code review recently and it turned into a rabbit hole I think is worth sharing, because the code looks completely reasonable and the cost is invisible until the list grows.

The setup: a List of posts, and for each row you check wheteher it's favorited.

List(posts) { post in
    PostRow(
        post: post,
        isFavorite: favorites.contains(where: { $0.id == post.id })
    )
}

Nothing here looks wrong. But .contains(where:) scans up to every favorite, for every row. That's O(n × m), and it re-runs on every body evaluation, which during a scroll is a lot. With a few hundred posts and a few hundred favorites you're doing tens of thousands of comparisons per frame. It shows up as scroll jank you can't easily place, because no single line looks expensive.

The fix is to build a Set of the favorite IDs once, above the List, so each row becomes an O(1) lookup:

let favoriteIDs = Set(favorites.map(\.id))

List(posts) { post in
    PostRow(post: post, isFavorite: favoriteIDs.contains(post.id))
}

O(n × m) becomes O(n + m). The part that bit me: it has to be built above the List, not inside the row closure. Build it inside and you're rebuilding the Set every row, which is worse than where you started.

Two things I'm curious about from people who've shipped more of this than I have:

Do you reach for this proactively, or only after Instruments points at it? I've gone back and forth on whether pre-optimizing membership checks is worth the readability cost on small lists.

And is there a cleaner pattern than a manually-built ID Set for this, something with diffable data sources or a computed lookup, that holds up in production?

(I've been making short videos connecting interview algorithms to real iOS code, and this one came from that. Happy to link it if it's useful, but the discussion is the part I actually care about.)

I ship iOS apps solo. No code reviewer, no teammate catching me cut corners at 1am. The codebase only stays sane if I enforce structure on myself, because nobody else is going to.

The rule that saves me: views do not touch data.

My basic split:

• Views handle layout and taps. If a view is deciding how data gets saved, I moved too much into the view.
• ViewModels own screen state. I keep them @Observable and @MainActor, because SwiftUI already gives me enough ways to hurt myself.
• Services do the work: SwiftData, network calls, file access, anything that changes the outside world.
• Models stay boring. Data only.

I use it as a fence. Future me needs fewer places to look.

When a screen breaks, I know where to start. When I change storage, the UI does not need surgery. And when I let an AI agent work on a service, it has less room to wander into seven other files.

I learned this by doing the opposite. I let views query SwiftData directly in an early app and it turned into spaghetti. Worked fine until it didn't. Then every small change felt like pulling a wire out of a wall and hoping the lights stayed on.

Curious how other solo SwiftUI devs handle this. Do you keep the layers this strict, go heavier with something like TCA, or let small apps stay messy.

I work as an iOS developer in a team of 8 developers. We are starting a brand new greenfield project in a financial sector. Few of our team members suggested that we should use TCA for iOS SwiftUI application. I personally have no experience with TCA.

What are your thoughts and recommendations?