r/iOSProgramming

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

Hi guys, I dont know if I expect any any help or I just want to rant on this one...

I built an pokemon card scanner apps. I know there are dozens but that's not the point here.

I have been rejected multiple times because of using "pokemon" term in appstore page or showing pokemon cards in screenshots.

My app was finally accepted with "pokemon" in subtitle, which help users finding my app.

They are now blocking my update because of that.

The thing is : there are dozens recently updated apps using pokemon terms and images without any issue !

It seems this rule is applying to me but not to others, they are using terms in titles, subtitles, showing cards images in screenshots or app preview...

Apple keep rejecting my updates even if it has been approved before, it's driving me crazy.

I submitted a form for unfair treatment but no feedback so far indeed.

Here it is, let me know if you had a similar experience and how you manage to solve it !

Thanks !

Hey r/iOSApps community,

Quick summary of the app based on the sub rules:
* A – Answer: Solves sunscreen guesswork by calculating a dynamic UV-based protection countdown using the Monk skin scale.
* B – Better: Privacy-first (no tracking/no ads), uses a clean Bento-grid UI instead of medical fear tactics, and features an advanced non-linear degradation formula.
* C – Cost: Completely Free (no ads, no IAPs). Link: https://apps.apple.com/us/app/burnie-smart-uv-protection/id6770673915

***

I just flipped the switch on Burnie. I built this side project because I constantly find myself getting sunburned, and after seeing skin cancer impact my own family, I wanted to stop guessing with sun safety. I wanted to build something straightforward that provides actual scientific guidance based on live UV data.

The app checks your local UV index, maps it against your skin profile using the scientific Monk Scale, and runs a real-time protection countdown the moment you log your sunscreen application.

Behind the scenes on how the math works:
The countdown isn't just a simple, linear timer. It uses a fine-tuned calculation that assumes your sunscreen degrades dynamically over time based on actual UV exposure levels. I also built in a conservative safety margin to automatically account for natural wear and tear from clothes, sweating, or moving around.

A few intentional choices I made while building it:

* Privacy First: It is built natively on iOS 17 with SwiftData. Absolutely everything stays entirely local on your device. There is no user registration, no data collection, and no ad networks. It doesn't track your location; it merely uses your current coordinates locally to fetch the exact UV data.
* Clean UI: I deliberately avoided scary medical charts or fear-based warnings. Instead, it uses a clean Bento-grid layout with an ambient background that shows your current shield status at a quick glance.
* Smart Nudges: It sends lightweight local notifications exactly when your calculated protection layer degrades under your current local UV conditions.

The app is completely free to download. I am just trying to get the name out there right now and grab some real-world feedback from fellow builders.

I would love to hear your thoughts on the design or the countdown system!

iOS 26 borders with rounded corners look different than what we used to have before. It looks like the top left and bottom right corners have whiter border and the top right and bottom left corner have almost transparent border.

Anyone know how to add these types of borders to views?

I’m a software engineer in my day job, with a big interest and background in music. I’ve built a couple little things for iOS and web. Trouble is, I never really actually collected a set of contacts in a single niche that would be helpful for eg beta testing. Even if I today had some wonderful and finished music app or whatever, I really don’t know where I’d find my first users. I guess I have a few names of people I could poke, but that’s about it.

I’ve heard App Store ads can be great here.

What else have you seen work?

Hey everyone!

If you localize your iOS or macOS apps, you know how tedious App Store Connect can be when pushing updates. Cycling through 10 to 15+ languages just to paste a minor change into "What's New," "Promotional Text" usually turns into a massive click-and-paste marathon.

Unless there is a hidden feature in App Store Connect that handles this natively (and if there is, please let me know!), I couldn't find a clean way around it. Not even an MCP! So I built a Chrome extension called App Store Connect Metadata Filler to automate it. I wanted a complete free alternative.

What it does:

• One-Click Apply: Fills out Promotional Text, Description, What's New, and Keywords across all active language tabs at once.
• React-Aware: It interacts with Apple's frontend elements correctly so it doesn't break the form state when you hit save.
• Fetch Previous Version: Automatically jumps to your last "Ready for Distribution" page, grabs the existing localized strings, and brings them back to your current in-flight version.
• Save/Export Configs: Keeps your translation configurations saved locally as JSON so you can reuse or tweak them next month.
• Private: No external APIs or trackers. Everything stays in your browser's local storage.

It is completely free, dependency-free (plain Manifest V3 JavaScript), and open source so anyone can audit the code or check out how the background scraping script works.

