docs(mobile): complete the App Store 4.7 self-audit - #291
Conversation
Checked against the shipped tree rather than against intent. Clean: no ROM acquisition path -- load_rom takes bytes from the caller, and there is no download, fetch or URL anywhere in rustysnes-mobile or rustysnes-android. No bundled copyrighted content -- the game DB ships empty and is user-loaded; the three 'Super Mario World' strings are a doc comment and two test fixtures, none of which reaches a binary. Findings: 'Super Nintendo Entertainment System', 'Super Famicom' and 'Super Scope' appear in user-facing strings. The app's own identity is clean (android:label and PRODUCT_NAME are RustySNES, bundle IDs are com.doublegate.*), and naming the emulated hardware is ordinary nominative use -- but App Store review is conservative and 4.7 rejections have cited exactly this. Recorded as a RECOMMENDATION to soften the two iOS-visible surfaces before submission, for the maintainer to accept or reject. Deliberately not applied: it is a judgement about review risk, not a legal conclusion, and the desktop strings face no reviewer at all. The touch UX for Mouse/Super Scope/Multitap does not exist yet, so its naming and art could not be audited; the doc says to re-run that item once it does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 6 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Comment |
Antigravity review (Gemini via Ultra)This PR updates Blocking issuesNone found. Suggestions
Nitpicks
Automated first-pass review by |
#332 stated the App Store §4.7 self-audit "had never been done" and added docs/app-store-4-7-self-audit.md as though performing it. The audit already existed: docs/mobile-readiness.md's own "App Store §4.7 self-audit" section, written in #291, marked done and struck through in the deferred list. The duplication is not the serious part. The two reach DIFFERENT VERDICTS on trademark exposure, and the newer one is the permissive one: authoritative (#291), whole shipped tree -> FINDINGS, maintainer decision: cli.rs:60,61,351 and ui_shell.rs:942,1723 carry "Super Nintendo Entertainment System" / "Super Famicom"; ui_shell.rs:1534 is a "Super Scope" picker label. supplement (#332), mobile shells only -> clean, and clean ONLY because it never looked at the desktop frontend. A reader landing on the newer file would have taken a scoped pass for a project-wide clean bill. Both files now open by naming which governs, with a scope table; the supplement's trademark criterion points at the authoritative section before making any claim; and its title says "supplement", not "audit". The #332 CHANGELOG entry carries the correction inline rather than being rewritten, and mobile-readiness.md records that the false claim was made. A readiness document whose corrections are invisible is the thing that file exists to avoid. Nothing was lost: #291's audit and all three of its references survived #332 intact. The error was additive, not destructive. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Third
v1.30.0item, after #289 (Android CI) and #290 (iOS launch).Checked against the shipped tree, not against intent.
Clean
No ROM acquisition path.
load_rom(rom: Vec<u8>)takes bytes from the caller. No download, no fetch, no URL of any kind inrustysnes-mobileorrustysnes-android— the app cannot obtain content on the user's behalf, which is the substance of §4.7.No bundled copyrighted content. The game DB ships empty and is loaded from a user-supplied file; there is no
include_str!of a title list. The three "Super Mario World" strings ingame_db.rsare a doc comment and two test fixtures insidemod tests— none reaches a binary.Findings
"Super Nintendo Entertainment System", "Super Famicom" and "Super Scope" appear in user-facing strings (
cli.rs, two About dialogs, and the peripheral picker).What is already right: the app's own identity carries no Nintendo mark —
android:labelandPRODUCT_NAMEare bothRustySNES, bundle IDs arecom.doublegate.*. Nothing passes itself off as a Nintendo product, and naming the hardware you emulate is ordinary nominative use.But App Store review is conservative here and §4.7 rejections have cited exactly this.
Left as a recommendation, not applied
Soften the two iOS-visible surfaces before submission — the About string and the "Super Scope" label — and keep the marks in the desktop CLI, which no reviewer sees.
I have deliberately not made that change. It is a judgement about review risk rather than a legal conclusion, and it is the maintainer's call; applying it unilaterally would also make the About text less accurate for the desktop build.
Not covered
The touch UX for Mouse/Super Scope/Multitap does not exist yet, so its naming and art could not be audited. The doc says to re-run that item once it does.
🤖 Generated with Claude Code