Hacker News new | past | comments | ask | show | jobs | submit login

They are basically solving a self-inflicted problem. The real issue there is the fact that macOS doesn't provide a standarized way to completely uninstall an app.





It does provide a standard way to uninstall an app: drag it to the trash can.

I would say that what Zoom did was have their app intentionally install malware that bypassed this normal uninstall.

I do think that it would be great to have a more thoroughly sandboxed idea of what an “app” is on the desktop, though.


Snapd, flatpak, appimage all can do this on Linux. Even docker/singularity can sort of do the same for some, if you pass through all the necessary devices and sockets from the host. When you remove the app (or container) all the files it brought with it or created during runtime are now gone.

Even the regular Linux package managers like apt, dnf, pacman track which files were installed by which packages, so they can be removed when the package is uninstalled. The downside to these is they don't track files created at runtime so a lot of the config or cache files created can be left over if the package itself doesn't remove them.


A sandboxed macOS app would offer similar protections as what snapd, flatpak, etc provide on Linux.

> Even the regular Linux package managers like apt, dnf, pacman track which files were installed by which packages, so they can be removed when the package is uninstalled.

Technically speaking, Zoom could have abused dpkg post-install scripts, or pulled similar tricks, to install their malware server and leave it behind after the package was removed. Linux distributions aren't invincible to these shenanigans.


> Technically speaking, Zoom could have abused dpkg post-install scripts, or pulled similar tricks, to install their malware server and leave it behind after the package was removed. Linux distributions aren't invincible to these shenanigans.

This is correct, but such a package should not make it into the distribution's package repositories.


And likewise Zoom didn’t make it to the AppStore...

The install scripts in rpm/deb can do all sorts of stuff that doesn't get tracked/reversed. There are package linters to help detect some of this buts it's largely a faith based endeavor either way.

> all the files it brought with it or created during runtime are now gone.

How would this work with apps that create things that a user would expect to persist, like downloads (kept after uninstalling a browser) or office documents (kept after uninstalling the office suite), or media production apps, IDEs, etc.?

It could have some rule like "let it be if it's in the user home directory" or "only remove stuff in these system directories" but it seems kind of fragile, like what if you use a text editor to create a system config file and then uninstall the text editor?


> How would this work with apps that create things that a user would expect to persist, like downloads (kept after uninstalling a browser) or office documents (kept after uninstalling the office suite), or media production apps, IDEs, etc.?

