Mac App Store App Review Guidelines for Sandboxed Utilities

Parent: Apple Platform Publishing (Mac App Store) · Published reference · snapshot 2026-10-02 · skill apple-platform-publishing/references/apple-app-review-mac-utility-guidelines.md

Also known as: Mac App Store App Review guidelines for a sandboxed menu-bar network/DNS monitoring utility that bundles Python (py2app) — rules, reviewer behaviour, rejection causes; verify against Apple's current App Review Guidelines (as of Oct 2026, macOS 27.x) at developer.apple.com

↓ Facts as markdown all context files

Source-anchored research for Mac App Store App Review Guidelines for Sandboxed Utilities. Run status: COMPLETED.

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Definitions

Feature flags are not banned outright. An Apple Developer Forums answer (Mar 2017) says a hidden feature is acceptable if App Review is told about it and given a way to exercise it, and that central features must not be hidden from review. A 2019 forum report describes a developer using flags to hide 17+ content in a 4+ app, which is the abuse 2.3.1(b) targets with Developer Program removal. This is community interpretation, not Apple policy text. (low confidence) [source]

Structure and components

Guideline 4.2 says an app should include features, content and UI that elevate it beyond a repackaged website; an app that is not particularly useful, unique or 'app-like' does not belong on the App Store, and an app lacking lasting entertainment value or adequate utility may be rejected. The sub-rules (4.2.1 ARKit, 4.2.2 catalogs/marketing/link collections, 4.2.3 standalone and download disclosure, 4.2.6 templates, 4.2.7 remote desktop) contain no Mac-specific or menu-bar rule. (medium confidence) (verified as of 2026-10-02) [source]
Guideline 5.2.4(a) forbids suggesting or implying Apple is a source or supplier of the app or endorses its quality or functionality; 5.2.5 forbids an app that looks confusingly similar to an Apple product, interface (Finder is the named example) or app. A menu-bar utility should avoid Apple-styled branding, icons or wording implying it is a system component. (high confidence) (verified as of 2026-10-02) [source]
Apple's trademark guidelines bar using Apple marks (Apple, Macintosh, iMac, etc.) in whole or in part in a product name. 'Mac' is allowed only if the product is not a computer or OS, is Mac-related, 'Mac' is combined with another non-generic word, and it is not more prominent than the rest of the name. Referential phrases like 'for use with' or 'compatible with' are allowed if the Apple mark is less prominent. The Apple Logo needs a written license. (medium confidence) (verified as of 2026-10-02) [source]

How it works

'Information Needed' is a provisional rejection under Guideline 2.1: App Review asks questions (costs, hardware, account creation, business model, login access) because it could not complete review; the developer answers in Resolution Center or in the App Review Information section of App Store Connect. (high confidence) [source]
Many Information Needed rejections need no new build: after correcting the App Review Information (demo account, notes) the developer can reply in Resolution Center; a new binary is only needed if a code bug is the cause. (medium confidence) [source]
Typical 2.3.1 triggers: OTA/remote code-update SDKs not declared in Notes for Review, debug menus or debug artifacts left in production builds, and feature flags or remote config that hide functionality from the reviewer. Reviewers judge the binary as shipped; the Resolution Center message rarely names the screen or code flagged. (medium confidence) (verified as of 2026-05-01) [source]
Fixes reported for 2.3.1: rewrite Notes for Review feature by feature (each mode, menu item, hidden preference or debug switch), strip debug routes from release configs, declare any OTA mechanism by name, provide access or demo accounts for gated surfaces, reply in the Resolution Center asking which surface was flagged, and resubmit with an incremented CFBundleVersion. Rewriting the store description alone is reported as the most wasted response. (medium confidence) [source]
WWDC22 'Power down' guidance: tell the system when background work is done, defer non-urgent work (discretionary URLSession, BGProcessingTask), and use low-priority pushes to avoid wakeups; the session is iOS-centred, so only the principle transfers to a Mac menu-bar app. (low confidence) [source]
ITMS-90338 'Non-public API usage' is an automated check that matches symbols referenced by any Mach-O in the bundle (including third-party frameworks and static libs) against Apple's private-symbol list. Apple's remedy text: rename source methods that collide with listed private APIs, or remove static libraries containing them; the cause is often a bundled third-party framework that needs updating. (medium confidence) [source]
Resubmitting closes the Resolution Center line of communication, so the safe order is: reply with evidence (e.g. screen recording), wait for the reviewer to confirm or answer, then resubmit only if a code or metadata change is needed. Replies without resubmitting do get answers in practice, but replying alone does not necessarily trigger a fresh review cycle. (medium confidence) [source]

