Anyone aware of a work around for the followiing? Using an unsupervised device. iOS 26.5, MacOS 26.5.1, cfgutil 2.20 (1001.5), App Configurator 2.20 (11B11), on an iMac 2024 and an iPhone 16 Pro cfgutil get-icon-layout works as expected, returning the app layout list. Add an app to any page from the App Library. Rerun the command and a crash is the result. *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil' *** First throw call stack: ( 0 CoreFoundation 0x00000001854a91c0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x0000000184f3291c objc_exception_throw + 88 2 CoreFoundation 0x00000001853db9dc -[__NSArrayM insertObject:atIndex:] + 1864 3 cfgutil 0x0000000104cc2df4 cfgutil + 44532 4 cfgutil 0x0000000104cc2ce4 cfgutil + 44260 5 cfgutil 0x0000000104cc2ce4 cfgutil + 44260 6 cfgutil 0x0000000104cc3104 cfgutil + 45316 7 cfgutil 0x0000000104cd3d14 cfgutil + 113940 8 cfgutil 0x0000000104ccee68 cfgutil + 93800 9 dyld 0x0000000184fbfe00 start + 6992 ) libc++abi: terminating due to uncaught exception of type NSException

Hi all: We use MDM profile to apply Full Disk Access permission for app on macOS, After profile deployed successfully, The App can get correct Full Disk Access permission, However, on "Privacy & Security" UI, we found that our app shown disabled, see as however, on some macOS, it showed correctly as below The issue happened on different os version. macOS 15 and macOS 26 When the item shown as disable, even reboot computer several times, the issue still persist. Thanks for your help

We are seeing a startup issue with in-house enterprise iOS apps on iOS 27 Developer Beta. We would like to understand whether this could be related to changes in iOS 27 Developer Beta startup validation, code signing validation, provisioning profile validation, certificate chain validation, entitlements, embedded frameworks, enterprise developer trust state, or device-specific launch behavior. This issue blocks our enterprise app compatibility validation on iOS 27 Developer Beta, especially on iPhone 11 and iPhone 12 devices. If this is a known beta issue, we would appreciate confirmation from Apple and any available fix plan or workaround. Symptoms: After installing the same enterprise app, some iPhone 11 / iPhone 12 devices running iOS 27 Developer Beta cannot launch it correctly. There are two visible behaviors: When launched from the Home Screen icon, the app stays on the Launch Screen. The normal app UI never appears. When launched from Spotlight/Search, the app crashes immediately. Additional observations: iPhone 13 and later devices do not show this issue. Other enterprise apps distributed with the same provisioning profile or provisioning setup show the same behavior. This makes the issue look less like a single app's business logic problem and more like an iOS 27 Developer Beta validation, trust, or launch-time behavior difference on specific device models. We added logs and breakpoints at the earliest possible app startup points, including main, AppDelegate, SceneDelegate, and before crash-reporting SDK initialization. On affected devices, none of these logs are printed. Based on this, it appears that our app code is never reached. The failure seems to happen before iOS transfers control to the app, possibly while launching the process or loading the app binary/frameworks. Our current suspicion is that the failure may happen during one of these system-level steps: Enterprise code signing validation embedded.mobileprovision validation Certificate chain validation Enterprise developer certificate trust validation Mach-O / embedded frameworks / dynamic libraries loading Entitlements validation Bundle ID / App ID / provisioning profile matching Reuse of stale local enterprise trust, provisioning, or signing validation state on the device Temporary workaround observed: We found a temporary workaround on affected devices: Completely uninstall the existing enterprise app from the device. Download and install the app again. Trust the enterprise developer certificate again in Settings. Launch the app again. After doing this, the app can start normally on the affected iPhone 11 / iPhone 12 devices running iOS 27 Developer Beta. The Launch Screen hang and Spotlight/Search crash no longer reproduce. This suggests that the IPA itself may not be permanently invalid, and the issue may not be caused by app business logic. It may instead be related to stale or invalid local enterprise trust, provisioning profile, certificate chain, or signing validation state after upgrading to iOS 27 Developer Beta. Questions: Does iOS 27 Developer Beta introduce any new restrictions or behavior changes for enterprise in-house app launch validation, code signing validation, enterprise developer trust state, embedded frameworks loading, entitlements, or provisioning profile validation? Are there any known differences in this area between iPhone 11 / iPhone 12 and iPhone 13 or later devices on iOS 27 Developer Beta? If multiple enterprise apps distributed with the same provisioning profile or provisioning setup fail before app code runs, does that point more strongly to a provisioning profile, certificate chain, enterprise trust state, or system validation issue? Given that completely uninstalling the old enterprise app, reinstalling it, and trusting the enterprise developer certificate again fixes the issue, could this be caused by stale trust, provisioning profile, certificate, or code-signing validation state cached on the device after upgrading to iOS 27 Developer Beta? For an enterprise app that stays on the Launch Screen before app code runs, or crashes immediately when launched from Spotlight/Search, what are the most common signing, certificate, provisioning profile, entitlement, or enterprise trust problems to check? Which system logs or crash log fields should we focus on for this kind of pre-main launch failure? For example: device console, crash log, Termination Reason, dyld message, Code Signature Invalid, profile validation, or trust evaluation messages. Are there recommended commands or checks to verify that the IPA's code signature, certificates, entitlements, embedded.mobileprovision, and embedded frameworks are all valid and consistent? If this is an iOS 27 Developer Beta regression, is there any known workaround until the issue is fixed? Environment: Distribution type: Apple Developer Enterprise Program / In-House distribution Affected OS: iOS 27 Developer Beta Affected devices: iPhone 11 / iPhone 12 Unaffected devices: iPhone 13 and later Same provisioning profile or provisioning setup: other enterprise apps show the same behavior Behavior 1: stuck on Launch Screen when launched from Home Screen Behavior 2: crashes immediately when launched from Spotlight/Search App code execution: not reached main/AppDelegate/SceneDelegate logs: not printed Crash SDK initialization: not reached Temporary workaround: completely uninstall the old enterprise app, reinstall it, and trust the enterprise developer certificate again. After that, the app launches normally. Impact: blocks enterprise app compatibility validation on iOS 27 Developer Beta for affected devices Suspected area: iOS 27 Developer Beta startup validation / code signing / provisioning profile / certificate / enterprise developer trust state / entitlements / embedded frameworks / device-specific validation behavior We are looking for guidance on how to confirm whether this is caused by an iOS 27 Developer Beta signing, provisioning profile, or enterprise developer trust validation change on iPhone 11 / iPhone 12, rather than an app-level crash. If this is a system issue in iOS 27 Developer Beta, we hope Apple can provide a fix or a practical temporary workaround as soon as possible.

