1. https://help.webex.com/en-us/WBX38280/How-Do-I-Uninstall-Web...

The uninstallation page basically describes how to completely uninstall any nontrivial Mac application.

Under windows, I would consider any software that requires a separate removal tool to be suspect. Software wanting you to download a separate tool, fill out unavoidable surveys or linking you to a site to track uninstallations is all very seedy practices.

Why isn't it expected of Mac software to keep an installation manifest and provide a way for removing the software?

It is dead simple to remove a .app from the Applications folder. Sadly the pkg installers also throw files everywhere. Some software does include an uninstaller pkg, like Windows apps will include an uninstall.exe. But like windows, not everyone is meticulous about making sure you can uninstall cleanly.

Linux certainly does not make clean removal (/etc, /var, dotfiles/directories) easy.

Oh, and the “separate tool” can be pre-bundled, whether you have to download it separately is orthogonal. Pretty much every Windows program has a separate uninstaller, because on Windows you simply can’t uninstall yourself.

https://ss64.com/osx/lsbom.html

Except that packaging (in the package manager sense) and distributing proprietary software for Linux, with its too-many distros and even-more-too-many library versions, is such a pain in the ass that almost no one does it in the first place.

Now AppImage, that's trivial.

It really highlights how on desktop apps can do what they like. Whilst on mobile platforms at least you have to grant specific access.

I always wonder ... "Uh, do you want platform specific desktop apps? You're not much better protected there man... and app availability becomes limited / a pain."

The UNIX-y solution to this is to ban proprietary apps and run only vetted free software, interoperate with protocols, not implementations.

They thought binding a web server to localhost and having a browser make requests to it was OK. They did not consider that literally any other web page can make the same requests.

There is also a system with Webex, that is separate, and if you have Webex meetings registered against your email, it will provide you those meetings if you are not signed in.

Personally, my best guess is because that’s the flow the product manager expected.

    % pkgutil --expand foo-1.0.pkg foo_pkg
    % cd foo_pkg 
    % ls -Al
    total 352
    -rw-r--r--  1 magervalp staff  44491 16 Mar 12:19 Bom
    -rw-r--r--  1 magervalp staff    566  9 Apr 13:51 PackageInfo
    -rw-r--r--@ 1 magervalp staff  67794 16 Mar 12:19 Payload
    drwxr-xr-x  4 magervalp staff    128  9 Apr 13:51 Scripts
    % mv Payload Payload.cpio.gz
    % open Payload.cpio.gz

https://stackoverflow.com/questions/11298855/how-to-unpack-a...

https://news.ycombinator.com/item?id=16985460

https://www.keka.io/

On an unrelated product we learned that users ended up with many different copies of the app scattered throughout the system, if they were allowed to use the traditional bundle + DMG distribution method. Spotlight would then helpfully pick one random copy, with obvious consequences wrt. project file versioning. That is despite the DMG having the usual symlink to /Applications for a drag-and-drop installation.

Maybe the issue could be ameliorated with a self-updater built-in into the app? Not a separate daemon, but something that by running inside the app, would be able to know what's the path of the old version that should be thrown away.

Still, there's the possibility of users clicking "Cancel". Even then, it's a bit more code to write, test and pay for (from the POV of a client).

Wrapping the bundle inside a .pkg instead of a .dmg solves the problem "for free".

Deprovisionig might not work right, but that's rarely needed.

As an example, I noticed the Docker installer starts off doing telemetry before anything has been installed.

Other less nefarious uses are to ask about telemetry / GDPR before installation.

Apple documentation on installers specifically says -- you don't even have to have an installer. And most software really doesn't.

I’d imagine you’d want to gate this through the process itself to ensure users have actually accepted, especially as EULA enforceability varies from place to place.

Why would the user expect that script to install the application, or even modify their system in any way?

Why they didn't just use a dmg that has you drag the application into /Applications/ is something I still don't understand though. Surely that is the simplest most user friendly way to have non-technical users install applications without using the appstore.

Not “This installer will run a script that installs this package without asking further questions, then terminate abruptly without going through the rest of the install process and giving you a chance to decide exactly where it should go”.

But that's my paranoid tech background speaking. I can totally understand technical naïveté though.

Tbh I think that most people here on hn are experiencing cognitive bias because of additional knowledge - reality is that most of regular users do not give a damn about what installer does, they just want working app.