I can't see how it would. Making the uninstall remove all the files created at runtime is the wrong solution to a real problem, which is better solved by forcing all packages to be self-contained and making their installation an idempotent operation. If we're able to do this, there's not much to clean up afterwards, and we ensure there's no privileged malware left (such as Zoom's one) as both the package install scripts and runtime would be able to run unprivileged.

I use NixOS, an OS built on Nix, a functional package manager that does this, and being able to set my system to a known state without going through the steps of formatting and reinstalling is really nice.


Such a system would not allow the application to write to any place outside of its sandbox or a designated user document volume. The system can't be touched. If you want to create a system config file, you are responsible to break the glass and move it and then all bets are off.

I can imagine an allowance to "break the glass" within the context of the app so long as the app invokes an obvious-to-the-user common dialog (like the typical file>save / file>open / choose-a-folder), but there would be no "breaking the glass" in an invisible / programmatic manner. That sounds quite nice.

That’s exactly how the macOS AppStore apps work. Your app gets permission only to those files that were intentionally opened by the user via the system open dialog.

Malware intends to harm you, with intent to steal or destroy or hold hostage your information, data, and computing resources.

Does the ZoomOpener app have malicious intentions towards you, your computing resources, or your data? Not just “could it be unintentionally exploited” - note the unintentionality! - but specifically “this was intended to harm”.

If not, then you need to reconsider your use of the word “malware” - a word shortened from “malicious software” - and find a better way to describe software design patterns that aren’t compatible with “drag it to the trash” but also aren’t intended to harm.

Adobe Creative Cloud, any $$$$ audio software DRM, and HP printer drivers all use similar patterns of “can’t just drag it to the trash”, and are all similarly annoying to remove - but they are not malware, any more than this ZoomOpener is.


>The real issue there is the fact that macOS doesn't provide a standarized way to completely uninstall an app. reply

And Windows does? Uninstallers are completely at the behest of application developers. No consumer OS but iOS actually provides any sort of true app level sandboxing.


> And Windows does?

Control Panel “add and remove programs” usually works?

There’s no equivalent on Mac. Yes, dragging the app to the trash is a thing but that leaves behind content in ~/Library/caches, ~/Library/Application Support, and ~/Library/Preferences . It’s been somewhat of an issue with Mac ever since they first put a hard drive on the original ones back in the 80s...

Edit: I literally cleared several GB of junk out of my application support folder left behind by just one app today, so it’s fresh on my mind. OmniDiskSweeper is great for finding this stuff.


Control Panel “add and remove programs” usually works?

All that does is launch the app’s uninstall process. The app is free to leave whatever crap it wants to on your system.


OK but on Mac, dragging the app to the trash doesn’t launch an uninstall process, so it will always leave the crap behind.

Your app is suppose to be self contained....

Then what in the world is the huge Application Support folder for?

And why is it filled with stuff from Apple programs?


The point is, all of those files are generally still left behind on Windows as well. Uninstalling a program in Windows is roughly equivalent to dragging it into the trash in macOS.

> all of those files are generally still left behind on Windows as well.

Citation needed. That was the case in the 90s, these days most apps (device drivers aside) uninstall fairly cleanly with only settings/configurations stored in the registry still resident afterwards. Startup programs remaining after an uninstall is straight-up a bug.


> these days most apps (device drivers aside) uninstall fairly cleanly

Citation needed.


Windows installers are declarative and data-driven. An installer script does not simply use the file copy operations a usual app would use during runtime.

Instead an installer is driven by a number of "database" tables that specify the installer actions in a declarative way.

There are several benefits to this approach. The declarative actions are reversible and the uninstall actions can thus be inferred automatically. This removes the burden on install authors to create a script to reverse the install operations.

This includes registering services/daemons (will unregister on uninstall), registering protocol handlers, filetype/program associations, desktop shortcuts etc.

The declarative approach also allows the installer to roll back in case of an error during installation. This even includes "undeleting" files that were deleted. (https://docs.microsoft.com/en-us/windows/win32/msi/rollback-...)

The author of the install script can (non-Store installers) escape and execute a specific program during the install process. This is rarely needed, though. So the default is that the uninstaller will uninstall by completely reversing the install actions.

https://docs.microsoft.com/en-us/windows/win32/msi/windows-i...


No, dragging an app from "Applications/" into Trash is equivalent to dragging a program folder from "Program Files\" into Recycle Bin. Actually that's exactly what it is.

Have you checked ProgramData, Local, and Roaming recently? Or your registry?

Also, Add/Remove only works if the program adds itself there. And remove only works if the program added an uninstaller. Also, even then, it still leaves crap behind.


At least there is a convention to have an uninstaller. If you create the installer through conventional toolboxes the uninstaller comes for free. That's how most Windows programs have both.

macOS has the same convention. Conventional toolboxes are mostly not-Windows and not-Microsoft toolboxes, indicating that even if it's a convention, it'a apparently not a windows-native convention.

Doesn't "Add and Remove Programs" just run whatever custom Uninstaller came bundled with the program? Is there anything it can do with programs that don't come with an uninstaller?

Yes: the annoying ones open up iexplorer.exe and ask you to fill out a survey of why you're uninstalling them.

"add and remove programs" is still relying on the application developer to get it right. I've seen plenty of apps leave behind crap.

> OmniDiskSweeper is great for finding this stuff.

iTrash [1] is also worth mentioning. It uses the Levenshtein distance algorithm [2] to find all of the junk related to an app.

[1] http://www.osxbytes.com

[2] https://en.wikipedia.org/wiki/Levenshtein_distance


I've been using AppCleaner [1] for years and it's awesome. And it's free.

https://freemacsoft.net/appcleaner/


That's a cool little app. But at some point, I became very wary of running free, closed-source binaries from the Internet.

What do you think about this one?


Why do they put that stuff in there instead of keeping it in the .app folder?

Flatpak, Appimage, etc.

Zoom is even available in Flathub, and that's how I use it.


> No consumer OS but iOS actually provides any sort of true app level sandboxing.

Android does, too.


Which is completely frustrating, because Mac is totally in the position of using its built-in capabilities to deal with this. The Mac Bundle (.app) format could solve this entirely. All application specific data should be written inside of the bundle folder, so that when you delete the app, you delete the thing entirely.

I mean, maybe you need a "user data" bundle of sorts tied to the specific application. If you delete the app, it deletes all the user data bundles as well.

The default installer and bundle runners should be controlling the process. "XYZ App is attempting to write data files outside of its bundle location. These may not be cleaned up if you delete the application. Do you want to continue?"

The unix permissions system and the Mac bundle format should completely solve this problem. I honestly just don't get why this still happens. Doesn't iOS at least get this right?


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.


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.


> 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.


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.


Ok, but an SQLite dB isn’t an executable. So what should an app do with that?

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.

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.


It’s a design choice, and of course it arguable but it have it’s (good) reasons.

By design choice user data of any App should be only be readable and modifiable by the active user. If user data is stored somewhere under home folder, this mechanism comes for free for the App developer and the OS handle it. If you want that same level of privacy in the App Bundle developers would have to handle it themselves (and well).

But then what happen when you uninstall ? Either you are blocked because you can’t remove data from another user or you somehow require escalation to admin privileges to remove data of all users at once. Which might or might not make other users happy if they were unaware of the uninstall...

With current data model choice (pretty much shared across all UNIX world and even Windows). If user A delete the App but user B still needed it you just have to reinstall to keep user B unharmed.

Your proposal is not bad to optimize for disk space gain at removal, it just happen that (quite rightfully) OS vendors chooses to rather optimize for data persistence and security.


> /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.


All these are fair and good points. But all of these are still workable problems that should be very much in the capable hands and constraints of the operating system and "app bundle runner" (call it) to deal with.

Your points are all solved by using the user's home directory, very true. But the problem simply remains -- I think this is my main point -- that the "App bundle" has failed the user by not allowing for cleanup of everything that the application has created. If an application can simply write any executable into any user directory it wants, there's no code signing or integrity checks on the app itself that matters.

Applications should be treated as hostile, just like a user is treated in a multi-user system.

I think it's a failure of an operating system to not be completely in control of the limitations and installation of any program. It's also a failure of the developer community to not stand up and insist on this too. A sand-boxed model is what we should all be striving for here. Force the bad actors out.

I'm not a Mac developer (obviously). But I am an old Unix neckbeard. So I get all of your points; Unix invented this problem.

In a multiuser system, individual users are treated as hostile. Going forward, so too should applications. That's the failure in all of this (and it's been with us a long time now). Our security model is based on not trusting users, but in trusting applications. This thinking was born in the 60's when users couldn't install/execute any random download.

It's interesting that the unix model of security is hurting us more today than helping. The time for sandboxed applications is definitely overdue.


For the record, sandboxed macOS apps do exist (as someone mentioned upthread) and have a design somewhat similar to what you're describing, but uglier for the sake of backwards compatibility. For each app you have a directory like /Users/foo/Library/Containers/com.some.bundleid/Data, which is an entire virtualized home directory, containing not just a Library subdirectory but also Desktop, Documents, Downloads, etc. The latter directories shouldn't actually be used, but they're there in case some legacy code tries to access them. When an app presents an open or save dialog, the dialog is out-of-process and unsandboxed, so the user can pick a file from their real home directory or anywhere else; once they do so, the app is automatically granted the ability to access that particular file.

You're trading one problem for another. What if I want to delete a user instead? Now I have that user's crap in every application bundle.

However, the OS should perhaps insist on a particular location within "Application Support/" that each app can write to, and when the application bundle is deleted, provide a way to delete those support files as well, either for that user alone or for all users within permission (can be a system-wide configuration).


I would argue, I think most systems have more quantity and churn of applications than users. Meaning, it would be better to pay some overhead to deal with "user's crap" in every application bundle than to deal with "application crap" in every user's home.

Your second paragraph though is probably closer to a realistic solution. That is, the OS provisions an Application Support directory and restricts the application to using it exclusively. Any application uninstalls can (via admin prompting or configuration settings) then also delete the support directories as well.


You absolutely wouldn't want user data stored in app bundles. You can back up all user data by backing up /Users/ or /home/ on Linux.

As an application developer, I want to be able to drop a new bundle over the old version and NOT LOSE ANY USER DATA. The only way to do that is separate them completely.


In addition, users can run applications from a CDROM or a read only USB stick, where the app would not be able to write anything.

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.


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.

[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.


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.


I'd argue that linux distros have this power, too, and they haven't either (unless you use a snap, which has compatibility and performance issues).

If you uninstall a .deb or .rpm or AppImage, the files you wrote into XDG_CONFIG_HOME (defaults to ~/.config) won't magically get cleaned up.

I'd love to be wrong here, BTW! I've had several PhotoStructure users try to reset their configuration by uninstall/reinstall, but that just removes the files in the installer, it doesn't do anything to files in user directories (and I'd be really surprised if that was ever a thing). Can you imagine the havoc from `apt remove vscode` and having it remove user's keybindings, extensions, and anything else?


>~/.config) won't magically get cleaned up. >I'd love to be wrong here,

