General: DevForums subtopic: App & System Services > Core OS Core OS is a catch-all subtopic for low-level APIs that don’t fall into one of these more specific areas: Processes & Concurrency Resources Files and Storage Resources Networking Resources Network Extension Resources Security Resources Virtualization Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Since the iOS 26.2 update, we have been experiencing anomalous behavior with the DeviceActivityMonitor extension when utilizing the ScreenTime API. Specifically, we are receiving the eventDidReachThreshold event within a few minutes of initiating monitoring, despite configuring a high usage limit. The process of turning off Screen Time -> restarting the device -> turning on Screen Time does not work. Any ideas? Thanks Filed Feedback Assistant: FB21560904

Hello, We're developing endpoint security software using the Endpoint Security framework, and we've encountered challenges with the behavior change in macOS 15 regarding provisioning UDIDs in cloned VMs. The Change Prior to macOS 15, cloning a VM preserved its UDID (format: 0000FE00-9C4ED9F68BBDC72D). Starting with macOS 15, cloned VMs receive a new UDID generated from the host's Secure Enclave (format: b043d27202c7ac37ca3c6b82673302225485cae9), making each clone effectively a new device. Our Workflow We maintain a clean base VM image and clone it for each test run. We add the base VM's UDID to our provisioning profile once, then create clones which (previously) retained that same UDID, allowing us to start new testing cycles without re-registering devices. This is essential because our product involves low-level system integration through the Endpoint Security framework, and if something goes wrong during development, it has the potential to affect system stability. To prevent any cascading issues between test runs or different product versions, we need each test to start from a known clean state rather than reusing the same VM. The Challenge With each VM clone generating a new UDID, we're hitting Apple's device registration limits quickly. This particularly impacts: New team members who spin up VMs for the first time and can't run signed builds Our CI/CD pipeline where multiple test environments need provisioning profiles Developers testing different branches who need separate clean environments Current Workaround We've found that VMs created on macOS 14 and upgraded to macOS 15+ retain their original UDID format. However, we're concerned this workaround may stop working in future macOS versions, which would leave us without a viable path forward. If the workaround stops working, our fallback would be signing each CI build with a Developer ID signature to allow running on any device. However, we'd prefer to avoid this as it would significantly increase load on Apple's signing infrastructure for what are essentially internal test builds. We completely understand the security reasoning behind tying UDIDs to the host's Secure Enclave for Apple Account support. However, for development workflows that don't require Apple Account features in VMs but do require clean, isolated test environments, the previous behavior was quite valuable. Question Is there a recommended approach for teams in our situation? We're happy to explore alternative workflows if there's a pattern we're missing, or we'd be glad to provide more context if this is a use case Apple is considering for future updates. Thanks for any guidance you can provide! Feedback case: FB21389730

I. am working on an app that uses automounted files using nfsv4 where the server has zfs filesystems. As a test I've created a very simple example and the directory in question seems to automount correctly, but when I try to access it, I get strange behavior. The directory is mounted on is /System/Volumes/Data/mnt/subdir and I can change to that directory just fine. However I get the following: 63 rrsum@Anywhere:subdata% pwd /System/Volumes/Data/mnt/subdata 64 rrsum@Anywhere:subdata% ls -la total 3 drwxr-xr-x 3 nobody nobody 4 Jan 10 13:03 . dr-xr-xr-x 3 root wheel 2 Jan 8 17:27 .. drwxr-xr-x 2 nobody nobody 3 Jan 9 11:20 dir -rw-r--r-- 1 nobody nobody 12 Jan 10 13:09 file.txt 65 rrsum@Anywhere:subdata% cd dir cd: string not in pwd: ls The directory appears in the 'ls -la' properly, but I cannot cd to it.

Hello, Is there a 2-device limit for CoreBluetooth on visionOS 2.1? My app connects to 4 BLE peripherals on iOS but fails at the 3rd device on Vision Pro. The 3rd call to centralManager.connect() is successful and the peripheral enters .connecting state, but didConnect never fires and it stays in .connecting forever. No errors reported. First 2 devices work perfectly. Same code on iOS connects all 4. Has anyone else had this problem? Is there any documentation I can refer to that states something like this? Environment: visionOS 2.1, CoreBluetooth, Apple Vision Pro. My BLE Peripherals are running on nRF52840.

