Feasible for Indigo to control native Apple HomeKit devices?

Apple WWDC 2020 announced (finally), that macOS apps will be able to control HomeKit devices in the upcoming Big Sur release.

Does this mean it is now technically feasible for Indigo to interface with HomeKit devices in a fully Apple certified way?

I would LOVE to be able to use Indigo as essentially a more advanced rules engine for HomeKit automations, with or without Python.

This would be complementary and s very different than using HomeBridge to bring Indigo and 3rd party devices INTO HomeKit.

Apple is slowly improving HomeKit every other year or so, but the Apple automation, with it's heavy emphasis on personal shortcuts rather than server-based automations for more advanced scenarios is woefully inadequate. Combining HomeKit with Indigo would be a very powerful best-of-both solution!

From Jay another topic

I did notice that on one of those large Big Sur slides about capabilities HomeKit was listed. We'll be monitoring what exactly that means as we can find more details. Not holding my breath of course given their refusal to license software bridges, but one can always hope.

TL;DR; "We shall see"

[jay (support)]

Apple WWDC 2020 announced (finally), that macOS apps will be able to control HomeKit devices in the upcoming Big Sur release.

We'll see. Right now, it requires the Mac app to use Catalyst on Big Sur, and it's unclear what limitations there will be to apps running in this configuration (from both a technical and licensing perspective - for instance I'm not sure that the license allows you to distribute Catalyst apps outside of the App Store which is something we can't do given our architecture without a HUGE rewrite). It is definitely something we'll keep an eye on however, perhaps we'll be pleasantly surprised.

A developer of HomeKit apps just told me it is for Catalyst apps, but if you disable system integrity protection (SIP) regular Mac apps which do not have to go through the Apple store, can use the new API's

[jay (support)]

A developer of HomeKit apps just told me it is for Catalyst apps, but if you disable system integrity protection (SIP) regular Mac apps which do not have to go through the Apple store, can use the new API's

Interesting. Of course, we would never build a feature that required users to disable a fundamental piece of macOS security on their Mac (which is likely an unsupported configuration from Apple's perspective). But it is interesting information.

Anyone have a link to the WWDC session this was discussed? I just looked, and couldn't find anything related to HomeKit.

I wonder how hard it would be to do an "Indigo Companion" app for the Mac App Store that would bridge between Indigo and HomeKit. That could be a Catalyst app. I used to do a fair amount of Cocoa programming, and might be interested in a project to learn Swift.

The only thing to be careful of is how Catalyst apps on Mac are handled when switching away from them - whether they keep running or are suspended. There may not be a problem, but just highlighting the one thing that might trip up trying to write a "background task" as a Catalyst app instead of a native macOS app.

[jay (support)]

Anyone have a link to the WWDC session this was discussed? I just looked, and couldn't find anything related to HomeKit.

I couldn't find any specific discussion of HomeKit on the Mac. The closest I found was in the What's New in Catalyst session, HomeKit was shown on a slide as being accessible through Catalyst. But no specific verbal discussion/mention.

I wonder how hard it would be to do an "Indigo Companion" app for the Mac App Store that would bridge between Indigo and HomeKit. That could be a Catalyst app. I used to do a fair amount of Cocoa programming, and might be interested in a project to learn Swift.

If Apple would approve it (we've discussed that idea a bit as well). My guess is that given what the app's intended purpose would be (to circumvent Apple's policy of no software bridges) it most likely wouldn't be approved, or if it was then it might be pulled at any time after that. But, certainly, putting the effort into building something that might not be able to be distributed is not really something we're interested in (we have too many other higher priorities).

We'll watch to see if someone else attempts it. And we'd love to see someone from our ecosystem lead the charge!

[jay (support)]

The only thing to be careful of is how Catalyst apps on Mac are handled when switching away from them - whether they keep running or are suspended. There may not be a problem, but just highlighting the one thing that might trip up trying to write a "background task" as a Catalyst app instead of a native macOS app.

The Catalyst session had some discussion of this, but what wasn't clear to me is if/how a catalyst app could continue to run in the background state. There was a discussion of catalyst apps behaving more like the iOS model, but of course that's not how you'd want an app whose main purpose is to run in the background to function.