Hello Apple Home/Matter team, our Matter product is CSA-certified, has a valid CD, and is listed in Compliance DCL. In testing with HomePod mini as border router, commissioning proceeds but Apple Home still shows “Uncertified Accessory.” We are an OEM/ODM manufacturer: product vendor_id/product_id belong to the brand owner, while dac_origin_vendor_id/dac_origin_product_id belong to us(manufacturer). The device also uses the brand owner’s product VID/PID at runtime. Our certification is Portfolio Family, so CD product_id is an array covering 6 SKUs. Is this model expected to pass Apple Home certification checks, and what are the most common causes of this warning? Emma

Hello, I'm developing Verde, a Matter irrigation system (soil moisture sensors, a hub, and a multi-valve irrigation controller). My question is about Matter device type support in Apple Home, not about hardware or commissioning. The failure: when an endpoint declares certain device type IDs, Home refuses to create the accessory and reports that the device is not supported. Change nothing but the device type ID, and the same accessory is created and works. So this is Home rejecting a device type, not a pairing, discovery or hardware problem. Water Valve — 0x0042 Device type 0x0042 Water Valve (Matter 1.3) Cluster 0x0081 Valve Configuration and Control Result in Apple Home Not supported — accessory is not created Result on other Matter controllers Created and controllable Substitute we now ship: device type 0x010A On/Off Plug-in Unit with cluster 0x0006 On/Off. Accepted by Home immediately, and toggling the endpoint operates the valve. The substitution works but is a misrepresentation: the user sees a row of "plugs" for a device that controls irrigation valves. There are no valve semantics, no open/close vocabulary, and nothing tells Home — or an automation the user writes — that switching this on releases water. Soil Sensor — Matter 1.5 Device type Soil Sensor / soil measurement, introduced in Matter 1.5 Result in Apple Home Not available Substitute we now ship: 0x0307 Humidity Sensor with cluster 0x0405 Relative Humidity Measurement, because that is what Home renders. Soil moisture therefore appears in Home as air humidity — conceptually wrong, wrong icon, and it contaminates any humidity-based automation the user has set up. The CSA positioned the 1.5 soil types explicitly for irrigation use with Matter water valves, so the two gaps above are the same gap for us. Multi-endpoint valve controller — composition Our controller is a single accessory exposing seven independently controlled valve endpoints (endpoint IDs 1–7). Endpoints exist only for valves the installer has enabled, so the composition can legitimately change after a configuration change. Two questions on this: Changed composition isn't picked up. When an endpoint is removed, Home keeps showing it until the accessory is deleted and re-added. Is there a supported way to make Home re-read a device's composition in place? Preferred shape. For seven valves, does Apple prefer one accessory with seven endpoints, or a Bridge (0x000E) exposing seven separate accessories? 4. What we're asking Is Water Valve 0x0042 planned for Apple Home, and is there a timeframe we can plan to? Is the Matter 1.5 Soil Sensor device type planned? Until then, is substituting On/Off Plug-in Unit for a valve, and Humidity Sensor for soil moisture, acceptable to Apple? We'd rather follow your guidance than ship a misrepresentation we later have to undo — and than have a valve presented to users and automations as a plug. For a multi-endpoint valve controller: guidance on composition, and on refreshing a changed endpoint list in Home. Is there an authoritative, current list of the Matter device type IDs Apple Home accepts, more specific than the general support article? Designing against it is far cheaper than building an accessory and discovering Home will not create it.