We have a Matter 1.2 certified device, with device type "On/Off Light Switch" (0x0103) that we are launching soon. The last tests include the updatability via DCL published updates: showing up immediately via Google Home, and Home Assistant not showing up at all in Apple Home, waited for >1 week We successfully tested with the TestNet DCL profile.

I am able to symbolicate kernel backtraces for addresses that belong to my kext. Is it possible to symbolicate kernel backtraces for addresses that lie beyond my kext and reference kernel code? Sample kernel panic log

When using CBPeripheralManager in the peripheral role on iPhone 17 series devices (iPhone 17 Air, iPhone 17 Pro) running iOS 26.1 and above, the delegate method peripheralManager:central:didSubscribeToCharacteristic: is never called when a third-party BLE central device attempts to connect and subscribe to a characteristic. This functionality works correctly on all previous iPhone models and iOS versions. (This worked previously for the same iPhone 17 Air/Pro when running iOS 26.0.1.)

Background: We are developing a cross-platform mobile application that communicates with a custom NFC-enabled hardware device. The hardware expects ISO7816-style APDU commands for data exchange and functions correctly with Android using the IsoDep protocol. Observed Issue on iOS: On iOS, the tag is only detectable via NFCNdefReaderSession, which provides access to INFCNdefTag. Attempting to use NFCTagReaderSession with NFCPollingOption.Iso14443 (which is required for APDU communication) results in no tag detection. As a result, the tag is inaccessible for APDU-based communication on iOS. Since NFCNdefReaderSession does not support APDU, we are unable to establish the required command channel. Constraints: The hardware firmware cannot be changed to support NDEF-based command interpretation. The device expects raw ISO-DEP APDU commands (i.e., Class-Instruction-Param1-Param2-Data-Le). Impact: The lack of ISO7816 tag detection on iOS prevents the app from sending APDU commands, resulting in a platform-specific feature limitation. Functionality that relies on secure, structured APDU communication is unavailable to iOS users, even though it works seamlessly on Android.

We're updating a FileProvider-based app which was written for Big Sur to recent macOS. The system requires that the extension be manually enabled by the user in System Preferences -- either under Extensions > Added Extensions, Privacy & Security > Extensions > Added Extensions, or in newer versions General > Login Items & Extensions. Is there a programmatic (preferably Swift) or installer-based way to enable this checkbox-- or at least to detect if it has been enabled for a particular app, and if not bring up the appropriate pane of Preferences? (For which I'd need a complete OS-version-specific list of which pane to bring up.) (I can detect whether our particular NSFileProviderDomain has its userEnabled flag set after it's defined during the mounting process, but I'd rather be able to detect / set it during initial setup.)

