Hello everyone, our company has an annual fee of $299 for an enterprise developer account, which is about to expire next month, but I submitted the renewal application, but after a month, I received an email that refused to renew the subscription. Is there any remedy for this? This account is very important to our company. Thank you

I'm reaching out to discuss a significant issue related to how iOS handles app login sessions, particularly in the context of MDM (Mobile Device Management) and the Outlook app. In our organization, we use MDM to distribute applications, including Outlook, with certificate-based authentication for BYOD (Bring Your Own Device) devices. This setup allows users to log in seamlessly to their accounts. However, we've encountered a concerning behavior: when a user unenrolls from MDM, which automatically removes the distributed apps and certificates, they can later reinstall the app from the App Store and find themselves automatically logged back into their previous accounts without any authentication prompts. Here’s a detailed breakdown of the situation: Initial Installation: Users enroll their devices in MDM, which installs the necessary apps and certificates on those devices. Session Storage: After the initial login, the app stores the session locally on the device. App Deletion: When users un enroll their devices from MDM, it automatically removes the distributed apps and certificates. Reinstallation: Days or weeks later, when they reinstall the Outlook app from the App Store, they find themselves automatically logged back into their accounts. This behavior raises important concerns: Lack of Authentication: The app retaining user sessions even after deletion allows users to access their accounts without re-authentication, which could lead to potential unauthorized access and undermines the effectiveness of certificate-based authentication and two-factor authentication (2FA). Note: This issue is not limited to Outlook; we've observed similar behavior with many other apps. Need for a Solution - Given the implications of this behavior, we are looking for effective solutions to prevent it. Specifically, we need options within the MDM framework to: Restrict Session Retention: Implement settings that ensure any app deleted via MDM will lose all stored sessions and require re-authentication upon reinstallation. Default Settings for MDM-Distributed Apps: Ideally, this would be a default feature for all apps distributed through MDM, ensuring that user sessions are not retained after app deletion. Has anyone else experienced this issue? Are there any existing settings or workarounds within MDM platforms to mitigate this problem? Your insights and experiences would be invaluable as we navigate this challenge. Thank you!

I'm developing an ACME server to issue identity certificates to macOS/iOS devices for MDM attestation, following RFC 8555. Per RFC, the client creates an order, performs authorization, verifies the challenge, and finalizes the order by submitting a CSR to the CA. In my setup, the CA sometimes takes longer to issue the certificate (around 50 seconds). According to RFC 8555, if certificate issuance isn’t complete after the /finalize call, the server should respond with an "order" object with a "processing" status. The client should then send a POST-as-GET request to the order resource (e.g., /order/<order_id>) to check the current state. If the CA still hasn’t issued the certificate, the server should return the order object with the same "processing" status and include a "Retry-After" header, indicating when the client should retry. The client is expected to poll the order resource at this specified interval with POST-as-GET requests. However, it seems the Apple ACME client ignores the "Retry-After" header and instead returns the error: "Profile failed - Order status is processing, not yet valid" immediately upon the first poll response with "processing." Apple ACME client deviating from the RFC documentation. Has anyone found a reliable solution to this issue? Or does Apple supports asynchronous order finalization? Ref -https://datatracker.ietf.org/doc/html/rfc8555#:~:text=A%20request%20to%20finalize%20an%20order%20will%20result%20in%20error,to%20the%20%22certificate%22%20field%20of%20the%20order.%20%20Download%20the%0A%20%20%20%20%20%20certificate. To work around this, I’m holding the /finalize call until the CA issues the certificate. This works when issuance is quick (under 20 seconds), but if it takes more than that , the client times out. Interestingly, the Apple ACME client’s timeout appears shorter than the usual 60-second URLSession default.

We are pushing some Chrome settings through Directory Services command line utility /usr/bin/dscl /usr/bin/dscl /Local/Default -mcximport /Computers/local_computer chrome_settings.plist /usr/bin/mcxrefresh -n root These commands created com.google.Chrome.plist in /Library/Managed Preferences on previous macOS versions. However on macOS 15.x Sequoia these commands intermittently fail to create the file in /Library/Managed Preferences though there is no error reported or any log entries that could indicate an error. There could be other component on Sequoia that is preventing directory services tool to push the preferences but I am unable to locate it. It is not MDM because the machines are not enrolled (also have a setup where dscl and MDM both work). This is happening on a clean macbook setup but I have never seen it happen on mac mini. Anyone have an idea what could be interfering with directory services to complete its task of pushing managed settings? DDM?

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.