Isn't this what apt purge appname does ? or is something missing

Form the apt-get docs:

purge - purge is identical to remove except that packages are removed and purged (any configuration files are deleted too).


That would only purge config files that came with the package (which would live in /etc/). Config files in the homedir of a user are not managed by apt.

Thanks, I was wrong, not sure why I believed that it worked. so in the end Linux needs a CCleaner tool like Windows, it should also contain a browser cache cleaner, I sometimes find a few Gb of space in Chromium localstorage/cache and have to hunt them down and delete manually.

> The default installer and bundle runners should be controlling the process. "XYZ App is attempting to write data files outside of its bundle location. These may not be cleaned up if you delete the application. Do you want to continue?"

If you do that, the entire system stops working. Everyone will just click "ok" and then still gets mad when uninstalling doesn't fully clean things up.


So users who want crapware can get it, and users who want a clean secure system can get it, and app developers are pressured to build apps correctly. And App Store/GateKeeper can prevent misbehavior for apps distributiled through Apple's friendly marketplace. Win-win-win.

Well, that's fair. But hopefully in the process of getting mad, it starts to reflect negatively on the application vendors and/or Apple directly. Maybe that will be enough for them to change.

Maybe the app bundle runner should be logging files written outside of the bundle folder? Then the uninstall process will wipe those out?


