In iOS 26.1 beta 4, under MDM restrictions that disable the camera via a configuration profile, the Camera and FaceTime apps are hidden as expected. However, other third-party apps can still access and use the camera function normally. This is unreasonable.

Recently, we have encountered some users who have been unable to open the enterprise signature application after upgrading to version 18.3.2, without an IPS file. Through system logs, we found that signature verification has occurred SecKeyVerifySignature failed: Error Domain=NSOSStatusErrorDomain Code=-50 "rsa_pub_crypt failed, ccerr=-7" UserInfo={numberOfErrorsDeep=0, NSDescription=rsa_pub_crypt failed, ccerr=-7} Waiting for the information, I will provide the obtained system logs below. The application package name that crashed is com. mobile. moa aa.txt new

We have applications RME and RMEUI, which are added under FileProviders section. Looking for MDM profile that can lock these entries so that users cannot disable them. Currently we are using JAMF Pro MDM to control our applications. In Sequoia OS -> Open System Preferences -> General -> Login Items & Extensions -> Under Extensions section -> File Providers In Tahoe OS -> Open System Preferences -> General -> Login Items & Extensions -> Under By Category/App section -> File Providers (In the screen shot you can find RME entry)

Microsoft are retiring the “Azure AD Graph API”. We allow the use of Apple email apps in our M365 tenant via the “Apple Internet Accounts” Entra ID Enterprise Application, however this is using the “User.Read” permission from this retiring “Azure AD Graph API”. My concern is that Apple email app’s will stop working in our tenant when Microsoft retire the “Azure AD Graph API” and this permission is removed, as this is an Apple managed Enterprise Application, we have no method of changing the permissions ourselves. I have not been able to find any information on how the “Apple Internet Accounts” Entra ID Enterprise Application can be updated to use the required, newer “Microsoft Graph API” “User.Read” permission. It is not possible for us to change the permissions on the “Apple Internet Accounts” Entra ID Enterprise Application in our tenant, my assumption is that Apple would need to deploy a newer version of Email app that uses the newer “Microsoft Graph API” “User.Read” permission, and we would then need to consent the use of this new permission in our tenant. I would have thought Apple would have deploy this by now, but we have not seen any consent requests. Does anyone have any information about how Apple are handling this Microsoft change and how we can pre-emptively update the “Apple Internet Accounts” Entra ID Enterprise Application to ensure that Apple email client continue to work in our tenant? Many thanks.

I have enrolled a macbook through ADE to Apple School Manager and register it to the MDM service. Upon sending the initial DeclarativeManagement payload, the device return the client capabilities as below: "supported-versions": [ "1.0.0" ], "supported-payloads": { "declarations": { "activations": [ "com.apple.activation.simple" ], "assets": [ "com.apple.asset.credential.acme", "com.apple.asset.credential.certificate", "com.apple.asset.credential.identity", "com.apple.asset.credential.scep", "com.apple.asset.credential.userpassword", "com.apple.asset.data", "com.apple.asset.useridentity" ], "configurations": [ "com.apple.configuration.account.caldav", "com.apple.configuration.account.carddav", "com.apple.configuration.account.exchange", "com.apple.configuration.account.google", "com.apple.configuration.account.ldap", "com.apple.configuration.account.mail", "com.apple.configuration.account.subscribed-calendar", "com.apple.configuration.legacy", "com.apple.configuration.legacy.interactive", "com.apple.configuration.management.status-subscriptions", "com.apple.configuration.management.test", "com.apple.configuration.math.settings", "com.apple.configuration.passcode.settings", "com.apple.configuration.safari.extensions.settings", "com.apple.configuration.screensharing.connection", "com.apple.configuration.screensharing.connection.group", "com.apple.configuration.security.certificate", "com.apple.configuration.security.identity", "com.apple.configuration.security.passkey.attestation" ], "management": [ "com.apple.management.organization-info", "com.apple.management.properties", "com.apple.management.server-capabilities" ] }, "status-items": [ "account.list.caldav", "account.list.carddav", "account.list.exchange", "account.list.google", "account.list.ldap", "account.list.mail.incoming", "account.list.mail.outgoing", "account.list.subscribed-calendar", "device.identifier.serial-number", "device.identifier.udid", "device.model.family", "device.model.identifier", "device.model.marketing-name", "device.model.number", "device.operating-system.build-version", "device.operating-system.family", "device.operating-system.marketing-name", "device.operating-system.supplemental.build-version", "device.operating-system.supplemental.extra-version", "device.operating-system.version", "management.client-capabilities", "management.declarations", "screensharing.connection.group.unresolved-connection", "security.certificate.list", "test.array-value", "test.boolean-value", "test.dictionary-value", "test.error-value", "test.integer-value", "test.real-value", "test.string-value" ] }, "supported-features": { } } }, com.apple.configuration.softwareupdate.enforcement.specific couldn't be found. The macbook current OS version is 15.5 and it's supervised so looking at this, I assume it should include the Software Update:Enforcement:Specific capability? https://github.com/apple/device-management/blob/release/declarative/declarations/configurations/softwareupdate.enforcement.specific.yaml When I tried sending the payload to the device anyway the valid status is unknown