We use a profile that delays the installation of the new system in order to test it earlier. Well Sequoia works differently and fails with our system, the manufacturer tells us to talk to Apple. Does anyone have any idea about this? My MDM is Mosyle

Hello Is there any official source from Apple listing all their models with their respective specs (mainly storage and device color)? Third party open source exist, but it's incomplete, and we'd like to use an official source. EG https://theapplewiki.com/wiki/Models No "ML9C3" in that site.

Hello everyone. Until macOS 14.x Sonoma, the Configuration Profiles, were hosted in System Preferences / Privacy & Security / Profiles. Now, in macOS 15.x, they are hosted in System Preferences / General / Device Management. The thing is, we need to hide this panel since it shows the initial password of a LAPS account to any user. I have seen that in developer.apple.com in the Profile-Specific Payload Keys section, the object SystemPreferences have been Deprecated, and these are the ones we used until now to lock this panel, so it does not work anymore. So that only the objects Restrictions works, in which it does not show any to block the Device Management panel. Does anyone know how to hide/lock the new Device Management panel in System Settings? Thank you very much! Translated with DeepL.com (free version)

I’m looking for advice on implementing an Active Supervision Mode for enhanced parental control. My goal is to restrict access to both iOS system apps and third-party applications to create a safer and more tailored digital experience for my child. Here’s what I’d like to achieve: App Restrictions: Block specific apps (both iOS and third-party) and allow access only to approved ones. Time Limits: Set daily usage limits for individual apps or app categories. Content Filtering: Apply restrictions to block inappropriate content and age-inappropriate apps. Remote Management: Manage these settings remotely from my device for added convenience. Activity Monitoring: View app usage stats or receive alerts for policy violations. I understand that Screen Time on iOS offers basic parental controls, but I’m exploring whether iOS supports more advanced capabilities natively or through additional configurations. I’ve also heard that enrolling a device in Apple Business Manager (ABM) and linking it to an MDM (Mobile Device Management) solution might provide greater control. If this is a viable solution, could anyone provide guidance on: Enrolling a personal or family-owned device into Apple Business Manager. Linking an MDM for configuring app restrictions and monitoring usage. Alternatively, if there are third-party parental control apps that work seamlessly with iOS to achieve these goals, I’d appreciate your recommendations! Thanks in advance for your insights!

I’m looking for advice on implementing an Active Supervision Mode for enhanced parental control. My goal is to restrict access to both iOS system apps and third-party applications to create a safer and more tailored digital experience for my child. Here’s what I’d like to achieve: App Restrictions: Block specific apps (both iOS and third-party) and allow access only to approved ones. Time Limits: Set daily usage limits for individual apps or app categories. Content Filtering: Apply restrictions to block inappropriate content and age-inappropriate apps. Remote Management: Manage these settings remotely from my device for added convenience. Activity Monitoring: View app usage stats or receive alerts for policy violations. I understand that Screen Time on iOS offers basic parental controls, but I’m exploring whether iOS supports more advanced capabilities natively or through additional configurations. I’ve also heard that enrolling a device in Apple Business Manager (ABM) and linking it to an MDM (Mobile Device Management) solution might provide greater control. If this is a viable solution, could anyone provide guidance on: Enrolling a personal or family-owned device into Apple Business Manager. Linking an MDM for configuring app restrictions and monitoring usage. Alternatively, if there are third-party parental control apps that work seamlessly with iOS to achieve these goals, I’d appreciate your recommendations! Thanks in advance for your insights!

We provide a MDM product. In our product, payloads and properties which require supervision display those requirements. Two properties forcePreserveESIMOnErase and allowWebDistributionAppInstallation of the restriction payload don’t require a supervised device according to the descriptions in Apple Developer Documentation. However, in our observation, those properties seem to require it. Are those OS bugs or documentation errors? (In which category should I submit a feedback?) Steps to reproduce Prepare a supervised device (I used an iPhone 12 mini with iOS 18.1) and a configuration profile contains the following restrictions: <!-- Does not require a supervised device --> <key>allowDiagnosticSubmission</key> <false/> <!-- Requires a supervised device --> <key>allowESIMModification</key> <false/> <!-- Does not require a supervised device according to its description --> <key>allowWebDistributionAppInstallation</key> <false/> <!-- Does not require a supervised device according to its description --> <key>forcePreserveESIMOnErase</key> <true/> Then, Install the profile with Apple Configurator. Confirm 4 restrictions are shown in Settings > General > VPN & Device Management > PayloadDisplayName > Restrictions. Punch Settings > General > Transfer or Reset iPhone > Erase All Content and Settings, to unsupervise. Install the profile with Apple Configurator. It cannot be installed automatically because the device was not supervised. Manually install the downloaded profile. Check Settings > General > VPN & Device Management > PayloadDisplayName > Restrictions. Expected results 3 restrictions—allowDiagnosticSubmission, allowWebDistributionAppInstallation and forcePreserveESIMOnErase—are shown. Actual results Only one restriction—allowDiagnosticSubmission—is shown. Appendix: Restriction keys and their restricted message shown in Settings allowESIMModification: eSIM modification not allowed forcePreserveESIMOnErase: Preserve eSIM on erase enforced allowWebDistributionAppInstallation: Web app distribution not allowed allowDiagnosticSubmission: Diagnostic submission not allowed

