apple: add rustynes core to App Store builds

[doublegate]

The RustyNES core builds cleanly for every Apple target on the buildbot but is absent from appstore_cores, so it is never bundled into the App Store builds and is unavailable to users on iOS, iPadOS and tvOS.

One line, inserted in alphabetical order between reminiscence and sameboy:

     quicknes
     race
     reminiscence
+    rustynes
     sameboy
     sameduck

This is not a build problem

I verified the artifact before submitting rather than assuming the buildbot output was usable. nightly/apple/ios-arm64/latest/rustynes_libretro.dylib.zip:

• Mach-O 64-bit arm64 dynamically linked shared library, 1.3 MiB unpacked
• exports all 51 retro_* symbols, including the full disk-control interface (retro_get_num_images, retro_set_image_index, retro_add_image_index) that the FDS multi-side support needs

Present and building on ios-arm64, tvos-arm64 and osx/arm64, so this single entry covers iOS, tvOS and the macOS App Store build.

About the core

rustynes is a cycle-accurate NES/Famicom core written in Rust (libretro/RustyNES on the buildbot; info file in libretro-super/dist/info/). Relevant to bundling:

• No JIT and no dynamic code generation — a straightforward interpreter, so nothing here conflicts with App Store restrictions.
• Software rendering (hw_render = "false"), no external runtime dependencies.
• Deterministic, with savestate_features = "deterministic" — so run-ahead and RetroArch's rollback netplay both work.
• Native SET_MEMORY_MAPS for achievements, disk control for FDS, and native Game Genie cheats.

Licensing

RustyNES is GPL-3.0-or-later. Flagging it explicitly since App Store distribution is the context: this matches mesen and bsnes_hd_beta, which are GPLv3 and already in this list, and RetroArch itself. The copyright holder is aware of and has approved App Store distribution under these terms.

Two companion PRs correct the core's advertised license, which predates a relicense: libretro-super#2069 and docs#1180.

Happy to adjust anything that doesn't fit house convention.

[Copilot]

Pull request overview

Adds the rustynes libretro core to the Apple App Store export set so it gets bundled into iOS/iPadOS/tvOS (and macOS App Store) builds produced via the appstore path in the Apple core update script.

Changes:

• Include rustynes in appstore_cores (kept in alphabetical order).

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[doublegate]

Flagging the two red checks — build and Cross-arch crc32_test (armv7) — since they'd otherwise look like this PR's doing.

This PR changes exactly one file:

pkg/apple/update-cores.sh  +1 -0

a single entry added to the appstore_cores bash array. The failing steps are Compile RA and Build crc32_test for armv7, both C compilation steps. That shell script isn't compiled and isn't consumed by any C build — it's invoked from the Xcode build phase for App Store packaging — so there's no mechanism by which this change could affect either.

I couldn't read the job logs to identify the actual cause (they're not fetchable without repo access), so I'm not claiming to know what broke — only that it isn't this. For what it's worth, the comparison PRs I checked last ran their checks on Aug 12 and Aug 15, whereas this branch's run is from Aug 16, so they wouldn't reflect a recent master state either way.

Happy to rebase onto current master for a fresh run if that's useful, or to leave it alone if these are known-flaky. Just let me know.

[LibretroAdmin]

@doublegate Don't worry those two CI jobs are already fixed in master, it had nothing to do with your PR