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"

System Version: 26.1 Device: M1 Mac Mini Steps to Reproduce: Create a UNIX socket file at /tmp/a.sock Execute the command: ln /tmp/a.sock /tmp/b.sock Execute the command: rm /tmp/b.sock Bug Description: At this point, a bug occurs in the ES_EVENT_TYPE_AUTH_UNLINK event of the system extension. The value returned for message->event.unlink.target->path is /tmp/a.sock, while it is expected to be /tmp/b.sock Reproducibility: 100%

Environment Device: iPad Air (5th generation, M1) OS Version: iPadOS 26.1 Device Orientation Lock: OFF Stage Manager / Multitasking: Disabled App Mode: Full screen (UIRequiresFullScreen = true) Supported Orientations: iPhone: Portrait + Landscape iPad: Landscape only Description On iPadOS 26.x, when device orientation lock is OFF, iPad apps that support only landscape orientation can be displayed in portrait orientation, even though portrait is explicitly not supported for iPad. This issue: Occurs not only at app launch Can also happen during runtime, such as: Returning to the app from background Unlocking the device Rotating the device while the app is running Switching focus (Control Center, Notification Center, multitasking gestures) When orientation lock is ON, the system consistently respects the app’s supported interface orientations and the issue does not occur. This behavior is a regression in iPadOS 26.x. Expected Behavior Regardless of device orientation lock state: The system should never display an app in an unsupported orientation supportedInterfaceOrientations must always be enforced Physical device orientation should only be applied within supported orientations Actual Behavior With orientation lock OFF: The system can force the app into portrait orientation This happens even though portrait is not listed in UISupportedInterfaceOrientations~ipad The app UI becomes incorrectly laid out or broken With orientation lock ON: Orientation behavior is correct and stable This suggests iPadOS 26.x is allowing device orientation to override supportedInterfaceOrientations during runtime. Info.plist Configuration UIRequiresFullScreen UISupportedInterfaceOrientations UIInterfaceOrientationPortrait UIInterfaceOrientationLandscapeLeft UIInterfaceOrientationLandscapeRight UISupportedInterfaceOrientations~ipad UIInterfaceOrientationLandscapeLeft UIInterfaceOrientationLandscapeRight

On a MacBook Pro, 16GB of RAM, 500 GB SSD, OS Sequoia 15.7.1, M3 chip, I am running some python3 code in a conda environment that requires lots of RAM and sure enough, once physical memory is almost exhausted, swapfiles of about 1GB each start being created, which I can see in /System/Volumes/VM. This folder has about 470 GB of available space at the start of the process (I can see this through get info) however, once about 40 or so swapfiles are created, for a total of about 40GB of virtual memory occupied (and thus still plenty of available space in VM), zsh kills the python process responsible for the RAM usage (notably, it does not kill another python process using only about 100 MB of RAM). The message received is "zsh: killed" in the tmux pane where the logging of the process is printed. All the documentation I was able to consult says that macOS is designed to use up to all available storage on the startup disk (which is the one I am using since I have only one disk and the available space aforementioned reflects this) for swapping, when physical RAM is not enough. Then why is the process killed long before the swapping area is exhausted? In contrast, the same process on a Linux machine (basic python venv here) just keeps swapping, and never gets killed until swap area is exhausted. One last note, I do not have administrator rights on this device, so I could not run dmesg to retrieve more precise information, I can only check with df -h how the swap area increases little by little. My employer's IT team confirmed that they do not mess with memory usage on managed profiles, so macOS is just doing its thing. Thanks for any insight you can share on this issue, is it a known bug (perhaps with conda/python environments) or is it expected behaviour? Is there a way to keep the process from being killed?

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.

I am trying to populate the Finder comment field from extendedAttributes with the code bellow but it doesn't work. Any idea why ? var extendedAttributes: [String : Data] { var attrs = [String: Data]() let comment = self.caption do { let xmlPlistData = try PropertyListSerialization.data(fromPropertyList: comment as Any, format: .xml, options: 0) attrs["com.apple.metadata:kMDItemFinderComment"] = xmlPlistData } catch { NSLog("Error during plist conversion: \(error)") } return attrs }

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.