The new Device Management Service APIs provide support for creating and updating MDM servers programmatically, including updating the public key. However, we could not find a documented API workflow for retrieving, downloading, or renewing the associated Device Management Service token after a public key update. Could you please clarify whether there is an API-supported method for managing the server token ? If such functionality is not currently available, we would like to request support for token management APIs, as this would help enable fully automated MDM onboarding and certificate rotation workflows.

When deploying Macs through Automated Device Enrolment (ADE), we've found that automatic date and time configuration still depends on the Location Services pane in Setup Assistant being enabled. What's particularly interesting is that macOS already determines and pre-selects the correct language and country/region before enrolment begins, which suggests that some form of geographic awareness already exists during setup, whether through GeoIP, network-based location detection, or another mechanism. Despite this, the correct time and time zone are not automatically configured unless Location Services is enabled. For organisations pursuing zero-touch deployments, this creates an unnecessary dependency on a privacy-related feature purely to obtain accurate time settings. Today, administrators often resort to workarounds after enrolment, such as: Using scripts to configure time settings via systemsetup. Modifying the authorisation database to permit automated changes. These approaches introduce additional complexity, require elevated privileges, and create deployment dependencies that should not be necessary for such a fundamental operating system function. If macOS is already geographically aware enough to determine the correct language and region during Setup Assistant, it should also be capable of automatically configuring the correct date, time and time zone without requiring user interaction with Location Services. Benefits would include: True zero-touch and near zero-touch deployment workflows. Fewer Setup Assistant prompts and reduced user interaction. Accurate date, time and time zone configuration immediately after enrolment. Elimination of unnecessary post-enrolment scripting and workarounds. Improved privacy by avoiding the need to enable Location Services solely for time configuration. A more streamlined enterprise deployment experience across all MDM platforms. This would bring date and time configuration in line with the existing automatic language and region detection behaviour already present during ADE and significantly improve Mac deployment workflows at scale. I've already submitted Feedback Assistant report FB21973612 for this enhancement request. This has been a well-known pain point for Mac administrators for many years, particularly for organisations striving to achieve fully automated and consistent provisioning workflows.

