I'm the IT Admin in my company. We use Microsoft Intune, which is a Mobile Device Management tool, to manage our devices and apps. I created an app protection policy, restricting the data can only be shared between the allowed apps. For example, if our user want to copy the content in Outlook for iOS to WeChat or personal memo, the action will be blocked. However, may be it's too strict, here is the scenario that we need to hadle: A user selected the content in the Outlook for iOS mail, and wanted to use the "translate" function to do translation. Before the app protection policy was deployed, he can do the translation successfully. And now, it's blocked. Therefore, we need to find a way to exempt the app "Translate" so that users can do the translation successfully. We put the value "com.apple.Translate"(this is a package ID listed in the official document of Apple) to the exemption, but it's not working. May I know what is the correct "value" for the iOS native Translate APP? I need to put this value to our app protection policy to exempt Translate app. Thank you so much.

Topic: App Store Small Business Program Application - Pending Review Submission Date: April 22 Most Recent Support Case ID: 102935711794 Hi everyone, I submitted my application for the App Store Small Business Program back on April 22. It has been over 3 months without any status update or confirmation. I have checked my Agreements, Tax, and Banking page in App Store Connect to ensure all contracts (including the Paid Applications Agreement), tax documents, and banking information are active and fully up to date. There are no pending actions required on my end. I have submitted 5 separate support inquiries through the Developer Contact portal regarding this delay, but I have not received a resolution or progress update. Could an Apple Staff member or moderator please assist in escalating my Team ID and Case IDs to the Agreements & Contracts Operations team so my enrollment can be reviewed? Thank you!

We develop a third-party endpoint security agent (DLP / device control). It needs kTCCServiceBluetoothAlways to enumerate paired Bluetooth devices and disconnect them selectively based on policy — without user interaction, since this runs unattended on managed fleets. Until recently we granted this silently via a com.apple.TCC.configuration-profile-policy (PPPC) profile pushed by MDM, or by writing directly to the TCC database — the latter no longer possible starting with macOS 27 (Golden Gate). As of macOS 27, tccd also ignores the PPPC profile approach: Override: skipping kTCCServiceBluetoothAlways ... as it is defined in deprecated PPPC profile As a result, end users now hit the standard Bluetooth access consent popup, which we have no way to suppress or pre-answer with Allow. ** Questions: ** Is there any currently supported MDM mechanism — profile-based, DDM, or otherwise — to pre-approve kTCCServiceBluetoothAlways for a specific managed app, so the popup never appears? If direct pre-approval is gone for good, is there any supported way to auto-answer the popup on the user’s behalf via policy (as exists for some other TCC services)? Is this now permanently interactive by design, or is a replacement mechanism planned for MDM-managed Bluetooth access?

Hi everyone, We are currently preparing to submit an enterprise MDM (Mobile Device Management) agent/client application to the App Store. We would like to seek advice or best practices from the community and Apple engineers on how to handle the App Review process for this type of application. https://postimg.cc/kBLFWB3t Our production workflow is as follows: The target device is enrolled into our MDM server. The server then deploys our agent app to the device, attaching its ManagedAppConfiguration payload during installation. The app is launched and successfully reads the configuration. If the app is launched standalone (without being deployed and configured by our MDM server), it naturally starts in an "Unconfigured" state and displays "Application not configured. Please register your device or contact the administrator." Since App Reviewers do not enroll their test devices into our MDM server, they will only see the "Unconfigured" screen when launching the app during the review. Our questions are: How does the App Review team typically evaluate the complete functionality of an MDM agent app in this scenario under Guideline 2.1 (App Completeness)? What are the recommended practices or setup requirements for developers to prepare? (e.g., Is providing an offline/demo sandbox mode inside the app, or providing an end-to-end walkthrough video of the active management workflow, the standard way to satisfy the review?) Under Guideline 5.5 (Mobile Device Management), what specific verification materials or organizational documentation should we prepare in App Store Connect to demonstrate that our application is an authorized commercial MDM solution? We would highly appreciate any guidance, shared experiences, or official best practices. Thank you!

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.

