First-scan walkthrough: extracting the prep content from APK strings.xml

The earlier OnboardingSheet had six pages that I’d written from rough memory of the APK plus product reviews. They covered the right topics (clothing, hair, pose, privacy), but the bullet text was paraphrased and generic. The APK has the original copy, written by whoever wrote the Naked product manuals, embedded as string resources in res/values/strings.xml. Worth using verbatim.

A quick grep -E 'first_scan_prepare' strings.xml returns:

first_scan_prepare_clothing_bullet_1   "Loose clothing will impact your metrics"first_scan_prepare_clothing_bullet_2_men   "Go bare-chested on top"first_scan_prepare_clothing_bullet_2_women "Bra, sports bra, bikini, or nothing on top"first_scan_prepare_clothing_bullet_3_men   "Briefs, boxer briefs, compression shorts or nothing on bottom"first_scan_prepare_clothing_bullet_3_women "Use a ponytail, bun or swim cap to pull hair off your neck"first_scan_prepare_clothing_bullet_4   "Leave on glasses and jewelry, but take off socks"first_scan_prepare_hair_bullet_1       "Long hair will impact your metrics"first_scan_prepare_hair_bullet_2       "Hair must not touch your neck or shoulders"first_scan_prepare_hair_bullet_3       "Use a ponytail, bun or swim cap to pull hair off your neck"first_scan_prepare_lighting_bullet_1   "Bright light can cause bad scans"first_scan_prepare_lighting_bullet_2   "Avoid direct light on your body or the mirror"first_scan_prepare_lighting_bullet_3   "Turn off lights and pull down shades"first_scan_prepare_lighting_bullet_4   "You can scan in the dark"first_scan_prepare_routine_bullet_1    "We recommend scanning weekly"first_scan_prepare_routine_bullet_2    "This minimizes noise but shows progress"first_scan_prepare_routine_bullet_3    "Scan at the same time of the day and on the same day of the week"

The first thing worth noticing: there are gendered variants for some clothing bullets (_men / _women keys, plus a _unisex for bullet_4), but only for clothing. Hair/lighting/routine bullets are gender-neutral. Three of the four bullets the APK shows under “Clothing” change copy based on the user’s stored gender; iOS adapts that into a single combined bullet for the iOS pass.

“You can scan in the dark” is the kind of detail that makes a product manual feel lived-in. It’s reassuring information: the user is about to undress in their bedroom in low light and the app is telling them that’s fine, that’s how it’s supposed to work. Worth keeping verbatim.

The routine bullets (“scan weekly at the same time of day, same day of the week”) answer a question the user will have within a week of owning the device: how often should I do this? The APK has a clear answer. The iOS version had been silent on it.

§ 22.1

Page structure

Each APK first-scan fragment has the same shape: a small step indicator at top-left (01 / 06, 02 / 06, etc.), an icon, a title, body text, optional bullet list, and a “Next” button bottom-right. iOS structures it as a paged TabView (.page style) where each page contains:

An icon (SF Symbols for now; APK has custom Lottie animations that I’m not porting)
The chapter label (01 / 06)
A title
Body text
An optional bullet list with accent-colored dots

Page count became 8 (intro, 6 numbered chapters, privacy outro):

Fig. 22-1

flowchart LR
    A[Intro] --> B["01 What to wear"]
    B --> C["02 Hair off your neck"]
    C --> D["03 Lighting"]
    D --> E["04 Position the scale"]
    E --> F["05 The pose"]
    F --> G["06 Step off & step in"]
    G --> H[Privacy outro]

The iOS page count slightly compresses the APK’s ~10 fragments: fragment_first_scan_intro, fragment_first_scan_intro_prepare, fragment_first_scan_prepare, and fragment_first_scan_align_scale are essentially one continuous “prep” topic on iOS rather than four separate APK fragments, so they got merged.

§ 22.2

Bullets, not paragraphs

The APK uses a custom bullet drawable (@drawable/ic_bullet), a small circle next to each list item. iOS uses a Circle().fill(AppTheme.accent).frame(width: 6, height: 6) to match. The same visual idiom regardless of platform: an accent-colored 6pt circle with text to the right, indented 10pt from the chapter content’s leading edge.

The bullets carry the load on the prep page. The body text introduces the topic in one sentence; the bullets enumerate the rules. Trying to write this as flowing prose (“for accurate measurements, wear…”) is verbose; the bullet form is one rule per visual line. The original APK strings already use this shape; iOS just follows.

§ 22.3

Privacy outro is iOS-specific

The eighth page is iOS-only:

Your scans stay yours Avatars and measurements live only on this device. Your profile syncs encrypted via iCloud Keychain, and nothing ever lands on Naked Labs servers.

The APK has no equivalent because in the APK’s world, the cloud was active and scans did land on Naked Labs servers. For the recovery app, the cloud is dead and I hold everything locally, and that’s a feature worth stating explicitly to anyone setting up a recovered scanner. The text mentions Naked Labs by name because the audience for this app is owners-of-Naked-mirrors specifically, who already know the brand and the dead-cloud context.

