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)

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?

We are trying the renewal the apple Enterprise program. It asks set of questions after that it shows the below message "Thank you for your request to renew your membership in the Apple Developer Enterprise Program. We’ll review your submission and get back to you shortly to let you know if we can process the renewal or if another program better serves your organization’s needs." We have submitted for review for over two months now. During these two months, we have contacted the official customer service multiple times, only to be told to wait for news. Now, with only a few days left, The status hasn't changed, neither approved nor rejected，what should we do？This account is very important to our company. Thank you

"If your app includes any links outside the app, or offers any in-app or other purchasing opportunities, make sure these are behind a parental gate" Super Awesome and Kidoz are proving with a parental gate on ad click and they also claim that all ads are manually approved (another criteria for ads in Kids apps). So these two are the only ad networks we can use moving forward. Or we can use ad networks like Admob as well? I dont intend not to be in Kids category - so leaving Kids category is not a choice.

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

Hello Apple Developer Community, I am implementing the "Return to Service" feature with app preservation in our MDM solution (iOS 26+). My goal is to use the EraseDeviceCommand to securely erase user data while preserving managed apps, and then have the device automatically re-enroll without user interaction. What I am doing: The device is supervised and successfully enrolled in Automated Device Enrollment (ADE). The device has generated and escrowed a bootstrap token to our MDM server (SetBootstrapToken received). I am sending the EraseDeviceCommand to the device via MDM with the necessary parameters for Return to Service with app preservation. The command payload includes: Enabled: true The previously escrowed BootstrapToken (as Base64 data). WiFiProfileData (as Base64 data) to ensure connectivity post-erase. Example Payload Structure (Simplified): <key>ReturnToService</key> <dict> <key>Enabled</key> <true/> <key>BootstrapToken</key> <data>YOUR_BASE64_TOKEN</data> <key>WiFiProfileData</key> <data>YOUR_BASE64_WIFI_PROFILE</data> </dict> The observed behavior: The erase command is successful. The device performs the secure user data erase. Crucially, the managed applications are preserved and automatically installed again after the reboot (confirming app preservation is working). The device connects to the Wi-Fi network successfully. The issue: I am not seeing the GetBootstrapToken request from the device hit our MDM server's check-in URL during the post-erase setup assistant phase. The re-enrollment seems to complete, but this specific request is missing from our server logs. My questions: Is the GetBootstrapToken request an explicit check-in message type, or is it an implicit part of the general CheckIn process during ADE re-enrollment when the token is used? If the device successfully re-enrolls and preserves apps, is the explicit GetBootstrapToken request still expected? Or does the token included in the EraseDeviceCommand payload satisfy all authentication needs for this workflow? What specific conditions or capabilities on the MDM server side might prevent the device from sending this specific request, even if the overall process succeeds? Any insights from Apple engineers or other developers who have successfully implemented this flow would be greatly appreciated. Thank you!

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)?

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 everyone, I submitted this feature request through Apple’s Feedback Assistant and wanted to share it here, because many families run into the same issue and Apple prioritizes features based on the number of reports they receive. Current limitation: Screen Time only allows one single Downtime period per day for child accounts. For families with separate school hours and bedtime, this is very impractical. My real-world use case: • Downtime 1: 08:00–13:00 (school) • Downtime 2: 20:00–06:00 (bedtime) Both serve completely different purposes, but are not possible to combine with the current system. My suggestions to Apple: Support multiple Downtime periods per day for child accounts. Allow custom exceptions per Downtime block (e.g., allow Phone app). Provide more flexibility overall for families using Screen Time. If you would benefit from this too, it would be great if you could submit the same request via the Feedback app – the more reports Apple receives, the higher the chance for implementation. My Feedback ID: FB21265678 Thank you! 🙏 Hallo zusammen, ich habe über die Feedback-App einen Vorschlag an Apple eingereicht und wollte ihn hier teilen, weil viele Familien dasselbe Problem haben und Apple mehr Rückmeldungen braucht, um das Thema zu priorisieren. Aktuelles Problem: In Bildschirmzeit kann für Kinder aktuell nur eine einzige Auszeit pro Tag eingerichtet werden. Für Familien mit getrennten Schul- und Schlafenszeiten ist das extrem unpraktisch. Mein Anwendungsfall: • Auszeit 1: 08:00–13:00 (Schule) • Auszeit 2: 20:00–06:00 (Schlafenszeit) Beides erfüllt unterschiedliche Zwecke, ist aber nicht kombinierbar. Mein Vorschlag an Apple: Mehrere Auszeiten pro Tag für Kinderaccounts. Pro Auszeit eigene Ausnahmen festlegen (z. B. Telefon erlauben). Allgemein mehr Flexibilität im Screen-Time-System für Familien. Wenn ihr das ebenfalls hilfreich findet, wäre es super, wenn ihr es auch über die Feedback-App meldet – je mehr, desto besser. Feedback-ID meines Vorschlags: FB21265678 Danke euch! 🙏

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

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>

