Hi how could I tell in my OSSystemExtensionRequestDelegate if the request I receive is either an activation request or a deactivation one.
func request(_ request: OSSystemExtensionRequest, didFinishWithResult result: OSSystemExtensionRequest.Result) {
guard result == .completed else {
return
}
// Take different actions depending on activation/deactivation
}
The normal approach here would be to serialise your requests, that is, not issue a deactivate until the activate request has finished and vice versa. If you do that you can then determine the type of request by tracking the last request you made.
Alternatively, you could use a different type of delegate object for each request type.
Finally, be aware that activate and deactivate aren’t your only options. The API was designed to be extended to support other request types, and indeed we’ve added a new one in macOS 12 beta (the properties request) [1].
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Which I didn’t know about until I looked at the header today (-:
Just to jump in here, serializing your activation / deactivation requests has the added benefit of letting your container app know when it is appropriate to run the next request. For example, in the case where a System Extension needs to be deactivated and removed first before a new one is installed, this let's you run the deactivation request from the container app and then run the activation request once the deactivation request has completed.
I think using a different delegate for each request is appropiate for my use case. I don't think serializing will work for me because my container app does not have a gui and is only used via command line therefore it is only run when I want to activate or deactivate the extension. Thanks to both btw :)
The normal approach here would be to serialise your requests, that is, not issue a deactivate until the activate request has finished and vice versa. If you do that you can then determine the type of request by tracking the last request you made.
Alternatively, you could use a different type of delegate object for each request type.
Finally, be aware that activate and deactivate aren’t your only options. The API was designed to be extended to support other request types, and indeed we’ve added a new one in macOS 12 beta (the properties request) [1].
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Which I didn’t know about until I looked at the header today (-:
Just to jump in here, serializing your activation / deactivation requests has the added benefit of letting your container app know when it is appropriate to run the next request. For example, in the case where a System Extension needs to be deactivated and removed first before a new one is installed, this let's you run the deactivation request from the container app and then run the activation request once the deactivation request has completed.
I think using a different delegate for each request is appropiate for my use case. I don't think serializing will work for me because my container app does not have a gui and is only used via command line therefore it is only run when I want to activate or deactivate the extension. Thanks to both btw :)
my container app does not have a gui and is only used via command line
I want to be clear that this is not a setup that we support. See this post for more.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
My app runs on macOS, I am currently deploying it to the users via a pkg that is installed through the mdm. I can't use a GUI, I understand what you are saying but I really see no other way to do this.
I completely agree with Quinn here that you should avoid load and activating a System Extension from a command line tool at all costs. The reason for this is that you may be able to activate the System Extension from the command line fine, but I suspect that you will run into problems when you want to deactivate it or update it and that is where having a regular container app will make all of the difference here.