§ 22.4

What got skipped

The APK’s full OOBE has ~70 layouts including 20+ scanner-pairing fragments (fragment_oobe_bluetooth_pairing, fragment_oobe_downloading_firmware, fragment_oobe_scanner_set_up, etc.). All skipped. By the time a recovery-app owner gets here, the device has been physically paired and the firmware is whatever it is. The iOS app doesn’t run a setup wizard, it just talks to whatever scanner answers.

Auth/account-creation fragments (Login, Signup, MFA, Verify Email, Set New Password): also all skipped. iOS uses UserKeyStore (iCloud Keychain UUID) for per-user scoping; no account, no password, no email.

fragment_first_scan_check, fragment_first_scan_final_prepare, fragment_first_scan_reminder: these are intermediate confirmation screens between “you’ve read the prep” and “we’re about to scan.” iOS folds them into the ScanFlowView’s existing state machine (the pre-flight check + alignment + confirm-alignment sequence already does the same gating).

§ 22.5

Surfacing it

The walkthrough is launched from the MoreTab → Scan tips & setup row that already existed. It’s not shown automatically. The prod app’s FirstLaunchSheet still captures name/height/units on first launch, and the walkthrough is a user-initiated read-when-you-want-it surface. That matches how the APK does it; their first-scan flow runs on the literal first scan, but is also reachable from MoreFragment afterward.

Five phases in, one to go. Phase F is profile/settings/history polish: the MoreTab itself, MirrorSettingsView, ProfileEditView, and HistoryView chart styling.

§ 22.6

Follow along

Procedure 22-A

This post is almost entirely content extraction rather than a debugging journey, so the clean version and the story above are nearly the same thing. If you’re pulling first-scan prep copy out of your own decompiled APK:

1
Grep res/values/strings.xml for the fragment’s key prefix (here, first_scan_prepare) rather than paraphrasing from memory or reviews. The original product-manual copy is almost always better than a rewrite.
2
Watch for gendered key variants (_men / _women / _unisex suffixes). Decide per topic whether to keep the split or combine into one neutral bullet; the APK itself doesn’t gender every topic, so check each one rather than assuming.
3
Match the APK’s structural shape (step indicator, icon, title, body, optional bullet list) even if you’re not porting its exact animation assets. A paged TabView(.page) with that per-page content block covers it on iOS.
4
Fold intermediate confirmation fragments into your existing state machine rather than building new screens for them, if your app already gates the same transitions elsewhere.
5
Surface the walkthrough as a user-initiated, re-readable entry point (a settings row), not just a one-time first-launch sheet, if the source app does the same.

§ 22.7

Agent prompts Procedure 22-A as prompts for a coding agent · 5 prompts

Paste into Claude Code or a similar agent, one at a time, from the root of your iOS project. Each prompt maps to the step with the same number above.

Extract copy from strings.xml

In the decoded APK's `res/values/strings.xml`, run `grep -E 'first_scan_prepare'` (substitute the relevant fragment's key prefix) to pull the original product-manual bullet copy verbatim, rather than paraphrasing from memory, screenshots, or reviews. Use these strings directly in the SwiftUI onboarding/walkthrough content.

Resolve gendered string variants

When extracted string keys include gendered suffixes (`_men`, `_women`, `_unisex`), check each topic (clothing, hair, lighting, routine) individually rather than assuming all are split. For a topic that only has unisex copy, use one neutral bullet; for a topic with men/women variants, decide whether to keep them conditional on stored user gender or combine into one neutral bullet, and note the decision.

Match fragment structure in a paged TabView

Rebuild the walkthrough as a SwiftUI `TabView(.page)` where each page matches the APK fragment's structural shape: a step indicator (`01 / N`), an icon, a title, body text, and an optional bullet list rendered with small accent-colored dot markers (e.g. `Circle().fill(AppTheme.accent).frame(width: 6, height: 6)`). Merge any APK fragments that cover one continuous topic (e.g. intro + prepare + align-scale) into a single page rather than preserving a 1:1 fragment-to-page mapping if that's a more coherent user flow.

Fold confirmation fragments into existing flow

For APK fragments that are intermediate confirmations between "user has read the prep content" and "scan begins" (e.g. `fragment_first_scan_check`, `fragment_first_scan_final_prepare`, `fragment_first_scan_reminder`), do not build new standalone screens for them if your app's existing scan-flow state machine already gates the same transitions (pre-flight check, alignment, confirm-alignment). Confirm the existing gating covers the same user-facing confirmation and skip the redundant screens.

Expose walkthrough as a re-readable entry point

Add (or confirm) an entry point to the first-scan walkthrough content from a persistent settings/more-tab row (e.g. "Scan tips & setup") so a user can re-open it anytime, rather than only showing it once during first launch. Keep the separate first-launch onboarding sheet (e.g. name/height/units capture) as its own distinct flow.