I am currently testing Managed Open-In restrictions in an MDM-managed environment on iPadOS 27 beta. I have observed that the restrictions "allowOpenFromManagedToUnmanaged" and "allowOpenFromUnmanagedToManaged", even when set to false, are still being bypassed in certain scenarios. Specifically, I observed two issues: Photos App – Images opened from a managed application can still be saved using the Save to Photos option. Shortcuts App – Custom Shortcuts triggered from the Share Sheet can accept managed content, compress it into an archive, and share that archive with unmanaged applications, effectively bypassing the Managed Open-In restrictions. According to the iPadOS 27 beta release notes, both of these issues were marked as resolved. However, they remain reproducible in my testing on a supervised MDM-enrolled device. I have submitted a detailed report with a sys diagnose log via the Feedback Assistant (FB ID:FB23316986).

We just got a rejection on our VoIP calling app (think Boss Revolution / Rebtel style/Yolla — prepaid credits, app-to-app calls free, calls to real landline/mobile numbers charged per minute). Apple's rejection (Guideline 3.1.1.1): "We noticed that the app includes or accesses paid digital content, services, or functionality by means other than In-App Purchase... The credits for VoIP calls can be purchased in the app using payment mechanisms other than In-App Purchase... The app includes intermediary currencies, such as points, coins, or gems, without using In-App Purchase." Our current setup: Users buy "credits" (shown in real USD, e.g. $10 = stored balance) Credits are spent calling real phone numbers (landline/mobile) over standard internet data (SIP/WebRTC) — not the device's native cellular dialer Payment was happening in an in-app webview (likely the actual issue) rather than opening external Safari Questions: Has anyone successfully shipped a prepaid VoIP/calling-credit app using ONLY external browser links (Safari, not webview) under the post-May-2025 US storefront ruling (3.1.1/3.1.1(a))? Or does Apple still reject "stored balance" models even with proper external links? Does anyone know HOW Rebtel, Boss Revolution, Dingtone, or similar apps are technically structured to avoid this? Is it because they trigger the native cellular dialer for the local access number leg of the call (qualifying under a different guideline) rather than using pure data/SIP the whole way through? Is "intermediary currency" purely about NAMING (coins/points) or does ANY stored prepaid balance — even shown in real currency — count, regardless of payment method used to acquire it? Does 3.1.3(f) ("Free Stand-alone Apps" for VoIP) actually prohibit ANY in-app call-to-action for purchase (even an external link), forcing us to have NO purchase flow in the app at all, with credits only purchasable via a fully separate website experience the user finds on their own? Has anyone gotten clarity from Apple directly (App Review Board call, or written response) on where VoIP termination minutes fall — "real-world service" (3.1.3 exception) vs "digital content consumed in-app" (requires IAP)? Any war stories, links to Apple's actual decisions, or technical breakdowns would be hugely appreciated. We're a small Canadian startup and don't want to burn anot

I bought an iMac 2018 years ago, but it seems that I am having trouble securing it now, which source I have not been able to pin down. I went to turn on FileVault, but saw an unusual procedure flow. I got a message: "Recovery Key A recovery key has been set by your company, school, or institution." I did NOT get this unusual procedure flow with the other macs (MacMini, macbookAir), to which I applied FileVault enable (OK). This iMac has never been under the governance of any company, school, or institution, because I bought it straight out of the Apple Store, right out of the box. But lately, I think that the security of the system has been breached by a hacker. Vitals: Model Name: iMac Model Identifier: iMac18,1 Processor Name: Dual-Core Intel Core i5 Processor Speed: 2.3 GHz Number of Processors: 1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache: 4 MB Hyper-Threading Technology: Enabled Memory: 16 GB System Firmware Version: 529.140.2.0.0 OS Loader Version: 577.140.2~30 SMC Version (system): 2.39f40 Serial Number (system): D25XJ01NH7VF I went ahead & enabled FileVault with this warning statement, listed below, thinking that I could find a workaround. I have tried "sudo fdesetup removerecovery -institutional", and this works for staff, but not for administrators, either terminal in macOS 13.7.8 (22H730), or in Recovery Mode. Can someone enlighten me about what needs to be done to right my iMac's security issue, and help remove what seems to be a breach in my security with the MDM governance installation, which looks out of place because this iMac has always been at my house & never used with any instutition?

