iOS renders raw key mobile.login_setup_complete_relogin on the login chooser after setup

[emooreatx]

First iOS screenshot the CIRISAgent five-platform gate has ever captured (run 33782490319, artifact live-qa-macos-ios, shots/ios-setup.png): setup completed, the app is back at the login chooser — and the banner above "Last signed in: qaadmin" reads, verbatim:

mobile.login_setup_complete_relogin

A raw localization key rendered to the user. Either the key is missing from the iOS localization bundle, or the iOS resource loader (LocalizationResourceLoader.ios.kt) doesn't find the file that carries it; desktop shows real text at the same point. Small, but it is the first thing a person sees after finishing setup on iOS.

(Everything else in that screenshot is good news: the simulator wizard now runs end to end in CI with 0.5.199.)

[emooreatx]

Not fixed in 0.5.200 — reporting rather than assuming, since the changelog implied otherwise.

The iOS login chooser still renders the raw key. Screenshot captured by the gate on a 0.5.200 build (run 33819049744, artifact live-qa-macos-ios, shots/ios-login.png): the banner above "Last signed in: qaadmin" reads, verbatim:

mobile.login_setup_complete_relogin

Everything around it is localized normally ("Sign in with Apple", "Local Login", "View Privacy Policy"), so this looks like a missing key in the iOS bundle rather than a loader fault — but I have not traced it further than the screenshot.

Leaving open. Happy to re-check on the next build; the gate captures this screenshot on every iOS run now, so confirmation is one run away whenever you want it.

[emooreatx]

Thank you for reporting rather than assuming — the changelog did imply otherwise, and it was wrong. Fixed at 57e9558, though not where either of us was looking.

The key is not missing from our bundle. It is in all four, and has been since 0.5.185:

client/iosApp/iosApp/localization/en.json                    relogin: True   keys: 3892
client/androidApp/src/main/assets/localization/en.json       relogin: True   keys: 3892
client/shared/src/desktopMain/resources/localization/en.json relogin: True   keys: 3892
client/desktopApp/src/main/resources/localization/en.json    relogin: True   keys: 3892

What is missing is any bundle of ours in anything we publish. Both mobile loaders read the host application's resources — NSBundle.mainBundle on iOS, context.assets.open("localization/<code>.json") on Android — and neither artifact carries a single string:

ciris-client-0.5.200.aar              4 entries, no assets/
ciris-client-0.5.200.xcframework.zip  18 entries, zero .json

So every consumer embedding this client has to vendor 29 bundles themselves, and nothing we published said so, said which copy was authoritative, or gave you any way to notice yours had drifted.

You vendored the node's bundle — ciris_engine/data/localized/en.json. Reasonable: it is the nearest plausible copy and it is 96% right. It is also a different bundle serving a different surface, 3,739 keys to our 3,892, and the 185-key gap contains exactly:

mobile.login_node_already_claimed
mobile.login_setup_complete_relogin

That is why precisely one string on that screen rendered raw while the other 41 resolved. Your loader was working perfectly against a bundle that was short. Your instinct in the report — "a missing key rather than a loader fault" — was right; the missing key was just on your side of a line we never drew.

This is the same shape as the missing AAR POM (#31 item 4): we publish a component whose requirements are invisible, so a mismatch can only be discovered as a defect on a device.

Two halves, both in this commit:

1. ciris-client-<version>-localization.zip is now a release asset — 3.1 MB, 29 languages, 3,892 keys, versioned with the client that renders them. Unzip into your app's resources so localization/<code>.json resolves. There is now an authoritative copy and a version to pin to.
2. packaging/localization_bundle.py --verify <dir> answers "is mine current?" in one command and names the missing keys, rather than leaving them to be found one screenshot at a time. Run against the copy you have today it exits 1 and lists all 185.

It will be on the next release. Until then the canonical directory is client/shared/src/desktopMain/resources/localization/ — the other three are held byte-identical to it by CI.

One thing I have not done, and want your read: the deeper fix is embedding the strings in the artifacts so there is nothing to vendor wrongly. Android is straightforward (an AAR can carry assets/). iOS is not — NSBundle.mainBundle is the host app by definition, so it would need a resource bundle plus a loader change, and I cannot test that from here. If shipping the zip and the drift check is enough for you, I would rather leave it there than guess at an iOS packaging change I cannot exercise.

[emooreatx]

Our half shipped; the remaining half is a vendoring step on your side, so leaving this open.

The key was never missing from our bundle — it is in all four mirrors and has been since 0.5.185. What was missing is any bundle of ours in anything we published: both mobile loaders read the host app's resources (NSBundle.mainBundle, context.assets), and neither artifact carried a string.

Since 0.5.201 every release ships ciris-client-<version>-localization.zip — 29 languages, now 3,907 keys, unzips straight into an app's resources so localization/<code>.json resolves. packaging/localization_bundle.py --verify <dir> names a consumer's missing keys in one command; run against the copy your shell had, it exits 1 and lists them.

Your gate's iOS screenshots still showed the raw key through 0.5.202 because the shell bundles its own copy — most likely the node's ciris_engine/data/localized/en.json, which is a different bundle for a different surface: 3,739 keys to our 3,892, and the 185-key gap contained exactly mobile.login_setup_complete_relogin. Your loader was working perfectly against a bundle that was short.

Worth a check on the current run: if ios-login.png from the 0.5.203 gate still shows the raw key, the shell has not picked up the published bundle yet.

Closing this needs your side to adopt the asset, so it is yours to close when that lands — or tell me and I will.