Hi everyone, We are currently developing an on-premises enterprise MDM (Mobile Device Management) server. We are implementing the Software Update feature and need to support a wide range of devices, ranging from legacy versions (iOS 15 and below) to modern versions (iOS 16, 17, and later). As we know, iOS 16+ supports Declarative Device Management (DDM) for software updates (using configurations like com.apple.configuration.softwareupdate.enforcement.specific), which is now the recommended best practice. However, we still have enterprise clients running iOS 15 and below, which do not support DDM. These legacy devices require traditional MDM command payloads (such as ScheduleOSUpdate, OSUpdateStatus, and AvailableOSUpdates). We noticed that Apple has recently deprecated and removed the documentation for these legacy commands (e.g., the "Schedule an OS Update" endpoint documentation has been deleted from the Apple Developer Documentation portal). We would appreciate advice on the following: Is a "Dual-Pathway" approach still the recommended architecture for modern MDM servers to handle this transition (i.e., detecting OS version, sending traditional ScheduleOSUpdate plist commands for iOS 15 and below, and sending DDM Declarative configurations for iOS 16+)? Since the official documentation for legacy ScheduleOSUpdate and related commands has been deleted, where can we officially find the archived technical specifications and plist schemas for these commands to ensure proper backward-compatible implementation? Thank you so much in advance for your guidance!

Hi everyone, We are currently developing an on-premises enterprise MDM (Mobile Device Management) server. We are implementing the Software Update feature and need to support a wide range of devices, ranging from legacy versions (iOS 15 and below) to modern versions (iOS 16, 17, and later). As we know, iOS 16+ supports Declarative Device Management (DDM) for software updates (using configurations like com.apple.configuration.softwareupdate.enforcement.specific), which is now the recommended best practice. However, we still have enterprise clients running iOS 15 and below, which do not support DDM. These legacy devices require traditional MDM command payloads (such as ScheduleOSUpdate, OSUpdateStatus, and AvailableOSUpdates). We noticed that Apple has recently deprecated and removed the documentation for these legacy commands (e.g., the "Schedule an OS Update" endpoint documentation has been deleted from the Apple Developer Documentation portal). We would appreciate advice on the following: Is a "Dual-Pathway" approach still the recommended architecture for modern MDM servers to handle this transition (i.e., detecting OS version, sending traditional ScheduleOSUpdate plist commands for iOS 15 and below, and sending DDM Declarative configurations for iOS 16+)? Since the official documentation for legacy ScheduleOSUpdate and related commands has been deleted, where can we officially find the archived technical specifications and plist schemas for these commands to ensure proper backward-compatible implementation? Thank you so much in advance for your guidance!

Summary: When applying a configuration profile that uses allowListedAppBundleIDs to permit a defined set of apps, essential Apple Watch apps are unexpectedly removed from the paired Watch — even though their associated iPhone bundle IDs are explicitly included. This issue occurs with a minimal profile, and has been consistently reproducible on the latest versions of iOS and watchOS. Impact: This behavior severely limits the use of Apple Watch in managed environments (e.g., education, family management, accessibility contexts), where allowlisting is a key control mechanism. It also suggests either: Undocumented internal dependencies between iOS and watchOS apps, or A possible regression in how allowlists interact with Watch integration. Steps to Reproduce: Create a configuration profile with a Restrictions payload containing only the allowListedAppBundleIDs key. Allow a broad list of essential system apps, including all known Apple Watch-related bundle IDs: com.apple.NanoAlarm com.apple.NanoNowPlaying com.apple.NanoOxygenSaturation com.apple.NanoRegistry com.apple.NanoRemote com.apple.NanoSleep com.apple.NanoStopwatch com.apple.NanoWorldClock (All the bundles can be seen in the Attached profile) Install the profile on a supervised or non-supervised iPhone paired with an Apple Watch. Restart both devices. Observe that several core Watch apps (e.g. Heart Rate, Activity, Workout) are missing from the Watch. Expected Behavior: All apps explicitly included in the allowlist should function normally. System apps — especially those tied to hardware like Apple Watch — should remain accessible unless explicitly excluded. Actual Behavior: Multiple Apple Watch system apps are removed or hidden, despite their iPhone bundle IDs being listed in the allowlist. Test Environment: iPhone running iOS 18 Apple Watch running watchOS 11 Profile includes only the allowListedAppBundleIDs key Issue confirmed on fresh devices with no third-party apps Request for Apple Engineering: Please confirm whether additional internal or undocumented bundle IDs are required to preserve Apple Watch functionality when allowlisting apps. If this behavior is unintended, please treat this as a regression or bug affecting key system components. If intentional, please provide formal documentation listing all required bundle IDs for preserving Watch support with allowlisting enabled. Attachment: .mobileconfig profile demonstrating the issue (clean, minimal, reproducible) Attached test profile = https://drive.google.com/file/d/12YknGWuo1bDG-bmzPi0T41H6uHrhDmdR/view?usp=sharing

