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.

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.

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.