I'm building a Matter irrigation system and I've hit a device-type wall in the Home app. This is not a commissioning or pairing problem - the accessory is found, setup proceeds, and then Home declines to create the accessory, reporting that the device is not supported. The controlled comparison, which is why I'm confident it is the device type and nothing else: Endpoint declares 0x0042 Water Valve (Matter 1.3) with cluster 0x0081 Valve Configuration and Control -> Home: NOT SUPPORTED, accessory is not created. Endpoint declares 0x010A On/Off Plug-in Unit with cluster 0x0006 On/Off -> Home: created, works, valve opens and closes. Same hardware, same firmware image, same network, same iPhone. The only variable is the device type ID. Other Matter controllers accept the 0x0042 version and control it correctly. Water Valve (0x0042) - is this device type supported by the Home app in any current or announced iOS version? If not, is support planned? Right now I ship the plug-in-unit substitution because it is the only thing Home will accept. It works, but it misrepresents the device: the user sees a row of "plugs" that are actually irrigation valves, with no valve semantics and nothing telling Home - or an automation the user writes - that switching this on releases water into a garden. Soil Sensor (Matter 1.5) - same question. Matter 1.5 added soil sensing (moisture, optionally temperature), explicitly positioned for irrigation paired with Matter water valves. Is it supported or planned in Home? Today I publish soil moisture on a Relative Humidity Measurement endpoint (0x0405) because that is what Home renders, so garden soil moisture appears as air humidity and pollutes any humidity-based automation the user has. The general question, which is the one I actually want answered: is there an authoritative list of the Matter device type IDs the Home app accepts? The public support article describes categories in prose (lights, plugs, switches, thermostats, sensors...), but gives no device type IDs, so there is no way to check a design against it before building. I would like to design to the list rather than discover at pairing time that Home will not create my accessory. A related composition question: my controller is a single accessory with seven independently controlled valve endpoints, and endpoints exist only for valves the installer has enabled. When a valve is disabled and its endpoint disappears, Home keeps showing it until the accessory is removed and re-added. Is there a supported way to make Home re-read a device's composition in place - and for seven valves, does Apple prefer one accessory with seven endpoints, or a Bridge (0x000E) exposing seven accessories? Setup: Matter over Wi-Fi (2.4 GHz), esp-matter / connectedhomeip, test VID 0xFFF1 during development. iOS 17 and 18, iPhone 12, Home hub present. Happy to provide the full endpoint and cluster composition or logs if useful.

Hello Apple Home / Matter Engineering Team, We are developing a Matter-enabled indoor air quality monitoring device that includes radon measurement. The device can be successfully commissioned into Apple Home, and Apple Home correctly recognizes and displays the overall Air Quality information. However, the actual Radon concentration measurement is not displayed in the Apple Home app. We would like to clarify whether this is expected behavior in the current Apple Home implementation. Specifically: Does Apple Home currently support displaying the Matter Radon Concentration Measurement separately from the overall Air Quality value? If supported, which Matter cluster/attributes and device configuration does Apple Home expect? If our device correctly exposes the applicable Matter Radon Concentration Measurement cluster, should Apple Home display the measured value in the accessory UI? If Apple Home currently does not expose the Radon concentration in its UI, is there a recommended implementation for Matter accessory manufacturers? Commissioning and other Matter functionality are working correctly. We are specifically trying to determine whether this behavior is an Apple Home UI/support limitation or whether our Matter implementation needs to be modified. We can provide our Matter specification version, device type, endpoint/cluster configuration, screenshots, logs, and certification information if needed. Thank you, JS

I'm building a HomeKit app that discovers Thread devices and visualizes the mesh topology. I can detect device roles (Router vs End Device via characteristic 0x0703) and identify Border Routers (via _meshcop._udp), but I cannot determine which Router is the parent of a given End Device. Any Thread device can act as a Router (a Nanoleaf bulb, an Eve plug, not just HomePods), and End Devices attach to these Routers as children. That parent-child relationship is what I'm trying to map, but there's no RLOC16, neighbor table, or parent identifier exposed through any available API. I've tested every path I can find. Here's what I've tried on a network with 44 Thread devices and 6 Border Routers: What works (partially) HAP Thread Management Service (0x0701) gives me the device role from characteristic 0x0703, the OpenThread version from 0x0706, and node capabilities from 0x0702. That's the complete set of characteristics on that service. None of them contain RLOC16, parent Router, or neighbor data. This service also only exists on HAP-native Thread devices. My 20 Matter-over-Thread devices (Aqara, Eve Door, SmartWings, Onvis S4) don't have it at all. MeshCoP Bonjour (_meshcop._udp) identifies Border Routers and the network name/Extended PAN ID. No topology data about other mesh nodes. What doesn't work ThreadNetwork framework (THClient) - retrieveAllCredentials() returns error Code 3 because the app can't access credentials stored by Apple Home. Even if it worked, THCredentials only contains network config (name, PAN ID, channel), not topology. Direct CoAP queries - Border Routers don't route traffic from WiFi to Thread management ports. Mesh-local addresses aren't reachable. No Thread NWInterface in Network.framework. Network.framework - No visibility into the Thread mesh from the WiFi side. The only remaining path I can see (but it's not practical) Matter cluster 0x0035 (Thread Network Diagnostics) appears to have exactly what I need: RLOC16, NeighborTable with isChild boolean, RouteTable. I haven't implemented this because it requires commissioning each device individually onto my app's own Matter fabric via Multi-Admin. That's 21 separate user-initiated pairing actions on my network. I can't ask end users to do that. The core issue Every Thread Router (whether it's a HomePod acting as a Border Router or a Nanoleaf bulb acting as a mesh Router) knows its own children and neighbors. The Border Routers also maintain route tables covering the mesh backbone. This data exists on the user's own devices but none of it is exposed to third-party apps. Even something minimal would help. HMAccessory already exposes matterNodeID as a cross-protocol identifier. Exposing RLOC16 the same way would be enough, since parent-child relationships are encoded in the address itself (ParentRLOC = ChildRLOC & 0xFC00). Has anyone found another approach I'm missing? Thanks in advance for any pointers.