I regularly see questions, both here on the Apple Developer Forums and in my Day Job™ at DTS, that are caused by a fundamental misunderstanding of how background execution works on iOS. These come in many different variants, for example: How do I keep my app running continuously in the background? If I schedule a timer, how do I get it to fire when the screen is locked? How do I run code in the background every 15 minutes? How do I set up a network server that runs in the background? How can my app provide an IPC service to another one of my apps while it’s in the background? How can I resume my app in the background if it’s been ‘force quit’ by the user? The short answer to all of these is You can’t. iOS puts strict limits on background execution. Its default behaviour is to suspend your app shortly after the user has moved it to the background; this suspension prevents the process from running any code. There’s no general-purpose mechanism for: Running code continuously in the background Running code at some specific time in the background Running code periodically at a guaranteed interval Resuming in the background in response to a network or IPC request [1] However, iOS does provide a wide range of special-purpose mechanisms for accomplishing specific user goals. For example: If you’re building a music player, use the audio background mode to continue playing after the user has moved your app to the background. If you’re building a timer app, check out the AlarmKit framework. On older systems, use a local notification to notify the user when your timer has expired. If you’re building a video player app, use AVFoundation’s download support. Keep in mind that the above is just a short list of examples. There are many other special-purpose background execution mechanisms, so you should search the documentation for something appropriate to your needs. IMPORTANT Each of these mechanisms fulfils a specific purpose. Do not attempt to use them for some other purpose. Before using a background API, read clause 2.5.4 of the App Review Guidelines. Additionally, iOS provides some general-purpose mechanisms for background execution: To resume your app in the background in response to an event on your server, use a background notification (aka a ‘silent’ push). For more information, see Pushing background updates to your App. To request a small amount of background execution time to refresh your UI, use the BGAppRefreshTaskRequest class. To request extended background execution time, typically delivered overnight when the user is asleep, use the BGProcessingTaskRequest class. To continue user-visible work after the user has left your app, use the BGContinuedProcessingTask class. To prevent your app from being suspended for a short period of time so that you can complete some user task, use a UIApplication background task. For more information on this, see UIApplication Background Task Notes. To download or upload a large HTTP resource, use an URLSession background session. All of these mechanisms prevent you from abusing them to run arbitrary code in the background. As an example, consider the URLSession resume rate limiter. For more information about these limitations, and background execution in general, I strongly recommend that you watch WWDC 2020 Session 10063 Background execution demystified [2]. It’s an excellent resource. Specifically, this talk addresses a common misconception about the app refresh mechanism (BGAppRefreshTaskRequest and the older background fetch API). Folks assume that app refresh will provide regular background execution time. That’s not the case. The system applies a range of heuristics to decide which apps get app refresh time and when. This is a complex issue, one that I’m not going to try to summarise here, but the take-home message is that, if you expect that the app refresh mechanism will grant you background execution time, say, every 15 minutes, you’ll be disappointed. In fact, there are common scenarios where it won’t grant you any background execution time at all! Watch the talk for the details. [1] iOS 26 introduced support for general-purpose IPC, in the form of enhanced security helper extensions. However, these can only be invoked by the container app, and that means there’s no background execution benefit. [2] Sadly the video is currently not available from Apple. I’ve left the link in place just in case it comes back. When the user ‘force quits’ an app by swiping up in the multitasking UI, iOS interprets that to mean that the user doesn’t want the app running at all. So: If the app is running, iOS terminates it. iOS also sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually. This gesture is a clear statement of user intent; there’s no documented way for your app to override the user’s choice. Note In some circumstances iOS will not honour this flag. The exact cases where this happens are not documented and have changed over time. Finally, if you have questions about background execution that aren’t covered by the resources listed here, please open a new thread on the forums with the details. Put it in a reasonable subtopic and tag it appropriately for the technology you’re using; if nothing specific springs to mind, use Background Tasks. Also, make sure to include details about the specific problem you’re trying to solve because, when it comes to background execution, the devil really is in the details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Change history: 2026-01-09 Added a reference to AlarmKit. Added a reference to BGContinuedProcessingTask. Add a footnote about IPC and another one about WWDC 2020 Session 10063. Made other minor editorial changes. 2024-03-21 Added a discussion of ‘force quit’. 2023-05-11 Added a paragraph that explains a common misconception about the app refresh mechanism. Made other minor editorial changes. 2021-08-12 Added more entries to the common questions list, this time related to networking and IPC. Made minor editorial changes. 2021-07-26 Extended the statement about what’s not possible to include “running code periodically at a guaranteed interval”. 2021-07-22 First posted.

