Distribute a Mac app: Mac App Store or notarization.

Without an active membership nothing can be uploaded to App Store Connect. Apps in regulated fields are submitted by the legal entity that provides the service (5.1.1(ix)).

Verify: developer.apple.com → Account: active membership and correct seller name.

Evidence: Screenshot of the Account page.

Apple Developer Program — Enrollment ↗ · reviewed 2026-10-23

Without a verified trader status the app is removed from EU storefronts and its updates are blocked there (Digital Services Act).

Verify: App Store Connect → Business → Compliance: status declared and verified.

Evidence: Screenshot of the DSA status.

App Store Connect Help — EU Digital Services Act trader requirements ↗ · reviewed 2026-10-23

Mac App Store apps must be appropriately sandboxed (2.4.5(i)). File access goes through user-selected files and security-scoped bookmarks; every extra entitlement must serve a real feature.

Verify: Run the sandboxed Release build and repeat every flow that reads or writes files, uses the network or hardware.

Evidence: List of entitlements with their justification.

Common failure: A feature that worked outside the sandbox and fails silently once sandboxed.

Apple — Configuring the macOS App Sandbox ↗ · reviewed 2026-10-23

The app is packaged and submitted with Xcode tools, with no third-party installer, as a single bundle that installs nothing in shared locations (2.4.5(ii)). Since 18 February 2025, no file may carry the com.apple.quarantine attribute to be uploaded.

Verify: Distribute App → App Store Connect from the Organizer completes without validation errors.

Evidence: Build visible in App Store Connect.

App Review Guidelines 2.4.5 — Mac App Store requirements ↗ · reviewed 2026-10-23

The build is signed for App Store distribution, entitlements matching the App ID. It does not need notarization: Apple states that Mac App Store submission already includes equivalent security checks. Notarization is for direct distribution (Developer ID).

Verify: The archive is distributed through “App Store Connect”, not through “Developer ID”.

Evidence: Distribution method chosen in the Organizer.

Apple — Notarizing macOS software before distribution ↗ · reviewed 2026-10-23

Since 1 May 2024, new and updated apps declare approved reasons for the APIs Apple lists, including those used by third-party SDKs.

Verify: Organizer → Generate Privacy Report on the archive.

Evidence: Archive privacy report.

Apple — Privacy manifest files ↗ · reviewed 2026-10-23

Mac App Store apps update through the Mac App Store; any other mechanism (Sparkle or a custom updater) is not allowed (2.4.5(vii)). Remove it from the App Store target if you share code with a Developer ID version.

Verify: Look for any updater framework or “Check for Updates” menu in the App Store target.

Evidence: List of frameworks linked to the App Store target.

Common failure: “Check for Updates” menu left in the build: 2.4.5 rejection.

App Review Guidelines 2.4.5 — Mac App Store requirements ↗ · reviewed 2026-10-23

No launch at login or processes that keep running after quitting without consent (2.4.5(iii)), no downloaded code or apps adding features (2.4.5(iv)), no root escalation (2.4.5(v)), no licence screen or licence key (2.4.5(vi)).

Verify: Quit the app: no process remains (Activity Monitor). Restart: nothing launches without the user’s consent.

Evidence: Activity Monitor test result.

App Review Guidelines 2.4.5 — Mac App Store requirements ↗ · reviewed 2026-10-23

Final version, tested for crashes and bugs, with no placeholder text or temporary content (2.1(a)). It runs on the currently shipping macOS (2.4.5(viii)).

Verify: Test the TestFlight build on the current macOS and the oldest supported version, Apple silicon and Intel if the app is universal.

Evidence: List of Macs and macOS versions tested.

Common failure: Crash at first launch on the latest macOS: 2.1 rejection.

App Review Guidelines 2.1 — App Completeness ↗ · reviewed 2026-10-23

First launch, opening and saving documents, main task, purchase and restore if any: each flow works in the submitted sandboxed build.

Verify: On a fresh macOS user account, repeat each flow.

Evidence: Dated list of the flows tested.

App Review Guidelines 2.1 — App Completeness ↗ · reviewed 2026-10-23

Resizable windows, full screen, multiple windows when relevant, a complete menu bar and standard keyboard shortcuts: a Mac app that behaves like an enlarged iPhone app disappoints and can be judged incomplete.

Verify: Resize each window to extreme sizes; use the app with the keyboard only for five minutes.

Evidence: Screenshots at minimum and maximum sizes.

Human Interface Guidelines — Windows ↗ · reviewed 2026-10-23

Mac App Store apps contain all language and localization support in a single bundle (2.4.5(ix)).

Verify: Change the app’s preferred language in System Settings and relaunch it.

Evidence: Languages checked.

App Review Guidelines 2.4.5 — Mac App Store requirements ↗ · reviewed 2026-10-23

All apps link to their privacy policy in the metadata and inside the app (5.1.1(i)).

Verify: The link can be found from the app menu or its settings.