Hi Apple Home Team, We are integrating a Matter-enabled Tower Fan with Apple Home and have observed that the current Apple Home UI does not expose all the capabilities defined by the Matter Fan Control cluster. Wind Mode Our device supports the following WindMode values: Normal Natural Sleep However, Apple Home does not provide any UI to view or control the Natural and Sleep wind modes. Only the basic fan controls are available. Rock Mode (Oscillation Direction) Our device also supports the following RockMode values: Off Left-Right Up-Down In Apple Home, we only see a single Oscillation toggle (On/Off). There is no option to select the oscillation direction (e.g., Left-Right or Up-Down). Could you please clarify: Does Apple Home currently support the Matter WindMode attribute of the Fan Control cluster? Is the current On/Off Oscillation control the expected behavior for devices that support multiple RockMode directions? What is the recommended approach for Matter devices that implement multiple RockMode values (e.g., Left-Right and Up-Down)? Are there any plans to add native UI support for Wind Mode and Rock Mode direction selection in a future Apple Home release? Thank you for your support. We look forward to your guidance on the recommended implementation for Apple Home. Thanks, Chintan Patel

I am developing a Matter thermostat device and would like to understand the specific requirements for supporting the Adaptive Temperature feature in the Apple Home app. What we have tested: We built a standard Matter 1.4 thermostat that implements the Thermostat cluster with support for Cool, Heat, and Auto modes. We successfully added this device to a HomePod running iOS 26.2 (or later). However, the Adaptive Temperature button does not appear in the device settings within the Home app. Our questions: Are there additional Matter cluster attributes or features beyond the standard Matter 1.4 Thermostat cluster that are required for Adaptive Temperature to be recognized by Apple Home? Does Adaptive Temperature require any specific device type or optional feature (e.g., occupancy sensing, local temperature reporting intervals, or support for Auto mode in a particular way)? Is there any special entitlement or capability that must be enabled in the Apple Developer account (e.g., under Certificates, Identifiers & Profiles) for a Matter device to expose Adaptive Temperature? Are there known reference implementations or test cases we can follow to validate Adaptive Temperature support? Any documentation, technical specifications, or guidance would be greatly appreciated. Thank you.

Hi everyone, I'm developing a standalone Matter controller app on iOS 18+ using Apple's Matter.framework directly — without integrating with Apple Home or HomeKit. We manage our own Matter fabric and handle the full commissioning flow ourselves. Current setup: BLE-based Matter device discovery and commissioning via Matter.framework Own fabric management (not adding devices to Apple Home) During development, we rely on the "Bluetooth Central Matter Client Developer Mode" profile to enable BLE access The challenge: As we approach our App Store release, we need end users to be able to commission Matter devices without installing any developer profiles. I'm trying to figure out the correct entitlement path for a non-HomeKit Matter controller app in production. Questions: Which entitlements are required for a third-party Matter controller app using Matter.framework directly (not via HomeKit) to work in production? Is there a formal entitlement request process for something like com.apple.developer.matter.allow-setup-payload? If so, where do we initiate it? Are there additional program memberships or certifications required beyond the standard Apple Developer Program membership? We've gone through the Matter framework documentation and relevant WWDC sessions but haven't found a clear answer specifically for non-HomeKit standalone Matter controller apps. Would appreciate any input from Apple staff or developers who've shipped a similar app. Happy to provide more details if needed. Tagging for visibility: @Apple or relevant team — this involves a non-HomeKit Matter.framework usage pattern and entitlement approval process.

