My team has developed an app with a Matter commissioner feature (for own ecosystem) using the Matter framework on the MatterSupport extension. Recently, we've noticed that commissioning Matter devices with the MatterSupport extension has become very unstable. Occasionally, the HomeUIService stops the flow after commissioning to the first fabric successfully, displaying the error: "Failed to perform Matter device setup: Error Domain=HMErrorDomain Code=2." (normally, it should send open commissioning window to the device and then add the device to the 2nd fabric). The issue is never seen before until recently few weeks and there is no code changes in the app. We are suspected that there is some data that fail to download from the icloud or apple account that cause this problem. For evaluation, we tried removing the HomeSupport extension and run the Matter framework directly in developer mode, this issue disappears, and commissioning works without any problems.

We have developed a Parental/Self control app using Screen time API. We have used individual authentication to authorize the app, using the instructions here: https://developer.apple.com/documentation/familycontrols/authorizationcenter The problem is , that individual auth can be disabled easily , by the following steps: enter Settings app. in Settings app, click on the Parental/Self control app. click to disable screen time restriction. show the device owner's face/fingerprint. (or pin code) Why is that a problem: Parental control apps, or self-control apps, are about giving control to the software, To make it hard for the user to disable the restrictions. So using the flow I have introduced above, it's super-easy for a user to disable his Parental control restrictions, which misses the entire point of Parental/Self control idea. Furthermore, not only the user have the means to unlock his screen time restrictions, he also MUST have the means to unlock it. This makes Screen time (with individual auth) useless: I have a code ready to make a great parental control app for my clients, with amazing ideas, but I can't use the Screen time API unless this problem is fixed. Why child-parent auth is not enough: My clients are grownups people between ages of 15-40, that are interested in self-control, so they don't have iCloud child accounts. also, the child-parent auth solution forces my clients to give some control to other person, and my clients prefer their privacy. Some of them prefer self-control and not parental-control. What I suggest as a solution: 1: Give more options to users how to disable the Screen time restrictions. including: a second faceID / FingerPrint (that isn't the same as the one used to unlock the device) a second pin password. a string password 2: Give the users the option to choose to not have the device's owner Face/Finger/Pincode ID , as a method to disable the Screen time restrictions.

I'm a font developer. In the development process, I will revise a font and overwrite the OTF file that is currently enabled (registered) with macOS. If I then launch an app, it will immediately use the revised version of the font; while apps that are already loaded will continue to use the old version. This suggests that each app is loading new and separate font data, rather than getting it from some existing cache in memory. Yet macOS does have a "font cache" of some sort. Some apps, like TextEdit, seem to only load the fonts that they need to use. However, other apps, like Pages, load every enabled (registered) font on the OS!! (According to the Open Files list in Activity Monitor.) Given that /System/Library/Fonts/ is 625 Mb, and we can't disable any of it, isn't that a lot of data to be repeating? How many fonts is too many fonts? I can't find much documentation about the process.

Dear Apple Engineers： My app utilizes the App Clip experience. I would like to prevent the App Clip card from appearing when the host app is running in the foreground. How can this be achieved? I have observed that Alipay (in China) does not display an App Clip card when the device is tapped against a tag while the app is in the foreground, which indicates that this behavior is possible. Thank you for your assistance.

I decode an object with NSKeyedArchiver (SecureCoding): typealias BoolArray = Array<Array<Bool>> let val = decoder.decodeObject(of: NSArray.self, forKey: someKey) as? BoolArray I get the following log: *** -[NSKeyedUnarchiver validateAllowedClass:forKey:] allowed unarchiving safe plist type ''NSNumber' (0x204cdbeb8) [/System/Library/Frameworks/Foundation.framework]' for key 'NS.objects', even though it was not explicitly included in the client allowed classes set: '{( "'NSArray' (0x204cd5598) [/System/Library/Frameworks/CoreFoundation.framework]" )}'. This will be disallowed in the future. I changed by adding NSNumber.self in the list : let val = decoder.decodeObject(of: [NSArray.self, NSNumber.self], forKey: someKey) as? BoolArray No more warning in log. Is there a reason for this ?

