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.

We develop an endpoint security agent that customer IT deploys and manages via MDM on supervised, ADE-enrolled Macs. The agent requires Accessibility permissions to perform core security functions. Historically, IT provisioned this via the PPPC payload which granted Accessibility as a managed control without end-user interaction. In macOS 27 this path for Accessibility has been removed. The documented replacement — the Privacy key in com.apple.configuration.app.settings — is consent-based: on a supervised device it presents the user a consolidated prompt with "Allow" preselected, which the user may decline. We are seeking guidance on the supported approach for macOS 27 GA: On a supervised macOS 27 device, is there a supported mechanism for an MDM-managed, code-signature-verified application to be provisioned with Accessibility as a managed security control, without depending on individual end-user consent? (i.e. an equivalent to what PPPC provided for enterprise-managed endpoints.) If the consent-based com.apple.configuration.app.settings Privacy declaration is the only path, what is Apple's recommended approach for enterprise-mandated security agents that must have Accessibility to function — including handling the case where a user declines or dismisses the prompt? We have also filed this as an enhancement request via Feedback Assistant (FB23531820). Environment for context: macOS 27 supervised via Automated Device Enrollment, managed by Jamf Pro.

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

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.

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?

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}

I am currently working on mdm.push-token status item subscription via the DDM User Channel while testing on Beta OS 27. I have observed that the User Channel subscription consistently returns the device's push token rather than a unique user-specific push token. This behaviour is persistent across both macOS and Shared iPad environments. Before I conclude that this is a bug, I would like to clarify if this is the expected behaviour for the DDM User Channel. If so, could anyone provide guidance on the correct or alternative method to retrieve a unique, user-specific push token within the DDM framework to ensure proper notification routing? I have submitted a detailed report with a sys diagnose log via the Feedback Assistant (FB ID:FB23214856). Any insights or documentation references would be greatly appreciated.

Hi, I have an app which I would like to test on macOS27, specifically the use of 'Accessibility' permission which is granted via the new DDM payload introduced in macOS27 (com.apple.configuration.app.settings). Problem is once the app is launched once and the consent popup is displayed and a choice is made ('Allow' or 'Not Now') I cannot reset the system so that the popup appears again for test purposes, i.e. is there a command line I can execute similar to 'tccutil reset Accessibility' which would reset the system? Thanks

I entered FB18878081 - July 16, 2025 and FB23195930 - June 16, 2026

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.