PRACTICAL NOTES

Investigate an iPhone crash

Separate iPhone IPA setup from Mac reports, record your device and build, protect app data and collect useful evidence before retrying a crash.

PublishedTranslation updatedSources checked

Applies to iPhone IPA route; no device-specific gameplay test verified by this site. Additional checks: nxnative 201dfd1, 2026-10-28.

Start with the right platform

An iPhone needs the upstream IPA build and signing or sideloading route, not the Finder Mac app. Read the current project README for the device and system requirements. Meeting a requirement does not establish that a particular game works on your device. Our Odyssey iPhone record cites an author report; device-specific measurements are still unknown.

Prerequisites

Keep your exact device model, iOS version, project commit, game version and installation method in one note. Use only your own game and keys. Note whether the failure happens during installation, at launch, while preparing pipelines or after loading a save: those are different diagnostic stages.

A careful retry sequence

  1. Compare your setup with the requirements at your chosen upstream revision.
  2. If the app opens, copy save/ and pso_user.tsv from Files → app name before replacing it. Save log.txt from the same container when available.
  3. Check your signing or sideloading tool if installation or launch fails. Do not assume a Mac gameplay report explains a signing failure.
  4. Try one documented change at a time, then record the first point of failure again.
  5. If filing an issue, include the environment and relevant redacted log lines; do not upload game files or keys.

Checkpoint and failure handling

Some sideloading tools may replace the data container on reinstall. A fresh installation may therefore hide the old save rather than repair a game. Keep a separate backup and verify save visibility after any update. If the app cannot open and its Files container is unavailable, preserve the current installation while you investigate access; this guide cannot promise recovery.

Identify the first failed stage

SymptomFirst checkDo not assume
Installation tool rejects the IPATool error and signing configurationThat the game’s graphics code has run
App closes before the game startsDevice/OS requirements and available app logThat a newer game update will repair signing
App closes after a particular scene or saveReproducible steps, build and game versionThat every platform has the same defect
App opens but old progress is missingApp identity and data containerThat the save was erased or that reinstalling again will recover it

For the build-to-install sequence, use the iPhone/iPad installation guide. The upstream README discusses Increased Memory Limit support where available in your signing method. Record whether it was applied, but do not label every crash a memory issue or promise that this capability fixes it.

Prepare a report someone can reproduce

Keep a short note with the game/version, nxnative commit, device/chip, OS, installation tool, first failed stage and the smallest sequence that reaches it. Include whether a new session and an existing save behave differently only if you actually checked both. An unknown result should stay unknown.

The README locates log.txt under the app in Files, and identifies log.prev.txt as the previous run’s log. Copy useful evidence before repeating a launch. Review it for private paths or personal data before posting; never attach a key file or game data. If no container is accessible, record that limitation rather than uninstalling your only copy. Use save protection before a replacement.

Separate a container failure from a game crash

Checked on 2026-10-28 against nxnative 201dfd1 and the LiveContainer FAQ: first record whether failure happens while importing, signing, launching the container, or loading the game. A certificate error belongs to container/signing setup; changing shaders will not repair it. See the LiveContainer installation checks.

After backing up the guest’s data, follow LiveContainer’s suggestion to compare a direct AltStore/SideStore installation if your device/account supports that route. Treat it as a separate diagnostic installation, preserve the original, and record differences in signing capabilities. A direct-install result alone does not prove a container bug if those conditions differ.

If no nxnative log was written, an iOS crash report may still be available in Settings → Privacy & Security → Analytics & Improvements → Analytics Data; the wording can vary by system version. LiveContainer’s FAQ requests the container build hash, device, iOS version and reproduction steps. Review the crash report for personal information before sharing. If neither report is accessible, say so rather than guessing an out-of-memory cause.

The community SideStore tutorial contains reinstall and certificate-reset suggestions. They are not universal crash fixes. In particular, Increased Memory Limit must be supported by the actual signing/container setup; selecting an option is not independent evidence that the entitlement took effect or that a particular crash is memory-related.

Common questions

Can Mac frame rates be used for iPhone expectations?

No. We do not transfer Mac frame rates, devices or run status to iPhone or iPad records.

Sources & verification

Original guidance based on the linked project documentation and reports. Review dates are shown with each article.

Compatibility →