Thanks a lot! As for simulating an accessory on iOS isn't really all that useful I guess in my specific case this would not be a big problem, for I can either — for the time when I actually need to observe those automations, which would be limited to days, weeks at worst — keep my app foreground on an iPad; or simply run my application on a Mac, where there are no background-execution limits at all, far as I know. Thus, unless I overlook some other hurdle, this would be OK. I am a bit wary of the “large-scale projects” though: for me, this functionality is not extremely important (rather “just a bit helpful”), and if the only way to achieve it would mean to write, test and maintain heaps of complex code, I can do without (e.g., for automations triggered by HMCalendarEvents I've already wrote a tool which reads the fireDateComponents and then simply keeps track of the time; whilst there of course could be a small difference betwixt the time the trigger assumed to fire and the moment it actually did, usually this makes no real problem for me). Is there a documentation or even a public sample code for this anywhere, which i could check? If not, well I guess I'll focus on other and more important tasks for the time being :) Thanks again!

Thanks a lot, I've added the info to the ticket. (Does not seem to me to be a bug, rather a feature request, or a “suggestion” type feedback. That's probably quite unimportant :)) Incidentally, not really all that different than what HAS (HomeKit Accessory Simulator) does is there a public API which would allow me to do (essentially) the same, namely, to create a HomeKit pseudo-device (or bridge) purely by software in my application code? I've tried to find such an API, but so far, in vain. The goal here is, I would like to be able to keep track in my application of when/whether at all some HK automations did actually fire. If I added such a pseudo-device of mine to the appropriate scene (action set), I presume it would get the characteristic-change event, and thus I'd get the desired information this way. (I happened to notice that there is a software out there which for a similar goal uses shortcut-based automations which open specific URLs. I don't like that approach myself, and if it happens to be the only possibility to achieve the goal, I've decided to do without.)

Thanks a very big lot for the detailed explanation! All clear now. (I wonder if it might be perhaps worth the effort to add this information to the standard HomeKit documentation.)

Kevin, thanks for a quick response! the HomePod (and derived sensors) aren't actually "HomeKit Accessories". Aha, I see. I (along with the OP, it seems) got misled by the fact they are presented through the Home application (but of course, I can see there's no reason why Home could/should not use different and probably private APIs to communicate with these, aside of its primary task to present and control the HomeKit). In that case I quite appreciate that presenting the HomePod temperature sensor through an appropriate HomeKit API, albeit technically possible for sure (perhaps just at the software level, without a need to change the underlying protocols Pods actually use to communicate), might well be complicated enough not to be worth implementing. What's the bug number? Let me see... FB21802284 what do you actually want to do with these sensors at the "app" level Myself, I'd like to keep track of all the temperature sensors in my home to implement a smarter temperature control. (I've checked a number of HomeKit-enabled thermostats and so far found none which would fulfil my needs, so I am about to write one myself as a HomeKit application, primarily for my own usage — at this moment I seriously doubt the result would ever make it to AppStore.) did you include those details in the bug? Oh, I did not; I regret to admit I had considered “whatever one might want to do with all the other HomeKit temperature sensors should be possible with the one in HomePod just as well” as self-evident as not worth expressing explicitly. Sorry for that. Should I add essentially the contents of this reply to the ticket? Or just a link to here? What's better? Thanks!

I might be wrong, but I understand Apple intentionally hides Pods (and ATVs) from the public API. Whilst there might be a point in doing that with more sophisticated characteristics for privacy and safety, with the temperature sensor it's patently absurd :( I've just filled a feature request with Apple. The more of us does the same, the better chance we get the access.

P.S. As for the privacy concerns — for the moment, I write the code just for myself; I am struggling with some weird behaviour of an Eve Thermo when controlled through automations... well no point to detail here I guess, completely irrelevant. If it ever grows into a publicly available application (which I very seriously doubt), I'll of course check these concerns in detail (starting with the primary question whether it is all right to record the HK characteristics at all). Offhand I'd think the user should be able to see which of his devices the values were recorded on (by the very device name he assigned it himself), but I admit I did not think it through much and might well be missing some important point. Anyway, for the time being, it's rather at the moot side :)

Thanks a lot!

Thanks, Quinn! What specific information are you looking for here? Well ... information of the device and operating system the code really runs on would be sort of nice. It's pretty weird to ask the code which runs on Mac for the device it runs on and get “iPad”. I could understand this when running as “Designed for iPad”, in which case the code might really need to be lied to, for it was designed for iSomething originally. But in the Catalyst mode, where the code is designed for Mac, it seems really at the strange side. And what do you plan to do with that information? At this moment, I just wanted to save it for possible further interest, along with other things my application stores (see please below). Currently the only practical part would be to determine whether I can store my data into any file in any folder (as on Mac), or whether I should stick with Application Support sub-folders (as on iWhatever). Given that, I’m not sure Mac Catalyst is your best option Well the main purpose of my application is to observe the characteristics of some HomeKit devices and save their value changes along with timestamps. To these stored data I wanted to add the information on which device this happened, purely for possible further interest (most probably nothing more than “recorded on XXX” :)) Do please correct me if I am wrong and if I overlook something of importance, but I understand there is, triple alas, no HomeKit API available amongst the native macOS APIs. Thus — far as I got it right — to write a macOS HomeKit application, I am, alas, forced to stick with Catalyst.

Thanks again :) Test please at your leisure at your side this project: https://ocs.cz/CD/catalyst_test.zip Note: my application is intended primarily for macOS, should be able to run also with lower priority, essentially as a side-effect, on iPadOS. Thus I believe “Catalyst” to be a much better destination than “Designed for iPad”, or am I wrong here?

