A New, Better Way to Install Apps in macOS

3 minute read
| Particle Debris

Apple has required macOS developers to comply with many modern security practices. Here’s an idea for the next logical step.

The Particle Debris article of the week comes from our own Andrew Orr.

Apple Releases Mac Update to Remove Zoom Web Server

The fact that Apple had to (silently) remove an app component shown to be vulnerable to malware is just part of the larger issue. Namely, Zoom used the obscurity of the app install process to put a hidden web server into place. I’m sure that if users were properly informed of this app’s web service and offered a way to manage it—or fully delete Zoom and its support components when done with the app—users would have done so.

But its existence was a secret.

Now, Zoom is a fine app. But when developers take advantage of an obscured installation process to avoid full disclosure to the customer, trust has been lost. Abuse of trust, in any human endeavor, eventually leads to prohibitions or restrictions.

In this case, it seems sensible to ponder the prospect of macOS taking over the control of any GUI app installed in /Applications or /Users//Applications

There is justification and precedent for macOS supervising installations. Several security practices have been previously instituted by Apple over the years. macOS developers have been required to:

A new macOS Installation Process

Here’s how it would work.

macOS 10.16 gets new functionality. Only macOS can install GUI apps. (More on UNIX apps below.) Developers will have to set up a package of components with details on how and where each component goes. Only macOS has the privileges to install the files. During the install, a log window is opened and as each file is installed, its name, location, version and file type is echoed to the log window. A full copy of the log is also saved to a text file in a folder/directory called InstallerLogs

At any time, any user can inspect (but not delete) this log file for any app that’s been installed.

As an aside, this would not apply to UNIX apps that go into, say, /usr. Presumably, the experienced UNIX user can inspect the .tar file and look at the component files for him/herself.

A promise (about Macs) from WWDC 2019, session 701.

Now this is a very notional concept. I haven’t thought of everything by any means. But the point of it all is to eliminate hidden installations of dubious files into macOS, avoiding full disclosure to the user. It would also serve as a roadmap for the complete deletion of the app and its components if the developer doesn’t provide an uninstall option. (Which should probably be required anyway.)

Something like this has to happen. The days of secretly installed, questionable, files in macOS must come to an end. What say you?

Apple's Mac family with macOS Mojave

More News Debris

In the space I have left, I want to point to this excellent MacWorld article by Dan Moren. “Does Apple’s simplified Mac lineup have a hole in it?” Recently, on TMO’s Daily Observations podcast, we discussed the same topic. Namely, after two years of hard work, starting with the iMac Pro, Apple has brought coherence to a relatively up-to-date Mac lineup.

There could be several reasons for this. Here are a few.

  1. Outcries and defections by technical and creative Pros.
  2. The need to compensate for declining iPhone revenue.
  3. The realization that ultimate, productive mobility is best left in the hands of iPadOS and not the (now cancelled) MacBook.

In addition, the coherency and currency of the Mac lineup may just possibly have something to do with the declining influence of Jony Ive. That’s just a theory, but I’m not the only one to ponder that possibility.

Circling back, Dan Moren also makes an intriguing argument.

But that doesn’t mean there isn’t room for an ultralight MacBook in the mix. I’ve been banging the ARM-based MacBook drum for a while now, in the hopes that I’ll eventually be that stopped clock that’s right twice a day. Such a device could theoretically provide much better power efficiency in a package that’s lighter and smaller than a MacBook Air—and perhaps has more acceptable trade-offs. And if a newer device is in the works, it potentially explains why Apple might choose to discontinue the 12-inch MacBook now rather than simply updating it at a later date.

I’m not completely sold, but the best way to have a good idea is to have lots of ideas. Dan has them all.


Particle Debris is a generally a mix of John Martellaro’s observations and opinions about a standout event or article(s) of the week followed by a discussion of articles that didn’t make the TMO headlines, the technical news debris. The column is published most every Friday except for holiday weeks.

2
Leave a Reply

Please Login to comment
2 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
2 Comment authors
alvarnellJohn Kheit Recent comment authors

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
newest oldest most voted
Notify of
alvarnell
Member
alvarnell

This would be a great start and relatively easy to implement since there .bom files are still produce and stored in multiple places, including /private/var/db/receipts/, but it wouldn’t be quite enough. A great number of applications currently install additional files upon their first launch and that’s not limited to simple preference files. That would either have to be disallowed or means provided to capture such activity. Some advancements in this area have already been adapted for recent versions of macOS. Kernel Extensions, Login Items, Services, etc. should now be resident within the Application bundle, rather than scattered around to various… Read more »

John Kheit
Member
John Kheit

This implementation was standard with NEXTSTEP. Any install would create a .bom (bill of materials) file in the /Library/Receipts folder. It was useful but today you can get a view of where things will go with an app called Pacifist.app https://www.charlessoft.com