4 ms·

As a Mac app developer, you mostly have to go out of your way to install things[1] outside of the app bundle, and you typically don't want to because that's onl

As a Mac app developer, you mostly have to go out of your way to install things[1] outside of the app bundle, and you typically don't want to because that's only extra maintenance you have to do to update / version those files. Most apps don't, and that's why most apps actually are effectively removed when you drag the bundle into the trash. There is already a concept of a "user data" directory for the app, which is determined just like on iOS. There are also other directories for things like caches that the system can clear if it's low on disk space. Of course they could sandbox Mac apps just like on iOS, and Mac App Store apps essentially already work that way. I can assure you, though, that any barrier they put in the way of letting non-App Store apps run however they always have will be met by strong resistance. It's easy to point to this occurrence with Zoom and call it unreasonable, but prompts like what you're describing will undoubtedly disrupt what other people see as totally valid use cases and ruining of the UX. [1] By "things", I mean things like a separate web server process. Apps do store files in app-specific folders like "Application Support" by convention, but not for separate processes.

taftster 7y ago
Thanks for the reply, really good stuff. But what I don't get, why even have an "Application Support" directory at all. There is absolutely nothing of value added to me (as a user) to have files stored there. It's just one more place I have to look to clean up after an application is deleted. So dumb and adds zero value. I'll put my files into Documents (or whatever). And you (as an application developer) put your files in your app bundle directory. That should be the contract for most (all?) user space applications. I agree my prompt idea is generally poor and wouldn't work, it was mostly just for discussion purposes. But the mechanics of a fix for this are in place, rogue daemons that can't be deleted are just unacceptable.
- taftster 7y ago
  [self-reply, sorry] For example, Steam games stored in Application Support. Why?? If I install a game from Steam, it should be installed somewhere in the Steam app bundle. When I delete the Steam app, I delete everything related. So dumb.
  - Twisell 7y ago
    Yeah but this is clearly a special case as Steam is not AppStore distributable AND it is basically an alternative to the AppStore. They clearly could have made other choices and they have their own logic, but that clearly not on Apple role to oversight how their concurrents operate. Antitrust, geeks and media network would instantly gather pitchforks to run on Apple if they even dare to hypothetically mention it.
- moduspol 7y ago
  > But what I don't get, why even have an "Application Support" directory at all. The bundle isn't normally writeable by the app itself. It's generally good security practice to not have your app capable of rewriting what itself can do, and iOS is the same way. You can't write into your app bundle, so anything at all that you want to persist needs to go somewhere else (typically in "Application Support"). That would include mostly anything the app persists to disk that the user didn't explicitly choose, like an sqlite database or something. > But the mechanics of a fix for this are in place, rogue daemons that can't be deleted are just unacceptable. I see where you're coming from, but I think this is really the only balance Apple can strike here. That balance is essentially that non-App Store apps/installers are not sandboxed and can mostly do whatever they want, but Apple can step in with X-Protect (like they did here) and remove anything egregious. They've also moved forward recently with the concept of notarizing, which will still allow apps/installers to do whatever they want, but they'll at least need to be validly signed by a verifiable private key that Apple can then revoke if you (as the developer who signed things with it) do anything egregious. Again--it seems unreasonable in this case, but there are undoubtedly numerous very popular unsandboxed Mac apps that do sketchier things for more valid use cases. Any prompts or restrictions are going to be very disruptive and prompt a new wave of blog and HN posts about Apple trying to kill app distribution outside the App Stores.
  - taftster 7y ago
    Again, good reply thank you. Just to continue a little more... > The bundle isn't normally writeable by the app itself. It's generally good security practice to not have your app capable of rewriting what itself can do, and iOS is the same way. You can't write into your app bundle, so anything at all that you want to persist needs to go somewhere else (typically in "Application Support"). I don't buy this. If you are writing "anything at all" into Application Support, this is no different than writing to the bundle. An executable binary written into Application Support is just as effectively the same thing as an executable binary written into the bundle itself. I don't see a difference between a program rewriting its own code vs. writing an executable into another location. There's no added security and no added user value to writing into Application Support vs. the App Bundle itself. Not arguing with you, I appreciate you explaining the current state and conventions. Thanks for the discussion.