They are using a .pkg only for the side effect of running a pre installation script that simply copies Zoom.app in the /Application directory. That is to a software develper garbage, why doing so, when all other macOS application require the user a single drag and drop?

Sure, that is probably not malware, but is a very poor practice, gives the user a bad experience, for no reason. These are the things that let's you wonder if the installation is managed in such a poor way how is the rest of the infrastructure.

This issue mainly tells me that macOS installers are largely like a Windows .exe and Linux curl | sh (well, that's not true since it still needs to be signed…).

Or would that mean that their premium services would require paying the fees to Apple, which they avoid this way?

But when everyone and their dog is using Zoom on their personal machines, Mac App Store should be an option.

By the time we were done -- I use copilot (basically VNC with NAT punching built in) -- and I got control of the laptop to just do it myself, there were 7 downloads and 4 unzip attempts.

My MIL and I have literally had facetime pointed at her laptop while I directed her where to to get copilot running for the quarterly cleansing-of-the-spyware.

I haven't used it, but macOS does have screen sharing built into Messages.

I wonder how could Apple take 30% their revenue out of this -- yeah, by forcing them to submit the apps to the AppStore instead!

Yes. But neither are distributed on the App Store, so…

Second, Zoom already runs sandboxed for the other two ways you can run their client on Apple operating systems: the (iOS) App Store and the web. The Mac sandbox is the least strict of the three. So whatever they do, it doesn't seem to be hindered by 'severe limitations'.

I have yet to hear any feature that a legitimate videoconferencing application would need that would be disallowed by the macOS sandbox. Lots of other video chat apps are on the Mac App Store, like Facebook Messenger. Is the issue simply that Zoom is being sketchy and wants to continue to be sketchy, and sandboxing would not allow them to? That's not because the MAS is 'a trap'. That's its main feature.

And these apps deserve to have “breaking opening from Finder” and even more restrictions considering they have shown themselves to be completely untrustworthy, insecure, invasive and hostile.

It even works in Safari on an iPhone (!!!!!!).

Users don't use your software as you would like them to. Zoom now requires ~4 clicks to update when a new version is released as you click through the installer steps. You have to click the single frickin' disk icon (which is the only disk 99.9% of Apple users are going to have... still you have click on it) in one of the steps for the Next button to activate. Result: I fully expect a large percentage of the users to never update their Zoom successfully again. Great win for the users, the software which you downloaded, then clicked to install, no longer executes that scary pre-install script.

Zoom uses an .pkg, and have now removed the one-click install script. So every update to Zoom now runs through the same multi-step Next process as well (with one of the steps inactive until you select your disk, as is customary). If you think that isn't a problem for users, you've never walked grandma through the steps while she's trying to show her screen though the phone to you.

Malware on macOS isn't prevalent. There is no market for anti-virus vendors on macOS, and Apple have been repeatedly tightening the approval process for macOS software. Gatekeeper only ever gets more aggressive, not less. Meanwhile videocall software is widespread, it's rapidly become a necessity for a large part of the world's population. I wouldn't be surprised if on macOS it's now in second place as a category behind web browsers.

No.

What Apple should, MUST do as quickly as possible, is understand and react to what developers here are trying to tell them - the usability of macOS software installation is terrible and no, the App Store is not an acceptable alternative. macOS software install UX is worse than Windows. It's worse than Android and iOS. It's better than Linux but that doesn't say much.

If Apple want to end these practices, they need to deliver:

1. Genuine one or two-click install of software from the web, without the App Store being involved and without requiring sandboxing, allowing install scripts and for signed/notarised software, without any security popups. DMG style installs require drag and drop AND device unmounting, which isn't especially discoverable and hardly used on mobile platforms so some users can't figure it out (hence the reliance on PKG files).

2. Removal of the scary popup that Safari shows when a user clicks a non-http URL.

Desktop software on macOS relies on these techniques because measuring the ratio of number of downloads to number of successful app starts shows that far fewer people make it through the process than they should, for instance, fewer than on Windows. This is a bit of an open secret in the desktop software world for many years now; Google for instance has detailed data on the problem. Each click you add causes the success rate to drop and macOS requires far more clicks than is justifiable. Additionally, the web server trick Zoom uses is because otherwise some non-trivial proportion of Safari users just automatically click cancel on the security popup when a web page tries to open a meeting, without even reading it. They don't understand what they're being asked or why, but figure if Apple want to double check with them it's safer to say no. Then they fail to join a meeting and if they're an important participant, that means the meeting fails for everyone.

Note that this usability problem is Safari-specific. On other platforms and browsers such workarounds aren't needed.

People need to stop giving Apple the benefit of the doubt here. Videoconf firms aren't doing this extra work because they're malicious or incompetent or because they inexplicably like doing work. They're doing it because otherwise a lot of Mac users fail to achieve the task they set out to do, and that hurts the usage of the video platform. It's ultimately Apple's problem to fix.

Sounds questionable in all the parts.

Mac: Just click-mount an installation disk image and drag an app icon to the Applicationss folder - isn't this a perfect install UX? If an app installed this way wants to handle some URLs it should declare that in its metadata. No app should be allowed to modify files outside its dedicated directories unless modifying those files is its actual mission.

Linux: just type "sudo apt install app_name" - what can be more handy?

Windows: let every app you install do anything it wants with all the system files, leaving traces after uninstallation is a norm.

The only problems with iOS are it removes a user's right to program his own device freely and demands too much money from 3rd party devs.

On the Mac, the whole "drag an app to the trash to delete" thing has always been a lie, since most applications spew things in ~/Library, /Library, and other app support directories, which means you miss lots of stuff that AppCleaner has to find. It's still a terrible experience, and if you don't know that then downloading a new copy of the app won't fix anything because all of its preferences and extra files are in a directory you didn't think to clean out because its hidden by the system.

No. Please do set up a usability test in a lab and watch people try.

You will find:

1. Many users struggle with unusual mouse/trackpad movements like drag and drop, right clicking. That's why the Mac theoretically has a one-button mouse.

2. The instructions for what to do differ between DMGs and usually consists of a single arrow if present at all. This isn't clear enough to communicate "drag and drop" to people.

3. If the user figures out or has been shown that they have to drag and drop, they may then be confused when it appears nothing has happened, or by a small dialog that appears and then quickly disappears. It's now not clear how to actually start the app. Nothing appears in the dock, the app itself doesn't start. Launchpad made this better some years back because now there's at least a button to push to show you all apps and let you search for them iOS style, but the user has to realise they haven't started the app.

Note that if you use the App Store there's a sort of animation that (if the user sees it) suggests the app has been deposited into the launchpad. But you don't get that with out-of-store installs.

4. If the user isn't very familiar with this DMG process they may double click the app to start it from the DMG itself, which will look like they successfully installed it (because the app starts) but which may (a) break the app in subtle ways if it expects to be able to write to its own directory, (b) confuse the user when the folder disappears along with the downloaded file button in their browser, thus giving no obvious way to get back to it, except via a realisation that the window which popped up was a folder despite not looking like one and thus could be perhaps relocated via the Finder, unless you rebooted in between in which case maybe not.

Bizarrely and against all rules of good UX design the right thing to do isn't the simplest action that appears to work, but rather, several more steps in between.

5. If they do manage to drag it, find it in Launchpad and start it, very likely they won't realise they're supposed to "eject" the DMG to get rid of the prior copy, even though nothing is actually being physically ejected anywhere. They may also be confused by the presence of two icons that should be equivalent but aren't. If they do know they're meant to eject/unmount it there's nothing obvious to let you do that, for instance there's no button labelled "Eject", but rather you're meant to find the icon for the DMG on the desktop (which is covered), realise it's an icon that represents the window you saw earlier although in the absence of a branded icon there's no indication of that, be mystified by the strange metal object in the icon (who has seen a real HDD these days?) and then realise you're meant to start dragging it again to the trash can, which magically turns into an eject symbol? Or you could try using the Finder, in which case the sidebar entry for the DMG is going to be under "Locations" in a scrollable area that doesn't have scrollbars, and no visual indication it can be scrolled, and the icons next to the name of the app don't indicate what they do, and if your Finder is set to use e.g. tree mode then clicking it shows a view totally different to the one you saw earlier!

The entire UX is something only a UNIX hacker could ever think makes sense. Unless you have a really solid grip on filesystems, nested folders, mount points etc this whole thing is just totally mystifying and a lot of pointless busywork too.

Some Mac apps have code that detects when the user has made these sorts of mistakes and will offer to move the app to /Applications for them. It's intended to partly work around these usability problems, but ultimately, a PKG is still much better especially for videoconf apps where the standard way to start them is via the browser and not by finding an icon in Mission Control.

Windows: let every app you install do anything it wants with all the system files, leaving traces after uninstallation is a norm.

Mac apps leave stuff behind all the time too because they don't have any uninstallation procedure. On Windows it's at least a bug in the uninstaller which could be fixed. On macOS it's a fundamental design issue with the OS itself.

I'd beg to differ on that. If anything, I'd bet MacOS is now be the platform with the most malware (adware specifically).

I've had to check laptops from wife and step family (all apple users) in the past year and they all turned out to be infected with a truckload of mac adware, that they only noticed after it replaced their homepage browser or spammed unending popups on the desktop.

While browsing for help on safari, pages were filled with ads and popups trying to send you more malware. That is, when pages are not right away sending you some executable files (just like pages sending you .apk on android devices). MacOS is as unsafe as everything else nowadays.

I disagree with this. Why is going via the app store a bad thing? The app store is the solution here. Zoom should be able to tell apple "Hey I'd like to handle zoom://" links, and clicking one will redirect you to either zoom or the app store (without the source of your link knowing where you ended up), where you can have a one click install.

I also firmly disagree with the concept that sandboxing shouldn't be enforced. There is _no_ reason for any software (particularly software like Zoom, Webex, Slack) to have unfettered access to my machine,

The App Store has problems, but all apps there being "loser apps" is not one of them.

But I would vociferously disagree that an app store can be the only solution.

Giving anyone that much power over a platform is antithetical to the promise of computing.

Ergo, as GP noted, Apple has a lot of work to do on making non-app store installs a viable alternative.

1. Apple have a history of convoluted review processes and arbitrary rejections. It has a terrible reputation amongst devs.

2. Thanks to unpredictable reviews you can't time when a new upgrade becomes available to coincide with e.g. website changes, emails.

3. The App Store can't upgrade apps whilst they're running.

4. App Store 30% standard cut is far too high when a developer could sell direct from their website and pay 2% or less to a card processor.

5. The App Store UX is itself pretty bad. There's no flexibility or ability to customise how your app appears.

6. Devs are forced to allow app reviews and ratings although they may not wish to have that e.g. because users use reviews as a way to request support instead of an actual support system, but you can't reply.

7. App Stores often create problems for corporate or managed desktop deployments.

8. For software that is billed, despite exhorbitant fees their billing engines can be primitive. For instance even years after launch the Windows app store had no ability to do bulk discounts or other kinds of completely normal retail strategies. I don't know if it does these days, but I do know of an app developer who shipped via the WAS and whose business was badly hurt by Microsoft's lackadaisical attitude towards basic features like that. They could have sold big into education but couldn't get much traction because there was no way to offer reduced rates to schools.

9. App Stores enforce random policies unrelated to the core mission of app distribution. For instance the Mac App Store is extremely vague about to what extent plugin mechanisms are allowed. Good luck implementing an IDE or browser in the MAS; you'll always be living in a grey zone. It also forbids any kind of custom licensing mechanism or copy protection, so when Apple's is insufficient you're SOL and requires all languages to be in the same bundle yielding huge downloads (=lower conversion rate due to failed downloads). Those are just implementation limitations but you aren't allowed to do better.

Basically, Apple don't have a good track record of creating an excellent developer experience with their app stores. On mobile they forced devs into it against their will. On desktop where backwards compatibility prevents it, devs have nearly universally rejected app stores ... even when an app is in it, it's common for websites to direct users to their own distribution points.

I know that companies have a perverse incentive to sell your info to advertisers and such, so I'm not trying to wave that away.

Just wanting to understand if Safari DID have webRTC much earlier, would we be talking about Zoom today?

This stuff is common. You know how many populat windows software acts bad? Filezilla's installer for example would literally install a very nasty strain of adware (to their credit, they give you the option to opt-out)

I would do the same.

The difficult problem is making sure non-technical users can install and run binaries from untrusted third parties in basically a single click.

Does that sound like a security nightmare? It is. But it's also the users' expectation of "just working".