When I try to sign in Managed Apple ID in supervised device there appears a prompt stating that "Apple ID" is a work account.This account must be signed in as a work account on this device.When I click continue it takes to VPN and device management tab where MDM profile already exists. Note:The managed Apple ID has a ICloud subscription for it. When I remove the subscription for the Apple ID and try to sign in, it works. Kindly help on this or advise on any additional steps required to enable sign in for managed Apple ID in this scenario

I found a new Payload attribute LegacyAppConfigAssetReference in AppManaged introduced in iOs 18.4 beta. So I tried it, however no configuration is discoverted in the installed app. -- configuration { "Identifier": "8c2af0b6-5ae0-5927-a1cd-bab5e4148bb8", "Type": "com.apple.configuration.app.managed", "Payload": { "InstallBehavior": { "Install": "Required", "License": { "Assignment": "Device", "VPPType": "Device" } }, "AppStoreID": "535886823", "LegacyAppConfigAssetReference": "ac35558f-aefc-5faf-8f64-1faaff993b96" }, "ServerToken": "2abdc89492d89ca1a213ca61318ae0651c2b8de660c2847a44a3fb8ad9d9a8ad" } -- declaration/asset/ac35558f-aefc-5faf-8f64-1faaff993b96 { "Identifier": "ac35558f-aefc-5faf-8f64-1faaff993b96", "Type": "com.apple.asset.data", "Payload": { "Reference": { "DataURL": "https://i3-oreore-ios-mdm.azurewebsites.net/asset_files/eyJpZCI6IjNkOTg2YWVjNzQ1MWJiYWZlZjJmZGU1NmZmYmJlYjdkLnBsaXN0Iiwic3RvcmFnZSI6InN0b3JlIiwibWV0YWRhdGEiOnsiZmlsZW5hbWUiOiJFbmNvZGVkQ2hyb21lUG9saWN5RXhhbXBsZS5wbGlzdCIsInNpemUiOjMyMjUsIm1pbWVfdHlwZSI6ImFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbSJ9fQ", "ContentType": "application/plist" } }, "ServerToken": "7433f7c0c991a1943636ff7bd8949e88738c684ecbde347ac8a9c5b5c19dda14" } -- And the data type of the managed app configuration is application/plist http https://i3-oreore-ios-mdm.azurewebsites.net/asset_files/eyJpZCI6IjNkOTg2YWVjNzQ1MWJiYWZlZjJmZGU1NmZmYmJlYjdkLnBsaXN0Iiwic3RvcmFnZSI6InN0b3JlIiwibWV0YWRhdGEiOnsiZmlsZW5hbWUiOiJFbmNvZGVkQ2hyb21lUG9saWN5RXhhbXBsZS5wbGlzdCIsInNpemUiOjMyMjUsIm1pbWVfdHlwZSI6ImFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbSJ9fQ HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: max-age=31536000 Content-Length: 3225 Content-Type: application/plist Date: Tue, 18 Mar 2025 22:59:40 GMT X-Content-Type-Options: nosniff <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC '-//Apple//DTD PLIST 1.0//EN' 'http://www.apple.com/DTDs/PropertyList-1.0.dtd'> <plist version="1.0"> <dict> <key>EncodedChromePolicy</key> <string>PD94bWwgdmVyc2lvbj0iMS4wIiA/PjwhRE9DVFlQRSBwbGlzdCAgUFVCTElDICctLy9BcHBsZS8vRFREIFBMSVNUIDEuMC8vRU4nICAnaHR0cDovL3d3dy5hcHBsZS5jb20vRFREcy9Qcm9wZXJ0eUxpc3QtMS4wLmR0ZCc+PHBsaXN0IHZlcnNpb249IjEuMCI+PGRpY3Q+PGtleT5BdXRvRmlsbEVuYWJsZWQ8L2tleT48ZmFsc2UvPjxrZXk+Q29va2llc0FsbG93ZWRGb3JVcmxzPC9rZXk+PGFycmF5PjxzdHJpbmc+aHR0cDovL3d3dy5leGFtcGxlLmNvbTwvc3RyaW5nPjxzdHJpbmc+WyouXWV4YW1wbGUuZWR1PC9zdHJpbmc+PC9hcnJheT48a2V5PkNvb2tpZXNCbG9ja2VkRm9yVXJsczwva2V5PjxhcnJheT48c3RyaW5nPmh0dHA6Ly93d3cuZXhhbXBsZS5jb208L3N0cmluZz48c3RyaW5nPlsqLl1leGFtcGxlLmVkdTwvc3RyaW5nPjwvYXJyYXk+PGtleT5Db29raWVzU2Vzc2lvbk9ubHlGb3JVcmxzPC9rZXk+PGFycmF5PjxzdHJpbmc+aHR0cDovL3d3dy5leGFtcGxlLmNvbTwvc3RyaW5nPjxzdHJpbmc+WyouXWV4YW1wbGUuZWR1PC9zdHJpbmc+PC9hcnJheT48a2V5PkRlZmF1bHRDb29raWVzU2V0dGluZzwva2V5PjxpbnRlZ2VyPjE8L2ludGVnZXI+PGtleT5EZWZhdWx0UG9wdXBzU2V0dGluZzwva2V5PjxpbnRlZ2VyPjE8L2ludGVnZXI+PGtleT5EZWZhdWx0U2VhcmNoUHJvdmlkZXJFbmFibGVkPC9rZXk+PHRydWUvPjxrZXk+RGVmYXVsdFNlYXJjaFByb3ZpZGVyS2V5d29yZDwva2V5PjxzdHJpbmc+bWlzPC9zdHJpbmc+PGtleT5EZWZhdWx0U2VhcmNoUHJvdmlkZXJOYW1lPC9rZXk+PHN0cmluZz5NeSBJbnRyYW5ldCBTZWFyY2g8L3N0cmluZz48a2V5PkRlZmF1bHRTZWFyY2hQcm92aWRlclNlYXJjaFVSTDwva2V5PjxzdHJpbmc+aHR0cDovL3NlYXJjaC5teS5jb21wYW55L3NlYXJjaD9xPXtzZWFyY2hUZXJtc308L3N0cmluZz48a2V5Pk1hbmFnZWRCb29rbWFya3M8L2tleT48YXJyYXk+PGRpY3Q+PGtleT5uYW1lPC9rZXk+PHN0cmluZz5Hb29nbGU8L3N0cmluZz48a2V5PnVybDwva2V5PjxzdHJpbmc+Z29vZ2xlLmNvbTwvc3RyaW5nPjwvZGljdD48ZGljdD48a2V5Pm5hbWU8L2tleT48c3RyaW5nPllvdXR1YmU8L3N0cmluZz48a2V5PnVybDwva2V5PjxzdHJpbmc+eW91dHViZS5jb208L3N0cmluZz48L2RpY3Q+PC9hcnJheT48a2V5PlBhc3N3b3JkTWFuYWdlckVuYWJsZWQ8L2tleT48dHJ1ZS8+PGtleT5Qb3B1cHNBbGxvd2VkRm9yVXJsczwva2V5PjxhcnJheT48c3RyaW5nPmh0dHA6Ly93d3cuZXhhbXBsZS5jb208L3N0cmluZz48c3RyaW5nPlsqLl1leGFtcGxlLmVkdTwvc3RyaW5nPjwvYXJyYXk+PGtleT5Qb3B1cHNCbG9ja2VkRm9yVXJsczwva2V5PjxhcnJheT48c3RyaW5nPmh0dHA6Ly93d3cuZXhhbXBsZS5jb208L3N0cmluZz48c3RyaW5nPlsqLl1leGFtcGxlLmVkdTwvc3RyaW5nPjwvYXJyYXk+PGtleT5Qcm94eUJ5cGFzc0xpc3Q8L2tleT48c3RyaW5nPmh0dHA6Ly93d3cuZXhhbXBsZTEuY29tLGh0dHA6Ly93d3cuZXhhbXBsZTIuY29tLGh0dHA6Ly9pbnRlcm5hbHNpdGUvPC9zdHJpbmc+PGtleT5Qcm94eU1vZGU8L2tleT48c3RyaW5nPmRpcmVjdDwvc3RyaW5nPjxrZXk+UHJveHlQYWNVcmw8L2tleT48c3RyaW5nPmh0dHA6Ly9pbnRlcm5hbC5zaXRlL2V4YW1wbGUucGFjPC9zdHJpbmc+PGtleT5Qcm94eVNlcnZlcjwva2V5PjxzdHJpbmc+MTIzLjEyMy4xMjMuMTIzOjgwODA8L3N0cmluZz48a2V5PlNlYXJjaFN1Z2dlc3RFbmFibGVkPC9rZXk+PHRydWUvPjxrZXk+VHJhbnNsYXRlRW5hYmxlZDwva2V5Pjx0cnVlLz48a2V5PlVSTEJsYWNrbGlzdDwva2V5PjxhcnJheT48c3RyaW5nPmV4YW1wbGUuY29tPC9zdHJpbmc+PHN0cmluZz5odHRwczovL3NzbC5zZXJ2ZXIuY29tPC9zdHJpbmc+PHN0cmluZz5ob3N0aW5nLmNvbS9iYWRfcGF0aDwvc3RyaW5nPjxzdHJpbmc+aHR0cDovL3NlcnZlcjo4MDgwL3BhdGg8L3N0cmluZz48c3RyaW5nPi5leGFjdC5ob3N0bmFtZS5jb208L3N0cmluZz48L2FycmF5PjxrZXk+VVJMV2hpdGVsaXN0PC9rZXk+PGFycmF5PjxzdHJpbmc+ZXhhbXBsZS5jb208L3N0cmluZz48c3RyaW5nPmh0dHBzOi8vc3NsLnNlcnZlci5jb208L3N0cmluZz48c3RyaW5nPmhvc3RpbmcuY29tL2JhZF9wYXRoPC9zdHJpbmc+PHN0cmluZz5odHRwOi8vc2VydmVyOjgwODAvcGF0aDwvc3RyaW5nPjxzdHJpbmc+LmV4YWN0Lmhvc3RuYW1lLmNvbTwvc3RyaW5nPjwvYXJyYXk+PC9kaWN0PjwvcGxpc3Q+</string> </dict> </plist> Please note that this example plist is the same content as is described here: https://www.chromium.org/administrators/ios-mdm-policy-format/ After applying the declaration, the app GoogleChrome is successfully installed but no managed app configuration seems applied. MDMAppManagement.plist in the sysdiagnose is like below: plutil -p logs/MCState/Shared/MDMAppManagement.plist { "metadataByBundleID" => { "com.google.chrome.ios" => { "Attributes" => { "Removable" => 0 } "flags" => 1 "source" => "Declarative Device Management" "state" => 7 } "com.microsoft.skype.teams" => { "Attributes" => { "Removable" => 0 } "flags" => 1 "source" => "Declarative Device Management" "state" => 7 } } } I also tried with our private apps and not applied... How can we use this feature or check the configuration is applied? Thank you,