Wipe out all the things that you create with the app? All the text you created when you uninstall a text editor, the photos you touched up and saved under a new name, the audio recordings you made?

> All application specific data should be written inside of the bundle folder, so that when you delete the app, you delete the thing entirely

Not even Apple follows that ideology though, I can't be the only one who has had to delete the gigs of Garageband data from ~/Library/Application Support on an under-specced company laptop 128GB SSD


Nor does Windows for that matter. Running installshield with some command line parameter doesn't count. Linux package managers come close, but not all third party apps are installed like that.

Having a standard installer toolkit that comes with the os and used by many os updates along with a centralized uninstall UI is nothing?

> Having a standard installer toolkit that comes with the os and used by many os updates along with a centralized uninstall UI is nothing?

If we are talking about OS updates, OSX has the same thing.

You are not required to use Windows Installer. And even if you do, you are not guaranteed that everything will be removed, be it due to malice or incompetence.

Not even Linux can guarantee that. Something like the Nix package manager would be closer to what's required. Plus a sandbox.


Funny, it is also self-inflicted because Safari inspired Zoom to do this hack by breaking the correct behavior of protocol links.

> This is a workaround to a change introduced in Safari 12 that requires a user to confirm that they want to start the Zoom client prior to joining every meeting. The local web server enables users to avoid this extra click before joining every meeting.

https://blog.zoom.us/wordpress/2019/07/08/response-to-video-...


I don’t understand how a “you’re about to jump out of the app” confirm panel is breaking protocol links. I actually want this behavior for zoom and any other app...

The first time you use that protocol, of course a warning is appropriate. To prompt the user on _every_ external protocol click seems.. hostile to the concept of linking

It needs to happen at least for every combination of source domain and protocol. Otherwise websites can drive-by open zoom, reminders, or whatever other app you have installed to achieve some marketing or malware goal (or just DoS your computer).

Edit: Once you consider social sites with user-submitted content, like reddit, it might be best if you’re prompted every time.


So then you have a protocol link to a .vbs file and you tell all of your contacts how much you love them.....

It adds an extra, confusing step, that is not necessary most of the time.

I think "breaking the correct behavior" might be a bit of misleading term -- it's obvious that in some contexts we would want to be warned about the context switch and in others we'd be annoyed by it. I could totally understand why Zoom would, for frequent users, want the users not to get an annoying dialogue. On the other hand, if I'm a rare user or don't know a program is installed on my system, the context switch dialogue would be super useful alerting me that something is happening.

So I think you could argue Apple might want to let you override that, I don't know what the language is and whether there's a "click here to skip this next time" box on the dialogue. It's possible they got the annoyance versus security tradeoff wrong.

But imho they didn't break the correct behavior any more than Microsoft "broke the correct behavior" of privilege escalation by adding a dialogue box with UAC in Windows 7 .


> But imho they didn't break the correct behavior any more than Microsoft "broke the correct behavior" of privilege escalation by adding a dialogue box with UAC in Windows 7 .

well, it did a shitton didn't it ? to this day, most people I know disable UAC because of how annyoing it is.


Zoom deliberately circumvented Apple's standard package format, contrary to security interests. Zoom is basically behaving like a virus here.

Neither does Windows or Linux. I don't think you can have such a standardized way on a flexible general-purpose OS.

What apple should do though is provide an API that developers can hook into, where in when the user drags the app to the trash, it can also uninstall anything else the app placed elsewhere on the system.

They do! The app developers didn't follow the guidelines.

Oh really? Cool!

I've been out of the MacOS app dev scene for too long, it seems.


it really does provide a very nice and effective standard way to bundle components needed by an app altogether and to manage them appropriately.

The developers in this case didn't bother trying to use it.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: