WWDC26 app management updates
Note: The features discussed on this page are pre-release versions and may be incomplete, changed, or removed before final release.
The content below is listed in order of operating system versions, then the number of operating systems affected:
Management for launching apps and binaries
IT teams may need control over what apps can be used on supervised iOS, iPadOS, tvOS, visionOS devices and binaries on supervised Mac computers, for example, to meet compliance requirements.
On supervised devices with iOS 27, iPadOS 27, tvOS 27, and visionOS 27, a new com.apple.configuration.app.settings configuration contains AllowedApps and DeniedApps keys that can be used to implement app launch rules on those platforms.
On supervised Mac computers with macOS 27, a new com.apple.configuration.app.settings configuration uses the Endpoint Security extension framework to provide granular and flexible management of binaries allowed to run. Those can be standalone binaries or binaries embedded in an app bundle. Most binaries included in the signed and sealed operating system are always permitted.
IT teams can use the AlwaysAllowManagedApps key to automatically allow execution of managed apps. These are apps deployed using the com.apple.configuration.app.managed configuration or using the InstallAsManaged flag set to TRUE in the InstallApplication command. This can help to reduce maintenance overhead of the ruleset.
Note: If the launch of an app binary is blocked, the device shows the user an alert. If it appears in both lists, the device blocks it from launching.
The keys and associated information are listed in the table below.
Key | Purpose | Match criteria | Behavior |
|---|---|---|---|
| Allow list for iOS, iPadOS, tvOS, visionOS | Bundle ID | Only listed apps can launch. Apps not listed are unable to launch. |
| Deny list for iOS, iPadOS, tvOS, visionOS | Bundle ID | All listed apps can’t launch. Apps not listed are able to launch. Note: The launch of web clips can be restricted when |
| Define what can run on macOS | CD Hash, Team ID (optional: path, state, signing ID) | Only listed binaries can run. Binaries not listed are unable to run. |
| Define what can’t run on macOS | CD Hash, Team ID, signing ID (optional: path, state) | Listed binaries can’t run. Binaries not listed are able to run. |
Important: The com.apple.applicationaccess.new profile to manage what apps are allowed to launch is deprecated in macOS 27.
Privacy consent updates
For apps
Currently, ensuring apps deployed in an organization have the necessary access to privacy-sensitive functions may be a time-consuming process that also introduces user friction, prompts appear at inopportune moments with no default selection. This can lead to incorrect choices, broken app workflows, and unnecessary support calls.
On supervised devices with iOS 27, iPadOS 27, and macOS 27, a new Privacy key in the com.apple.configuration.app.settings configuration allows IT teams to provide necessary default app permissions.
At first launch of an app, the device generates a single consolidated consent prompt for all necessary permissions with the managed defaults and the Allow button shown as default. This helps guide users to the right choice. The prompt also shows the organization’s name, the app name, and a justification provided by the organization as part of the configuration. If the user selects Allow, defaults are applied and no additional prompts appear. If the user selects Not Now, the standard per-component prompts appear.
Organizations can set the following default permissions on a per-app basis:
Accessibility: Assistive technology access
Bluetooth: Peripheral and device pairing
Camera: Video capture
Dictation: Voice-to-text input
LocalNetwork: Access to local network devices
Location: Location data
LocationAccuracy: Precise or approximate location
Microphone: Audio capture
Important: The corresponding keys in the com.apple.TCC.configuration-profile-policy profile are deprecated in iOS 27, iPadOS 27, and macOS 27.
For websites in Safari
On supervised devices with iOS 27, iPadOS 27, and macOS 27, IT teams can:
Apply the same consolidated privacy consent model to websites in Safari, which resolves prompt fatigue for web-based enterprise tools and reduces incorrect user choices on managed devices.
Use the new
Privacykey in thecom.apple.configuration.safari.settingsconfiguration to define website privacy permission defaults.
They can also set the following default permissions individually for each web page accessed using Safari:
Camera: Video capture
Microphone: Audio capture
Web pages are defined by:
A specific domain, for example melardclothing.com. The permission defaults apply to that website only.
A wildcard domain, for example *.melardclothing.com, using a single “*” character as a prefix. The permission defaults apply to the exact domain and any sub-domains, for example www.melardclothing.com.
Safari uses the most precise pattern when multiple patterns match a website.
App rating exemptions
On iPhone and iPad devices with iOS 26.1, iPadOS 26.1, or later, organizations can exempt specific apps from age-based rating restrictions. IT teams can provide an array of bundle IDs using the ratingAppsExemptedBundleIDs restriction key.
The operating system then exempts these apps from parental control limitations and rating restrictions. This feature is particularly useful for educational institutions or specific business use cases where certain apps—despite their age rating—are essential for organizational functions. iOS and iPadOS combine these exemptions with any provided by parental control apps, including ScreenTime, using intersection combine rules.
ManagedApp framework on macOS
Apps on macOS 27 can now implement the ManagedApp framework. This framework—already available on iOS, iPadOS, and visionOS—can be used to deploy app-specific configurations and secrets (for example, hardware-bound identities, passwords, and certificates) in a secure way. IT teams can customize the behavior of an app and streamline the user experience. Based on the app type, use the following:
Apps using the ManagedApp framework: Use
com.apple.configuration.app.managedLegacy apps not using the ManagedApp framework: Store the MDMv1 .plist file as a
com.apple.asset.dataasset and reference it usingLegacyAppConfigAssetReference.Supported
com.apple.asset.datacontent types are:application/plistapplication/x-plistapplication/xmltext/xml
Note: After com.apple.configuration.app.managed is in use, mobile device management (MDM) commands for app configuration are unavailable.
For more information, see the ManagedApp framework in Apple Developer documentation.
App Attest on macOS
Ensuring only trusted iPhone and iPad apps connect to a backend service is a key component of a zero-trust architecture. Apple has provided the DeviceCheck framework to allow app developers to verify the integrity of apps when they connect to backend services. This can help to defend against fraud, API abuse, and modified app versions.
On a Mac with macOS 27, App Attest is available for Mac apps. App Attest creates hardware-backed cryptographic keys in the Secure Enclave and uses Apple servers to generate attestations that embed app and system properties. When an app connects to a backend service, the service verifies app authenticity using attestations and accepts only valid, signed requests.
For more information, see the WWDC26 session Secure your apps with App Attest.
Package uninstall behavior control
On a Mac with macOS 27, IT teams can control what happens to package files when a managed package is removed. This helps ensure unwanted data and files are removed on devices when no longer needed. A new UninstallBehavior key in the com.apple.configuration.package configuration takes a dictionary with a Remove boolean subkey (default is FALSE) to specify file removal behavior. IT teams can set the Remove key to TRUE before installation so macOS records all files during the installation of a package and removes those files when IT teams remove the configuration from the device.
Important: The following are important considerations:
The
Removekey needs to be set toTRUEbefore package installation. Applying it to an already-installed package has no effect. macOS can’t retroactively build the file manifest.Post-install script changes aren’t tracked.
Post-install local file modifications after installation aren’t tracked.
Removal of accessibility management
On a Mac with macOS 26.2, the ability to grant access to an app using the Accessibility subsystem through a com.apple.TCC.configuration-profile-policy profile was deprecated and is removed in macOS 27. Apple evolved the macOS security model to adopt more modern and secure methods for managing app permissions. If management of accessibility access is required, use the Privacy key in com.apple.configuration.app.settings.
Support for Intel-based Mac computers
macOS 26 is the last macOS release with full support for Intel-based Mac computers. All Mac computers with macOS 26.4 or later display a pop-up notification to transparently inform users about the deprecation when an application using Rosetta launches. This proactive communication helps IT teams and users plan for app compatibility and transitions well in advance. IT teams can use the allowRosettaUsageAwareness restriction to suppress this notification on devices enrolled using Automated Device Enrollment, account-driven Device Enrollment, and profile-based Device Enrollment.
Apple will continue providing software security updates for Intel-based Mac computers for three years. Rosetta will continue as a general-purpose compatibility tool through macOS 27. Beyond this, a subset of Rosetta functionality will be kept that supports older unmaintained gaming titles (which rely on Intel-based frameworks). Organizations with Intel-based Mac computers should begin transition planning now.
For more information, see About the Rosetta translation environment in Apple Developer documentation.