Hello All, I come to ask a question that I haven't been able to find the docs. I continue to work on implementing declarative management and while working there is a question/concern I have. I have noticed that during some destructive testing, if the device is attempting to fetch a configuration and the server responds with a 503 (or any server related error) then the device will wipe all configurations and attempt to reapply them. Is there any way to prevent this by intercepting status codes or would the only real solution be to force down a temp/test config if the real config can't be fetched from the server?

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.

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.

We are currently working on a SCEP server implementation that operates in FIPS-approved mode. In this mode, RSA PKCS#1 v1.5 encryption is disallowed due to compliance requirements, and only FIPS-approved padding schemes such as RSA-OAEP are permitted. However, we have observed that the SCEP client functionality on Apple devices currently does not support RSA-OAEP for CMS EnvelopedData decryption. This creates a challenge for us in ensuring FIPS compliance while maintaining compatibility with Apple devices during certificate enrollment through SCEP. We would appreciate your guidance on the following: Are there any alternative FIPS-approved encryption algorithms or configurations supported by Apple devices for SCEP CMS EnvelopedData decryption? Is there any plan or timeline for future support of RSA-OAEP on Apple platforms for this use case? Feedback raised along with sysdiagnose logs as well : FB17655410

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

Hey folks, I work as a software development consultant. We develop enterprise applications for our clients, and the apps we create are usually for internal use. We've ran into a bit of a conundrum with a client who doesn't have their own Apple Enterprise account, and neither do we as we don't meet the criteria, but they're wanting to distribute an application we've built for them via their own MDM software. We are not entirely sure how to provide them with a distribution ready .ipa file that isn't AdHoc and will be recognized as a secure app. We've looked into generating a Developer ID provisioning profile and accompanying cert, however we're running into a problem where the platform of our app (iOS) doesn't match the platform required by the Developer ID profile (macOS). I've also come across the idea of resigning an .ipa, but again, the client doesn't have a Apple Developer account and expects the working .ipa to be included in the service rendered. Any suggestions or advice or documentation around the subject would be greatly appreciated. Thanks, Ale

10:17:34.335397+0900 Process SpringBoard Bootstrapping failed for <FBApplicationProcess: 0x4d8eca700; app<com.a.b.c>:> with error: <NSError: 0x300a3d1d0; domain: RBSRequestErrorDomain; code: 5; "Launch failed."> { NSUnderlyingError = <NSError: 0x300a54090; domain: NSPOSIXErrorDomain; code: 85> { NSLocalizedDescription = Launchd job spawn failed; }; }

How to test ManagedAppConfigurationProvider without MDM ? Task { /* Configuration provider task */ for await configuration in configurationProvider.configurations(MyAppConfiguration.self) { self.configuration = configuration ?? MyAppConfiguration.defaultConfiguration } } Can the existence of a configuration be simulated, e.g. by storing a mocked configuration in UserDefaults? The UserDefaults key "com.apple.configuration.managed" seems not relevant here.