Measurements and reference values

Apple advises setting timer tolerance to at least 10% of the interval for repeating timers (NSTimer setTolerance:, dispatch_source_set_timer leeway, CFRunLoopTimerSetTolerance) so the system can coalesce wakeups across processes; timers never fire early, only up to fire date plus tolerance. (medium confidence) [source]

Problems, failure modes and limitations

Guideline 2.1(b) tells developers to explain in review notes any configured in-app purchase that the reviewer cannot find in the app. (low confidence) (verified as of 2026-10-02) [source]
Unclear or evasive replies can trigger a slow secondary review; one author advises budgeting an extra 1-2 weeks when a reply is likely to prompt follow-up questions, so answer each question directly and completely. (medium confidence) [source]
Effective review notes are short (3-5 lines), give concrete navigation to the features under review, list working credentials (no 2FA/email/SMS gate, not expired), explain features needing hardware the reviewer lacks, and avoid marketing copy; stale UI directions are a common pitfall. (medium confidence) [source]
Reported 4.2 rejection patterns are WebView wrappers, single-feature utilities that duplicate built-ins, marketing brochures, and unmaintained aggregators. Reviewers allegedly decide within about a minute whether the app feels native. Evidence is iOS-centric; no source found for a 4.2 rejection of a native menu-bar network monitor. A utility mitigates the risk with visible native UI, system integration and clear purpose in screenshots and Notes. (low confidence) [source]
Removing an unneeded extension module from the bundle (e.g. _tkinter .so) cleared a non-public-API rejection for a Mac app embedding Python; Apple's reply stated non-public or deprecated APIs are not permitted and offered appeal to the App Review Board. (low confidence) [source]
Guideline 2.3.7 says do not pack metadata with trademarked terms, popular app names, pricing or irrelevant phrases; app names are capped at 30 characters; subtitles must not reference other apps or make unverifiable claims; Apple may modify keywords at any time. Naming competing monitors (e.g. 'like Little Snitch') in keywords or subtitle is a rejection risk. (medium confidence) (verified as of 2026-10-02) [source]
Guideline 2.4.5(v) forbids requesting escalation to root privileges and using setuid attributes. A DNS or network monitor cannot ship a root helper or privileged-tool installer in the store build; it must work with user-level sandbox entitlements such as com.apple.security.network.client. (high confidence) (verified as of 2026-10-02) [source]
A child process inherits its sandboxed parent's sandbox and cannot exceed its permissions (Apple DTS, January 2024). Apple's own frameworks such as MapKit reach the network through non-sandboxed system daemons via XPC; third-party Mac App Store apps cannot do the same because every component must be sandboxed. (medium confidence) [source]
py2app apps for the Mac App Store must be signed manually; a March 2022 py2app issue reports 'Killed: 9' with 'Restricted entitlements not validated' (error -67050) when sandbox entitlements were applied, with suspected causes of nested binaries not signed individually, entitlement or profile mismatch. The issue records no resolution. (low confidence) (verified as of 2022-03-27) [source]

Comparisons and alternatives