This is not a question but rather a small bit of documentation on how Accessory Setup Kit actually works. I spent a couple days figuring this out so I thought let's share my findings. The example app is very light and the documentation definitely has room for improvement so here are a couple important notes. Findings: If you're running > iOS 18 and add any property to your Info.plist file you're no longer able to scan for devices by using CBCentralManager.scanForPeriphals. This will no longer return discoverable devices. Below iOS 18 these properties in the Info.plist are ignored by the OS and you can safely use the "legacy" method of connecting to bluetooth devices. If you're running > iOS 26 the removeAccessory will show a prompt to the user. If you're running < 26 you can silently remove the accessory and start each session with a clean state. If you create CBCentralManager before you start the ASK session you'll not get the state = PoweredOn. If you have 0 accessories connected to your application CBCentralManager will never enter the state = PoweredOn when you create the CBCentralManager. Pre-ASK this would be the trigger for iOS to ask the user permission. This is no longer necessary with ASK. If you have have 1 or more accessories authorized to your app this will be returned in the session.accessories after the session has started. This is an important indicator to determine app behavior. If you have 1 or more accessories CBCentralManager.scanForPeripherals will ONLY return previously authorized AND discoverable devices. Use this for when you want to connect to a previously authorized device. If you have 1 or more accessories and the CBCentralManager.scanForPeripherals returns nothing you can (safely) assume the user attempts to onboard a new device. So for my application I take the following steps: Check for iOS version, if > iOS 18 start ASK session. Are there previously authorized devices? -- yes: run CBCentralManger.scanForPeripherals -- no: show the picker Did the scan return any devices? -- yes: show UI to select device or connect with first available device in the list -- no: show the picker Feel free to add any of your findings and @Apple please update the documentation!

I am developing a FileProvider extension which will be launched for one or more domains. In the case where I have two domains, say with displayNames "Foo" and "Bar", the finder will then show "MyExtension - Foo" and "MyExtension - Bar" respectively after registering them with addDomain. However, if I only have a single domain, let's say "Foo" – then I just see "MyExtension" rather than "MyExtension - Foo". Now ideally I'd like to be able to control the entire name, but barring that at least be able to show the displayName even with a single domain. How can I achieve that?

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 ?

I'm trying to put a sub menu inside the context menu using the NSExtensionFileProviderActions in info.plist. Which should look like this image below I have been trying to use FPUIActionExtensionViewController for doing this task but I havent got any context menu like above. But still doing that does seem to complicate the task more. Is there a simpler way to do this task, like doing it within the info.plist so I dont have to complicate the task by creating a view controller. ?

I came across this tool that enables supervised mode on iOS without resetting the data. it's essentially a macOS with a unix executable file underneath. a quick guide of how it works is here https://www.techlockdown.com/guides/enable-supervised-mode-iphone I would appreciate any guidance on how to recreate this, as this is behind a paywall, and would like to offer something similar for free to people who want to restrict their families devices.

Is it possible to use the Matter.xcframework without the MatterSupport extension for onboarding a Matter device to our own ecosystem(own OTBR and matter controller) for an official App Store release? Currently, we can achieve this in developer mode by adding the Bluetooth Central Matter Client Developer mode profile (as outlined here https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/darwin.md). For an official release, what entitlements or capabilities do we need to request approval from Apple to replace the Bluetooth Central Matter Client Developer mode profile? Thank you for your assistance.

Bit of an odd one here, just keen to understand if it’s just me or a more generic issue. For all other apps, I can drag the icon from the dock to place into stage manager left, centre or right. However when I try to do the same with Safari (and only Safari), it just doesn’t work at all. I can repeat this 100%, has been an issue with 26.0, 26.1 and now 26.2. Can confirm this isn’t a problem on my 11” M4 iPad pro running same O/S. Here is a video showing the issue (YouTube) https://youtu.be/0WBGBZVHsfs