We have an Apple Watch app and companion iPhone app that we distribute via Enterprise Distribution using OTA manual installation. (We are on an Apple Enterprise Developer Team) With WatchOS 26.4 and earlier, the app would install fine on both the phone and the watch. However, after updating to WatchOS 26.5 (and iOS 26.5), the app will not install on the watch. It will install on the phone and we can trust the developer/run the phone app. However, when we go into the Apple Watch app on the phone and choose "Install" for the app, it tries to install for a minute and then returns an error "The app could not be installed at this time". We have tried the following remedies: Restarting both watch and phone, and reinstalling the app on phone Factory resetting both the watch and the phone, then reinstalling app Generating a new Distribution Certificate and new manual profiles for the app in Apple Developer Looking through console logs from both the phone and the watch Confirmed that we can install other (non-Enterprise) apps on the watch Try installing a basic example app (the default Xcode watch + companion app project) There does not seem to be anything obviously amiss about the app or its packaging, it seems to be something to do with the update to WatchOS 26.5. The closest related errors we have found seems to be these: appconduitd 0x16d43f000 -[ACXInstallQueue _onQueue_deQueueNextOperation]_block_invoke_3: Failed to install app .EnterpriseInstallTest.watchkitapp (p = Y, ui = Y) : Error Domain=ACXErrorDomain Code=8 "Failed to create socket" UserInfo={NSUnderlyingError=0xcf9138e10 {Error Domain=com.apple.identityservices.error Code=20 "Socket open timed out" UserInfo={NSLocalizedDescription=Socket open timed out}}, FunctionName=-[ACXServerInstallOperation _onQueue_prepForTransferAndInstall]_block_invoke, SourceFileLine=370, NSLocalizedDescription=Failed to create socket} appconduitd 0x16d89f000 -[ACXCompanionSyncConnection _installQueuedOrCompletedForWatchBundleID:companionAppBundleID:withName:userInitiated:withError:withCompletion:]_block_invoke: Failed to install app .EnterpriseInstallTest.watchkitapp : Error Domain=ACXErrorDomain Code=8 "Failed to create socket" UserInfo={NSUnderlyingError=0xcf9138e10 {Error Domain=com.apple.identityservices.error Code=20 "Socket open timed out" UserInfo={NSLocalizedDescription=Socket open timed out}}, FunctionName=-[ACXServerInstallOperation _onQueue_prepForTransferAndInstall]_block_invoke, SourceFileLine=370, NSLocalizedDescription=Failed to create socket}

I am currently working on mdm.push-token status item subscription via the DDM User Channel while testing on Beta OS 27. I have observed that the User Channel subscription consistently returns the device's push token rather than a unique user-specific push token. This behaviour is persistent across both macOS and Shared iPad environments. Before I conclude that this is a bug, I would like to clarify if this is the expected behaviour for the DDM User Channel. If so, could anyone provide guidance on the correct or alternative method to retrieve a unique, user-specific push token within the DDM framework to ensure proper notification routing? I have submitted a detailed report with a sys diagnose log via the Feedback Assistant (FB ID:FB23214856). Any insights or documentation references would be greatly appreciated.

Hi, I have an app which I would like to test on macOS27, specifically the use of 'Accessibility' permission which is granted via the new DDM payload introduced in macOS27 (com.apple.configuration.app.settings). Problem is once the app is launched once and the consent popup is displayed and a choice is made ('Allow' or 'Not Now') I cannot reset the system so that the popup appears again for test purposes, i.e. is there a command line I can execute similar to 'tccutil reset Accessibility' which would reset the system? Thanks

I entered FB18878081 - July 16, 2025 and FB23195930 - June 16, 2026