I'm pleased to share some significant updates that have recently been released for our Hypervisor and Virtualization frameworks. We've focused on enhancing efficiency, expanding capabilities, and addressing common developer needs. I believe these will be valuable for many of you. Here’s a look at what’s new: Hypervisor Updates We've introduced support for configuring the intermediate physical address (IPA) memory granularity of a VM. This allows for more granular memory mappings, enabling granularity sizes down to 4KB. This is particularly useful for certain specialized device drivers requiring finer memory control. Virtualization Framework Updates More Efficient VM Image Storage with ASIF: We've integrated support for the Apple Sparse Image Format (ASIF). This results in a smaller disk footprint and optimized transfer for VM disk images when using VZDiskImageStorageDeviceAttachment, improving storage efficiency. Custom Network Topologies with vmnet: We've added support for vmnet custom network topologies. This enables more flexible VM-to-VM communication based on logical networks with customized configurations, useful for complex testing or development environments. See VZVmnetNetworkDeviceAttachment to get started. Simplified VM Queue Discovery: It's now easier to discover a VM’s on-process thanks to a new property on VZVirtualMachine. This should aid in development and debugging when interacting directly with the VM's queue. These are some of the key highlights of the first beta, and I'm looking forward to seeing how these improvements will be utilized. I encourage you to explore the documentation for full details on these features.

I get several warnings in log: *** -[NSKeyedUnarchiver validateAllowedClass:forKey:] allowed unarchiving safe plist type ''NSNumber' (0x204cdbeb8) [/System/Library/Frameworks/Foundation.framework]' for key 'NS.objects', even though it was not explicitly included in the client allowed classes set: '{( "'NSArray' (0x204cd5598) [/System/Library/Frameworks/CoreFoundation.framework]" )}'. This will be disallowed in the future. I am not sure how to understand it: I have removed every NSNumber.self in the allowed lists for decode. To no avail, still get the avalanche of warnings. What is the key NS.objects about ? What may allowed classes set: '{( "'NSArray' be referring to ? An inclusion of NSArray.self in a list for decode ? The type of a property in a class ?