For additional security we would like to avoid keeping generated certificates (their private keys) on our server after installing them on a device, but still be able to reference them in later installed configuration profiles via MDM. However, it seems that for a configuration profile's payload to use a certificate (e.g. VPN payload), the certificate payload must be present in the same profile. Are we missing anything, perhaps it's already possible somehow? Ideal workflow for us would be: our MDM server generates a certificate (private+public keys) for a given device our MDM server sends this certificate to the device as configuration profile and saves PayloadUUID of the certificate's payload our MDM server deletes the generated private key from its storage. At this point the private key is present only on the device. at some point in the future our MDM server sends a configuration profile that references the certificate from step 2 via the saved PayloadUUID (e.g. using key PayloadCertificateUUID in a VPN payload) Current result: device responds to MDM server with error "The profile “VPN” could not be installed. Certificates needed for the VPN service “VPN” are invalid." Desired result: device is able to find the previously installed certificate via its PayloadUUID. Alternatively, it could be certificate fingerprint or something similar. One more alternative could be to replace steps 1-3 by an app on the device that obtains a certificate (in any way), installs it to device as a configuration profile, passes the certificate's PayloadUUID to our MDM server and then doing step 4.

Hi, I found In-App purchase feature is restricted even with User-based VPP. I understand Device-based VPP does not accept In-App purchase, however User-based VPP accept In-App purchase. (It works on iOS 15 device actually.) When I tried subscribe ChatGPT on iOS 26 device using User-based VPP, an error dialog is shown that explains In-App purchase is not allowed. sysdiagnose shows logs belog: 情報 2025-10-26 23:58:22.350841 -0700 storekitd [Client] (ChatGPT) Initializing client デフォルト 2025-10-26 23:58:22.353982 -0700 storekitd [Client] (ChatGPT) Initialized with server Production bundle ID com.openai.chat and request bundle ID com.openai.chat] デフォルト 2025-10-26 23:58:22.354020 -0700 storekitd [CanMakePayments] In-app purchase disabled because app com.openai.chat has MID based SINF In iOS 15 device, no storekitd logs are found and appstored and several processes seem to handle In-App purchase. Does In-App purchase no longer work with User-based VPP? Thank you.

