When we try to distinguish mobile users from other users we look for the presense of either kODAttributeTypeOriginalNFSHomeDirectory or kODAttributeTypeOriginalNodeName. The help for both those keys indicate they are used for "local account caching" and they work fairly reliably for our use. You need to test for both since some users may only have one and not the other.

Does the ODRecord method isMemberRecord:error:, for determining group membership, handle nested groups? The documentation for the method is silent on that point. I'm wondering if I should change our code to use mbr_check_membership instead of isMemberRecord:error:.

In reply to your followup question, if you use the command line tool xcodebuild (see man xcodebuild), to build your Xcode projects, you can override build settings on the command line. We use this for our builds. In the project we set the CODE_SIGN_IDENTITY to "Mac Developer" for both Release and Debug builds so the Developer ID certificate is not needed on normal development computers. When we actually want to build the final product we use xcodebuild and set CODE_SIGN_IDENTITY="Developer ID Application" on the command line. There may be a few other build settings that need to be overriden at the command line. If I recall correctly we needed to explicitly set CODE_SIGN_INJECT_BASE_ENTITLEMENTS=NO and OTHER_CODE_SIGN_FLAGS="--timestamp" to get notarization to work.

Check if there is a copy of your kext in /Library/StagedExtensions/Library/Extensions and what permissions it has. Last time I work with kernel extensions the system would load a copy of the kext into that folder but would not modify the permission on that copy if you changed the permissions on the kext in /Library/Extensions. Incorrect permissions on that copy would result in permission errors loading the kext. If I recall correctly changing the permission on the copy in StagedExtensions was a pain since that folder was protected by SIP (You need to boot into recovery mode and delete the copy in StagedExentions from there).

I would also like to know if there is a solution. We have the same issue. Our product is rather complex with an application, a daemon, an agent plus some other components (like an authorization plugin) so it is just simpler to install via a package (built with productbuild --distribution). We have added the AssociatedBundleIdentifiers key to the launchd plist for both the daemon and agent but they still show under our developer name and not the application in System Settings after installing. It is only after running sfltool resetbtm and restarting that the daemon and agent show with the application name. I have tried using /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister to register the application in its postinstall script (which executes before the daemon or agent gets installed) but that didn't help.