Would it be possible to prevent deletion of specific apps on iOS devices using MDM.

Hello We extend the program every year, but after we sent a request for extension we do not receive a response. Our program is ending 23 november and we really need to extend it. We created 2 requests, but we did not receive a response to them either. How can we speed up the decision?

Dear Apple Team, As an MDM (Mobile Device Management) service provider, we are writing to bring attention to an issue that is affecting many of our customers who manage large fleets of iOS devices. Specifically, we have encountered challenges with the app update process via MDM, which is impacting both kiosk devices and non-kiosk devices in a variety of use cases. Issue 1: App Updates Delayed on Kiosk Devices Many of our customers are deploying kiosk devices that are used 24/7 independently with no attendants. In these cases, when an app update is sent through MDM via the installApplication command, the installation does not begin immediately. Instead, the update starts only after the device is locked. However, since these kiosk devices are running continuously, they are rarely locked, preventing the app update from occurring. To force the update, administrators need to manually remote lock or physically lock the device, which is a time-consuming process. This becomes even more challenging for devices like Apple TV, where remotely locking and unlocking the device to complete app updates is especially difficult, making it hard to keep the apps up to date in a timely manner. Issue 2: User Cancellations of Critical Updates on Non-Kiosk Devices In the case of non-kiosk devices, customers are encountering another challenge: when a critical update is pushed during business hours, users are often prompted to install the update. However, many users tend to cancel the update, leaving devices unpatched and potentially vulnerable. This behavior can delay the deployment of important security patches, which is a critical concern for organizations managing sensitive data or business-critical apps. Request for a Solution Our customers have expressed the need for a more reliable and forceful app update mechanism. Specifically, we are requesting the following features to improve the app update experience: Scheduled app updates: The ability to schedule app updates, similar to the way OS updates are handled. If the user does not install the update within a specified timeframe, the update should begin automatically or prompt the user with a stronger reminder. Force install option: A feature that would allow MDM administrators to force an app update immediately, without relying on user intervention. This would ensure that critical updates are installed promptly, improving security and system stability across all devices. These features are essential for many of our customers who rely on timely and consistent app updates to maintain security, functionality, and compliance across their managed devices. Without these options, they face challenges in ensuring devices are kept up-to-date, which can result in security vulnerabilities and operational disruptions. We kindly request that Apple consider adding these functionalities to improve the MDM app update process and provide a more reliable experience for both kiosk and non-kiosk device management. Thank you for your attention to this matter. We look forward to your feedback and any potential improvements in future iOS updates. Raised in the same manner as feedback: FB15910292

We have a development where we are MDM managing iOS devices and attempting to enforce mutual TLS for all interactions with the MDM. We are DEP provisionng an enrolment profile that utilises an ACME hardware attested Device Identity Certificate. All interactions with the MDM endpoints are correctly utilising the ACME certificate for the client mutual TLS handshake. The certificate has Client Authentication Extended Key Usage. Behind the same API gateway and on the same SNI we are also serving paths to Enterprise application manifests and IPAs. We can see from the phone log and from packet traces the iOS device doesn't offer the Device Identity Certificate for client authentication when retrieving these URLs. We have also tried adding non ACME client certificates from the root trusted by the server to the initial profile with exactly the same outcome. If we temporarily disable the mutualTLS we can see that the request for the manifest has a userAgent of "com.apple.appstored/1.0 iOS/18.2 model/iPhone17,3 hwp/t8140 build/22C5125e (6; dt:329) AMS/1" which is not the same as the mdm interactions. Is it actually possible to achieve mutualTLS to authenticate these downloads or is a different solution required ? Any advice greatly appreciated.