Subject: Questions Regarding Signing Certificates for MDM Configuration Profiles Dear all, I hope this message finds you well. I have some questions regarding the signing certificates used for MDM configuration profiles. Currently, our company uses an SSL certificate to sign MDM configuration profiles. However, with the announcement that the validity period of SSL certificates will gradually be shortened starting in 2026, we are considering alternative options for signing certificates. Through our internal testing and investigation, we have found examples of the following certificate chains being used: ・Developer ID - G1 (Expiring 02/01/2027 22:12:15 UTC) + Developer ID Application certificate chain ・Apple Root CA + Apple Worldwide Developer Relations Intermediate Certificate + MDM CSR certificate chain We would appreciate any insights or experiences you can share regarding the following points: Apple Support previously advised that "certificates issued by public certificate authorities (CAs) trusted by Apple" are recommended. The certificates listed at https://www.apple.com/certificateauthority/ are typically preinstalled on Apple devices. Are these considered "trusted public CAs" by Apple in this context? Is it acceptable in practice to use a certificate obtained from the “Certificates, Identifiers &amp; Profiles” section on developer.apple.com for signing MDM configuration profiles? We would be grateful to hear about any real-world experiences. If the answer to question 2 is yes, which certificate type within “Certificates, Identifiers &amp; Profiles” would be most appropriate for signing configuration profiles? If using certificates from question 2 is not suitable, are there alternative certificate types (other than SSL) that are valid for longer periods (e.g., more than one year) and appropriate for signing MDM configuration profiles? Apple's official documents do not seem to clearly specify what type of certificate should be used to sign MDM configuration profiles. If you know of any helpful documents or resources related to this topic, we would greatly appreciate it if you could share them. Thank you very much for your time and support. We would truly appreciate any advice or guidance you can provide.

