3 ms·

FWIW I am not sure how dragging the .app to the trash would uninstall other things installed by the app. If I drag photoshop to my trash instead of using Adobe

FWIW I am not sure how dragging the .app to the trash would uninstall other things installed by the app. If I drag photoshop to my trash instead of using Adobe’s uninstaller, I’m pretty sure that leaves Creative Cloud junk running on my machine. Now, zoom did mess up by not having a proper uninstaller shipped with their app, I think a lot of other Mac apps do fail at this too though.

fastball 7y ago
Yes, as is, dragging apps to the trash cannot do that. Apple should probably implement an API that allows developers to tell the OS what other stuff should be removed if the app is dragged to the trash. To prevent devs from removing other people's stuff, you could require that the subcomponents need to be cryptographically signed with the same key as the main app bundle. edit: or, even simpler solution (potentially) - have a fairly basic API via which devs can install subprograms elsewhere on the system. When you use this API to install something, it adds the thing installed to an OS-level registry. When the user drags the app to the trash, the OS checks the registry and removes anything that was added by the application.
- javagram 7y ago
  I think your edit is describing a package manager :D Or the Mac App Store... (But yes, it would be good if this feature were available for apps that can’t come through the App Store)
- comex 7y ago
  The real solution is to not install anything outside of your app bundle in the first place. In this case, instead of sticking a plist in ~/Library/LaunchAgents, you can use an API to add a login item, pointing to a helper .app inside the main app bundle: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLoginItems.html https://developer.apple.com/library/archive/documentation/Ma... Then the system will automatically disable the login item if the app is removed. Edit: It seems like Zoom was using a login item, but using the "shared file list" API instead of the newer (but still dating back to 10.6) SMLoginItemSetEnabled. An alternative is to just make your daemon check for itself whether the main app has been removed, and delete itself if so.
- olliej 7y ago
  No, on OS X there is literally no reason to move anything from out of your application bundle. Copying the server out of the application bundle had one effect: it makes removing the app not remove the server. There are apis to register for launch, there are launch service plists, etc which all correctly, and by default handle the user deleting your app bundle. There are already “cryptographic mechanisms to detect modification of your app”, it’s the platform code signing mechanism, and Xcode will produced signed binaries by default. Finally, your post comes across as saying that you believe leaving the server was unintentional due to lack of APIs (ignoring that removing an application is a sign that the user doesn’t want your app to run any code). Their “unintentionally” persistent server explicitly check for the app being removed, and if it had been, would redownload it and install it without user consent.
xenadu02 7y ago
It is perfectly supported to leave daemons in your app’s bundle. There was no requirement to install the executable to a different directory. They appear to have done it to ensure the web server could silently reinstall the app after the user deleted it.
olliej 7y ago
The server was deliberately left running: if it was unintentional it would just error out if Zoom had been removed. Instead it downloaded and installed the client again. That’s fairly clearly designed to override the user’s attempt to remove the software, and is exactly the kind of thing malware does. There is a real problem many (often primarily windows) apps have this bizarre desire to “install” content randomly scattershot across the OS. There is no reason to do this on Mac OS. OS X happily supports multiple binaries and services per bundle. If you write an app that needs an uninstaller on OS X, and you aren’t needing to install some kind of driver, your app is doing things it should not be doing, and does not even need to do.

fastball 7y ago

Yes, as is, dragging apps to the trash cannot do that. Apple should probably implement an API that allows developers to tell the OS what other stuff should be removed if the app is dragged to the trash. To prevent devs from removing other people's stuff, you could require that the subcomponents need to be cryptographically signed with the same key as the main app bundle. edit: or, even simpler solution (potentially) - have a fairly basic API via which devs can install subprograms elsewhere on the system. When you use this API to install something, it adds the thing installed to an OS-level registry. When the user drags the app to the trash, the OS checks the registry and removes anything that was added by the application.

javagram 7y ago
I think your edit is describing a package manager :D Or the Mac App Store... (But yes, it would be good if this feature were available for apps that can’t come through the App Store)
comex 7y ago
The real solution is to not install anything outside of your app bundle in the first place. In this case, instead of sticking a plist in ~/Library/LaunchAgents, you can use an API to add a login item, pointing to a helper .app inside the main app bundle: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLoginItems.html https://developer.apple.com/library/archive/documentation/Ma... Then the system will automatically disable the login item if the app is removed. Edit: It seems like Zoom was using a login item, but using the "shared file list" API instead of the newer (but still dating back to 10.6) SMLoginItemSetEnabled. An alternative is to just make your daemon check for itself whether the main app has been removed, and delete itself if so.
olliej 7y ago
No, on OS X there is literally no reason to move anything from out of your application bundle. Copying the server out of the application bundle had one effect: it makes removing the app not remove the server. There are apis to register for launch, there are launch service plists, etc which all correctly, and by default handle the user deleting your app bundle. There are already “cryptographic mechanisms to detect modification of your app”, it’s the platform code signing mechanism, and Xcode will produced signed binaries by default. Finally, your post comes across as saying that you believe leaving the server was unintentional due to lack of APIs (ignoring that removing an application is a sign that the user doesn’t want your app to run any code). Their “unintentionally” persistent server explicitly check for the app being removed, and if it had been, would redownload it and install it without user consent.

xenadu02 7y ago

It is perfectly supported to leave daemons in your app’s bundle. There was no requirement to install the executable to a different directory. They appear to have done it to ensure the web server could silently reinstall the app after the user deleted it.

olliej 7y ago

The server was deliberately left running: if it was unintentional it would just error out if Zoom had been removed. Instead it downloaded and installed the client again. That’s fairly clearly designed to override the user’s attempt to remove the software, and is exactly the kind of thing malware does. There is a real problem many (often primarily windows) apps have this bizarre desire to “install” content randomly scattershot across the OS. There is no reason to do this on Mac OS. OS X happily supports multiple binaries and services per bundle. If you write an app that needs an uninstaller on OS X, and you aren’t needing to install some kind of driver, your app is doing things it should not be doing, and does not even need to do.