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

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

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

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

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

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

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

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

We develop an education-focused app used on institutionally managed iPads deployed through Apple School Manager and MDM. While schools can purchase and deploy the app, they cannot purchase or assign feature add-ons delivered through standard In-App Purchases. As a result, some premium features are unavailable on managed devices. What is Apple’s recommended approach for providing premium feature add-ons in educational and MDM-managed deployments? Is there any support for assigning or redeeming non-consumable In-App Purchases through Apple School Manager or MDM? Are Offer Codes supported for Managed Apple Accounts or managed devices? If not, what is the recommended path forward for developers serving educational institutions? We would appreciate any guidance on current best practices.

OS update info within sysdiagnose is relatively helpful as it stands right now, but with the addition of Machine Learning updates via Global Settings, diagnosing what the device is thinking becomes a little bit more difficult. The SoftwareUpdateSubscriber channel gives some good info, but oftentimes it's not too insightful when an issue is happening. Let's say a device leveraging ML Global Settings isn't updating, and it's been about two weeks since a new applicable minor OS version dropped. The sysdiagnose says that it has the Global Settings in place, so it knows it needs to do the update this way. SoftwareUpdateSubscriber doesn't seem to report any error. So, what else could be the problem? Where can we look? This makes things difficult to troubleshoot for those of us who are self-help focused, especially me, being in an MDM vendor support team. The process is no fault of anyone in particular, but sometimes a resolution is needed asap, and submitting feedback isn't meant for immediate assistance. So, rounding everything out, I'd love to be able to see absolutely everything that updates on devices are thinking, ideally in a 'as organized as it can be' way, to help aid self-help resolutions. Related FB: FB18106259

Did Apple add support to any of the ManagedApp features in business console? I didn't see anything in the release announcement earlier this year and haven't seen anything obvious in the UI. According to the dev videos from last year, ManagedApp is the go to framework for developers to expose MDM admins to configurations, passwords, certificates, and more. This seems like a gap. Happy to continue to file feedback for this capability if it wasn't part of this summers announcements.

Hello! Is the cross-device passkey sign in supported in the new PSSO Web-based auth? It requires bluetooth for proximity checks and it wasn’t clear whether bluetooth is enabled in the highly constrained web view. Though if it uses ASWebAuthenticationSession under the hood, then I would expect it would work. Thank you! Jesse

We are currently updating an existing MDM configuration profile using the InstallProfile command in order to modify its capabilities. Is re-installing the MDM profile via the InstallProfile command the only supported approach for updating its capabilities? Also, are there any ways to update the MDM profile without requiring re-enrollment?

Thank you for the announcements at WWDC. I have one question. Are there any plans to support APIs in Apple Business that allow device actions such as Lock and Erase? Some operations are already possible with the current APIs, but having APIs for these actions would enable conditional operations and the provision of self-service portals. This would also allow for deeper integration with internal corporate systems.

Currently MDM must poll Apple Business for device assignments in order to detect any changes. Even with frequent syncs, admins still occasionally run into issues where devices were recently added to Apple Business and properly assigned, but do not properly enroll because they forgot to manually sync and the timing was in between regular scheduled syncs. The MDM can attempt to solve this by polling with high frequency, but there are still gaps and it feels a bit excessive. Current best practice is to just manually sync every time devices are added, but it's easy for admins to forget. In organizations with devices being added from multiple sources/individuals, this becomes more of challenge. Ideally, the MDM would be able to subscribe to notifications from Apple Business any time an assignment is updated and receive a list of changes - similar to how it works with Apps & Books licenses. This would simplify the admin experience and reduce end-user friction caused from devices not being enrolled properly on initial setup. Are there any plans to implement this type of functionality? If not, is there a "reasonable" interval you recommend polling for device assignment changes? FB16997801

When a device is locked into a single application using App Lock Mode, there is currently no convenient way to troubleshoot network connectivity issues if the device loses access to Wi-Fi or fails to connect to the configured network. In such scenarios, administrators or users may be unable to restore connectivity without performing a full device reset and re-enrollment, which can be time-consuming and disruptive. It would be beneficial to provide a mechanism that allows authorized users or administrators to temporarily exit App Lock Mode, or access limited device settings, for the purpose of configuring or troubleshooting Wi-Fi connectivity. This could be achieved through an administrator-defined password, recovery code, or another secure authentication method. Providing a secure Wi-Fi recovery option would significantly improve device manageability and reduce the need for device resets when network-related issues occur.

SUMMARY: Apple offers the Persistent Content Capture entitlement to developers who pinky-swear that it is only used for products in “VNC” (headless) deployments. This deployment scope also means that enterprises need to grant its use during applicable automated deployments. However, there is no means for an enterprise to pre-grant its use via MDM. At present, it is NOT POSSIBLE for enterprises to: [a] deploy products using Persistent Content Capture, and [b] achieve hands-off automated deployment. ASK: Enable macOS 27's new com.apple.configuration.app.settings to enable grants for com.apple.developer.persistent-content-capture. SEE ALSO, RELATED: FB21547531, FB21509640 REFERENCE: https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.persistent-content-capture

We noticed that the Asset Management API includes support for subscriptions for In App Purchases. Could you share the expected timeline for when this feature will be available for testing? https://developer.apple.com/documentation/devicemanagement/managing-subscriptions

I haven't yet found documentation that describes the behavior of the group or organization subscriptions at the time of renewal. Here are some examples. For Apple's scenario, a run club, say a coach orders a subscription for 'the team'. The app does seasonal (3 month) and annual (yearly) passes. One could collect group dues outside of the app store and help make the purchase. What happens at time of renewal? Does the person that made the original purchase have to manage that? How do they add or remove subscription users as club members may change? How about refunds? In another scenario, B2B, either education or enterprise. With Apple Business providing a free basic MDM (Business Essentials), I can see a lot more use for this case. The same questions apply. Maybe it is a productivity app for students or employees. The video described there being 'seats' that one could assign in Apple Business the say way that apps are assigned (and removed). What happens at the time of renewal? How about refunds? The video teased that management will be available in the future. To determine how 'seamless' the experience is, or to provide feedback, it would be good to even get some still screenshots of what this will look like. Choosing to go individual subscription vs group/org heavily depends on how much work it is removing from the individual consumer (and moving to a single or few administrators). When will some visuals of the 'group' management experience be available? For club scenarios, often the 'lead' or 'coach' is volunteer. Someone might leave for a season, the head coach might change, or groups want to have several admins that can manage the group for convenience to club members, and backup for those admins. Does the 'group' subscription support co-managers? To put it another way, can you have two or more coaches that can manage the group seats? Will there be a way to manage the managers of the group? What resources aside from the Device Management and new Subscriptions talks are relevant to this topic? Sorry the questions are 1-10 in the preview, but forums rendering is renumbering :)

We can either point the device at a URL to download and install the Legacy Profile (what we are doing now), or wrap it in a Declarative asset and reference that (newer offered path). Is there a recommended approach, and what drives it — reliability if the URL is unreachable at install time, how refreshes are handled, payload size? One of the pain points we have been working through with the Legacy Profile migration/default use (using the workflow point the device at a URL to download and install the Legacy Profile) is that durring the deployment of net new Declarations at ADE, and UIE on new enroll devices the profile install fails after ~15-30 profiles, and results in deadlock (FB22832791, FB22828244, and FB22827718) until devices reboot. Not ideal for a net new enroll with a end user. Would moving all net new deployments to the asset fix this? Is that going to be required? Thanks!