Hey everyone, Is it possible and how to get Managed Apple ID (email) programmatically for user signed in to ipad through shared IPad feature ? It would be good to have MDM independent solution, I mean API call to MDM service is not acceptable for us. Maybe API call to ASM or ABM, or get that somehow on iOS device end... any advice ? Thanks in advance, Dima

I recently reviewed the device management restrictions page of the developer docs (https://developer.apple.com/documentation/devicemanagement/restrictions) and noticed that several items are now marked "In a future release, this restriction will begin requiring supervision." Some of these changes are likely to have a dramatic impact on our app and business! So my question is threefold: a) where can I find out or request more information about the planned changes (e.g. timeline would be especially helpful)? b) why are these changes being implemented at all? c) to whom / where can I protest these changes (aside from this forum and feedback assistant)?

Background / Objective We are currently developing a solution to centrally manage Apple OS updates (major and minor) across managed macOS devices. Before implementing at scale, we need Apple’s guidance on supported and future-proof update mechanisms under MDM. Questions / Ask (Apple Guidance Requested) Apple recommended method What is Apple’s recommended approach to perform: Minor updates (e.g., macOS X.Y → X.Z) Major upgrades (e.g., Ventura → Sonoma) in an enterprise fleet? Support boundary Is macOS update management only supported via MDM (including any newer declarative workflows), or are local mechanisms (installer + command-line tooling) also considered supported for enterprise automation? Use of startosinstall Can we leverage the existing utility: /Applications/Install macOS .app/Contents/Resources/startosinstall for automated upgrades in enterprise environments? If yes, are there recommended flags/workflows Apple endorses for unattended or minimally interactive upgrades? Long-term support / stability Does startosinstall have any form of long-term support / stability guarantees across future macOS releases? Are there any known deprecations planned (or guidance that customers should transition to MDM/DDM workflows)? MDM interaction / interference When using startosinstall, can MDM policies (software update deferrals/restrictions, update enforcement, etc.) interfere with or block the upgrade? If interference is expected, what is the correct supported way to coordinate: MDM software update settings local startosinstall execution to avoid failures and ensure compliance? What We Need From Apple (Desired Outcome) A clear statement of recommended and supported update workflow(s) for enterprise managed macOS: for minor updates for major upgrades Guidance on whether startosinstall is acceptable for long-term automation, or whether we should only use MDM/DDM-driven workflows. Any best practices or reference documentation Apple recommends for implementing this safely and reliably.

Hello, I've noticed some unexpected behavior when updating a user's FileVault password. The set up: All actions are performed in virtualized macOS 14 and 15.5 guests on a 15.5 Apple Silicon host. FileVault is enabled. sjsp is a standard user with a Secure Token. The Mac is bound to AD, and the domain is reachable. Reproduction: systemctl -secureTokenStatus sjsp shows it's ENABLED. fdesetup remove -user sjsp fdesetup add -usertoadd sjsp systemctl -secureTokenStatus sjsp shows it's DISABLED. Surprisingly, sjsp is still able to unlock FileVault. Looking at unified logs for opendirectoryd and fdesetup, I see that a password change is being attempted in response to fdesetup add, which is unexpected. default 13:34:41.320883+0100 opendirectoryd Changing password for <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784) info 13:34:41.321317+0100 opendirectoryd No unlock record exists for E5CC46D7-0C1F-4009-8421-9AA8217CB784 info 13:34:41.321331+0100 opendirectoryd <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784) is not a SecureToken user: no unlock record default 13:34:41.321341+0100 opendirectoryd Changing password for <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784): user <private> SecureToken, only new password provided, credential <private> default 13:34:41.321454+0100 opendirectoryd Changing password for <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784) with no existing unlock record info 13:34:41.321857+0100 opendirectoryd No unlock record exists for E5CC46D7-0C1F-4009-8421-9AA8217CB784 default 13:34:41.321873+0100 opendirectoryd Record <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784) is eligible for SecureToken default 13:34:41.322637+0100 fdesetup DMAPFS cryptoUserForMacOSUserForVolume DMErr=-69594 retErr=-69594 outAPFSCryptoUser=(null) default 13:34:41.322699+0100 opendirectoryd While changing password for <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784): Not adding SecureToken; other unlock records exist, but no existing unlock record provided If I disconnect the network and follow the reproduction steps then the Secure Token is retained. Reconnecting and waiting a while doesn't cause the Secure Token to be lost. There are no log entries about attempting to change the password. Any help or explanation would be appreciated, thanks in advance.

Guideline 3.1.1 - Business - Payments - In-App Purchase The app includes an account registration feature for businesses and organizations, which is considered access to external mechanisms for purchases or subscriptions to be used in the app. Next Steps Remove the account registration features for business and organizations. Our application currently allows users to register and create multiple accounts using a phone number. All users can freely create an account. The app is designed to help users manage their own products, orders, and sales invoices. It is purely a sales management tool. We do not provide any external purchase links, external payment methods, or subscription mechanisms outside of Apple’s In-App Purchase system. However, our app was rejected under Guideline 3.1.1 with the explanation that the app includes “account registration for businesses or organizations,” which is considered access to external purchase mechanisms. We are confused about this interpretation. From our understanding: Any individual user can register. The registration process is only for authentication and data management. The app must include an account registration feature in order to function properly. There is no external purchasing mechanism involved in the registration process. Could someone please clarify: Why would allowing users (including small business owners) to register accounts be considered “access to external purchase mechanisms”? What specifically qualifies as “account registration for businesses or organizations” under Guideline 3.1.1? What changes would be required to comply with the guideline while still keeping mandatory account registration? We would greatly appreciate clarification so we can properly address the issue and ensure full compliance with App Store policies. Thank you.

Hello everyone, I recently changed the phone number associated with my Apple ID (about 4 days ago), but I’m still receiving the two-factor authentication verification codes on my old number instead of the new one. Has anyone experienced this? Is there a delay on Apple’s side, or is there something else I need to do to complete the update?

