During a test run of my HomeKit application in Xcode, after some time the app did run smoothly, I've started for one characteristic to get a pretty weird error in the readValueWithCompletionHandler: callback block: Error Domain=HMErrorDomain Code=80 "Missing entitlement for API." UserInfo={NSLocalizedFailureReason=Handler does not support background access, NSLocalizedDescription=Missing entitlement for API.} The application was launched just a couple of hours ago and the profile is still OK (though it will expire very inconveniently soon): 1044 ocs /tmp> security cms -D -i /Users/ocs/Library/Developer/Xcode/DerivedData/HomeObserverNA-hkazqlfbeuucvybpdzdgosyhhxnx/Build/Products/Debug-maccatalyst/HomeObserverNA.app/Contents/embedded.provisionprofile -o /tmp/ppp.plist 1045 ocs /tmp> plutil -extract ExpirationDate raw -o - /tmp/ppp.plist 2026-10-15T14:04:02Z 1046 ocs /tmp> Note please that immediately after launch (and for some time after that) the value was read in through the same code without any problem. Strangely enough, when I've switched the device through the Home application, I've got the update planned through enableNotification:completionHandler: all right. and the error stopped occurring, readValueWithCompletionHandler: from that moment on again works as presumed. How can I fix the problem, what's wrong in my app? Thanks!

Hi, Selecting Auto mode in the Home app on a Matter Room AC device results in Cool being sent over Matter. Off, Heat and Cool work correctly. The reverse also fails: selecting Auto from another ecosystem (e.g. Samsung SmartThings) goes out correctly over Matter, but the Home app shows Cool. The issue is specific to the Room AC device type — with the same device exposed as Thermostat, everything works. In the logs, the Home app parses the requested mode correctly and sends it to the home hub; on the hub side the logs show Cool going out over Matter. Filed as FB25164477 (logs and repro attached). Is this a known issue? Thanks!

Hi there, I am working on a (Mac Catalyst) HomeKit my own private application, which observes different characteristics of different accessories. This works (also thanks to the advice here, thanks again to all who helped!) like a charm. Now I've found that one of my outlets which is connected through Matter supports power consumption (in Home.app), but there is no characteristic for that, all I can see is its power state. Self-evidently, access to the consumption would be something Matter-specific. At this moment, to save time, I'd rather not study the complete Matter kit in detail if it can be dodged for this particular very limited goal. Is it possible just as simply as possible to read in (if readable) and observe (if observable) those extra Matter characteristics (if any) for an HMAccessory, presumably through its matterNodeID somehow? I'd be grateful for a sample code, if some is available (preferably ObjC, but of course Swift better'n nothing). Thanks a lot!

My application essentially goes through all accessories in a home (with some filtering to select just some of them) goes through all services of an accessory goes through all characteristics of a service (with some filtering, dtto) If the acc is reachable, non-blocked, and if the characteristic has the SupportsEventNotification property, then (and only then) my controller is set as the accessory delegate the characteristic is sent the enableNotification:completionHandler: message my controller, of course, implements the accessory:service:didUpdateValueForCharacteristic: method. It works well most time, but I have bumped into two separate problems: (i) occasionally, although a device does change its characteristic all right in reality (typically triggered by an automation and observed personally), I do not get the appropriate accessory:service:didUpdateValueForCharacteristic: message at all. Is that normal? I sort of presume it would happen, if there's some communication glitch inside of the HomeKit ecosystem, right? The best way to alleviate this problem would be to set up a timer and e.g., once a minute poll all observed characteristics using readValueWithCompletionHandler:, and if the current value differs from the previously seen one, assume it did change and simulate the update internally, right? Or is there a better approach? (ii) what seems to me even more weird, occasionally I get the accessory:service:didUpdateValueForCharacteristic: message for a characteristic which I did not observe (it never was sent enableNotification:completionHandler:). The solution is of course trivial, I simply ignore these superfluous updates, but I wonder: is it sort of normal, or does that mean my application must have a bug somewhere? Thanks!