Evidence: Policy URL and a screenshot of where it appears.

App Review Guidelines 5.1.1 — Data Collection and Storage ↗ · reviewed 2026-10-23

Required to submit new apps and updates, they also cover integrated third-party SDKs.

Verify: Compare each declared data type with what the app and its SDKs actually send.

Evidence: SDK inventory and a screenshot of the App Privacy section.

Apple — App privacy details on the App Store ↗ · reviewed 2026-10-23

Camera, microphone, contacts, calendar, protected folders: each request has a clear purpose string, comes at the right moment, and the app stays usable if declined (5.1.1).

Verify: Reset permissions (tccutil reset) then decline each request.

Evidence: Purpose strings and the decline test result.

App Review Guidelines 5.1.1 — Data Collection and Storage ↗ · reviewed 2026-10-23

An app that lets people create an account must let them start its deletion inside the app (5.1.1(v)).

Verify: Delete a test account from the app, then check the deletion on the server.

Evidence: Screenshot of the path in the app and proof on the server.

Apple — Offering account deletion in your app ↗ · reviewed 2026-10-23

If the primary login uses a third-party or social service, also offer an equivalent option that meets 4.8.

Verify: The equivalent option works with a new account.

Evidence: Screenshot of the login screen.

App Review Guidelines 4.8 — Login Services ↗ · reviewed 2026-10-23

Unlocking features goes through In-App Purchase, with no licence key (3.1.1, 2.4.5(vi)). Products are complete and visible to the reviewer (2.1(b)) and a restore is available.

Verify: Sandbox purchase of each product, then restore on another macOS user account.

Evidence: Product status and test result.

App Review Guidelines 3.1 — Payments ↗ · reviewed 2026-10-23

Before subscribing, the app describes what the person gets for the price; a period of at least seven days, available on all their devices (3.1.2).

Verify: Read the subscription screen as a stranger would.

Evidence: Screenshot of the subscription screen.

App Review Guidelines 3.1 — Payments ↗ · reviewed 2026-10-23

Screenshots show the app in use (2.3.3), at the Mac sizes App Store Connect accepts.

Verify: Each screenshot matches a real screen of the submitted build.

Evidence: Screenshot folder.

App Store Connect Help — Screenshot specifications ↗ · reviewed 2026-10-23

Metadata reflects the actual experience (2.3); no third-party trademarks or unrelated terms (2.3.7).

Verify: Every feature mentioned exists in the submitted build.

Evidence: Product page text reviewed.

App Review Guidelines 2.3 — Accurate Metadata ↗ · reviewed 2026-10-23

Apple uses a new rating system (4+, 9+, 13+, 16+, 18+); answer every updated question honestly (2.3.6).

Verify: Every question is answered and matches the app.

Evidence: Screenshot of the questionnaire.

App Store Connect Help — Age ratings values and definitions ↗ · reviewed 2026-10-23

TestFlight also works for Mac apps: have at least one person outside development install the build.

Verify: A tester completes the main task without help.

Evidence: Build number and tester feedback.

Apple — TestFlight ↗ · reviewed 2026-10-23

If the app has account-based features, provide an active demo account (or an approved demo mode), valid when the review happens.

Verify: Sign-in tested the day before submitting, on the submitted build.

Evidence: Date of the last sign-in test.

App Review Help — Provide information for a complete review ↗ · reviewed 2026-10-23

The services the app depends on are live and reachable for the whole review.

Verify: Uptime monitoring active, no maintenance scheduled.

Evidence: Uptime history.

App Review Guidelines 2.1 — App Completeness ↗ · reviewed 2026-10-23

Build selected, required sections complete, App Review notes written, no previous rejection pending. A ready submission does not guarantee approval.

Verify: App Store Connect shows no missing field and the App Review history holds no open message.

Evidence: Screenshot of the ready submission.

App Store Connect Help — Submit an app ↗ · reviewed 2026-10-23

Distribution outside the Mac App Store is signed with a “Developer ID Application” certificate (and “Developer ID Installer” for a PKG), obtained through the Apple Developer Program. Do not use a “Mac Distribution”, ad hoc or development certificate. Back up the private key off the build machine.

Verify: security find-identity -v -p codesigning lists the valid Developer ID Application certificate.

Evidence: Certificate name and expiry date.

Apple — Developer ID ↗ · reviewed 2026-10-23

The app, its frameworks, helpers, command-line tools and plug-ins are signed with Developer ID and a secure timestamp. The com.apple.security.get-task-allow entitlement must not be true in the distributed build.

Verify: codesign --verify --deep --strict --verbose=2 on the app; codesign -d --entitlements - to read the entitlements.

Evidence: codesign --verify output with no error.

Common failure: An unsigned embedded framework makes notarization fail.

Apple — Notarizing macOS software before distribution ↗ · reviewed 2026-10-23

Notarization requires the Hardened Runtime on the app and command-line targets. Each exception (JIT, unsigned memory, disabled library validation…) weakens protection: keep only those a feature requires.