I’m hitting a specific edge case with background execution that I can’t figure out. I'm using Flutter for the UI, but all the logic handles are in Swift using CoreBluetooth and CoreLocation. I need the app to wake up from a suspended state when it detects my specific BLE peripheral (OBD sensor), connect to it, and immediately start continuous location tracking for the duration of the drive. If I start this process while the app is in the foreground, or very shortly after going to BG, it works perfectly. The app stays alive for the whole trip. The issue only happens when the sequence starts from the background: The app is suspended. scanForPeripherals wakes the app when the sensor is found. In didDiscover, I immediately call locationManager.startUpdatingLocation(). locationd actually delivers updates successfully. However, 5-15 minutes later, iOS suspends the app again. Crucially, I never see the blue "Location In Use" pill on the status bar, even though I have showsBackgroundLocationIndicator = true set. Also, distance filter is set to None. Logs for reference (around suspending) locationd: {"msg":"Sending location to client","Client":"[appName]:","desiredAccuracy":"-1.000000"} runningboardd: Invalidating assertion ... from originator \\\[osservice<com.apple.bluetoothd>:...\\\] runningboardd: Removed last relative-start-date-defining assertion for process app<[appName]...> runningboardd: Calculated state ... running-suspended runningboardd: Suspending task locationd: Client [appName]: disconnected bluetoothd: State of application "[appName]" is now "suspended" Questions Why does invalidating the Bluetooth assertion cause an immediate suspend even though I called startUpdatingLocation() and am receiving updates? Does the missing blue location pill imply that the OS never fully "accepted" the location session? Is there a specific "handshake" required to transition from a BLE wake-up to a long-running location session? I'm wondering if I need to use a background task identifier to bridge the gap between the BLE wake and the location manager taking over. More context: Digging deeper in the comments, I just noticed the following patterns when the application is not suspended vs when it is recently suspended and got awaken by a BLE event. Not suspended: 303948:Jan 23 20:59:35.640118 locationd[6491] <Debug>: {"msg":"Client is setting ContinuousBackgroundLocationRequested", "Client":"[appName]:", "ContinuousBackgroundLocationRequested":1} 303949:Jan 23 20:59:35.640155 locationd[6491] <Debug>: {"msg":"Allowing process assertion due to foreground-ish status", "ClientKeyPath":"[appName]:"} Recently suspended and awaken by BLE: 564296:Jan 23 21:00:23.179125 locationd[6491] <Debug>: {"msg":"Client is setting ContinuousBackgroundLocationRequested", "Client":"[appName]:", "ContinuousBackgroundLocationRequested":1} 564298:Jan 23 21:00:23.179195 locationd[6491] <Notice>: {"msg":"#Warning Denying process assertion", "ClientKeyPath":"[appName]:"} The assertion fails for the second case and that's why the app could not persist. Most importantly, following the logs in the second case, I see the following: locationd[6491] <Notice>: {"msg":"computing freshAuthorizationContext", "Client":"[appName]:", "ClientDictionary":"{\n AlwaysServiceSession = 0;\n I suspect that the flag AlwaysServiceSession being 0 has to do with process assertion being denied for location.

Platforms: macOS 15.x (Sequoia), Intel-Based App type: Endpoint Security (ES) client, notarized Developer ID app + LaunchDaemon Goal: Boot-time ES client that runs on any Mac (managed or unmanaged) Summary Our ES client launches and functions when started manually (terminal), but when loaded as a LaunchDaemon it fails to initialize the ES connection with: (libEndpointSecurity.dylib) Failed to open service: 0xe00002d8: Caller lacks TCC authorization for Full Disk Access We can’t find a supported way to grant Full Disk Access (SystemPolicyAllFiles) to a system daemon on unmanaged Macs (no MDM). Local installation of a PPPC (TCC) profile is rejected as “must originate from a user-approved MDM server.” We’re seeking confirmation: Is MDM now the only supported path for a boot-time ES daemon that requires FDA? If so, what’s Apple’s recommended approach for unmanaged Macs? Environment & Artifacts Binary (path placeholder): /Library/Application Support///App/.app/Contents/MacOS/ Universal (x86_64 + arm64) Notarized, hardened runtime; Developer ID Team <TEAM_ID> Entitlements include: com.apple.developer.endpoint-security.client (present) Daemon plist (simplified; placeholders used): <?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>Label</key> <string>com.example.esd</string> <key>Program</key> <string>/Library/Application Support/<VENDOR>/<PRODUCT>/Platform/<daemon-exec></string> <key>WorkingDirectory</key> <string>/Library/Application Support/<VENDOR>/<PRODUCT>/Platform</string> <key>RunAtLoad</key><true/> <key>KeepAlive</key><true/> </dict></plist> Designated requirement (abridged & masked): identifier "<BUNDLE_ID>" and anchor apple generic and certificate 1[...] and certificate leaf[...] and certificate leaf[subject.OU] = "<TEAM_ID>" What works Launching the ES client manually (interactive shell) succeeds; ES events flow. Signature, notarization, entitlements, Gatekeeper: all OK. What fails (daemon) launchctl print system/ shows it starts, but Console logs: (libEndpointSecurity.dylib) Failed to open service: 0xe00002d8:Caller lacks TCC authorization for Full Disk Access System TCC DB shows ES consent rows but no allow for TCCServiceSystemPolicyAllFiles for the daemon binary. Installing a PPPC mobileconfig locally (system scope) is blocked as “must originate from a user-approved MDM server.” Repro (minimal) Install app bundle + LaunchDaemon plist above (placeholders). Verify entitlements & notarization: codesign -dvvv --entitlements :- "" spctl --assess --type execute -vv "" Start daemon & watch logs: sudo launchctl bootstrap system "/Library/LaunchDaemons/.plist" log stream --style compact --predicate 'process == "" OR subsystem == "com.apple.TCC"' --info Observe FDA denial message only in daemon context. Attempt to add FDA via PPPC profile (system scope) → rejected unless installed by user-approved MDM. Questions for Apple On macOS 14/15, is Full Disk Access for system daemons strictly MDM-only via PPPC (i.e., not installable locally)? Under what conditions would libEndpointSecurity report a Full Disk Access denial at client initialization, given ES consent is distinct from FDA? For unmanaged Macs needing boot-time ES processing, does Apple recommend a split: root LaunchDaemon (ES subscription; no protected file I/O) + per-user LaunchAgent (user-granted FDA) via XPC for on-demand disk access? Would moving ES connection code into a System Extension change FDA requirements for unmanaged devices, or is FDA still governed by PPPC/MDM? If behavior changed across releases, can Apple confirm the intended policy so vendors can document MDM requirements vs. unmanaged install paths? What we’ve tried Verified signature, notarization, hardened runtime, ES entitlement present. Confirmed context difference: manual run OK; daemon fails. Inspected system TCC: ES consent rows present; no FDA allow for daemon. Tried installing system-scoped PPPC locally → blocked as “must originate from a user-approved MDM server.” Considered LaunchAgent-only, but ES needs root; evaluating daemon+agent split to keep ES in root and put FDA-gated work in user space. What we need A definitive statement on the supported way to grant FDA to a system daemon on macOS 14/15. If MDM PPPC is required, we’ll ship “daemon mode requires MDM” and provide a daemon+agent fallback for unmanaged devices. If a compliant non-MDM path exists for daemon FDA on unmanaged Macs, please share exact steps. Thanks! Happy to provide additional logs privately if helpful.