File Provider Extension Testing Mode -2014 Error Issue I'm developing a macOS File Provider Extension and encountering a -2014 (Extension not registered) error when using Testing Mode only. Environment macOS: 13.0+ Xcode: Latest version Developer Account: Paid Developer Account Extension Type: NSFileProviderReplicatedExtension Current Status App ID Configuration App ID: kr.it.flux.FluxDrive2.FileProvider Capabilities: ✅ com.apple.developer.fileprovider.testing-mode (enabled) ❌ General com.apple.developer.fileprovider (not visible) Extension Configuration NSExtensionPointIdentifier: com.apple.fileprovider NSExtensionPrincipalClass: FluxDrive2FileProvider.FileProviderExtension Code Signing: Valid (Team Identifier verified) Info.plist: Valid Error Message Error Domain=NSFileProviderErrorDomain Code=-2014 The operation couldn't be completed. (NSFileProviderErrorDomain error -2014.) Underlying error: Error Domain=NSFileProviderErrorDomain Code=-2001 Extension cannot be used Attempted Solutions ✅ Verified and corrected Extension Info.plist ✅ Verified Extension code signing ✅ Added App Group (group.kr.it.flux.FluxDrive2) ✅ Clean Build and rebuild ✅ Verified installation in /Applications ❌ Attempted to enable Extension in System Settings (Testing Mode doesn't appear) Observations Extension is not actually loaded (FileProviderExtension.init() is never called) NSFileProviderManager.add(domain) immediately returns -2014 error Extension file is built correctly and included in the app bundle Questions Shouldn't Testing Mode allow testing of File Provider Extension? Why is the -2014 error occurring? The general com.apple.developer.fileprovider capability is not visible in Developer Portal. How can I enable it? Is it normal for Extension not to be registered in the system when using Testing Mode, or are additional settings required? Is the general File Provider capability mandatory for App Store submission? Additional Information Extension code correctly implements NSFileProviderReplicatedExtension protocol All required methods (item, enumerator, fetchContents, etc.) are implemented Network permission (com.apple.security.network.client) is configured Any help would be greatly appreciated!

File Provider Extension Testing Mode -2014 Error Issue I'm developing a macOS File Provider Extension and encountering a -2014 (Extension not registered) error when using Testing Mode only. Environment macOS: 13.0+ Xcode: Latest version Developer Account: Paid Developer Account Extension Type: NSFileProviderReplicatedExtension Current Status App ID Configuration App ID: kr.it.flux.FluxDrive2.FileProvider Capabilities: ✅ com.apple.developer.fileprovider.testing-mode (enabled) ❌ General com.apple.developer.fileprovider (not visible) Extension Configuration NSExtensionPointIdentifier: com.apple.fileprovider NSExtensionPrincipalClass: FluxDrive2FileProvider.FileProviderExtension Code Signing: Valid (Team Identifier verified) Info.plist: Valid Error Message Error Domain=NSFileProviderErrorDomain Code=-2014 The operation couldn't be completed. (NSFileProviderErrorDomain error -2014.) Underlying error: Error Domain=NSFileProviderErrorDomain Code=-2001 Extension cannot be used Attempted Solutions ✅ Verified and corrected Extension Info.plist ✅ Verified Extension code signing ✅ Added App Group (group.kr.it.flux.FluxDrive2) ✅ Clean Build and rebuild ✅ Verified installation in /Applications ❌ Attempted to enable Extension in System Settings (Testing Mode doesn't appear) Observations Extension is not actually loaded (FileProviderExtension.init() is never called) NSFileProviderManager.add(domain) immediately returns -2014 error Extension file is built correctly and included in the app bundle Questions Shouldn't Testing Mode allow testing of File Provider Extension? Why is the -2014 error occurring? The general com.apple.developer.fileprovider capability is not visible in Developer Portal. How can I enable it? Is it normal for Extension not to be registered in the system when using Testing Mode, or are additional settings required? Is the general File Provider capability mandatory for App Store submission? Additional Information Extension code correctly implements NSFileProviderReplicatedExtension protocol All required methods (item, enumerator, fetchContents, etc.) are implemented Network permission (com.apple.security.network.client) is configured Any help would be greatly appreciated!

If (in terminal) I type 'env', I'll see a line that looks like: LANG=en_GB.UTF-8 And I can parse that to get the 2-char 'en' locale-code, the sub-domain 'GB' and the character-set encoding of UTF-8. All well and good. However in a Cocoa app, I can't seem to find the equivalent for the "UTF-8" part. This is a cross-platform app, but at this point I'll go with any solution... I've tried: NSLocale *loc = NSLocale.currentLocale; NSString *lang = loc.localeIdentifier; setlocale(LC_ALL, NULL); char *text = nl_langinfo(CODESET); if (text) NSString *charset = [NSString stringWithUTF8String:text]; NSLog(@"lang:%@\nchar:%@\n",lang, charset); which displays: lang:en-GB char:US-ASCII Also tried: // Search for locale info by preferred environment variable NSProcessInfo *pi = NSProcessInfo.processInfo; NSDictionary<NSString *,NSString *> *env = pi.environment; NSString *spec = env[@"LC_ALL"]; if (spec == nil) spec = env[@"LC_CTYPE"]; if (spec == nil) spec = env[@"LANG"]; NSLog(@"spec:%@\n", spec); which displays: spec:(null) Also tried: CFStringEncoding sys = CFStringGetSystemEncoding(); CFStringRef enc = CFStringConvertEncodingToIANACharSetName(sys); NSString *nsEnc = (__bridge NSString *)enc; NSLog(@"iana:%@", nsEnc); enc = CFStringGetNameOfEncoding(sys); nsEnc = (__bridge NSString *)enc; NSLog(@"name:%@", nsEnc); CFStringEncoding compat = CFStringGetMostCompatibleMacStringEncoding(sys); enc = CFStringGetNameOfEncoding(compat); nsEnc = (__bridge NSString *)enc; NSLog(@"name:%@", nsEnc); which displays: iana:macintosh name:Western (Mac OS Roman) name:Western (Mac OS Roman) Any ideas ?

Hello, I am working on a cross‑platform application that uses libiconv to convert strings to/from Unicode. I need to modify the existing code for compatibility with macOS. However, the call to iconv() fails with an unclear errno value (92) when using "WCHAR_T": std::wstring ConvertToWchar(const std::string& iconvCodeSet, const std::string_view str) { iconv_t conv = iconv_open("WCHAR_T//TRANSLIT", iconvCodeSet.c_str()); if (conv == (iconv_t)-1) { std::cerr << "iconv_open() failed" << std::endl; return {}; } std::wstring out(str.size(), L'\0'); auto inPtr = (char*)str.data(); size_t inSize = str.size(); auto outPtr = (char*)out.data(); size_t outSize = out.size() * sizeof(wchar_t); if (iconv(conv, &inPtr, &inSize, &outPtr, &outSize) == (size_t)-1) { std::cerr << "iconv() failed. errno = " << errno << std::endl; return {}; } if (iconv(conv, nullptr, &inSize, &outPtr, &outSize) == (size_t)-1) { std::cerr << "iconv() failed. errno = " << errno << std::endl; return {}; } iconv_close(conv); return out; } int main() { std::string str1((const char*)u8"ΟΔΥΣΣΕΥΣ"); std::wstring str2 = ConvertToWchar("UTF-8", str1); if (str2.empty()) return 1; std::cout << "converted" << std::endl; return 0; } Using "UTF-32" works fine, but "WCHAR_T//TRANSLIT" fails. What is the recommended way to convert wchar_t strings using libiconv? Why does the conversion fail with "WCHAR_T//TRANSLIT"? Thank you in advance!

We are observing a reproducible issue on some (not all) iPad models equipped with A16, where BLE streaming from multiple peripherals at ≥33–40 Hz results in uneven packet distribution, burst delivery, and application-level lag. The same application, peripherals, firmware, iOS version, and physical environment do not exhibit this behaviour on A14-based iPads (iPad 10). Affected Hardware: • iPad 11" with A16 • iOS versions: identical across tested devices • Issue affects some devices of the same model, not all Internal field data • ~25 affected • ~5 unaffected • Customers actively prefer iPad 10 (A14) due to stability When two or more BLE peripherals stream data concurrently at frequencies ≥33–40 Hz, affected iPads exhibit: • Uneven packet arrival timing • Burst delivery instead of uniform intervals • Increasing latency over time • Observable application-level lag This does not present as simple packet loss. Instead, packets arrive in clusters, breaking real-time assumptions. At ≤30–33 Hz, the issue does not reproduce. We tested: • One affected iPad 11 • One unaffected iPad 11 • Same iOS version • Same app build • Same peripherals • Same firmware • Same physical location • Same Wi-Fi state Only the affected device reproduces the issue. This rules out: • App logic • Peripheral firmware • iOS version • Environmental RF noise • Wi-Fi coexistence configuration Evidence Available We can provide: • Screenshots from a minimal test app showing packet counts • CSV files of packet timestamps • Source code for the BLE test app • Side-by-side comparison logs (affected vs unaffected device) All evidence is from the same app, built solely to measure packet timing. Additional Technical Notes • Issue persists after factory reset • Occurs without third-party BLE libraries (CoreBluetooth only) • Occurs regardless of foreground/background state • Not correlated with MTU size • Appears threshold-based (~33–40 Hz) • Appears device-specific, not model-wide

On macOS Tahoe, our application using the Endpoint Security Framework (ESF) observes that during file copies through finder application, DesktopServicesHelper unlinks the source file if the ESF authorization response is delayed for ~5 seconds, even though the authorization event deadline remains 15 seconds, indicating that the process does not wait for the full ESF deadline before deleting the file. Before Tahoe, we didnt see this behaviour.

Hello All,I am trying to communicate with BLE device which is using HID service through my iOS App using Core Bluetooth.While discovering all Services , i cannot look HID Service but i can look other services. As per previous versions , Core Bluetooth doesn't expose HID peripheral service capabilities to apps.Currently i am using Xcode 8 and iOS 10 version for development. Is there any update on exposing HID peripheral service in latest versions. If yes, how can i achive this?I will appreciate any help!!

Hi! I'm trying to figure out what mechanism request stop sends to the guest to actually request a stop. It doesn't appear that Virtualization.framework implements any ACPI bits relating to power buttons, so unclear how a linux VM would detect that a request has been stopped. I don't see any documentation around what devices are implemented by Virtualization.framework either, in terms of things like realtime clock, etc. Thanks for any help!

Hello Everyone, I'm trying to add badges to files in my File Provider Extension for macOS. I'm not trying to create my own Item decorations here, but use the default Icons provided by apple (such as com.apple.icon-decoration.badge.heart , com.apple.icon-decoration.badge.pinned). I've gone through the Sample code provided by Apple for Fruit Basket. I've tried to replicate the same thing in my Extension as well but It seems I'm unable to display Icons. I'm not even getting any Error when the Icons are not being displayed, So I've been stuck for a month on this. These are the Things that I've done below: Folder Structure : FileExplorer |- FileProviderApp | |- UI.swift | |- ContentView.swift |- Extension |- extension.swift |- item.swift |- enumerator.swift |- info.plist According to the instructions given in the Documentation for Decorations here : https://developer.apple.com/documentation/fileprovider/nsfileprovideritemdecorating. The implementation was done as follows: content inside info.plist of the File provider Extension <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>NSExtension</key> <dict> <key>NSExtensionFileProviderSupportsEnumeration</key> <true/> <key>NSExtensionPointIdentifier</key> <string>com.apple.fileprovider-nonui</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).FileProviderExtension</string> <key>NSFileProviderDecorations</key> <array> <dict> <key>BadgeImageType</key> <string>com.apple.icon-decoration.badge.heart</string> <key>Category</key> <string>Badge</string> <key>Identifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER).heart</string> <key>Label</key> <string>Heart Item</string> </dict> </array> </dict> </dict> </plist> In my extension's NSFileProviderItem I've also Implemented the protocol NSFileProviderItemDecorating. and the decoration's method as static let decorationPrefix = Bundle.main.bundleIdentifier! static let heartDecoration = NSFileProviderItemDecorationIdentifier(rawValue: "\(decorationPrefix).heart") var decorations: [NSFileProviderItemDecorationIdentifier]? { var decos = [NSFileProviderItemDecorationIdentifier]() decos.append(Item.heartDecoration) return decos } I was expecting to see badges on the File items in Finder, but i got nothing. When I modified the FruitBasket Project to do the same i was able to see badges, but not when I try to implement it in my Extension. Was I missing a step or is the issue something else ?

We are observing some unexpected behavior in our app when using ASK. Our app is able to successfully discover and set up an accessory via ASK. After the setup completes, the connection to the accessory is managed through CBCentralManager and works as expected. However, when we attempt to discover another accessory afterward, the picker is shown and indicates that accessory discovery is in progress. After approximately 10 seconds, the CBCentralManager delegate reports the Bluetooth state as poweredOff. Once this happens, the state never transitions back to poweredOn. At this point, the only way to reconnect to the device or continue discovery is to relaunch the app. We are wondering if anyone else has encountered similar behavior, or if this is a known or documented limitation/behavior when using ASK in combination with CBCentralManager.