Hi, We're having problems starting an Ad Hoc ipa on an iPad with iOS 12.7.7 and 12.7.8. The iPad's UUID has been added to the provisioning profile. The iPad that we are trying to start the app on is online, so Apple's certificate validation server should be reachable. We don't have any problems with iOS versions above iOS 12. The .ipa was built using the latest version of Xcode (26.2, build 17C52). Here is the anonymised and reduced console log (only the app launch / bootstrap part): default 07:29:35.683108+0100 SpringBoard Icon touch began: <private> default 07:29:35.752640+0100 SpringBoard Icon tapped: <private> default 07:29:35.768538+0100 trustd cert[0]: SubjectCommonName =(leaf)[]> 0 default 07:29:35.791500+0100 SpringBoard Trust evaluate failure: [leaf IssuerCommonName LeafMarkerOid SubjectCommonName] default 07:29:35.793654+0100 trustd cert[0]: IssuerCommonName =(path)[]> 0 default 07:29:36.043497+0100 assertiond Submitting new job for "<APP_BUNDLE_ID>" on behalf of SpringBoard (pid: 48) default 07:29:36.044393+0100 SpringBoard Bootstrapping <APP_BUNDLE_ID> with intent foreground-interactive error 07:29:36.045124+0100 SpringBoard [<APP_BUNDLE_ID>] Bootstrap failed with error: domain: BKSProcessErrorDomain, code: 1 (bootstrap-failed), reason: "Failed to start job" error 07:29:36.045214+0100 SpringBoard Bootstrapping failed for <APP_BUNDLE_ID> (pid: -1): Error Domain=BKSProcessErrorDomain Code=1 "Unable to bootstrap process with bundleID <APP_BUNDLE_ID>" NSLocalizedFailureReason=Failed to start job NSUnderlyingError=NSPOSIXErrorDomain Code=3 "No such process" BKLaunchdOperation=launch_get_running_pid_4SB BKLaunchdJobLabel=<LAUNCHD_JOB_LABEL> BKSProcessJobLabel=<LAUNCHD_JOB_LABEL> default 07:29:36.046078+0100 assertiond Submitted job with label: <LAUNCHD_JOB_LABEL> default 07:29:36.046442+0100 assertiond Unable to get pid for '<LAUNCHD_JOB_LABEL>': No such process (3) error 07:29:36.046542+0100 assertiond Failed to start job: NSPOSIXErrorDomain Code=3 "No such process" default 07:29:36.046607+0100 assertiond Deleted job with label: <LAUNCHD_JOB_LABEL> default 07:29:36.081068+0100 SpringBoard Application process state changed for <APP_BUNDLE_ID>: pid: -1; taskState: Not Running

