The application will be used locally and privately only. Thus, the provisioning is definitely not needed,
As a quick aside, the issue you're having is not accidental. The users HomeKit configuration is considered fairly sensitive both for privacy reasons (they could be used to identify users) and general security/disruption risk (using HomeKit to disrupt the user). Requiring provisioning like this helps mitigate these issues, both by limiting what apps can do and by preventing unsigned code from using these APIs.
How to write a macOS (no need for i/Pad/OS at all) application which supports HomeKit without provisioning?
I don't see anyway to do this. The problem here is that this isn't actually about the signing itself, it's the homed is checking for that entitlement when your app launches and won't communicate with your app if it's not there. Note what Xcode is doing here:
Just to wrap loose ends, I checked that indeed the darned profile is a requirement for HomeKit: if I remove the capability from the target, macOS Provisioning Profile immediately turns to None Required. Soon as HK is added back, it's again at Xcode Managed. Sigh.
...isn't the actual problem. You could use "codesign" to manually sign your app and I think it would run fine... except that none of HomeKit's APIs would work. Xcode is just altering it's UI so that its harder to create a build that won't work.
You could bypass that check using the "nuclear option" Quinn talked about in the other thread, but the problem is that the security implications of that are very bad, as you're basically disabling the systems ability to validate all code.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