For repeated generic 4.2 rejections, Apple's forum reply (Nov 2025 thread) points to the one-on-one App Review consultation via Meet with Apple rather than more resubmissions. (low confidence) (verified as of 2025-11-01) [source]
Apple's help text does not document file-size limits, accepted video formats, or whether a link versus an uploaded file is preferred for screen recordings; the pages checked state only that other file types are allowed. (low confidence) (verified as of 2026-10-02) [source]

Facts and statements

Guideline 2.1(a) requires final, fully functional submissions with complete metadata and working URLs, demo account info if the app has a login (with the back-end turned on), and permits a built-in demo mode in place of a demo account only with prior Apple approval; apps that crash or are incomplete are rejected. (high confidence) (verified as of 2026-10-02) [source]
Apple's standard text for flagged apps says the app gets a longer review and is ineligible for expedited review until the developer confirms compliance; resubmitting without the requested confirmation keeps the longer review. (medium confidence) [source]
Replies may be written in the developer's preferred language, and developers should avoid loose wording that raises extra concerns. (low confidence) [source]
Guideline 2.3.1(a) forbids hidden, dormant or undocumented features; all new features, functionality and product changes must be described with specificity in Notes for Review in App Store Connect and be accessible for review. Generic descriptions will be rejected. (high confidence) (verified as of 2026-10-02) [source]
Guideline 2.3 opens by requiring that all metadata, including privacy information, description, screenshots and previews, accurately reflect the app's core experience and be kept up to date with new versions. 2.3.3 requires screenshots to show the app in use, not just title art, a login page or a splash screen. 2.3.12 requires 'What's New' text to describe significant changes; only bug fixes, security updates and performance improvements may use generic text. (medium confidence) (verified as of 2026-10-02) [source]
A bundled-Python string-scan rejection is cited under 2.5.2, not 2.3.1: Mac App Store apps containing the 'itms-services' string in Lib/urllib/parse.py (Python 3.12+) and its .pyc were auto-rejected with 'The app installed or launched executable code'. Removing the string fixed it, and CPython added a --with-app-store-compliance configure option. Details belong to the 2.5 sibling concept; do not diagnose such a rejection as a 2.3.1 hidden-feature issue. (low confidence) (verified as of 2026-10-02) [source]
Guideline 2.4.2 text: design the app to use power efficiently; apps should not rapidly drain battery, generate excessive heat, or put unnecessary strain on device resources (examples: encouraging placing the device under a mattress while charging, excessive write cycles to the SSD); apps and third-party ads may not run unrelated background processes such as cryptocurrency mining. (medium confidence) (verified as of 2026-10-02) [source]
The rule sets no numeric polling interval, CPU or wakeup threshold; it is a qualitative standard (rapidly, excessive, unnecessary), so a reviewer judges it by observed behaviour. (low confidence) (verified as of 2026-10-02) [source]
Apple's Mac energy guide says every timer fire wakes the CPU from low-power idle states at an energy cost that adds up, and that sporadic work prevents resources reaching true idle, so a lot of energy is spent on little work; it advises batching tasks and running them less often. (medium confidence) [source]
Apple's guide says not to use timers or sleep loops to poll for state changes; use event sources (dispatch sources) instead. For a network monitor this implies prefer SCDynamicStore / NWPathMonitor-style change notifications over fixed-interval probing where the state is observable. (low confidence) [source]
A bundled Python (py2app) interpreter running a polling loop makes timer tolerance and idle behaviour the app's own responsibility; reviewers or Activity Monitor/Energy tab would show 'Energy Impact' and idle wakeups, which are the observable evidence for 2.4.2. (low confidence) [source]
Guideline 2.5.1 says apps may only use public APIs and must run on the currently shipping OS; 2.5.2 says apps must be self-contained in their bundles, may not read/write outside the container, and may not download, install, or execute code that introduces or changes features. Educational code-teaching apps get a narrow exception. (medium confidence) (verified as of 2026-10-02) [source]
Embedded Python has been rejected for symbols the author never called: Python 3.9 libformw/libpanelw (ncurses) and posix_spawn symbols cited under Guideline 2.5.1 (March 2021, later validated without comment after the developer raised it), and Tcl.framework symbols via _tkinter.cpython-39-darwin.so (July 2024). (medium confidence) [source]
Python 3.12 added the literal string 'itms-services' to Lib/urllib/parse.py (and its .pyc); Apple's scan flagged it under Guideline 2.5.2 ('installed or launched executable code'). CPython added a --with-app-store-compliance configure option (issue opened 2024-06-14) to patch it out; removing the string from a bundled copy let an update pass. (medium confidence) (verified as of 2024-06-14) [source]
Tkinter remains unshippable on the Mac App Store in CPython 3.9-3.14: libtk8.6.dylib references _NSWindowDidOrderOnScreenNotification; no fix as of the issue opened 2025-01-23. A menu-bar utility without Tk should exclude tkinter/Tcl/Tk from the py2app bundle. (low confidence) (verified as of 2025-01-23) [source]
Embedding Python and shipping to the Mac App Store has worked in practice: an embedded, signed interpreter keeps the sandbox and hardened runtime; old py2app versions produced invalid Python.framework bundles, and py2app 0.26 replaced a private symbol in its stub executable with a public API. (low confidence) [source]
Guideline 5.2.1 prohibits protected third-party material such as trademarks, copyrighted works or patented ideas without permission, and misleading, false or copycat representations, names or metadata in the app bundle or developer name; apps must be submitted by the person or legal entity that owns or licenses the rights. (high confidence) (verified as of 2026-10-02) [source]
Guideline 4.1(c) forbids using another developer's icon, brand or product name in your app's icon or name without approval. (medium confidence) (verified as of 2026-10-02) [source]
Apple's 5.2.1 rejection can demand documentary proof of authorization to use a name or control a brand's hardware, or removal of the third-party content from app and metadata. An authorization statement from the developer's own company was accepted in one forum case (anecdotal). (low confidence) [source]
Guideline 5.2.2 requires that if the app uses, accesses or displays content from a third-party service, the service's terms of use specifically permit it, and Apple asks for authorization on request. A DNS/network monitor that queries third-party reputation or geo-IP APIs or shows their data should keep terms-of-use evidence. (medium confidence) (verified as of 2026-10-02) [source]
For trademark owners, Apple offers a content dispute form and an App Store name dispute form. Apple usually asks the app owner to resolve it with the complainant, does not itself decide infringement, and resolution can take weeks to months (law-firm commentary, updated 2024-08-27). (low confidence) (verified as of 2024-08-27) [source]
Guideline 2.4.5(i) requires Mac App Store apps to be appropriately sandboxed, follow the macOS File System documentation, and use only appropriate macOS APIs to modify user data stored by other apps (bookmarks, Address Book, Calendar). (high confidence) (verified as of 2026-10-02) [source]
Guideline 2.4.5(ii) requires packaging and submission with Xcode-provided technologies, bans third-party installers, and requires a self-contained, single app installation bundle that does not install code or resources in shared locations. A py2app bundle must therefore carry its interpreter, libraries and helpers inside the .app. (high confidence) (verified as of 2026-10-02) [source]
Guideline 2.4.5(iii): apps may not auto-launch or run code at startup or login without consent, may not spawn processes that keep running after the user quits without consent, and should not add Dock icons or desktop shortcuts automatically. A menu-bar utility that starts at login needs an explicit user opt-in toggle. (medium confidence) (verified as of 2026-10-02) [source]
Guideline 2.4.5(iv) bars downloading or installing standalone apps, kexts, additional code or resources that add functionality or significantly change the app from what App Review saw. Self-updating Python code or downloaded plugins breach it; updates go through the Mac App Store. (medium confidence) (verified as of 2026-10-02) [source]
Guideline 2.4.5(vi) bars a license screen at launch, license keys, and custom copy protection. (low confidence) (verified as of 2026-10-02) [source]
A 2014 write-up of a Python Mac App Store submission lists: sandbox blocks arbitrary file access outside open/save dialogs and the container, PowerPC slices in Python 2.7 must be removed with lipo, and manual codesign is required. Treat as dated; the lipo and Application Loader steps are obsolete. (low confidence) (verified as of 2014-06-24) [source]
Apple App Review answers questions on bundled extra executables only by directing developers to a one-on-one App Review consultation, so there is no official ruling on whether a bundled executable the user can run manually is allowed. (low confidence) (verified as of 2026-10-02) [source]
Apple's Resolution Center reply lets Account Holder, Admin, or App Manager roles send up to 4,000 characters and attach files (screenshots, supporting documents) to a rejection reply; the thread stays open only until the developer resubmits to App Review. (high confidence) (verified as of 2026-10-02) [source]
A metadata-rejected submission can be fixed by editing the cited metadata and resubmitting the same build; a binary rejection requires uploading and selecting a new build. (high confidence) [source]
For features hard to reproduce in review (hardware, special environments, unusual behaviour), Apple expects a demo video or the hardware; a video can be attached via the Attachment field in App Review Information, with explanations or links in Review Notes. (high confidence) [source]
Apple's FAQ says screenshots may be attached to the Resolution Center reply to show how the app addresses the rejection, and that the Notes/attachments in App Review Information can explain where reviewers find specific features; this applies to a menu-bar app with no main window. (medium confidence) [source]
Appeals go to the App Review Board through App Store Connect: give specific reasons the app complies, submit one appeal per rejected submission, and answer any pending information request before appealing. (high confidence) [source]
Apple generally responds to Resolution Center messages within about 24 hours, but forum reports describe repetitive copy-paste replies that ignore the developer's specific question. (low confidence) (verified as of 2026-10-02) [source]

