If App Store Connect just sent back a Guideline 2.1 rejection citing 'The app crashed on iPad running iPadOS 18.2,' you are looking at the most literal kind of review failure. Apple's reviewer launched your build on a specific iPad, the process aborted, and the rejection arrived with the crash log attached. Everything that follows depends on reading that log carefully.
Short answer
A Guideline 2.1 rejection that names 'App crashed on iPad running iPadOS 18.2' means Apple's reviewer hit a hard crash on a specific iPad model during App Review. The message attaches a .crash or .ips log. Download the log, symbolicate it with the matching dSYM, reproduce the crash on the same iPad model or in the Xcode simulator at iPadOS 18.2, fix the call that aborted, and resubmit with build notes that explain exactly what changed.
What you should know
- Guideline 2.1 covers App Completeness. The published text in the App Review Guidelines closes section 2.1(a) by stating that Apple will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems.
- Reviewers test on real iPads. Crashes that never appeared in your local Xcode simulator can still trip this gate, especially on iPadOS point releases that change runtime behavior.
- The rejection ships with a crash report attachment. Open App Store Connect, go to the Resolution Center thread, and download the .crash or .ips file the reviewer captured.
- An unsymbolicated crash log is mostly hex addresses. You need the matching dSYM, which lives in your Xcode archive or in App Store Connect under the build metadata.
- iPadOS 18.2 introduced WebKit and editing-context changes. Forum reports from early 2025 noted new crashes inside WebKit document editing routines for apps that embed web views, a regression that did not show up under iPadOS 17 or earlier.
What does 'App crashed on iPad running iPadOS 18.2' mean in plain terms?
The short answer is that Apple's review fleet runs each submitted build on multiple device classes, and at least one iPad in that fleet hit an abort signal during the session. The reviewer is required to report the failure under Guideline 2.1, the App Completeness section that says the binary must run.
In practice, the message you see in Resolution Center will name the device (commonly 'iPad Air (5th generation)' or a more recent model) and the iPadOS version (18.2 or a point release like 18.2.1). The attachment is a crash report in Apple's .ips format that includes the process name, the exception type (usually EXC_CRASH paired with SIGABRT, or EXC_BAD_ACCESS), the responsible thread, and the unsymbolicated stack frames.
The limit is that this report alone almost never explains the crash. It tells you where the process died inside system libraries, not why your code called the bad path. That is the work of symbolication.
How do you find and symbolicate the crash log Apple's reviewer attached?
The log lives in two places, and you should grab both. First, in App Store Connect Resolution Center, open the rejection thread for the rejected build. The reviewer attaches the crash report as a downloadable file under the rejection message. Save it locally with the .crash or .ips extension intact.
Second, in Xcode go to Window, then Organizer, then Crashes. The Organizer pulls crash reports for distributed builds from Apple's servers, including reports captured during App Review when the build is the one currently in review. The Organizer view symbolicates automatically when it can find the matching dSYM, so if your archive is still on the same Mac you usually see resolved function names without any extra work.
Symbolication is the step that turns hex addresses like 0x000000010001a3b0 into readable lines such as LoginViewController.signIn(_:). Apple's guide on acquiring crash reports and diagnostic logs covers the supported flow, and the companion guide on adding identifiable symbol names explains what files are required. The three inputs that must match by UUID are the executable binary, the dSYM, and the crash report itself. Verify with the dwarfdump --uuid command. If any UUID differs, symbolication silently fails and you are left guessing.
For no-code builds, the situation is harder. FlutterFlow, Bubble, and similar exporters generate Xcode projects on each build, so the dSYM you need is the one produced during the export that App Store Connect actually received. Keep that archive; do not re-export and assume the new dSYM will match. If your build was uploaded with bitcode or if your builder strips local dSYMs, download the dSYM from the TestFlight tab in App Store Connect first, then symbolicate manually.
Why do AI-generated and no-code builds crash more often on iPad than iPhone?
The honest answer is that most AI-coded scaffolds, and most no-code templates, are tested primarily on iPhone layouts. iPad introduces a wider screen, multi-window scenes, larger keyboards, drag-and-drop, and (since iPadOS 16) Stage Manager. Each of these is a path the build might never hit on iPhone.
Common iPad-specific failure modes in AI-generated builds include force-unwrapping a view that does not exist in the iPad layout file, missing UIScene configuration for multi-window, a UISplitViewController configured with no primary view, and assumptions about UIWindow.bounds that no longer hold under Stage Manager. Apps that embed web views also see iPadOS-specific WebKit changes; an Apple Developer Forums thread documented a 2025 crash in WebKit::WebPage::requestDocumentEditingContext on iPad Air (5th generation) running iPadOS 18.2.1 that did not appear on earlier versions.
A vibe-coded build also tends to leave debug-only code paths in the binary that hit network calls or shared state in surprising ways under review-fleet conditions. Treat that as a directional pattern reported by developers, not an officially documented Apple behavior.
How do you reproduce a crash you cannot trigger locally?
Reproducing the crash is the single highest-value step before resubmitting. Without a local repro, the fix is a guess.
| Approach | When to use | Trade-off |
|---|---|---|
| Xcode simulator at exact iPadOS version | First attempt for layout or WebKit crashes | Simulator does not catch hardware-specific bugs |
| Physical iPad matching the reviewer's model | Login, networking, and sensor crashes | Requires owning the hardware |
| TestFlight external testing | Slow path but uses Apple-signed builds | 24 to 48 hour feedback loop |
| Network Link Conditioner with poor connection profile | Login and API crashes during review | Catches timeout-driven aborts |
| Symbolicated crash log read line by line | Always | Tells you the failing function, not the root cause |
Match the exact iPadOS version Apple cited. The Xcode simulator catalog supports downloading older runtimes via Settings, then Components. For iPadOS 18.2 specifically, install the 18.2 simulator runtime if you only have 18.3 or later installed: behavior can drift between point releases.
If the crash log points to a system framework, search the Apple Developer Forums for the exact symbol name. Several iPadOS 18.x crashes turned out to be regressions Apple had acknowledged in forum responses, not bugs in the submitting app.
What should the resubmission notes say?
Reviewers read the notes you attach to a new build. Make those notes do work. Name the iPadOS version cited in the rejection, name the crash signature (the topmost symbolicated frame in your code), describe the fix in one sentence, and confirm that you reproduced and verified the fix on the same iPad model or simulator runtime. If the crash was inside a system framework and you worked around it, say so plainly and link the radar number if you filed one. This makes the next review faster and reduces the chance of a second rejection on the same gate.
What to watch out for
- Do not appeal a Guideline 2.1 crash rejection without a fix. App Review's appeals process is for editorial disputes, not for crashes Apple captured on a real device.
- Do not assume the crash is in your code. Some iPadOS 18.x crashes are in WebKit or other system frameworks. Reading the symbolicated log honestly is the only way to tell.
- Do not resubmit the same binary with different notes. The build UUID is the same, and Apple's automated layer will likely catch the repeat.
- Reject the myth that a clean TestFlight run proves a Guideline 2.1 fix. TestFlight installs to consenting testers and skips several review-only checks, so it is not a substitute for testing on the exact iPad model and iPadOS version the rejection cited.
Key takeaways
- The rejection wording 'App crashed on iPad running iPadOS 18.2' always points to a specific log file in Resolution Center; download it before doing anything else.
- Symbolicate with the matching dSYM, then read the topmost frame in your own code; that is where the fix lives.
- Reproduce on the exact iPadOS version cited before you ship a new build, or you are guessing.
- Resubmission notes that name the crash, the fix, and the verification step turn the second review around faster.
- Some teams outsource a pre-submission scan to platforms like PTKD.com (https://ptkd.com) that read compiled IPA files for the patterns that historically trip Guideline 2.1, before App Review sees the build.
