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

P.S. Just for the record, in future I shall need to change a couple of things, namely the setting of the thermostat which drives the main heating; switching a couple of power outlets which control some auxiliary heating units on/off. At this moment though, it is a far future and not my pressing concern; that is the observing and analysing the current state, effectively, far as HK is concerned, read-only.

Thanks again for all the detailed and very interesting insights! Nevertheless I am afraid I do not quite get it. Seems to me (probably due to my misunderstanding) that none of these concerns should apply to my application, which never ever tries to set or change anything in HK. All it does is reading the characteristic values; and even that just since waiting for the update notifications is unreliable, as detailed in https://developer.apple.com/forums/thread/849598. Based on this and my (probably mistaken) understanding of what you wrote, there should be absolutely no reason not to allow my app to work seamlessly in the background. What do I miss here?

Thanks a lot, interesting! I do apologise for stupidity: I've completely forgot there is the foreground-only limitation. Sigh. As for [1] (I hope you enjoyed the dinner :), and), correct me please if I am wrong, but I believe it is so for privacy concerns, so that no 3rd party app can analyse what I do with my accessories for evil goals. Nevertheless this is an application I wrote myself to be run by myself for my own completely benign (and even if not, it's my problem) goals in my own home (still the same one of https://developer.apple.com/forums/thread/849339), thus of course I don't mind it analyses my behaviours (it is its very purpose in fact). Compare please also closely related comment https://developer.apple.com/forums/thread/849288?answerId=907772022#907772022. I've added a request for the background support to my feedback ticket FB25066661. If you can see any way to overcome these limits (both the background and the ones caused by the profile, detailed in the thread linked above) in this particular case (my own private app run in my own home only), I'd be grateful for any advice.

Thanks a lot for all the support! And if you can bear with one more question relevant to this thread: is there a way to find the particular Matter cluster/attribute IDs which match a HomeKit characteristic? To better explain the question, I wonder where and how to get values for “???” in this code: HMCharacteristic *chr=...; // for any reason, I'd like to check the chr.value “mirror” Matter-side HMService *svc=chr.service; HMAccessory *acc=svc.accessory; MTRDeviceController *mtrC=[MTRDeviceController sharedControllerWithID:acc.home.matterControllerID xpcConnectBlock:acc.home.matterControllerXPCConnectBlock]; MTRBaseDevice *mtrD=[MTRBaseDevice deviceWithNodeID:acc.matterNodeID controller:mtrC]; [mtrD readAttributesWithEndpointID:svc.matterEndpointID clusterID:??? attributeID:??? params:nil queue:... completion:...];