Since macOS 14, accessing the current Wi-Fi SSID through CoreWLAN.framework requires both: Location Services to be enabled at the system level. Location permission to be granted to the application. For enterprise security and device-management solutions, this creates a deployment challenge because enabling Location Services system-wide requires administrator privileges and user interaction. Some enterprise use cases, such as Wi-Fi policy enforcement, network compliance, and location-aware security controls, depend on reliable access to the current SSID. On managed Macs, administrators currently have no MDM mechanism to enable Location Services system-wide or pre-authorize location access for specific applications. I reviewed the WWDC26 session "What's New in Managing Apple Devices" and the discussion of the new consolidated privacy consent experience. However, I did not find any new MDM capabilities that address Location Services management for specific apps. Questions: Are there any current MDM payloads or APIs that allow administrators to enable Location Services on supervised/managed Macs? Are there any recommended alternatives for enterprise applications that need access to Wi-Fi SSID information on managed devices? Is Apple considering future MDM enhancements that would allow administrators to enable Location Services and/or grant location access to specific applications in managed enterprise environments? Any guidance on Apple's direction in this area would be appreciated.

Are there any plans to allow wifi-only Apple TV 4K units to be manually enrolled into ASM/ABM like we can do with every other device/OS? I have several that were purchased as gifts but we can not use them as they need to be manually added to ASM. However, it's not yet possible.

Enterprise security products often need to establish trust for a locally generated root CA in order to implement features such as web filtering, traffic inspection, data loss prevention, or compliance controls. Our solution generates a unique CA certificate and private key on each managed Mac. The application then issues leaf certificates as needed and signs them with the device-specific CA. Using a unique CA per device helps avoid the security risks associated with deploying a shared CA private key across all managed endpoints. However, since macOS Big Sur, modifying trust settings for certificates in the System keychain (for example, setting a root CA to Always Trust) requires user interaction and administrator authorization. Even privileged processes cannot silently establish trust for a newly installed root CA. This creates deployment challenges in enterprise environments, particularly when: End users do not have administrator privileges. The CA must be unique per device. The private key must remain accessible to the security application while being protected from other applications. We have considered several approaches, but each appears to have significant limitations: Shared CA across all devices: introduces risk because compromise of the private key affects the entire fleet. Per-device PKCS#12 deployment with private key accessible: other local processes may be able to use the key. Per-device PKCS#12 deployment with private key protected: application access may require additional user approval, reducing deployment automation. Questions: Is there an MDM-supported mechanism for establishing trust for a device-specific root CA without requiring local administrator interaction? Are there recommended enterprise deployment patterns for applications that need both: a device-specific CA private key, and trusted root status for the corresponding CA certificate? Are there plans to expand MDM capabilities related to certificate trust management or keychain trust settings for managed Macs? What is Apple's recommended approach for enterprise security products that need to deploy device-specific trusted CAs while maintaining strong protection of the associated private keys?

The user in our Organization are not allowed to have admin permissions on their macs. They also use Eduroam to connect to the wireless network. When they change their password, which hapends every 90 days, sometimes the pop-up to re-enter the password doesn't work. Sice they are not admin on the computer, they are not able to forget the network to re-join with new credentials. Is there a Config Profile that would allow standar user to change network settings? if not, is there a group that would allow it, similar to lpadmin for allowing standar user to change printer settings?

Is there any roadmap for getting classroom to work with MDMs and standard accounts? I know it works for mobile accounts as well as having teachers/students sign into their Apple Account. We have moved away from mobile accounts and would still like compatibility with MDM instad of having everyone sign in.

What is the state of the Active Directory in macOS Golden Gate. We've had issues in both Tahoe and Sequoia like login timeouts with OpenDirectory/ActiveDirectory, UID collisions between usernames, etc. We still need it for lab logins. If I missed something and there is a new way for students to login and logout easily on lab workstations that doesn't involve AD, I'd be all for it. Platform SSO and other auth methods are great for faculty and staff but labs are another story. So I'm curious what will be the best practice going forward.

In an MSP environment, we manage hundreds of Mac based client organizations. It would be really helpful to have support in the Apple Business API for automating APNS certificate and ADE / Apps & Books token renewal. Thanks!

Is there any planned enhancement in Declarative Device Management (DDM) to support enforceable software update maintenance windows for macOS and iPadOS in education environments? With 1000+ devices, it is not feasible to guarantee all devices are updated outside school hours. Some devices will inevitably be powered off during deadlines, then later turned on during the school day, triggering updates and a 60-minute install/reboot countdown. This results in devices updating during lessons, which disrupts teaching and is exactly what we need to avoid. Ideally, updates should only be allowed to install and reboot once a device is inside an approved maintenance window, regardless of when it becomes available or comes back online. Feedback has been provided via MDM account.