Hi Apple Team / Community, We are currently pulling our hair out over a TestNet OTA issue and could really use some help. Our Matter Door Lock (VID: 5424, PID: 513) has already obtained official CSA Certification, so we are 100% confident that our device firmware and OTA Requestor logic are completely solid. However, we simply cannot get Apple's TestNet to serve the update via HomePod. Here is exactly what is happening: Our device successfully sends a QueryImage command to the HomePod. The HomePod receives it, but immediately fires back a QueryImageResponse that essentially means "UpdateNotAvailable", forcing the device into an 86400-second sleep timeout. Here is what we have verified so far: Local OTA works perfectly: If we use Nordic's chip-ota-provider-app locally with the exact same .ota file, the BDX transfer triggers instantly and the device updates without a hitch. DCL details are 100% accurate: We published a brand new version (1.0.4 / 16778240) which is strictly higher than the device's current version (1.0.1 / 16777472). The otaFileSize (973839) and Base64 Checksum match the file perfectly. ZERO hits on our server: The OTA file is hosted on an AWS S3 direct link (SSL Grade A via SSL Labs, ATS compliant). We checked our server logs, and there hasn't been a single download attempt from any Apple IP addresses. Since our device is certified and local OTA works flawlessly, it strongly feels like Apple's TestNet backend either has a stuck/cached "invalid" state for our VID/PID (very similar to what was reported in CHIP GitHub Issue #29338), or the Apple backend crawler is failing to reach our URL for some internal reason. Could someone please check if there is a cached exception for VID: 5424 / PID: 513 on the TestNet backend? Any help or pointers would be hugely appreciated! Thanks in advance.

Hi, We are facing the issue of commissioning our Matter device to google home through iOS device will be 100% failed. Here is our test summary regarding the issue: TestCase1 [OK]: Commissioning our Matter 1.4.0 device to Google Nest Hub 2 by Android device (see log DoorWindow_2.0.1_Google_Success.txt ) TestCase2 [NG]: Commissioning Matter 1.4.0 device to Google Nest Hub 2 by iPhone13 or iPhone16 (see log DoorWindow_2.0.1_Google_by_iOS_NG.txt ) TestCase3 [OK]: Commissioning our Matter 1.3.0 device to Google Nest Hub 2 by iPhone13 In TestCase2, we noticed that device was first commissioned to iOS(Apple keychain) then iOS opened a commissioning window again to commission it in Google’s ecosystem, and the device was failed at above step 2, so we also tried: Commissioning the device to Apple Home works as expected, next share the device to Google Home app on iOS, this also fails. Commissioning the device to Apple Home works as expected, next share the device to Google Home app on Android, this works as expected and device pops up in Google home of iOS as well. Could you help check what's the issue of TestCase2? Append the environment of our testing: NestHub 2 version Google Home app version

My team is evaluating an iOS companion app for our own network-connected device, and we want to understand whether the planned architecture would likely create an App Review problem under Guideline 2.5.17. Our situation is: We are building our own device and our own companion app. We do not intend to market the device as a Matter-certified device initially. We do not intend to support Apple Home or broad third-party Matter ecosystem interoperability in the first release. We are under a tight schedule and are considering reusing Matter/CSA-derived libraries, data models, and protocol concepts internally to reduce engineering effort and move faster toward eventual certification. Our current understanding is that there are already many iOS apps that communicate with LAN-connected devices using proprietary protocols, so our initial assumption is that a vendor-specific local-network device workflow should generally be acceptable. The point we are trying to clarify is whether that changes if the implementation under the hood is based in part on Matter-derived components. The idea we are considering is: Ship an initial release where the device and app use a vendor-specific onboarding and communication flow. The implementation would likely use something based on connectedhomeip under the hood, but the shipped protocol would be intentionally modified so that it is proprietary in practice and not interoperable with the broader Matter ecosystem. In other words, the device would not present as a normal Matter accessory, and other Matter controllers/devices would not be able to communicate with it as if it were a standard Matter device. Later, after full Matter certification work is complete, we would deliver an OTA update to enable proper Matter ecosystem interoperability. The question we are trying to answer is whether the mobile app itself would likely be acceptable on the App Store during that first phase. More specifically: If our app communicates only with our own device and not with Apple Home or third-party Matter controllers, but internally reuses Matter-derived software/protocol components, would Apple still likely consider that an app that “supports Matter” for purposes of Guideline 2.5.17? If the app includes something based on connectedhomeip or a modified subset of such a library, but the shipped device/app behavior is intentionally not interoperable with the general Matter ecosystem, is that still likely to be treated as use of a non-Apple Matter software component that must already be CSA-certified for iOS? From App Review’s point of view, what matters most here: whether Apple’s Matter pairing framework is used, whether the product is presented to users as a Matter accessory, whether the protocol remains interoperable with third-party Matter ecosystems, or simply whether Matter-derived software/components are included in the app at all? Is there a meaningful App Review distinction between: a proprietary device protocol designed entirely in-house, and a vendor-specific protocol that reuses Matter-derived transport/session/data-model components internally but is intentionally incompatible with standard Matter interoperability in the shipped product? We are trying to understand whether this staged approach is fundamentally incompatible with App Review, or whether it can be acceptable as a vendor-specific device workflow during development toward full certification.