Verify: codesign -d --verbose=2 shows “flags=0x10000(runtime)” for each executable.

Evidence: List of runtime exceptions with their justification.

Apple — Hardened Runtime ↗ · reviewed 2026-10-23

A PKG installer is signed with the “Developer ID Installer” certificate, separate from the app’s.

Verify: pkgutil --check-signature on the PKG shows the Developer ID Installer chain.

Evidence: pkgutil --check-signature output.

Xcode — Creating distribution-signed code for macOS ↗ · reviewed 2026-10-23

Software distributed with Developer ID must be notarized to run without being blocked. Submit it with notarytool or Xcode: since 1 November 2023, altool and Xcode 13 or earlier are no longer accepted. Notarization is an automated security check, not a review of the app.

Verify: xcrun notarytool submit … --wait returns “Accepted”; read the log (notarytool log) for warnings.

Evidence: Submission ID and notarization log.

Common failure: “Invalid” status because an executable lacks a timestamp or the Hardened Runtime.

Apple — Notarizing macOS software before distribution ↗ · reviewed 2026-10-23

Stapling the ticket lets Gatekeeper verify it offline. You staple an app, a DMG or a PKG; a ZIP archive cannot be stapled: staple the app inside it, then re-zip.

Verify: xcrun stapler validate on the final deliverable answers “The validate action worked”.

Evidence: stapler validate output.

Apple — Customizing the notarization workflow ↗ · reviewed 2026-10-23

Gatekeeper checks signature and notarization when a downloaded file is first launched. Recent macOS versions make opening un-notarized software much harder for users; test exactly like a customer: download through a browser, then open.

Verify: On another Mac (or a fresh account), download the deliverable from your real link and open it: no “damaged” or “cannot be opened” message; spctl --assess --type execute -vv accepts the app.

Evidence: Screenshot of the first launch and spctl output.

Common failure: A file changed after notarization (resource added, re-signed) is no longer recognised by Gatekeeper.

Apple — Resolving common notarization issues ↗ · reviewed 2026-10-23

DMG (drag to Applications), PKG (installs into system locations, scripts) or ZIP: choose based on the installation needed. Apple notarizes apps, disk images, installer packages and ZIP archives containing the app.

Verify: The published deliverable is the one that was notarized (same checksum).

Evidence: Chosen format and SHA-256 of the published file.

Apple — Notarizing macOS software before distribution ↗ · reviewed 2026-10-23

Installation without an administrator password when none is needed, app working from /Applications, nothing left outside the expected locations, and published uninstall instructions.

Verify: Install then uninstall on a fresh account following only your public instructions.

Evidence: Link to the installation and uninstall instructions.

Login items, agents and daemons register through the Service Management framework, and system extensions go through user approval. Explain to the person why they need to allow them.

Verify: On a fresh Mac, the requested approval appears in System Settings and the app guides the user.

Evidence: Screenshots of the approval flow.

Apple — Service Management ↗ · reviewed 2026-10-23

The deliverable downloads over HTTPS from a domain you control; publish the version and its SHA-256 so advanced users can verify it.

Verify: The public download link starts with https:// and the published checksum matches the file.

Evidence: Download URL and published checksum.

Outside the Mac App Store you handle payment, receipts, refunds and licence activation. Activation must not lock out a legitimate customer offline, and your terms of sale are published.

Verify: Real purchase, licence received, activation, then a test refund.

Evidence: Purchase flow result and link to the terms.

An auto-updater is a code execution path: update feed over HTTPS, each update’s signature verified by the app (for example Sparkle’s EdDSA signature), and every new version signed with Developer ID and notarized.

Verify: Install the previous version, trigger the update, then check with spctl that the new version is accepted.

Evidence: HTTPS feed URL and update test result.

Common failure: An HTTP update feed without signatures: anyone on the network can deliver a binary.

Without automatic updates, plan a releases page, an email notice or an in-app version check.

Verify: The download page shows the current version and its notes.

Evidence: Link to the releases page.

Keep the previous notarized deliverable: if a version misbehaves you can republish the old one immediately, then fix.

Verify: The old version is archived with its checksum.

Evidence: Location of the version archive.

Analytics, crash reports, accounts or telemetry: describe what is collected, why, by which providers, and how to request deletion. Check the rules that apply to you (Swiss FADP, GDPR).

Verify: Compare the policy with the data the app actually sends.

Evidence: Policy URL.

Camera, microphone, contacts, protected folders, accessibility: each request has a clear purpose string and the app explains what will not work if declined.

Verify: Reset permissions (tccutil reset) and decline each request.

Evidence: Purpose strings and test result.

Test the file actually published (not the Xcode build) on the oldest and newest supported macOS versions, Apple silicon and Intel if the app is universal.

Verify: Critical flows on each configuration, from the public download.

Evidence: List of Macs and macOS versions tested.