Children

App Review Board appeal process (frontier)
Apple trademark usage in app names (Mac, macOS) (frontier)
CPython --with-app-store-compliance (frontier)
Event-driven network change detection (SCDynamicStore/NWPathMonitor) (frontier)
Guideline 2.1 Information Needed reply: review notes
Guideline 2.3 accurate metadata and 4.2 minimum functionality and hidden-feature strings
Guideline 2.4.2 power and resource efficiency for polling network monitors
Guideline 2.5 public APIs and bundled interpreter and private-API string scan (ITMS-90338)
Guideline 5.2 trademark and IP rules in app metadata
Mac App Store Guideline 2.4.5 sandbox self-contained bundle and no-root rules
Metadata-only resubmission (frontier)
Notes for Review feature inventory for menu-bar utilities (frontier)
Reading the ITMS-90338 symbol list with swift-demangle (frontier)
Resolution Center reply mechanics (frontier)
Review notes template for menu-bar app (frontier)
SMAppService login item consent (frontier)
Sandbox entitlements for network monitoring (frontier)
Screenshot and preview rules for macOS (2.3.3, 2.3.4) (frontier)
Third-party API terms-of-use evidence under 5.2.2 (frontier)
Timer tolerance and wakeup coalescing (frontier)
py2app bundle slimming (excluding tkinter/curses) (frontier)
py2app nested code signing for App Store (frontier)
screen recording and resubmission protocol

Frontier under this node: App Review Board appeal process, Apple trademark usage in app names (Mac, macOS), CPython --with-app-store-compliance, Event-driven network change detection (SCDynamicStore/NWPathMonitor), Metadata-only resubmission, Notes for Review feature inventory for menu-bar utilities, Reading the ITMS-90338 symbol list with swift-demangle, Resolution Center reply mechanics, Review notes template for menu-bar app, SMAppService login item consent, Sandbox entitlements for network monitoring, Screenshot and preview rules for macOS (2.3.3, 2.3.4), Third-party API terms-of-use evidence under 5.2.2, Timer tolerance and wakeup coalescing, py2app bundle slimming (excluding tkinter/curses), py2app nested code signing for App Store

← the whole tree · 3D view· how to read this page