With the same firmware, OTA testing on the DCL test network was successful in September 2025, and the Home app was able to deliver software update notifications. Since the beginning of 2026, however, the Home app no longer delivers software update notifications. This is bug number: FB21922369

My team has developed an app with a biref Matter commissioner feature using the Matter framework on the MatterSupport extension. Our app support iOS and Android. However, we ran into a problem that the control certificate generated by the iOS app could not control the device on the Android side. And the control certificate generated by the Android app could not control the device on the iOS side. The Matter library used by Android is compiled by connectedhomeip. Does anyone have the same problem as us? How to solve this? Thank you

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.

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.

Hi, I’m developing a Matter commissioning flow and would like to clarify Apple Home’s support for concatenated (multi-device) QR codes. In my implementation, I generate a single QR code that contains multiple Matter onboarding payloads (concatenated payloads), intended to commission multiple devices in one scan, similar to a multi-pack / multi-accessory flow. What I’ve tested: Standard single-device Matter QR codes work as expected in the Apple Home app A concatenated QR code (multiple Matter payloads combined into one QR) does not get recognized / commissioned by Apple Home My questions: Does Apple Home officially support commissioning via concatenated or multi-device Matter QR codes? If yes, is there a specific payload format or delimiter that Apple Home expects? If not, is this a known limitation or something planned for future iOS/Home releases?

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.

Hi, We are facing the issue of commissioning our Matter device to google home through iOS device will be 100% failed. Here is our test summary regarding the issue: TestCase1 [OK]: Commissioning our Matter 1.4.0 device to Google Nest Hub 2 by Android device (see log DoorWindow_2.0.1_Google_Success.txt ) TestCase2 [NG]: Commissioning Matter 1.4.0 device to Google Nest Hub 2 by iPhone13 or iPhone16 (see log DoorWindow_2.0.1_Google_by_iOS_NG.txt ) TestCase3 [OK]: Commissioning our Matter 1.3.0 device to Google Nest Hub 2 by iPhone13 In TestCase2, we noticed that device was first commissioned to iOS(Apple keychain) then iOS opened a commissioning window again to commission it in Google’s ecosystem, and the device was failed at above step 2, so we also tried: Commissioning the device to Apple Home works as expected, next share the device to Google Home app on iOS, this also fails. Commissioning the device to Apple Home works as expected, next share the device to Google Home app on Android, this works as expected and device pops up in Google home of iOS as well. Could you help check what's the issue of TestCase2? Append the environment of our testing: NestHub 2 version Google Home APP version

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

I'm trying to use ThreadNetwork API to manage TheradNetworks on device (following this documentation: https://developer.apple.com/documentation/threadnetwork/), but while some functions on THClient work (such as getPreferedNetwork), most don't (storeCredentials, retrieveAllCredentials). When calling these functions I get the following warning/error: Client: -[THClient getConnectionEntitlementValidity]_block_invoke - Error: -[THClient storeCredentialsForBorderAgent:activeOperationalDataSet:completion:]_block_invoke:701: - Error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service with pid 414 named com.apple.ThreadNetwork.xpc was invalidated from this process." UserInfo={NSDebugDescription=The connection to service with pid 414 named com.apple.ThreadNetwork.xpc was invalidated from this process.} Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service with pid 414 named com.apple.ThreadNetwork.xpc was invalidated from this process." UserInfo={NSDebugDescription=The connection to service with pid 414 named com.apple.ThreadNetwork.xpc was invalidated from this process.} Failed to store Thread credentials: Couldn’t communicate with a helper application. STEPS TO REPRODUCE Create new project Add Thread Network capability via Xcode UI (com.apple.developer.networking.manage-thread-network-credentials) Trigger storeCredentials let extendedMacData = "9483C451DC3E".hexadecimal let tlvHex = "0e080000000000010000000300001035060004001fffe002083c66f0dc9ef53f1c0708fdb360c72874da9905104094dce45388fd3d3426e992cbf0697b030d474c2d5332302d6e65773030310102250b04106c9f919a4da9b213764fc83f849381080c0402a0f7f8".hexadecimal // Initialize the THClient let thClient = THClient() // Store the credentials await thClient.storeCredentials(forBorderAgent: extendedMacData!, activeOperationalDataSet: tlvHex!) { error in if let error = error { print(error) print("Failed to store Thread credentials: \(error.localizedDescription)") } else { print("Successfully stored Thread credentials") } } NOTES: I tried with first calling getPreferedNetwork to initiate network permission dialog Tried adding meshcop to bojur services Tried with different release and debug build configurations