DeviceActivityReportExtension issues Hi, I am currently working on a project and hoping to use DeviceActivityReportExtension. I have already successfully set up the DeviceActivityMonitorExtension and that is working correctly, but can't get this to reproduce. I initially had a complex capacitor project which displayed a native UI screen which (tried to) display the screen time report though it was failing silently. I tried a much simpler setup with a pure swift project (not an iOS dev so forgive my poor code quality) and still having an issue getting this to render on my computer. Here is a reproduction: https://github.com/ethanmichel0/screen-time-report-bug-recreation/tree/main Does this code work for others? and if not do you know how I can set this up? idk if my Xcode or iOS versions are incompatible (see versions in that link). Would be super grateful for some help, thanks so much.

I'm specifically focused on Live Activity, but I think this is somewhat a general question. The app could get a few callbacks when: There's a new payload (start, update, end) There's a new token (start, update) There's some other lifecycle event (stale, dismissed) Assuming that the user didn't force kill the app, would the app get launched in all these scenarios? When OS launches the app for a reason, should we wrap our tasks with beginBackgroundTask or that's unnecessary if we're expecting our tasks to finish within 30 seconds? Or the OS may sometimes be under stress and give you far less time (example 3 seconds) and if you're in slow internet, then adding beginBackgroundTask may actually come in handy?

