P.S. BTW, even if I could set up trigger shortcuts, I would most probably bump into extreme problems debugging them. It is difficult enough with just the events/predicates; without an access to detailed logs with more powerful shortcults it would get a proper nightmare :( Compare please also this comment in another thread.

Thanks again. Alas from the point of view of us poor people ordealed to stick with the public APIs, there is no such thing as “HomeKit's shortcut integration” at all :( All I could do in theory would be to prepare those in the Home application and then update the triggers from my app; even if I wanted to go this way despite its inconvenience, I still could bump into ugly problems, for, as we lately agreed in another thread you don't interact with automations you didn't create

Thanks a lot for all the insight! I must say, when I've started to study the HomeKit APIs, I was really excited by its nice design and flexibility. The more I use it though, I am bumping into limitations, things documented poorly or not at all, etc :( Eg. I've found by trial-and-error that it seems not to be possible to use an HMDurationEvent as a fire event of an HMEventTrigger — this would make an excellent sense with triggers set up just temporarily, “do this scene in an hour from now”, especially along with executeOnce. Of course it is easy to create and use an appropriate HMCalendarEvent instead, but unless I am overlooking something, this seems to be nowhere documented; what's even more surprising, endEvents do not seem to work at all with other characteristics than power state ones. So, e.g., to bump my thermostat up for half an hour I have to create two separate HMCalendarEvent-based triggers, which is rather at the unwieldy side :( As for you don't interact with automations you didn't create well I would never have tried, if there was an API to do it directly :(

Thanks a lot! Far as I understand, this would most probably mean the HMEventTrigger never uses[1] the standard evaluateWithObject: service. Instead it parses the predicate and evaluates it sort of “manually“, among others, whenever it encounters a nested compound predicate like the ones above, it evaluates it a special way, finding explicitly the appropriate characteristic in the current HomeKit, instead of evaluating it over same object as the other parts. Which alas opens more questions it answers. How could I create such predicates trusting they would work right? What would happen e.g., if the characteristic became unreachable or blocked, or even the accessory which contained it was removed from the HK meantime? The original reason I've started studying this was a need to set up a predicate which would compare values of two different characteristics: “perform the scene only if the current value of characteristic A is greater than the current value of characteristic B“. How do I do that (if possible at all)? Of course I could try to create different predicates and test whether they can be set up to triggers (and if so, whether they work right), but without a proper documentation that's not good, for even if something happens to work now, if not explicitly documented, it could stop working in the next system version :( [1] Or perhaps it first creates a different predicate essentially copying the original, but replacing those nested characteristic-based ones by constant boolean values, and then does use evaluateWithObject: on this “copy” to reuse the standard code for evaluating all those potentially complex boolean expressions and all the non-characteristic-based parts, which is probably how would I implement it myself. Which though boils down to essentially the same result and the questions open above remain.

Hmmm, well, this time it seems cleaning the build folder and re-building from scratch did help. Weird, the previous time on the other computer it did not. Perhaps it might have helped that this time before the re-build I went through my Accounts in the Xcode Settings to check whether all was OK. All was OK, nevertheless I wonder, might perhaps this, as a side-effect, re-set something somewhere related to the profile/signature/application identity weird and mysterious stuff, which caused the problem before? Aside of this improbable (but I guess technically possible) hypothesis, I've absolutely no idea what the H. might be both the culprit before and the cure now :( Anyway, touching wood the problem does not repeat and become worse... keep fingers crossed for me, thanks!

Well, darn. Now it happened on another computer. I did absolutely nothing suspicious, just slightly improved the code (without changing the bundle ID of course!), ⌘r, build succeeded, and ... “Could not launch “HomeObserverNA””. The complete report is below :( An attempt to launch the built application from Finder says “The application “Finder” does not have permission to open “(null)”.“. Quadruple sigh. I wonder whether there is a way to fix the problem (a) without restarting my Mac (which at this moment would be very inconvenient), (b) without changing all the uniqueIds... Can anybody see a cure? Of course this time I am not about to use codesign in any way. === Could not launch “HomeObserverNA” Domain: IDELaunchErrorDomain Code: 20 Recovery Suggestion: LaunchServices has returned error -54. Please check the system logs for the underlying cause of the error. User Info: { DVTErrorCreationDateKey = "2026-10-27 17:57:55 +0000"; DVTRadarComponentKey = 113722; IDERunOperationFailingWorker = IDELaunchServicesLauncher; } -- The operation couldn’t be completed. (OSStatus error -54.) Domain: NSOSStatusErrorDomain Code: -54 User Info: { "_LSErrorMessage" = permErr; "_LSFile" = "LSOpenCore.mm"; "_LSFunction" = "_LSOpenStuffCallLocal"; "_LSLine" = 4277; } -- Event Metadata: com.apple.dt.IDERunOperationWorkerFinished : { "device_identifier" = "00006040-001251A40C7A801C"; "device_model" = "Mac16,11"; "device_osBuild" = "26.6.2 (25G83)"; "device_osBuild_monotonic" = 2506008300; "device_os_variant" = 1; "device_platform" = "com.apple.platform.macosx"; "device_platform_family" = 1; "device_reality" = 1; "device_thinningType" = "Mac16,11"; "device_transport" = 4; "launchSession_schemeCommand" = Run; "launchSession_schemeCommand_enum" = 1; "launchSession_targetArch" = arm64; "launchSession_targetArch_enum" = 6; "operation_duration_ms" = 12; "operation_errorCode" = 20; "operation_errorDomain" = IDELaunchErrorDomain; "operation_errorWorker" = IDELaunchServicesLauncher; "operation_error_reportable" = 1; "operation_name" = IDERunOperationWorkerGroup; "param_consoleMode" = 1; "param_debugger_attachToExtensions" = 0; "param_debugger_attachToXPC" = 1; "param_debugger_type" = 3; "param_destination_isProxy" = 0; "param_destination_platform" = "com.apple.platform.macosx"; "param_diag_MTE_enable" = 0; "param_diag_MainThreadChecker_stopOnIssue" = 0; "param_diag_MallocStackLogging_enableDuringAttach" = 0; "param_diag_MallocStackLogging_enableForXPC" = 1; "param_diag_allowLocationSimulation" = 1; "param_diag_checker_mtc_enable" = 1; "param_diag_checker_tpc_enable" = 1; "param_diag_gpu_frameCapture_enable" = 0; "param_diag_gpu_shaderValidation_enable" = 0; "param_diag_gpu_validation_enable" = 0; "param_diag_guardMalloc_enable" = 0; "param_diag_memoryGraphOnResourceException" = 0; "param_diag_queueDebugging_enable" = 1; "param_diag_runtimeProfile_generate" = 0; "param_diag_sanitizer_asan_enable" = 0; "param_diag_sanitizer_tsan_enable" = 0; "param_diag_sanitizer_tsan_stopOnIssue" = 0; "param_diag_sanitizer_ubsan_enable" = 0; "param_diag_sanitizer_ubsan_stopOnIssue" = 0; "param_diag_showNonLocalizedStrings" = 0; "param_diag_viewDebugging_enabled" = 1; "param_diag_viewDebugging_insertDylibOnLaunch" = 1; "param_install_style" = 2; "param_launcher_UID" = 2; "param_launcher_allowDeviceSensorReplayData" = 0; "param_launcher_kind" = 0; "param_launcher_style" = 99; "param_launcher_substyle" = 0; "param_lldbVersion_component_idx_1" = 0; "param_lldbVersion_monotonic" = 170302360020; "param_runnable_appExtensionHostRunMode" = 0; "param_runnable_productType" = "com.apple.product-type.application"; "param_testing_launchedForTesting" = 0; "param_testing_suppressSimulatorApp" = 0; "param_testing_usingCLI" = 0; "sdk_canonicalName" = "macosx26.2"; "sdk_osVersion" = "26.2"; "sdk_platformID" = 6; "sdk_variant" = iosmac; "sdk_version_monotonic" = 2502005400; } -- System Information macOS Version 26.6.2 (Build 25G83) Xcode 26.2 (24549) (Build 17C48) Timestamp: 2026-10-27T18:57:55+01:00

Thanks again very much for the detailed insight! Frankly I must admit I can't see how my privacy could be compromised if any 3rd party application, evil as they come, happens to be able to distinguish and/or match my devices it just happens to run on; but then, it would be just a limitation of my imagination, nothing else (and not worth to pursue) :) (Also, I sort of wonder how those HK non-unique-unique-IDs really help privacy. If the problem happens more often, I am sadly prepared to store/match the accessory and characteristic attributes, finding thus the same items with a very high reliability and create an appropriate uniqueIdentifier translation table. Since any evil application can do that just as well, seems to me the ever-changing IDs help privacy just a very little, if at all... But again, that's not worth pursuing; self-evidently I overlook something of importance...) Thanks again!

Hm, to partially answer my own question, I've just found in the documentation of identifierForVendor The value changes when the user deletes all of that vendor’s apps from the device ... The value can also change when installing test builds using Xcode or when installing an app on a device using ad-hoc distribution. Therefore, if your app stores the value of this property anywhere, you should gracefully handle situations where the identifier changes That feels crazy. The device is still the same. The application is still the same (based on its bundle identifier). Why on earth ever to change something which should “uniquely identify a device to the app’s vendor”?!? Well, anyway, this part is not that important; I've used the thing just in a naïve idea that it would, well, identify the device to me. Can live without that. The most important part is, how do I make sure that for the same application (same bundle id) on the same device all the HomeKit uniqueIdentifiers remain unchanged? Thanks. (Considerably less important, but also interesting question is, what API could I use so that two applications, one Catalyst, another standard AppKit, would reliably get the same result on the same device — regardless “test builds”, “the user deletes all apps”, or whatever like that —, and different result on different devices?)

Another very weird problem happened today :( Xcode built my (Catalyst, HomeKit) application all right, but refused to launch it reporting “LaunchServices has returned error -54”. It could not be launched from Finder either (“Finder does not have permission to open (null)”). Strangely enough, directly from Terminal (“...my.app/Contents/MacOS/myapp”) it did run without any complaint. Also, when re-signed using codesign --remove-signature my.app codesign --force --deep --sign - my.appallowed it to be launched from Finder all right. A re-build in Xcode caused again “error -54”. I've resorted to the well-know Windoze-fix, ie., restarting my device. That indeed did help, now I can launch the application from both Xcode and Finder without any dirty tricks... ... but I've found that UIDevice.currentDevice.identifierForVendor did change (I presume most probably this was the root of the launch problems, along with the darned profile), and all the HomeKit uniqueIdentifiers changed as well. What the :( I naïvely thought these IDs never change for the same device and the same application bundle identifier — none of which changed. What did happen, and how to prevent this problem in future? Thanks!

And again, one more question, hopefully you are not completely fed up as of now :) Given the potential problems detailed in https://developer.apple.com/forums/thread/850391?answerId=909802022#909802022, I am reconsidering the behaviour of my home control. Originally I intended to make all the changes needed (essentially, setting thermostats and a couple of power plugs) directly from my application, sending my characteristics the writeValue:completionHandler: messages as needed. Now, I am moving as much functionality as possible to automations. This though leads to a completely new problem — debugging. Far as the control was at my side, I could have easily kept and analysed detailed logs. Now, when the control is at the hub/automation side, I can't be really sure whether all works as intended, whether there's perhaps some subtle bug in the predicates set to the triggers etc. Is there a way to get to a detailed log of what and when and why a trigger (created by my application) did or did not? All I have found for this so far is the lastFireDate property of HMTrigger. Which is far from optimal, but could help a bit; alas it is deprecated and does not work anyway. Is there anything better now? Thanks!

Thank you very much for a detailed information! As for the rationale why I am interested in the changes, see please https://developer.apple.com/forums/thread/849598?answerId=908486022#908486022 above: I need to observe temperatures (and a couple of others) to decide what to do next.

And one more question, if you can bear with me. What's a better approach (better=with lower risk that the app might miss some characteristic value change)? (i) when an accessory is found unreachable (either inside of my accessoryDidUpdateReachability: delegate method, or !acc.isReachable in the each-minute-poll), just mark the state, but do nothing else — keep the polled reads (which would yield errors, but do no harm) and the observations set before up through enableNotification:completionHandler: untouched; (ii) or, when an accessory is found unreachable (as above), un-observe it (enableNotification:NO completionHandler...) and do not poll its characteristics anymore. When later is found reachable again (either accessoryDidUpdateReachability:, or explicitly checking for acc.isReachable in the timed poll), again set observations through enableNotification:NO completionHandler... and start polling its characteristics afresh; (iii) any other way better than the two ones above? Perhaps never unobserve, but when found again reachable, re-observe, which (I hope, am not sure) should be harmless, i.e., any number of subsequent enableNotification:YES completionHandler... for the same HMCharacteristic would do no harm? Or is there some even better approach? The goal is to get as many characteristic value changes as reasonably possible and miss as little as possible. MacOS/Catalyst app, at this moment read-only far as HK is concerned, should run foreground (in the Catalyst terms) essentially all the time. Thanks a lot!

Thanks a lot! I've tested it a bit, and preliminarily it seems that — at least in my current macOS 27.0.1 (26A434) — my Catalyst application is considered foreground, far as the UIApplicationWillResignActive/DidBecomeActive notifications say, whenever it is not hidden. Hidden seems to be about the one case when the app goes „background“, unhidden goes back „foreground“ immediately. Frankly, some surprise for me, for I was sort of used to interpret „foreground“ on a Mac as (essentially and roughly) “has the keyboard/focus“. This is quite different point of view, which alleviates the problem very considerably :) As for the rest I deeply regret to say so far, I have absolutely no experience with VM. I shall find and study some documentation (or, perhaps, if you just happen to have a link to some good howto for Mac at hand, I'd appreciate if you could send it). Thanks again very much; your help is really appreciated!

Thanks, I see. How then do I write my own private application, which is intended to run only on my own devices (namely on one of my Macs), which constantly observes and occasionally changes some HomeKit characteristics? It needs to run for a long time (thus, there can't be the completely absurd good-for-just-a-few-days profile); it needs to run at background at the very least occasionally when I do some work on that particular Mac (the rest of the time it might be at foreground), and normally, that Mac won't be the one where the application has been built (for it's my 24/7 htpc mini, which does not contain Xcode at all). Given the above, there's no potential problem with things like crazy things happen that you can't understand, explain, or debug for I have complete logs of what my app does, and should it begin to look crazy, I can easily disable it in no time flat. Thanks!

I do apologise I've expressed it seemingly not clearly enough. What I can't understand is why the reasons explained above forbid read-only background applications which never ever change anything in HK, regardless the platform size and use case (given the privacy/analysis is of no concern).