- donarb 7y ago
  Mac OS is a multi-user operating system. Most applications that are installed are global to the system although each user also has their own Applications folder. The Application Support folder resides in the user's Library folder and contains information that the app needs when running for that particular user. Storing information in the .app bundle would affect every user on that computer.
  - taftster 7y ago
    You're saying that an application can't write user specific information into the bundle and sort that out? There's no difference between these two (hypothetical) file paths: /Applications/SomeApp.app/users/taftster/user.specific.data /Users/taftster/Library/Application Support/SomeApp/user.specific.data These two file paths are effectively the same. And when the "global" application gets deleted, I most definitely want all the user data deleted with it as well. And no, I'm not talking about saved output (documents, etc.) that are generated by the application. I'm saying there is just no need for Application Support at all; it adds no value and is just used by convention.
    - comex 7y ago
      > /Applications/SomeApp.app/users/taftster/user.specific.data This doesn't work well for a few reasons: - The Unix permission model makes it difficult to set that up in a way that doesn't allow someone to access someone else's user-specific data, or otherwise tamper with the app. - Some setups sync home directories across the network, so everything related to a particular user needs to be under their home directory. Applications, on the other hand, would be part of the read-only OS image. - If you delete a user in System Preferences, it gives you the option to delete their data or archive it. This works by deleting or archiving their home directory; things would be much messier if their data were scattered all over the disk. - It breaks the concept of an app bundle as a immutable, sealed tree that can have its validity checked via code signature. - If you're searching through your disk to see what's using up disk space, mingling user data with the app itself makes it harder to distinguish between the two. - If the app decides to start storing its data in iCloud and syncing it across devices, it wouldn't make any sense to have it within the app bundle: among other things, you don't want the app's immutable data (i.e. what's in the app bundle today) to count towards your storage quota, and the data may be shared between, e.g., the macOS and iOS version of an app. (Application Support itself is not synced to iCloud, though.) > And when the "global" application gets deleted, I most definitely want all the user data deleted with it as well. Do you? - What if you're just upgrading the app? If you download a new app bundle, drag it into Applications, and tell Finder to overwrite, it will delete everything in the old bundle. - What if you're migrating to a new Mac? You may prefer to reinstall applications manually instead of copying everything, but that doesn't mean you want to lose your data. - Even if you do want to delete the app entirely, does that actually mean you want to lose your data from that app? What if you're planning on reinstalling it in the future? iOS does automatically delete data when deleting an app, but it's not at all obvious to me that that's the best behavior.
- ssalazar 7y ago
  True, for many uses it would be cleaner to write application data to the bundle, even though this isn't commonly writeable. As someone who develops professional apps for Mac, I can thin of a few circumstances where this definitely won't work, or at least will introduce other compromises or require a whole lot of extra effort of developers and/or users. - You want to uninstall/re-install an app without removing the application's data - The application's data can become large (think raw audio or video libraries) and users request to store it in a separate disk - Users want to personally organize the data they make with your app (by project, client, personal/work, etc.), or use it with other apps - Your "installer" is just a zip of the .app bundle and there is no obvious opportunity to assume admin privileges make the bundle writeable Most of these could be solved by having a separate "sandbox" a la iOS or MAS that can be moved or, at the user's option, remain on disk when uninstalling; as far as I know neither system offers these capabilities.
- nottorp 7y ago
  Most of the time, the app's directory in Application Support has the per-user configuration files. And games put their saves there. In both cases, I really don't mind the files staying. I can always change my mind, reinstall the app and resume where i left off.

taftster 7y ago

Thanks for the reply, really good stuff. But what I don't get, why even have an "Application Support" directory at all. There is absolutely nothing of value added to me (as a user) to have files stored there. It's just one more place I have to look to clean up after an application is deleted. So dumb and adds zero value. I'll put my files into Documents (or whatever). And you (as an application developer) put your files in your app bundle directory. That should be the contract for most (all?) user space applications. I agree my prompt idea is generally poor and wouldn't work, it was mostly just for discussion purposes. But the mechanics of a fix for this are in place, rogue daemons that can't be deleted are just unacceptable.

taftster 7y ago
[self-reply, sorry] For example, Steam games stored in Application Support. Why?? If I install a game from Steam, it should be installed somewhere in the Steam app bundle. When I delete the Steam app, I delete everything related. So dumb.
- Twisell 7y ago
  Yeah but this is clearly a special case as Steam is not AppStore distributable AND it is basically an alternative to the AppStore. They clearly could have made other choices and they have their own logic, but that clearly not on Apple role to oversight how their concurrents operate. Antitrust, geeks and media network would instantly gather pitchforks to run on Apple if they even dare to hypothetically mention it.
moduspol 7y ago
> But what I don't get, why even have an "Application Support" directory at all. The bundle isn't normally writeable by the app itself. It's generally good security practice to not have your app capable of rewriting what itself can do, and iOS is the same way. You can't write into your app bundle, so anything at all that you want to persist needs to go somewhere else (typically in "Application Support"). That would include mostly anything the app persists to disk that the user didn't explicitly choose, like an sqlite database or something. > But the mechanics of a fix for this are in place, rogue daemons that can't be deleted are just unacceptable. I see where you're coming from, but I think this is really the only balance Apple can strike here. That balance is essentially that non-App Store apps/installers are not sandboxed and can mostly do whatever they want, but Apple can step in with X-Protect (like they did here) and remove anything egregious. They've also moved forward recently with the concept of notarizing, which will still allow apps/installers to do whatever they want, but they'll at least need to be validly signed by a verifiable private key that Apple can then revoke if you (as the developer who signed things with it) do anything egregious. Again--it seems unreasonable in this case, but there are undoubtedly numerous very popular unsandboxed Mac apps that do sketchier things for more valid use cases. Any prompts or restrictions are going to be very disruptive and prompt a new wave of blog and HN posts about Apple trying to kill app distribution outside the App Stores.
- taftster 7y ago
  Again, good reply thank you. Just to continue a little more... > The bundle isn't normally writeable by the app itself. It's generally good security practice to not have your app capable of rewriting what itself can do, and iOS is the same way. You can't write into your app bundle, so anything at all that you want to persist needs to go somewhere else (typically in "Application Support"). I don't buy this. If you are writing "anything at all" into Application Support, this is no different than writing to the bundle. An executable binary written into Application Support is just as effectively the same thing as an executable binary written into the bundle itself. I don't see a difference between a program rewriting its own code vs. writing an executable into another location. There's no added security and no added user value to writing into Application Support vs. the App Bundle itself. Not arguing with you, I appreciate you explaining the current state and conventions. Thanks for the discussion.
donarb 7y ago
Mac OS is a multi-user operating system. Most applications that are installed are global to the system although each user also has their own Applications folder. The Application Support folder resides in the user's Library folder and contains information that the app needs when running for that particular user. Storing information in the .app bundle would affect every user on that computer.
- taftster 7y ago
  You're saying that an application can't write user specific information into the bundle and sort that out? There's no difference between these two (hypothetical) file paths: /Applications/SomeApp.app/users/taftster/user.specific.data /Users/taftster/Library/Application Support/SomeApp/user.specific.data These two file paths are effectively the same. And when the "global" application gets deleted, I most definitely want all the user data deleted with it as well. And no, I'm not talking about saved output (documents, etc.) that are generated by the application. I'm saying there is just no need for Application Support at all; it adds no value and is just used by convention.
  - comex 7y ago
    > /Applications/SomeApp.app/users/taftster/user.specific.data This doesn't work well for a few reasons: - The Unix permission model makes it difficult to set that up in a way that doesn't allow someone to access someone else's user-specific data, or otherwise tamper with the app. - Some setups sync home directories across the network, so everything related to a particular user needs to be under their home directory. Applications, on the other hand, would be part of the read-only OS image. - If you delete a user in System Preferences, it gives you the option to delete their data or archive it. This works by deleting or archiving their home directory; things would be much messier if their data were scattered all over the disk. - It breaks the concept of an app bundle as a immutable, sealed tree that can have its validity checked via code signature. - If you're searching through your disk to see what's using up disk space, mingling user data with the app itself makes it harder to distinguish between the two. - If the app decides to start storing its data in iCloud and syncing it across devices, it wouldn't make any sense to have it within the app bundle: among other things, you don't want the app's immutable data (i.e. what's in the app bundle today) to count towards your storage quota, and the data may be shared between, e.g., the macOS and iOS version of an app. (Application Support itself is not synced to iCloud, though.) > And when the "global" application gets deleted, I most definitely want all the user data deleted with it as well. Do you? - What if you're just upgrading the app? If you download a new app bundle, drag it into Applications, and tell Finder to overwrite, it will delete everything in the old bundle. - What if you're migrating to a new Mac? You may prefer to reinstall applications manually instead of copying everything, but that doesn't mean you want to lose your data. - Even if you do want to delete the app entirely, does that actually mean you want to lose your data from that app? What if you're planning on reinstalling it in the future? iOS does automatically delete data when deleting an app, but it's not at all obvious to me that that's the best behavior.
ssalazar 7y ago
True, for many uses it would be cleaner to write application data to the bundle, even though this isn't commonly writeable. As someone who develops professional apps for Mac, I can thin of a few circumstances where this definitely won't work, or at least will introduce other compromises or require a whole lot of extra effort of developers and/or users. - You want to uninstall/re-install an app without removing the application's data - The application's data can become large (think raw audio or video libraries) and users request to store it in a separate disk - Users want to personally organize the data they make with your app (by project, client, personal/work, etc.), or use it with other apps - Your "installer" is just a zip of the .app bundle and there is no obvious opportunity to assume admin privileges make the bundle writeable Most of these could be solved by having a separate "sandbox" a la iOS or MAS that can be moved or, at the user's option, remain on disk when uninstalling; as far as I know neither system offers these capabilities.
nottorp 7y ago
Most of the time, the app's directory in Application Support has the per-user configuration files. And games put their saves there. In both cases, I really don't mind the files staying. I can always change my mind, reinstall the app and resume where i left off.