Let's image that someone wants to use a background service to keep track of FSEvents activity, at the file level (a firehose, some might say). I choose this example, to indicate the volume and rate of data transmission in question. I'm not creating a front-end for FSEvents data, but my background service may generate data at a similar pace. The service runs off of user defined document/s that specify the FSEvent background filtering to be applied. Those that match get stored into a database. But filters can match on almost all the data being emitted by FSEvents. The user decides to check on the service's activity and database writes by launching a GUI that sends requests to the background service using XPC. So the GUI can request historic data from a database, but also get a real-time view of what FS events the service is busy filtering. So it's a client-server approach, that's concerned with monitoring an event stream over XPC. I understand XPC is a request/response mechanism, and I might look into using a reverse connection here, but my main concern is one of performance. Is XPC capable of coping with such a high volume of data transmision? Could it cope with 1000s of rows of table data updates per second sent to a GUI frontend? I know there are streaming protocol options that involve a TCP connection, but I really want to stay away from opening sockets.

We are seeing a strange lifecycle issue on multiple MDM-managed iPads where application(_:didFinishLaunchingWithOptions:) is not called after the device is idle overnight. Even if we terminate the app manually via the app switcher, the next morning the system does not perform a cold launch. Instead, the app resumes directly in: applicationDidBecomeActive(_:) This causes all initialization logic that depends on didFinishLaunching to be completely skipped. This behavior is consistent across four different supervised MDM devices. Environment Devices: iPads enrolled in MDM (supervised) iOS version: 18.3 Xcode: 16.4 macOS: Sequoia 15.7.2 App type: Standard UIKit iOS app App: Salux Audiometer (App Store app) Expected Behavior If the app was terminated manually using the app switcher, the next launch should: Start a new process Trigger application(_:didFinishLaunchingWithOptions:) Follow the normal cold-start lifecycle Actual Behavior After leaving the iPad idle overnight (8–12 hours): The next launch skips didFinishLaunching The app resumes directly in applicationDidBecomeActive No new process is started App behaves as if it had been suspended, even though it was manually terminated Logs (Relevant Extracts) Day 1 — Normal cold launch [12:06:44.152 PM] PROCESS_STARTED [12:06:44.214 PM] DID_FINISH_LAUNCHING_START launchOptions=[] [12:06:44.448 PM] DID_FINISH_LAUNCHING_END We then used the app and terminated it via app switcher. Day 2 — Unexpected resume without cold start [12:57:49.328 PM] APP_DID_BECOME_ACTIVE No PROCESS_STARTED No didFinishLaunching No cold-start logs This means the OS resumed the app from a previous state that should not exist. Reproducible Steps Use an MDM-enrolled iPad. Launch the app normally. Terminate it manually via the multitasking app switcher. Leave the device idle overnight (8–12 hours). Launch the app the next morning. Observe that: didFinishLaunching does not fire applicationDidBecomeActive fires directly Questions for Apple Engineers / Community Is this expected behavior on MDM-supervised devices in iOS 18? Are there any known OS-level changes where terminated apps may be revived from disk/memory? Could MDM restrictions or background restoration policies override app termination? How can we ensure that our app always performs a clean initialization when launched after a long idle period? Additional Information We have full logs from four separate MDM iPads showing identical behavior. Happy to share a minimal reproducible sample if required.