Thanks, Kevin. Well yes, I'm bitterly aware of that — just lately I've bumped to the ugly problem that there's no way for us lowly 3rd parties e.g., to create a trigger-owned scene. It's wrong, you know — would make sense for privacy- or security-related APIs, but... well, this is no place to discuss this (and of course, I completely appreciate it was not your decision :)) As for the 3rd party app (whose creator I won't reveal for obvious reasons) ... hmmm, given your answer that the API is not public (alas!), I've re-tested a couple of times, and it seems it actually sometimes works, sometimes it does not, rather randomly. I guess they hacked-out some unreliable undocumented way to do that, most probably. Reminds one of https://openradar.appspot.com/7044974 sort of :)

Thanks! If I get the “target” thing right, it says “My Mac (Mac Catalyst)”. There's no other option; the selection looks like this ... hm, there's no option here to paste a pic? Darn, like this: https://ocs.cz/CD/run-options.jpg I'll prepare the test project soon, pbbly in a couple of hours, am a bit at the busy side :)

The runloop-based approach so far (up to iOS17) did work for long years without one single problem. If there indeed is a hardware were it would have failed with older iOSen, then it seems none of our many clients ever used that hardware. Weird. The API which needs to show an alert and return its result is multi-platform and I can't really refactor it. Hmmm... I guess I might be able to run it completely in a background thread, for all the other callbacks which do not have this problem use performSelectorOnMainThread or something like that, and for this one just let the background thread wait on a semaphore or another kind of lock, run the alert on the main thread normally, and when done, let the background thread go on. Offhand I guess it should work. Nevertheless it seems an indecent heap of work for such a triviality. Apple's UI frameworks did support such things from the first moment they ever existed, compare please the original NSRunAlertPanel (and current -[NSAlert runModal) APIs. It seems really extremely weird that i(Pad)OS would itentionally not support such a basic functionality :(

https://ocs.cz/CD/testModalAlert.zip

Thanks for the elaboration. As a "side bar" to your original questions, why is your login item running like this at all? Mostly for historical reasons (the applications are pretty old, 10+ years, and underwent many changes meantime). We are considering a serious refactoring, but now we need to solve the problem quickly. Interaction in your SA cause UI activity in your LI and, more importantly, your LI is attempting to activate your SA. Quite. Unless/until we refactor, we simply have to, for clicking into the LI window must bring up the SA menu. Which works well and completely reliably when the menu is not hidden. When it is hidden though, for some weird reason the very menu bar which would normally be visible does not show when the pointer goes up. That's the problem we need to solve now. When someone uses your app and another app unexpectedly steals focus... ... is not what happens here. In our case, the other app does not “steal” the focus and it is not unexpected. The focus is given to it willingly, it is as expected, and both the GUIs are written so that it works properly. We never encountered any problem like accidentally entering text into the wrong app or so, and never we need to switch back to the original app: as mentioned above, both the applications are written to work like one from the user's perspective. Our problem is quite different: while the SA is the menu owner and the menu is hidden, it (occasionally) does not show when the pointer goes up. I strongly suspect that the issues you're seeing only happen when another app is involved in the activation process Not really. The only involvement of another application is that it is active (both menu owner and frontmost) before the problem occurs. not if you first activate your SA directly (for example, but clicking on the dock). Quite, that's not our current problem. It happens when SA is activated through LI, as already outlined above: another application is both menu owner and frontmost (which is the only involvement of any other application) the LI's window title is clicked (seems that when the window content is clicked, the problem occasionally happens, but when the title bar is clicked, it always happens; weird) this makes LI frontmost, but not menu owner (since it is a login item which does not mess with its presentation and thus can't have menu) therefore, LI activates SA, so that it becomes the menu owner (note SA does not steal focus; LI gives it willingly) then in the final step, SA activates LI to make its window the frontmost one (again, LI does not steal the focus; SA gives it willingly). Now, LI is frontmost, SA is the menu owner. If menu is not hidden, the SA menu is at this moment shown properly. Alas, if the menu is hidden and at this moment the pointer goes up, nothing happens. What could we do to make sure that the SA menu occurs? Thanks.

Kevin, thanks a lot for a quick answer! What does this cooperation actually involve? The applications communicate (through DO) and perform tasks as needed. Typically, the standard application (SA) sends requests to the login item (LI), which contains most of the GUI, whenever the user selects a menu item. Is it just that they both run at the same time When the problem with non-functional hidden menu happens, they do. Sometimes only LI runs (when the user quits SA), but of course, there's no menu in this case and thus no problem either. they're cooperatively interacting with the same underlying data In fact the data is not shared; LI manages it, and if need be (e.g., to validate menu items), it sends the current state to SA through DO. To be frank tho, I can't really see how this could be relevant to the problem that the menu of SA does not unhide properly when SA is the menu owner and the pointer goes up. are they directly manipulating each other interfaces Not sure what does this mean :( The apps communicate through DO, which affect both the GUIs: when the user selects a menu item in SA, it (usually, not always — e.g., About... is solved completely SA-side) sends an appropriate request to LI, which updates its GUI accordingly LI validates menu items for SA based on the current data and application state None of this though actually happens in the simplest case when the problem happens. No menu (and essentially no SA/LI functionality) is really used. The typical scenario is LI runs and does nothing SA is launched, connects to LI and asks it to show the main window, which LI does (now, SA is menu owner, LI frontmost, all works well; when the pointer goes up, SA menu shows all right) SA is deactivated. Another application (e.g., System Settings, Console, Xcode, whatever) is frontmost/menu owner. When the pointer goes up, the menu of the other app shows LI is re-activated e.g., by clicking to its main window title bar. When it gets didBecomeActive, it checks whether SA happens to be the menu owner, and if not, it activates SA (to make it menu owner) When SA gets didBecomeActive, it activates LI (to make it frontmost) Now, SA is the menu owner and LI frontmost. Nevertheless, (pretty often) when the pointer goes up, nothing happens — the SA menu is not shown. does your main app always operate as a standard application Yes, SA is normal application and never changes its presentationOptions (nor does other tricks like that). Which process logged that state? I wrote a very simple independent application which does nothing but - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { NSWorkspace *wsp=NSWorkspace.sharedWorkspace; NSLog(@"menu owner: “%@” front: “%@”", wsp.menuBarOwningApplication.localizedName, wsp.frontmostApplication.localizedName); [self performSelector:_cmd withObject:nil afterDelay:5]; } I keep it running and observe its log. Do you have logging from both process at the same time so that you can see what they both "thought"? Yes, aside of the above, both LI and SA happen to log when they get didBecomeActive, and those logs show that the steps 4 and 5 above do happen all right.