# Mac App Store 2.4.5 rejection: sandbox saves and update checks

> Guideline 2.4.5 is the list of extra rules for Mac App Store apps, and two of them catch indie Mac apps most often. What Apple wrote to us for 2.4.5(i) (files saved into the sandbox container) and 2.4.5(vii) (a built-in update check), and how to fix each.

- Canonical page: https://obelisk.club/blog/app-review-guideline-2-4-5-mac-app-store
- Author: Peter Zhang
- Published: 2026-10-30
- Tags: app-review, app-store, guideline-2-4-5, mac, sandbox, rejection, indie

A **Guideline 2.4.5** rejection means your Mac App Store app breaks one of the extra rules for Mac apps, most often **(i)** sandboxing (user files saved into the app's container, or entitlements broader than needed) or **(vii)** an update mechanism outside the Mac App Store. The fix is to save user files through a standard Save dialog, trim entitlements to ones you can explain, and remove the updater framework, not just its menu item, from the store build.

Guideline 2.4.5 is the list of extra requirements for apps sold on the Mac App Store. Two of its items have hit our Mac utilities: **(i)**, "They must be appropriately sandboxed", and **(vii)**, "They must use the Mac App Store to distribute updates; other update mechanisms are not allowed." Both pass every local build and test, because both are about where the app is distributed, not whether it works. If your message cites a different item of 2.4.5, paste your rejection message into the [App Review rejection decoder](/tools/app-review-rejection-decoder) to see what it asks for.

## 2.4.5(i): user files saved into the container

**What Apple said.** One of our Mac apps saved its output inside its own sandbox container. Apple's message: "The app saves user data to the app's container, which is not user accessible", quoting Apple's own sandbox guide: "the container is not for user documents." The suggested fix: "save user files to a location selected by or available to users, using standard Save dialogs."

**Why it happens.** In a sandboxed app, a plain write to the Documents directory works and the file exists, so nothing fails. It just lands in the app's container, a hidden location the user never opens. The container is meant for databases, caches and app data, not for things the user made.

**How to fix it.**

- **AppKit:** ask with `NSSavePanel`. Apple's docs note that the panel runs in a separate process and that macOS adds the saved file to the app's sandbox, so you can write to the URL it returns.

```swift
let panel = NSSavePanel()
panel.nameFieldStringValue = "Notes.txt"
panel.allowedContentTypes = [.plainText]
if panel.runModal() == .OK, let url = panel.url {
    try text.write(to: url, atomically: true, encoding: .utf8)
}
```

- **SwiftUI:** use the `fileExporter(isPresented:document:contentType:defaultFilename:onCompletion:)` modifier with a `FileDocument`.
- **Entitlement:** turn on App Sandbox in Xcode and set **User Selected File** to **Read/Write** (`com.apple.security.files.user-selected.read-write`), so the app may write where the user picked.

**Entitlements, the other half of (i).** We have had two more 2.4.5(i) rejections over entitlements that were broader than the app needed. Before submitting, read the entitlements of the signed build, make sure `get-task-allow` is not there (an easy one to miss), and remove any entitlement you cannot explain in one sentence.

## 2.4.5(vii): a built-in update check

**What Apple said.** A Mac utility of ours had a "check for updates" feature. Apple: "The app contains frameworks or APIs that may be used to update the app outside of the Mac App Store", and "You should not provide additional update checks or updates through the app." The reviewer attached a screenshot of where it appeared.

**Why it happens.** The same code base often ships two ways: a direct download that needs its own updater, and the Mac App Store, which already tells users about updates. The updater comes along into the store build by default.

**How to fix it.** Note the wording: Apple names frameworks and APIs, not only the menu item. Hiding the button is not enough.

1. Give the direct-download build its own configuration or target with a Swift compilation condition (Xcode's **Active Compilation Conditions**), for example `DIRECT_DOWNLOAD`.
2. Wrap the updater code and its menu item in `#if DIRECT_DOWNLOAD ... #endif`.
3. Link the update framework only into the direct-download target, so the Mac App Store binary does not contain it.
4. Remove "check for updates" settings, preferences and onboarding text from the store build too.

## FAQ

### How do I fix a 2.4.5(i) rejection for saving files to the app's container?

Let the user choose where to save with a standard Save dialog: `NSSavePanel` in AppKit or `fileExporter` in SwiftUI. Turn on App Sandbox with User Selected File set to Read/Write so the app may write where the user picked.

### Can a Mac App Store app have a "check for updates" button?

No. Guideline 2.4.5(vii) says Mac App Store apps must use the store to distribute updates, and Apple's message names frameworks and APIs, not only the menu item. Keep the updater out of the store binary with a compilation condition and a separate target.

### Why did I get a 2.4.5(i) rejection for entitlements?

Entitlements broader than the app needs also fall under (i). Read the entitlements of the signed build, make sure `get-task-allow` is not there, and remove any you cannot explain in one sentence.

### Is hiding the update menu item enough to pass 2.4.5(vii)?

No. Remove the update framework from the Mac App Store build, along with update settings, preferences and onboarding text.

## One-minute check

On the archive you are about to upload: save something from the app and confirm a Save dialog asked you where. Open the app menu and Settings and confirm there is no update item. List the bundle's `Contents/Frameworks` folder and confirm no updater framework is inside. Then print the signed entitlements with `codesign -d --entitlements - YourApp.app` and read every line.

Mac apps also get a design rejection that iPhone apps never see: [no way to reopen the main window](/blog/app-review-guideline-4-mac-window-reopen). More release checks are on the [toolkit page](/toolkit), and the commonest first rejection is [2.1, App Completeness](/blog/app-review-guideline-2-1-app-completeness-rejection).

*These notes are from Obelisk Club's own submissions. Apple's wording and tools change; check the current App Review Guidelines and Apple's documentation for exact behaviour.*