I'm trying to embed a self-built copy of the WebKit frameworks to a macOS app. Most importantly I hope to get some features to work which Safari offers, but WKWebView in macOS doesn't (getDisplayMedia, Service Workers, WebInspector). Many years ago I was successful in using a self-built WebKit copy in this Mac app, but it seems the WebKit framework got more complex since them, I guess because of WKWebView's architecture. That time I had to open the projects for the main frameworks in Xcode, select the framework bundle in the target and change the "Installation Directory" setting to the path @executable_path/../Frameworks. After building WebKit using the build script, I could use otool -L to confirm the changed installation path, which then was displayed for example as @executable_path/../Frameworks/WebCore.framework/Versions/A/WebCore I tried the same with a current WebKit build: I copied the products for WebKit.framework, WebCore.framework, JavaScriptCore.framework, WebKitLegacy.framework, WebGPU.framework and WebInspectorUI.framework to my app and added it to the "Frameworks, Libraries and Embedded Content" section in the Project's Target/General tab and selected "Embed & Sign" for each framework. In "Build Phases" I made sure that WebCore.framework and WebGPU.framework are only in the "Copy Files" phase (Destination Frameworks) and not in "Link Binary with Libraries", as WebCore is linked through the WebKit umbrella framework and WebGPU gave another error (not sure about how to deal with that framework, as in the system it's in a PrivateFrameworks subfolder). In "Build Settings" I made sure that @executable_path/../Frameworks is entered for "Runpath Search Paths" (it was already probably because of Cocoapods, together with @loader_path/../Frameworks. When I build my app, the system's WebKit version is used. Only when I add the environment variable DYLD_FRAMEWORK_PATH with value @executable_path/../Frameworks in the run scheme, the embedded self-build WebKit frameworks are used. Because of currently necessary backward compatibility my app can use the legacy WebView or WKWebView. The legacy WebView works perfectly with the embedded WebKitLegacy.framework. But if I try to open any URL in WKWebView, no content is rendered and in the console output I can see: Safe Exam Browser[21391:145678] [Process] 0x10c67d760 - [PID=0] WebProcessProxy::didFinishLaunching: Invalid connection identifier (web process failed to launch) Safe Exam Browser[21391:145678] [Process] 0x10c67d760 - [PID=0] WebProcessProxy::processDidTerminateOrFailedToLaunch: reason=4 Safe Exam Browser[21391:145678] [ProcessSuspension] 0x10c005040 - [PID=0, throttler=0x10c67d8d8] ProcessThrottler::Activity::invalidate: Ending background activity / 'WebProcess initialization' Safe Exam Browser[21391:145678] [Process] 0x10c67d760 - [PID=0] WebProcessProxy::shutDown: Safe Exam Browser[21391:145678] [Process] 0x7fbe89064020 - [pageProxyID=40, webPageID=41, PID=0] WebPageProxy::processDidTerminate: (pid 0), reason 4 2022-02-14 12:53:01.764074+0100 Safe Exam Browser[21391:145678] [Process] 0x10c67d760 - [PID=0] WebProcessProxy::processTerminated: Safe Exam Browser[21391:145678] [Loading] 0x7fbe89064020 - [pageProxyID=40, webPageID=41, PID=0] WebPageProxy::dispatchProcessDidTerminate: reason=Crash Safe Exam Browser[21391:146842] [SEBOSXWKWebViewController webViewWebContentProcessDidTerminate:<Safe_Exam_Browser.SEBOSXWKWebView: 0x7fbe88f8b1c0>] I have the impression that the web process might fail to launch because I didn't embed all necessary parts of the self-built WebKit (the product folder contains a large number of XPC, dylib and .a files). Or some additional paths have to be adjusted before building WebKit, so that the embedded frameworks/libraries are used and not the system provided ones. I also looked at the bundle of the Safari Technology Preview and can see some similarities but also differences. I would be grateful if anybody could provide me with information how to embed a self-built copy of WebKit into a macOS app. Unfortunately I didn't find any Mac open source browser using an embedded copy of WebKit to get some inspiration from.

I have defined a class : class Item: NSObject, NSSecureCoding { var name : String = "" var color : ColorTag = .black // defined as enum ColorTag: Int var value : Int = 0 static var supportsSecureCoding: Bool { return true } Its decoder includes the following print statement to start: required init(coder decoder: NSCoder) { print(#function, "item should not be nil", decoder.decodeObject(of: Item.self, forKey: someKey))   Another class uses it: class AllItems: NSObject, NSSecureCoding { var allItems : [Item]? static var supportsSecureCoding: Bool { return true } and decodes as follows required init(coder decoder: NSCoder) { super.init() // Not sure it is necessary allItems = decoder.decodeObject(of: NSArray.self, forKey: mykey) as? [Item] print(#function, allItems) // <<-- get nil } I note: decoder returns nil at line 5 I have tried to change to decoder.decodeObject(of: [NSArray.self, NSString.self, NSColor.self, NSNumber.self], forKey: mykey)) Still get nil And, decoder of class Item is not called (no print in the log) What am I missing ?

Our team is in the process of updating our apps to comply with Texas's new state law. In order to minimize user confusion and provide the most ideal flow to access the app as possible, we have a few questions we would like answered. Summary of questions: Is isEligibleForAgeFeatures intended to be accurate and accessible before the user has accepted the Age Range permissions prompt? As other US states and/or other countries adopt a similar law going forward, will this instance variable cover those locations? Will the runtime crashes on isEligibleForAgeFeatures and other symbols in the DeclaredAgeRange framework be addressed in a future RC or in the official release? Details and Investigations: With regards to isEligibleForAgeFeatures, our team has noticed that this value is always false before the age range prompt has been accepted. This has been tested on the XCode RC 26.2 (17C48). Assuming the request needs to be accepted first, isEligibleForAgeFeatures does not get updated immediately when the user chooses to share their age range (updated to true, when our sandbox test account is a Texas resident). Only upon subsequent relaunches of the app does this return a value that reflects the sandbox user's location. Is isEligibleForAgeFeatures intended to be accurate and accessible before the user has accepted the Age Range permissions prompt? This leads to our follow-up question to clarify whether isEligibleForAgeFeatures explicitly correlates to a user in an affected legal jurisdiction–if future US states and/or other countries adopt a similar law going forward, will this instance variable cover those locations? Can we also get confirmation about whether the runtime crash on isEligibleForAgeFeatures and other symbols in the DeclaredAgeRange framework will be addressed in a future RC or in the official release? Thank you.

The documentation for isEligibleForAgeFeatures states: Use this property to determine whether a person using your app is in an applicable region that requires additional age-related obligations for when you distribute apps on the App Store. But what does "region" mean? Is this going to return true if the user has downloaded the app from the US App Store? Or will it go further and geolocate the user and identify them as being within a particular relevant state within the US?

Why can I use background delivery to realize background notifications when I run the app for the first time, but when I delete the app running in the background, and then reopen the app to run it in the background, there will be no background notification when the data changes?

I’m developing an iOS idle game (guild management). To detect manual device time changes that would break progression, I need a trusted “current real-world time” reference. I’m considering querying Apple’s NTP host time.apple.com, but I couldn’t find any official guidance about whether third-party apps may use time.apple.com directly (acceptable use, rate limits, whether it’s discouraged, etc.). Apple Developer Support couldn’t provide info and suggested asking on the forums. Questions: 1. Is it permitted for a third-party iOS app to query time.apple.com via NTP/SNTP (Yes/No or conditional)? 2. If permitted, are there any published or recommended constraints (rate limits, caching, prohibited patterns, commercial app considerations)? 3. If not permitted / not recommended, what is the recommended alternative approach (run our own time service, use public NTP pool, or any Apple-recommended mechanism)? 4. If there is any official document / policy covering this, could you point me to it? For context: I do not need sub-second accuracy and I do not intend high-frequency polling. If implemented at all, it would be very low frequency (e.g., first launch + once per 24h) with caching and graceful fallback on failure. My main goal is policy clarity rather than implementation details.

I would like to share an issue observed during app development. When changing Bluetooth settings from the system Settings app without using multitasking, the app does not terminate but instead logs the user out. However, when changing Bluetooth settings while using multitasking, the app terminates completely. In this context, I would like to understand: Whether there is any system behavior that causes the app to refresh or restart when Bluetooth settings are changed And why the app behavior differs in a multitasking environment, particularly in terms of app lifecycle handling Any insights into these behaviors would be greatly appreciated. “while using multitasking” means reducing the app’s size and displaying it side by side with the Settings screen at the same time. For better understanding, I will attach an image. Additionally, I found that YouTube also terminates when the “Allow Tracking” permission is changed in Settings while using the multitasking interface.