I am currently developing an air quality monitoring device that supports the Matter protocol and is intended to integrate with HomeKit. During the development process, I've encountered a couple of issues regarding sensor data display within the Home app and would appreciate any insights from the community. Issue 1: Temperature Sensor Display We have observed that when the temperature sensor is implemented as a cluster within the device, its data fails to appear in the Home app interface. However, if it is configured as an independent endpoint, it displays correctly. Is this a specific requirement of HomeKit regarding the structure of clusters and endpoints in Matter devices? Issue 2: Support for HCHO and TVOC Sensor Display Does HomeKit currently support displaying real-time data from HCHO (Formaldehyde) and TVOC sensors? If so, are there specific cluster specifications or data types that need to be followed?

The air conditioner is connected to the Home app via Matter Bridge, and two different methods have resulted in different behaviors: After scanning the QR code to bind the air conditioner, a fan speed slider is displayed. If the air conditioner is first added to MatterBridge (a gateway with Zigbee functionality), and then scanned to bind it to the Home app, the fan speed slider is not displayed. Data reporting is the same. fan-1.txt fan-2.txt nofan-1.txt nofan-2.txt nofan-3.txt

Hi, We are trying to use Apple Security API for KeyChain Services. Using the common App Group : Specifying the common app group in the "kSecAttrAccessGroup" field of the KeyChain query, allowed us to have a shared keychains for different apps (targets) in the app group, but this did not work for extensions. Enabling the KeyChain Sharing capability : We enabled the KeyChain Sharing Ability in the extensions and the app target as well, giving a common KeyChain Access group. Specifying this in the kSecAttrAccessGroup field also did not work. This was done in XCode as we were unable to locate it in the Developer portal in Indentifiers. We tried specifying "$AppIdentifier.KeyChainSharingGroup" in the kSecAttrAccessGroup field , but this did not work as well The error code which we get in all these 3 cases when trying to access the Keychain from the extension is error code 25291 (errSecNotAvailable). The Documentation says this error comes when "No Trust Results are available" and printing the error in xcode using the status says "No keychain is available. The online Documentation says that it is possible to share keychain with extensions, but by far we are unable to do it with the methods suggested. Do we need any special entitlement for this or is there something we are missing while using these APIs? We really appreciate any and all help in solving this issue! Thank you

When I use MatterSupport to configure a Tread device for networking, the selectThreadNetwork callback in MatterAddDeviceExtensionRequestHandler returns my own Tread network(.network(extendedPANID:), but I cannot successfully add the device to my own Tread network.

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

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

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, 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?

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

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

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 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.

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.