Rejected

“Two rejection reasons. One was my fault. One was almost my fault.”

The email arrived a few days after submission. No drama in the subject line. App Store Connect showed two guideline violations: 2.1(a) and 2.1(b). A crash, and a UI that looked broken.

Apple attaches a crash log to the rejection. I opened it.

Rejection 1: Guideline 2.1(a), the Crash

A crash log reads top-down: exception type, crashed thread, then stack frames with the closest to the crash first. The frame that matters is the first one past the system frames and into your code.

The log named dispatch_assert_queue_fail: the process tried to run code on the wrong dispatch queue, and a runtime assertion killed it.¹ The thread: com.apple.launchservices.open-queue. The frame directly above it: a closure inside DiagnosticsViewModel.openApp().

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000001xxxxxxxx
Crashed Thread:  com.apple.launchservices.open-queue

Thread 7 Crashed:: com.apple.launchservices.open-queue
0   libdispatch.dylib       dispatch_assert_queue_fail + 120
1   AppKit                  -[NSWorkspace _callCompletionHandler:...] + 88
2   Renala                  closure #1 in DiagnosticsViewModel.openApp() + 64
    // ^^^ This is the empty { _, _ in } closure.
    //     Swift 6 marked it @MainActor.
    //     It's running on the launch services queue.
    //     dispatch_assert_queue_fail fires.

The call site looked like this:

NSWorkspace.shared.openApplication(
    at: url,
    configuration: config,
    completionHandler: { _, _ in }
)

An empty closure, passed because the API has a completion handler parameter. The developer equivalent of nodding politely. It does nothing. So how did it crash?

DiagnosticsViewModel is @MainActor. In Swift 6, a closure that is not explicitly marked @Sendable (safe to pass across concurrency boundaries) or nonisolated (not bound to any specific actor) inherits the actor isolation of its enclosing context.² So {'{'{'}'} _, _ in {'}'} became @MainActor {'{'{'}'} _, _ in {'}'}.

But NSWorkspace.openApplication(at:configuration:completionHandler:) calls the completion handler on com.apple.launchservices.open-queue, not on the main actor. Starting with macOS Sequoia, AppKit began enforcing that expectation with dispatch_assert_queue.³ If the closure is marked @MainActor but runs on a different queue, the assertion fires and the process crashes.

macOS Sequoia was not installed on my development machine. Of course it wasn’t.

The fix is one line removed. If the completion handler does nothing, remove it entirely:

NSWorkspace.shared.openApplication(at: url, configuration: config)

No closure, no type annotation, no assertion violation.⁴

The tension is real. Swift 6 inferred @MainActor on the closure, following its own rules correctly. But the API calls the closure on a different queue. Before macOS Sequoia, this mismatch was invisible. After, it crashes.

The compiler cannot catch it because the completionHandler parameter in AppKit’s header lacks the annotations that would surface the conflict at compile time.⁵ An empty closure is not free. In Swift 6, even doing nothing has a type, and that type has opinions about where it runs. For a deeper look at how this compares across languages, see Where Does Nothing Run?.

Rejection 2: Guideline 2.1(b), the Empty Tip Jar

The second rejection was the more interesting one. The tip jar appeared blank during review. No products, no error. Just an empty sheet where the tip options should be.

The root cause:

// What you expect:
let products = try await Product.products(for: ["tip_small", "tip_medium", "tip_large"])
// products: [Product, Product, Product]

// What the reviewer gets:
// products: []  (no error, no exception, just empty)

Product.products(for:) returns an empty array when the Paid Apps Agreement in App Store Connect is not active.⁶ The agreement requires banking information, tax forms, and Digital Services Act compliance documentation to be completed first. Without an active agreement, Apple’s sandbox does not serve paid products regardless of their individual configuration. There is no error, no thrown exception, just an empty array, indistinguishable from “you made a typo in your product identifier.”⁷

The local StoreKit configuration in Xcode masked the problem entirely: every development and testing session served products from a local JSON file, bypassing Apple’s servers. The tip jar always worked on the developer’s machine.

An empty sheet with no explanation looks like a broken app. The reviewer sees a UI with nothing in it. They flag it under 2.1(b).

The fix: detect when the products array is empty and show a message instead of nothing.

if products.isEmpty {
    Text("Tips are not available right now.")
        .foregroundStyle(.secondary)
} else {
    // tip buttons
}

An empty sheet looks broken. A message looks intentional. The difference between a bug and a feature is sometimes just a label.

Both rejections, their root causes, and their fixes:

The Resubmission

Both fixes together. The crash fix removed one line. The tip jar fix added a conditional text view. Neither change touched any other functionality.

Bump build number, tag, let the pipeline run. The second review was faster than the first.

On Reading Crash Logs

The structure is always the same: exception type at the top (EXC_BREAKPOINT means the runtime hit a programmatic assertion, not an actual debugger breakpoint⁸), crashed thread, then stack frames closest to the crash first.

In this case, three data points told the whole story. The frame named the exact closure. The queue name was in the thread label. The assertion name described precisely what went wrong. From there, the cause was clear.

Apple does not include the Swift type annotation in the crash log. That requires reading the source. But the log points to the right location. Reading source from a specific frame is faster than general debugging.

The crash was on a macOS version not installed locally. The fix was a one-line deletion. The cost of not catching it earlier: 6 reviews across 4 versions, a few weeks of review time.

That cost is what gets you to set up testing on the full range of supported OS versions, or at minimum to spin up a VM before resubmitting. The crash was obvious once the log was in hand. The gap was not having the environment to reproduce it before submission.

References

• Apple: App Store Review Guidelines 2.1
• Apple: Understanding the exception types in a crash report
• Apple: Testing in-app purchases in Xcode
• WWDC 2018: Understanding Crashes and Crash Logs