https://preview.redd.it/kle9dbm3x5bh1.png?width=573&format=png&auto=webp&s=704be5cc2241dcf1a3149ecf5530d29d5d60c78f

GitHub Repository:

https://github.com/picklenick-dev/apple-storeconnect-metadata-filler

Hopefully, this saves some of you a bit of manual labour on your next release. Let me know if you run into any edge cases or if Apple changes their UI layout... this is major weakness of the chrome extension ~_^

Hi all,

I'm trying to rewrite my big-ass SwiftUI scroll view by utilising UITableView and UIHostingConfiguration for displaying cells' content. The setup was easy but I've hit a roadblock related to resizing cells.

Every time cell's content grows vertically the table view jumps erratically, does anyone have any idea how to approach fixing this issue? For reference please see the video attached.

I've uploaded the sample project to GitHub:
https://github.com/wiencheck/SwiftUITableViewPOC

Main stuff is located in `TableViewPOC/TableViewController.swift`

This tool i've built for myself and i've been using it for some time in company where i work. Want to share it with the community.

A tool called mobile-repo-doctor. It is a CLI and also a GitHub Action. It scans your repo and runs about 130 checks for iOS, Android, Flutter and KMP. It gives you a health score (size / speed / stability / hygiene) and makes reports in HTML, JSON or Markdown(optimized for AI).

Some iOS checks:

• - ios-missing-shared-scheme — CI can't build a scheme it can't see
• - ios-background-mode-missing-usage — you declared a capability but there is no usage text
• - dependency version drift in an SPM monorepo
• - and more

A few honest things:

- The package is not minified. If you worry about malware, you can read the code yourself, or give it to an AI to check. It is all plain JS.

- It makes only one network call — it asks npm if there is a new version. That's it. No telemetry. Nothing about your repo leaves your machine.

- It understands monorepos. It will not spam you with false positives from Pods/, forked packages or plugin host projects.

Install:

npm install -g mobile-repo-doctor

Run:

mrd scan ./path/to/repo

I would like to know which checks are useful and which are just noise. Also, what hidden bugs have hurt you before? Maybe I can add a check for them.

npm: mobile-repo-doctor

Documentation & full check reference

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.)

Xcode’s built-in AI tooling lets you add third-party model providers, but I haven’t found a clean way to point it at Claude Fable 5 yet. Has anyone gotten it working — either through the Anthropic API endpoint directly, a proxy, or an MCP setup? Curious if it’s a model-string issue or if Xcode just doesn’t support it yet. Would love to hear any working configs.

With the absolute deluge of new iOS apps coming out, there are certain design patterns that I'm seeing over and over again that are clearly the work of AI coding agents. I'm sure you've seen them too. Egregious monospaced fonts, glowing buttons, middle dots (·) all over the place, purple gradients, etc. It's not just iOS apps, it's websites too. For whatever reason, the LLMs (and maybe Claude in particular?) are just absolutely in love with these design patterns.

The question I have is, is that a bad thing? Is it bad for an app to have the LLM design smell? Do typical users notice? Do users care?

I'll share my opinion (shocker I know). I think that these design patterns are bad, and significantly so. Why?

For a minute forget about generative AI and all the baggage that carries. With 2 million apps on the iOS App Store (gotta be nearly 3M by now...), we all want our apps to stand out. What's the first thing a user sees about an app when browsing? Of course it's the screenshots of the app UI. And the more an app looks like the others, the less likely a user is going to stop and take a second look. So that's the first thing, that it just tends to make apps look alike.

But the other that I've been thinking about is more subtle and potentially more important. For better or worse, there is a hefty bias against generative AI out in the general population. Whether that's valid or not isn't really the point, the point is it exists. That said, I don't think your typical user is going to notice these patterns, at least not consciously. But there are some types of users that will notice: the blogger, the instagrammer, the journalist, the tik tok influencer. If you've ever had a popular blogger/influencer do a post/reel/whatever on your app, you know what an insane catalyst that can be. These types of users tend to be more savvy and more design oriented, will pick up on these design patterns, and I think would want to avoid boosting any app that has the smell.

Lastly, is the possibility of Apple featuring your app on the App Store. Maybe this will be seen as less important because it's so hard to get, but I've had Apple feature my apps many times and of course it's always an enormous boost. But I suspect that Apple App Store editors are going to be even more in the anti-smell camp and would be highly unlikely to feature an app with those patterns.

I have a feeling this could be a divisive topic, but I'd genuinely love to hear your thoughts!

Hello,

I understand that App Store Connect allows us to perform A/B testing on app icons. Since user preferences often vary by region, is it possible to apply different winning icons to different localized storefronts once an A/B test concludes?

Thank you.