Hi, everyone! Is there any way to change ACL of existing Private key in system keychain using MDM? We would like to add the binary or .app to access list of the key. I tried to send script via MDM which imported/exported our certificate with private key with required ACL. But can we change it without import/export?

Issue Using the DeviceInformationCommand API, the following device information can no longer be retrieved on iOS/iPadOS 26 and later. IMEI ICCID PhoneNumber This issue does not occur on devices running iOS/iPadOS 18.x or earlier. We would appreciate it if you could advise us on a solution to enable the retrieval of this information. Request XML <?xml version=\"1.0\" encoding=\"UTF-8\"?> <!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\"> <plist version=\"1.0\"> <dict> <key>CommandUUID</key> <string><!-- Here is CommandUUID --></string> <key>Command</key> <dict> <key>RequestType</key> <string>DeviceInformation</string> <key>Queries</key> <array> <string>IMEI</string> <string>ICCID</string> <string>PhoneNumber</string> </array> </dict> </dict> </plist>

We are upgrading macOS (minor versions and potentially major versions) using a scripted approach: Install the InstallAssistant package via installer Trigger OS install via startosinstall On MDM-managed assets, OS update policies appear to prohibit or interfere with the update flow. The update often fails with startosinstall reporting “Helper tool crashed…” during the “Preparing” phase. Steps to Reproduce On an MDM-enrolled Mac with OS update restriction/deferral policies applied, run: sudo /usr/sbin/installer -pkg /Path/To/InstallAssistant.pkg -target / && echo 'MACOS_PASSWORD' | /Applications/Install\ macOS\ Sonoma.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --stdinpass --user MACOS_USER Actual Result Package installation reports success, but startosinstall fails during preparation with: Standard Output installer: Package name is macOS15.7_SoftwareUpdate installer: Upgrading at base path / installer: The upgrade was successful. By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms. If you do not agree, press CTRL-C and cancel this process immediately. Preparing to run macOS Installer... Preparing: 0.0% Preparing: 0.1% ... Preparing: 24.9% Standard Error Helper tool crashed... notes.log Install.log is also attached. Questions for Apple / Ask: We suspect this crash is caused by MDM OS update restrictions/policies. We need Apple’s recommended method to perform macOS updates (minor + major) when MDM is present, especially in environments where update deferrals/restrictions may be configured.