We attempted to run a burn-in test while connected to our MacBook Pro M4 Max, but this crashed about 10 minutes into testing. We tried to run a 2-hour burn-in on M4 Max host while charging the battery from below 5%, running six bus-powered drives (via ATTO/Black Magic/IOmeter), hitting the RJ45 port for 2.5Gbps (via JPerf), and streaming at least 4K60Hz video content to two display, however, M4 Max will crashed in 20 [minutes.]( https://www.example.com/)

Hello, I’m working on an authorization plugin which allows users to login and unlock their computer with various methods like a FIDO key. I need to add smart cards support to it. If I understand correctly, I need to construct a URLCredential object with the identity from the smart card and pass it to the completion handler of URLSessionDelegate.urlSession(_:didReceive:completionHandler:) method. I’ve read the documentation at Using Cryptographic Assets Stored on a Smart Card, TN3137: On Mac keychain APIs and implementations, and SecItem: Pitfalls and Best Practices and created a simple code that reads the identities from the keychain: CFArrayRef identities = nil; OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)@{ (id)kSecClass: (id)kSecClassIdentity, (id)kSecMatchLimit: (id)kSecMatchLimitAll, (id)kSecReturnRef: @YES, }, (CFTypeRef *)&identities); if (status == errSecSuccess && identities) { os_log(OS_LOG_DEFAULT, "Found identities: %{public}ld\n", CFArrayGetCount(identities)); } else { os_log(OS_LOG_DEFAULT, "Error: %{public}ld\n", (long)status); } When I use this code in a simple demo app, it finds my Yubikey identities without problem. When I use it in my authorization plugin, it doesn’t find anything in system.login.console right and finds Yubikey in authenticate right only if I register my plugin as non-,privileged. I tried modifying the query in various ways, in particular by using SecKeychainCopyDomainSearchList with the domain kSecPreferencesDomainDynamic and adding it to the query as kSecMatchSearchList and trying other SecKeychain* methods, but ended up with nothing. I concluded that the identities from a smart card are being added to the data protection keychain rather than to a file based keychain and since I’m working in a privileged context, I won’t be able to get them. If this is indeed the case, could you please advise how to proceed? Thanks in advance.