I'm a third-party MDM developer using the Automated Device Enrollment (DEP) cloud service API. My flow is the standard token exchange: I upload my public key to Apple Business Manager, download the encrypted server token, and store the resulting OAuth credentials (consumer_key, consumer_secret, access_token, access_secret) to authenticate and fetch device information. Recently I've started seeing authentication failures on tokens whose access_token_expiry still has 6+ months of validity remaining. The credentials were working fine and then began getting rejected, with no change on my side. My questions for anyone who has seen this: Has anyone else observed DEP/ADE server tokens being rejected well before their stated access_token_expiry? What are the known triggers for early invalidation? (e.g., the ABM user who created the MDM server being deactivated or having a role change, the token being re-downloaded/regenerated, edits to the MDM server record, or Apple-side session invalidation.) Is there a supported way to detect that a still-unexpired token has been invalidated, other than catching the auth failure at request time? I want to confirm whether this is expected behavior tied to the ABM account/server lifecycle rather than the token's expiry date, so I can handle it correctly (i.e., prompt for a token re-download) instead of treating it as a bug. Any confirmation, similar reports, or official guidance would be appreciated. Thanks.

We're migrating our MDM-managed app from Enterprise (In-House) to App Store distribution and encountering error 9610 when using InstallApplication with iTunesStoreID. What worked (Enterprise) RequestType InstallApplication ManifestURL https://server/app.plist Configuration CompanyCode example This installed the app and delivered Managed App Configuration simultaneously. ✅ What fails (App Store) RequestType InstallApplication iTunesStoreID 6783649530 ChangeManagementState Managed Configuration CompanyCode example Result: Error 9610 (ASDServerErrorDomain — "Unhandled exception") We tried with/without PurchaseMethod (0 and 1), and without the Options key entirely — same error every time. Environment MDM: Custom (fully approved, case #102814667075) Device: iPhone 12 mini, iOS 18.5, non-supervised App: Already installed via TestFlight VPP/ABM: Not enrolled Questions Does InstallApplication with iTunesStoreID require a VPP license to work at all (even just for managing the app)? If VPP is required, is there an alternative to deliver Managed App Configuration (com.apple.configuration.managed) to an App Store app without Apple Business Manager? 3. Can Identifier (bundle ID) be used instead of iTunesStoreID to convert an already-installed app to managed state and push Configuration? Any guidance appreciated. The Enterprise → App Store migration is blocked solely by this issue.

