Hi Howard,
I wish I still had the link to a technical note by Apple that stated that refraining from unloading the bundle executable in CFBundles that rely on the ObjC runtime is the way to go pretty clearly. Maybe bx_joscha can help out here as we had a similar issue during the development of the PA WPAPI Shell while I was still working at BX and I kept the link in a comment in the source code somewhere.
Side-effects: Well, it basically leads to an unbalanced retain count so it doesn’t behave differently as if an additional instance was still running when you close the last instance of your plugin. Another side-effect is that the library doesn’t have to be re-loaded and remapped once the first instance is/was open, so new instances should open up faster even if all instances were shut down already. Probably that doesn’t count much in the days of SSD and multiple GHz.
If you’re worried about dumping attacks: You could easily trash/restore sensitive data in your singleton during your implementation of DeinitModule() / InitModule()…but someone could still use a e.g. VM to watch the memory regardless of the problem under consideration.
On whether your bundle should retain itself: That would be one possible workaround to defeat the auwrapper’s final CFRelease(). In case of the CFUnloadBundleExecutable() call there is no remedy so there is no way around patching the auwrapper if you’re working with newer base SDKs.
Hope this makes sense!
Best,
Ray