We have a simple function that retrieves users list via CSIdentityQueryCreate() and CSIdentityQueryExecute(). However, sometimes we get crashes in "com.apple.opendirectory.odxpc.xpc" queue and address sanitizer reports that something inside opendirectory related framework tries to access data that was released: ==327==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000166890010 at pc 0x000109b51f98 bp 0x00016b6f58d0 sp 0x00016b6f5070 READ of size 5 at 0x000166890010 thread T242 #0 0x000109b51f94 in memcpy+0x294 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x85f94) #1 0x000191c08e64 in __CFStringCreateImmutableFunnel3+0x4f8 (CoreFoundation:arm64e+0x2e64) #2 0x000191d2494c in ____CFBinaryPlistCreateObjectFiltered_block_invoke+0xa4 (CoreFoundation:arm64e+0x11e94c) #3 0x000191c39fc8 in __CFBinaryPlistCreateObjectFiltered+0x698 (CoreFoundation:arm64e+0x33fc8) #4 0x000191c3aff0 in __CFBinaryPlistCreateObjectFiltered+0x16c0 (CoreFoundation:arm64e+0x34ff0) #5 0x000191c20b98 in __CFTryParseBinaryPlist+0xe8 (CoreFoundation:arm64e+0x1ab98) #6 0x000191d11e14 in _CFPropertyListCreateWithData+0x98 (CoreFoundation:arm64e+0x10be14) #7 0x000191c20a2c in CFPropertyListCreateWithData+0x38 (CoreFoundation:arm64e+0x1aa2c) #8 0x00019b3a49d0 in ___odxpc_create_connection_block_invoke+0x104 (CFOpenDirectory:arm64e+0x29d0) #9 0x00019189e82c in _xpc_connection_call_event_handler+0x6c (libxpc.dylib:arm64e+0xe82c) #10 0x00019189d128 in _xpc_connection_mach_event+0x4a8 (libxpc.dylib:arm64e+0xd128) #11 0x0001919f98a0 in _dispatch_client_callout4+0xc (libdispatch.dylib:arm64e+0x1b8a0) #12 0x0001919fc10c in _dispatch_mach_msg_invoke+0x1cc (libdispatch.dylib:arm64e+0x1e10c) #13 0x0001919e81b4 in _dispatch_lane_serial_drain+0x148 (libdispatch.dylib:arm64e+0xa1b4) #14 0x0001919fce70 in _dispatch_mach_invoke+0x1d4 (libdispatch.dylib:arm64e+0x1ee70) #15 0x0001919e81b4 in _dispatch_lane_serial_drain+0x148 (libdispatch.dylib:arm64e+0xa1b4) #16 0x0001919e8e28 in _dispatch_lane_invoke+0x180 (libdispatch.dylib:arm64e+0xae28) #17 0x0001919f3260 in _dispatch_root_queue_drain_deferred_wlh+0x120 (libdispatch.dylib:arm64e+0x15260) #18 0x0001919f2ae4 in _dispatch_workloop_worker_thread+0x218 (libdispatch.dylib:arm64e+0x14ae4) #19 0x000191b93e1c in _pthread_wqthread+0x120 (libsystem_pthread.dylib:arm64e+0x2e1c) #20 0x000191b92b70 in start_wqthread+0x4 (libsystem_pthread.dylib:arm64e+0x1b70) 0x000166890010 is located 10946 bytes after 789838-byte region [0x0001667cc800,0x00016688d54e) freed by thread T240 here: #0 0x000109b09480 in free+0x7c (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3d480) #1 0x000191c25ca8 in __CFDataDeallocate+0x5c (CoreFoundation:arm64e+0x1fca8) #2 0x000191d56940 in _CFRelease+0x124 (CoreFoundation:arm64e+0x150940) #3 0x00019f8e4540 in DSIdentity::~DSIdentity()+0x80 (OSServices:arm64e+0xe540) #4 0x00019f8e45ec in DSUserIdentity::~DSUserIdentity()+0xc (OSServices:arm64e+0xe5ec) #5 0x000191d56940 in _CFRelease+0x124 (CoreFoundation:arm64e+0x150940) #6 0x000191c21b28 in __CFBasicHashDrain+0x1a8 (CoreFoundation:arm64e+0x1bb28) #7 0x000191d56940 in _CFRelease+0x124 (CoreFoundation:arm64e+0x150940) #8 0x00019f8ec1bc in DSIdentityQuery::~DSIdentityQuery()+0x88 (OSServices:arm64e+0x161bc) #9 0x00019f8ec220 in DSIdentityQuery::~DSIdentityQuery()+0xc (OSServices:arm64e+0x16220) #10 0x000191d56940 in _CFRelease+0x124 (CoreFoundation:arm64e+0x150940) #11 0x000107eda344 in eka::posix::memory::CFReleaseDeleter<__CSIdentityQuery*>::operator()(__CSIdentityQuery*) const+0x3c (libxxx.dylib:arm64+0x9a344) #12 0x000107eda1c8 (libxxx.dylib:arm64+0x9a1c8) #13 0x000107eda010 (libxxx.dylib:arm64+0x9a010) #14 0x000107e43424 (libx.dylib:axxrm64+0x3424) #15 0x000107e41cc4 in my::helper::EnumerateUsers(std::__1::function<void (my::helper::UserInfo&&, bool&)> const&, unsigned int)+0xf7c (libxxx.dylib:arm64+0x1cc4) ... previously allocated by thread T240 here: #0 0x000109b0938c in malloc+0x78 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3d38c) #1 0x0001919b39d4 in _malloc_type_malloc_outlined+0x60 (libsystem_malloc.dylib:arm64e+0x1d9d4) #2 0x000191d11c34 in __CFDataInit+0x214 (CoreFoundation:arm64e+0x10bc34) #3 0x00019f8e3228 in DSIdentityRecord::addJPEGData(char const*, unsigned int, unsigned int)+0x28 (OSServices:arm64e+0xd228) #4 0x00019f8e627c in DSIdentity::CreateIdentityFromDSAttributeList(__CFAllocator const*, unsigned int, tDataBuffer*, unsigned int, long, bool, DSIdentityAuthority&, tDirStatus*)+0x1c8 (OSServices:arm64e+0x1027c) #5 0x00019f8ecb64 in DSIdentityQuery::consumeRecordData(unsigned int, tDataBuffer*, long)+0xb4 (OSServices:arm64e+0x16b64) #6 0x00019f900e2c in findRecordsWithNames+0xd0 (OSServices:arm64e+0x2ae2c) #7 0x00019f8ec49c in DSIdentityQuery::performQuery(__CFError**)+0x1c4 (OSServices:arm64e+0x1649c) #8 0x00019f8ec5c4 in DSIdentityQuery::execute(unsigned long, __CFError**)+0x40 (OSServices:arm64e+0x165c4) #9 0x00019f8e06f4 in CSIdentityQueryExecute+0x2c (OSServices:arm64e+0xa6f4) #10 0x000107e4144c in my::helper::EnumerateUsers(std::__1::function<void (my::helper::UserInfo&&, bool&)> const&, unsigned int)+0x704 (libxxx.dylib:arm64+0x144c) EnumerateUsers is our function which basically does this (simplified, error checking skipped): unique_cfref<CSIdentityQueryRef> query(CSIdentityQueryCreate(kCFAllocatorDefault, kCSIdentityClassUser, CSGetLocalIdentityAuthority())); CSIdentityQueryExecute(query.get(), 0, &error); unique_cfref<CFArrayRef> userIdentities(CSIdentityQueryCopyResults(query.get())); auto userIdentitiesCount = CFArrayGetCount(userIdentities.get()); for (CFIndex i = 0; i < userIdentitiesCount; ++i) { // do something including calling getpwuid() } unique_cfref is just a std::unique_ptr wrapper that calls CFRelease when we goes out of scope. Looks like something in OpenDirectory tries to access released data (weak references and delayed processing?). The problem seems to occur on macOS 15. Is there any bug/regression, should we file a feedback? Or maybe we do something wrong?

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?