On a supervised device running iOS 18 without any AirDrop restrictions applied, when a profile with allowListedAppBundleIDs restriction key is installed, the AirDrop sound plays. But still the accept prompt does not appear, making it impossible to accept files. The prompt works as expected on iOS 18 devices to which the allowListedAppBundleIDs restriction is not installed. This issue occurs only on supervised iOS 18 devices to which the allowListedAppBundleIDs restriction is being applied. Device must be in iOS 18 version > Install the (allowListedAppBundleIDs restriction) profile with the device > Try to AirDrop files to the managed device. The expected result is that the accept prompt must pop up but it does not appear. This issue is occurring irrespective of any Whitelisted bundle ID being added to the allowListedAppBundleIDs restriction profile. Have attached a few Whitelisted bundle ID here com.talentlms.talentlms.ios.beta, com.maxaccel.safetrack, com.manageengine.mdm.iosagent, com.apple.weather, com.apple.mobilenotes, gov.dot.phmsa.erg2, com.apple.calculator, com.manageengine.mdm.iosagent, com.apple.webapp, com.apple.CoreCDPUI.localSecretPrompt etc. Have raised a Feedback request (FB15709399) with sysdiagnose logs and a short video on the issue.

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 building a NETransparentProxyProvider system extension on macOS. The extension needs a certificate identity provisioned by MDM for cryptographic operations at runtime (signing and/or mTLS). We have hit a wall where a PKCS#12-delivered identity resolves correctly inside the extension but an ACME-delivered identity does not, and we want to understand whether this is a known limitation, a gap, or whether there is a supported path we are missing. We understand the implications of the data protection keychain on macOS but wonder if there is a carveout here that may not be documented well. We deploy the extension via MDM (profile traditionally but could be via DDM on macOS27). A VPN profile delivers an identity reference to the extension at runtime via PayloadCertificateUUID which surfaces an identity reference within protocolConfiguration.identityReference. When referencing a PKCS#12 identity (com.apple.security.pkcs12 payload): the identityReference is 196 bytes, beginning with the 4-byte prefix 73737569 (ASCII "ssui"). The reference is self-describing — it embeds the keychain path (/Library/Keychains/System.keychain), the certificate subject (in our case, "Delegate Test CA"), the team ID, and a 20-byte SHA-1 hash at the tail. This format carries everything the Security framework needs to locate the item. Full reference (our test, redacted to structure): 73737569 00000020 <uuid-bytes> 00000000000000000000000000000006 64626e6d 00000023 2f4c696272…53797374656d2e6b6579636861696e00 ← /Library/Keychains/System.keychain 6974656d 00000069 80001000… ← item data incl. DER subject … 00000014 48b494ae47d1b7b07ed8c77a681337a3af8e92a8 ← 20-byte SHA-1 hash When referencing a ACME identity (com.apple.security.acme payload, ECSECPrimeRandom P-384, SE-backed): the identityReference is 20 bytes, beginning with the 4-byte prefix 63657274 (ASCII "cert"). The remaining 16 bytes are opaque — they do not embed a keychain path, certificate subject, or any other locator. Full reference (our test): 63657274 a4c7e569737944b1 ad464dc3bb398f14 Searching for the SecIdentity The PKCS#12 reference resolves using SecItemCopyMatching with kSecValuePersistentRef set to the 196-byte reference and kSecMatchSearchList pointing at System.keychain succeeds immediately, returning a SecIdentity with both SecIdentityCopyCertificate and SecIdentityCopyPrivateKey succeeding - this is obviously expected for an exportable software key type. The ACME reference fails using every path that we tried to search/load it as a SecIdentity. Primarily: kSecValuePersistentRef with kSecUseDataProtectionKeychain: true (no explicit keychain): -25291 (errSecNoDefaultKeychain) kSecValuePersistentRef with an explicit kSecMatchSearchList pointing at System.keychain: -50 (errSecParam) — combining kSecValuePersistentRef with an explicit keychain search list is an invalid parameter combination for the compact cert-format reference. kSecMatchItemList with an explicit kSecMatchSearchList: -25300 (errSecItemNotFound) SecKeychainItemCopyFromPersistentReference (legacy API): -25300 (errSecItemNotFound) kSecValuePersistentRef with no keychain qualifier at all: -25291 (errSecNoDefaultKeychain) com.apple.managed.vpn.shared access group (which i know has had entitled use on iOS): -34018 (errSecMissingEntitlement) Next steps The cert-format kSecValuePersistentRef produced by an ACME identity cannot be resolved in a root daemon context using any API path we can find. The ssui-format reference from a PKCS#12 identity works. With macOS 27, com.apple.configuration.network.vpn.vpn-plugin DDM declarations accept an Authentication.IdentityAssetReference which can point at an ACME identity asset. Traditional VPN profiles also support PayloadCertificateUUID referencing an ACME payload. Both paths result in the extension receiving a cert-format reference that it cannot resolve. Is there a supported API to resolve a cert-format kSecValuePersistentRef in a daemon context without a default keychain? Or is this just the reality of the DPK on macOS where ACME/SE-backed identities are not usable from system extensions, and the IdentityAssetReference and PayloadCertificateUUID fields only work for PKCS#12 or SCEP identity types in this context? For completeness: we have also explored ManagedApp.framework and ManagedAppIdentitiesProvider as an alternative delivery path, and believe this is the better method, but that hits a separate issue where managedappsd fails to verify the code signature of a system extension caller (filed separately as feedback FB23484530). Similar to this, we need to understand if the ExtensionConfigs in ManagedApp.framework are for appex user space app extensions only, and don't extend to System Extensions.