How do I write a macOS (no need for i/Pad/OS at all) application which supports HomeKit for my own private use only? My original idea was simply to write it non-provisioned, which would solve all problems perfectly. Nevertheless, that, triple alas, seems not possible (https://developer.apple.com/forums/thread/849288). Provisioned one built locally has a lot of problems, among which there are e.g., big hurdles to run it at my other Macs (https://developer.apple.com/forums/thread/848903?answerId=907702022#907702022) an extremely limited expiration date A reasonable solution would be a creation of a provisioning profile which would include an expiration date in a far future and also IDs of my other computers; alas, far as I understand, this does not seem to be possible with a Personal Team, as detailed in https://developer.apple.com/forums/thread/848903?answerId=907568022#907568022. Whilst a sort of solution might be the nuclear one, it does not feel right the slightest — I need just to run my own app, nothing more, and whilst naturally I gladly accept all the possible dangers of code I wrote myself, I definitely would not want to get completely vulnerable where all the other apps (and other threats) in the world are concerned. I've checked also the Unlisted distribution; far as understand it properly, won't do either, e.g., since it will be declined ... if your app is in a beta or prerelease state — the application is fully intended to be used locally for months or even years in this state. Besides, even Unlisted apps must go through Review, and when I bump to a need to make any kind of change, I want simply do that locally and launch my new version immediately without any Review hassle. Also, in this case the otherwise important privacy issues like e.g., determining the proper computer name (https://developer.apple.com/forums/thread/813853?answerId=874075022#874075022) are of absolutely no importance. Are there other, more reasonable options? What's the proper solution, after all? Thanks!

How to write a macOS (no need for i/Pad/OS at all) application which supports HomeKit without provisioning? Might be a non-GUI plain tool or essentially anything runnable, if it makes the solution easier. All it ever needs is access to HomeKit (in future probably also Matter) APIs and the filesystem (to write logs). The application will be used locally and privately only. Thus, the provisioning is definitely not needed, and it brings ugly problems (compare please the thread https://developer.apple.com/forums/thread/848903). Thanks!

Hi, Does anyone know if Apple has released the SDK to enable 2K streaming in HomeKit for doorbells/cameras? I've not seen anything posted so far, wondered if I've missed it. Thanks

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.

The Human Interface Guidelines for HomeKit say "Your app can display still images or streaming video from a connected HomeKit IP camera." Where is the documentation to explain how? Was this covered in a WWDC session (perhaps dating from before the introduction of SwiftUI) that is no longer searchable?

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.

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

Since beta 5 of iOS 27 a new entitlement is required to use THClient.enableCredentialSharingModeForExtendedPANID Code that was running fine with previous betas is now displaying an error : 'Did fail sharing credentials: Error Domain=ThreadCredentialsStore Code=14 "CredShare: Failed to enable Credential Sharing Mode; Missing entitlement" UserInfo={NSLocalizedDescription=CredShare: Failed to enable Credential Sharing Mode; Missing entitlement}' I cannot find any mention of this requirement in header or documentation. Has anybody informations about this ? Regards, Jerome T

I'm encountering a strange behavior with one of my home's on Home app while I'm off network. When I launch the app it indicates that the hub is not responding and all of my devices are unavailable. However, on the menu bar at the bottom if I switch to "Automation" and back to "Home" the pop-up goes away and my devices are accessible again (sometimes this take a few attempts). Siri is also able to consistently control my devices without an issue. The same behavior occurs with Home app on other devices (e.g. Mac) and with other members that have access to the household. 3rd party HomeKit app like "Controller" does not have an issue. This issue began with iOS 26 and I haven't had much luck resolving the issue. I already tried rebooting everything, including removing and re-adding an Apple TV (home hub). I have other homes shared with me in Home App with similar network/environment that are still working. The home I'm having issues has the most number of devices though (over 100+).

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.

I am currently developing an app for MacOS that needs to control HomeKit devices like lights. However, it seems like MacOS is supported on the official documentation, but not when I try to create an app ID on developer.apple.com. On the link https://developer.apple.com/apple-home/, MacOS is clearly showed as supported for MacOS. But when I try to create an app ID, it shows that it is only compatible for iOS, VisionOS and WatchOS. Could this be clarified? Best regards, orangeidle25

Hello, I wanted to share my experience with a recent bug I am having to see if anyone else is having the same issue. Recently, all of my devices will show as unresponsive on the Home app sometimes, and it will typically be accompanied by my Home Hubs also being unresponsive. Sometimes it works just fine. My iPhone is on the Developer Beta, as is my Apple TV 4K. However, my HomePod mini is on the 26 Beta still. The other members of my household are on the latest official release version. There is also another issue my Apple TV 4K is having... but I will make a separate post for that. Let me know if you are also experiencing this.

Hello everyone, I am trying to get my HomePod minis on the OS 27. But it is only showing that I have a public beta of 26.5. Does anyone know how to get OS 27 to show up as an option under Betas in Home App? I am a paid member of the developer program. Any information would be great!

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.

Is there any information available on how developers can implement the "Firmware Update Readiness" and/or "Firmware Update Status" characteristics in HomeKit? Many consumer devices support this (showing an "update available" icon), however, there appears to be nothing in the documentation about this characteristic, and it is not listed as an option in the HomeKit Accessory Simulator. Thanks in advance!

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.