I am currently encountering a problem: during the process of uploading a large file, I have moved the file that was not successfully uploaded to the trash can. These two operations have been tested to be serial (triggering the 'create Item' callback first, followed by the 'modify Item' callback), which means that the file must be uploaded before it can be moved to the recycle bin (which can also result in the file being stored in the cloud recycle bin). I want to implement: directly interrupt this upload process and then do not complete the upload. How can I achieve this? Please help me. Thank you

I am using the MatterSupport extension to commission devices for my own ecosystem. I use the extension to do the initial connection to the device (BLE, PASE, bring device onto wifi/thread) and then use the method commissionDevice(in home: MatterAddDeviceRequest.Home?, onboardingPayload: String, commissioningID: UUID) in MatterAddDeviceExtensionRequestHandler to send a request to my own hub on the local network where it then connects to the device via wifi/thread and fully commissions the device. This flow is working correctly for wifi enabled devices, however it fails for thread devices. For some context, I am using my own border router (and have already added the router's credentials to the phone using THClient's storeCredentials). Here are some device-specific results: ESP32 (WIFI): successful commission ESP32 (THREAD): failure Matter Certified ONVIS smart plug (THREAD): failure The ESP32's are running espressif matter examples. Example border router is a running OTBR docker container I believe that the entire PASE session is established and the device gets onto the thread network, but the process seems to stall after that. I have verified that selectThreadNetwork(...) and validateDeviceCredential(...) get called but the commissioning process seems to stall before it can get to commissionDevice(...) I am limited to 7k characters, but I'll try to include as many relevant log lines as I can near the error if anyone has any ideas. I've already created a bug report with ID: FB18985348 which includes the full logs from the esp32 and a sysdiagnose from an iPhone 12 Pro (iOS 18.5) using the following log profiles: Home app/HomeKit HomeThread ThreadNetwork When commissioning directly from my hub, the entire commissioning completes successfully 100% of the time. This failure only happens when I use MatterSupport to initiate commissioning for Matter over Thread devices specifically. Very condensed homed log overview for uncertified ESP32 thread example Next: 'SecurePairing' -> 'ReadCommissioningInfo' Step: 'ReadCommissioningInfo' Sending read requests for commissioning information NetworkCommissioning Features: has Thread. endpointid = 0 <MTRDeviceController_Concrete: ..., uuid: F9BB9F53-BF73-4B82-B00B-045E7709530E...> completed for nodeID 0x0000000055d193ec with status: Success ✔ 'ReadCommissioningInfo' Next: 'ReadCommissioningInfo' -> 'ArmFailSafe' Step: 'ArmFailSafe' ✔ 'ArmFailSafe' Next: 'ArmFailSafe' -> 'ConfigRegulatory' Step: 'ConfigRegulatory' ✔ 'ConfigRegulatory' Next: 'ConfigRegulatory' -> 'ConfigureTCAcknowledgments' Step: 'ConfigureTCAcknowledgments' ✔ 'ConfigureTCAcknowledgments' Next: 'ConfigureTCAcknowledgments' -> 'SendPAICertificateRequest' Step: 'SendPAICertificateRequest' ✔ 'SendPAICertificateRequest' Next: 'SendPAICertificateRequest' -> 'SendDACCertificateRequest' Step: 'SendDACCertificateRequest' ✔ 'SendDACCertificateRequest' Next: 'SendDACCertificateRequest' -> 'SendAttestationRequest' Step: 'SendAttestationRequest' ✔ 'SendAttestationRequest' Next: 'SendAttestationRequest' -> 'AttestationVerification' Step: 'AttestationVerification' Error on commissioning step 'AttestationVerification': Internal error Next: 'AttestationVerification' -> 'AttestationRevocationCheck' Step: 'AttestationRevocationCheck' (with error) Device attestation error: Integrity check failed. Continue commissioning (ignore attestation failure: YES) ✔ 'AttestationRevocationCheck' Next: 'AttestationRevocationCheck' -> 'SendOpCertSigningRequest' Step: 'SendOpCertSigningRequest' ✔ 'SendOpCertSigningRequest' Next: 'SendOpCertSigningRequest' -> 'ValidateCSR' Step: 'ValidateCSR' ✔ 'ValidateCSR' Next: 'ValidateCSR' -> 'GenerateNOCChain' Step: 'GenerateNOCChain' ✔ 'GenerateNOCChain' Step: 'SendTrustedRootCert' ✔ 'SendTrustedRootCert' Next: 'SendTrustedRootCert' -> 'SendNOC' Step: 'SendNOC' ✔ 'SendNOC' Next: 'SendNOC' -> 'ThreadNetworkSetup' Step: 'ThreadNetworkSetup' ✔ 'ThreadNetworkSetup' Next: 'ThreadNetworkSetup' -> 'FailsafeBeforeThreadEnable' Step: 'FailsafeBeforeThreadEnable' ✔ 'FailsafeBeforeThreadEnable' Next: 'FailsafeBeforeThreadEnable' -> 'ThreadNetworkEnable' Step: 'ThreadNetworkEnable' ✔ 'ThreadNetworkEnable' Next: 'ThreadNetworkEnable' -> 'kEvictPreviousCaseSessions' Step: 'kEvictPreviousCaseSessions' ✔ 'kEvictPreviousCaseSessions' Next: 'kEvictPreviousCaseSessions' -> 'kFindOperationalForStayActive' Step: 'kFindOperationalForStayActive' Error: Timeout Next: 'kFindOperationalForStayActive' -> 'Cleanup' Step: 'Cleanup' (with timeout error) ✔ 'Cleanup' Commissioning complete for node ID 0x0000000055D193EC with timeout error

Our app will launch automatically in the background，Doubt is the result of background fetch ，so we cancel the background modes setting of the background fetch,but we still can see the performFetchWithCompletionHandler method called when app launch in the background。Background launch will cause some bugs in our app. We don't want the app to start in the background. We hope to get help