I was trying to add a bank account, but the page seems to be having issue right now. And browser console showing: container.243b4934f1512a8c.js:2 TypeError: n is not a function at react-dom.production.min.js?3.0.0:2:58035 at unstable_runWithPriority (react.production.min.js?3.0.0:2:8382) at Et (react-dom.production.min.js?3.0.0:2:23750) at lr (react-dom.production.min.js?3.0.0:2:57957) at sr (react-dom.production.min.js?3.0.0:2:60521) at Fr (react-dom.production.min.js?3.0.0:2:73003) at unstable_runWithPriority (react.production.min.js?3.0.0:2:8382) at Et (react-dom.production.min.js?3.0.0:2:23750) at Rr (react-dom.production.min.js?3.0.0:2:70856) at kr (react-dom.production.min.js?3.0.0:2:67013) at react-dom.production.min.js?3.0.0:2:24040 at unstable_runWithPriority (react.production.min.js?3.0.0:2:8382) at Et (react-dom.production.min.js?3.0.0:2:23750) at Pt (react-dom.production.min.js?3.0.0:2:23986) at Ct (react-dom.production.min.js?3.0.0:2:23921) at zl (react-dom.production.min.js?3.0.0:2:114297) at fe (react-dom.production.min.js?3.0.0:2:13978) at HTMLDocument.n (container.243b4934f1512a8c.js:2:302781) (anonymous) @ container.243b4934f1512a8c.js:2 Zn @ react-dom.production.min.js?3.0.0:2 n.payload @ react-dom.production.min.js?3.0.0:2 Vt @ react-dom.production.min.js?3.0.0:2 Vn @ react-dom.production.min.js?3.0.0:2 ic @ react-dom.production.min.js?3.0.0:2 Mr @ react-dom.production.min.js?3.0.0:2 Nr @ react-dom.production.min.js?3.0.0:2 kr @ react-dom.production.min.js?3.0.0:2 (anonymous) @ react-dom.production.min.js?3.0.0:2 unstable_runWithPriority @ react.production.min.js?3.0.0:2 Et @ react-dom.production.min.js?3.0.0:2 Pt @ react-dom.production.min.js?3.0.0:2 Ct @ react-dom.production.min.js?3.0.0:2 zl @ react-dom.production.min.js?3.0.0:2 fe @ react-dom.production.min.js?3.0.0:2 n @ container.243b4934f1512a8c.js:2 container.243b4934f1512a8c.js:2 TypeError: n is not a function at react-dom.production.min.js?3.0.0:2:58035 at unstable_runWithPriority (react.production.min.js?3.0.0:2:8382) at Et (react-dom.production.min.js?3.0.0:2:23750) at lr (react-dom.production.min.js?3.0.0:2:57957) at sr (react-dom.production.min.js?3.0.0:2:60097) at lr (react-dom.production.min.js?3.0.0:2:58303) at sr (react-dom.production.min.js?3.0.0:2:60097) at Fr (react-dom.production.min.js?3.0.0:2:73003) at unstable_runWithPriority (react.production.min.js?3.0.0:2:8382) at Et (react-dom.production.min.js?3.0.0:2:23750) at Rr (react-dom.production.min.js?3.0.0:2:70856) at kr (react-dom.production.min.js?3.0.0:2:67013) at react-dom.production.min.js?3.0.0:2:24040 at unstable_runWithPriority (react.production.min.js?3.0.0:2:8382) at Et (react-dom.production.min.js?3.0.0:2:23750) at Pt (react-dom.production.min.js?3.0.0:2:23986) at Ct (react-dom.production.min.js?3.0.0:2:23921) at zl (react-dom.production.min.js?3.0.0:2:114297) at fe (react-dom.production.min.js?3.0.0:2:13978) at HTMLDocument.n (container.243b4934f1512a8c.js:2:302781)

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

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?