The Robservatory

Robservations on everything…

 

macOS

A full history of macOS (OS X) release dates and rates

Updated and republished for macOS 11.2.2; skip it unless you really really care about all the macOS releases. Originally published on November 14th, 2005.

Below the break is a table showing all major releases of macOS (previously Mac OS X) from the public beta through the latest public version, which is 11.2.2, as of February 25th, 2021—the 146th release in total.

Note: Click the ⓘ symbol to read Apple's release notes for a given update.

(more…)

A problem of time with Big Sur screencasts

As part of my job, I occasionally have to make screencasts, usually demonstrating features in our various apps. Sometimes I need to record the entire screen, as I'll be demonstrating things that require activating and selecting menu items. I have a demo account I use for these recordings that lacks all of my usual menu bar add-ons, so the look is quite clean.

And in versions of macOS prior to Big Sur, I also hid the menu bar clock (via System Preferences → Date & Time → Clock, uncheck "Show date and time in menu bar.") But in Big Sur, the menu bar clock is also the button you click to open Notification Center…so there's no way to remove the clock from the menu bar.

Most of the time, this isn't a problem. But when recording screencasts, it's a big issue. I often record segments across days, and at multiple times a day. I then splice those bits together, often times not in a linear fashion. With the default Big Sur settings (displaying the full date and time), this leads to a real annoying time travel experience as the clock jumps around like crazy.

The following two tips help greatly with this problem, though being able to hide the clock entirely would be a much better solution…

(more…)

My impressions of the M1 MacBook Pro

I recently received my Apple M1-powered 13" MacBook Pro, which is primarily going to be used for testing our apps on Apple silicon, and supporting customers using these machines. But that doesn't mean this is a work machine; it's a personal purchase as I'll use it for my own needs as well. (Thankfully, it only had a net cost of $33 after I sold my 16" MacBook Pro.)

By now, you've probably read a slew of stuff about both the MacBook Pro and its slightly-lighter MacBook Air cousin. Between unboxing videos, extensive benchmark suites, and multi-thousand-word reviews, there is no lack of coverage of these machines. (However, I will add that I did make a video of my MacBook Pro—with its 16GB of RAM—opening 75 apps in just over a minute. Not bad for an entry-level machine!)

I'm not going to try to replicate those reviews, because they do an excellent job of covering the new M1-powered Macs in a level of detail that I just don't have time to get into. Instead, here's what I'll be discussing…

  1. Why I chose the 13" MacBook Pro
  2. A few benchmark results of interest
  3. Rosetta and non-native apps
  4. Using iOS apps on macOS
  5. General discussion on performance
  6. The future of Apple silicon Macs

So why a MacBook Pro and not an Air?

(more…)

16GB of RAM and 75 open apps…what could go wrong?

I ordered my 13" M1 MacBook Pro with 16GB of RAM, as I felt buying the most offered was the best bet for future proofing this "entry level" M1 chipped Mac. Later today I'll be posting a detailed writeup of my time so far with the new machine, but for now, here's a little over-the-top demo.

I selected everything in the Applications folder—excluding Time Machine, Siri, Launchpad and a few other similar non-apps—and opened them all at once. I did this with a timer running, while recording the screen, and here's the result…

As you can see at the end of the video, it took one minute and seventeen seconds to open all 75 apps—do the math, and you'll see that's about 1.5 seconds per app (it was notably quicker than that at first, and slower than that at the end). For 75 apps. On a machine with nowhere near enough RAM to fit them all in active memory. I was amazed at how rapidly it was able to complete this task.

These weren't even all native apps, it was a mix of Intel, Apple, and Electron (both native and non-native) apps.

I tried a similar test on my MacBook Air, but as it's an 8GB RAM machine, I limited it to opening 37 apps, which took it well over three minutes (about 5.5 seconds per app). I didn't bother to try on my iMac—it has 40GB of RAM, but it's also got a slower SSD, so I don't know that it would've matched the MacBook Pro's performance.

(more…)

Fix a “could not complete your purchase” App Store error

I've been having an odd issue with the Mac App Store app on my Mojave-running iMac: Sometimes the App Store app will fail to install an update for some app. When that happens, I see a dialog with this text as the title:

We could not complete your purchase.

Below that is a single word, "cancelled," and that's all. Searching the web, I came across this thread on stackexchange.

What finally worked for me was a combination of things listed there—none of these steps on their own seem to fix the problem, but all together do, at least until it occurs again.

  1. Quit the App Store app.
  2. Switch my DNS to another provider.
  3. In Terminal, paste this command and press Return:
    open "$TMPDIR/../C/com.apple.appstore/"
  4. Confirm that the Finder opened a window to the com.apple.appstore folder, then drag everything there to the trash.
  5. Back in Terminal, paste this line and press Return: killall -9 appstoreagent
  6. Relaunch the App Store app.

This method has worked for me each time I've had this issue. It's annoying that it keeps recurring, but at least the fix is relatively simple.

Bookmark both of Apple’s system status pages

I've long known about Apple's general System Status page, which provides a dashboard showing the state of most of Apple's consumer-focused services:

https://www.apple.com/support/systemstatus/

Until yesterday's "why can't I launch any apps?" outage, however, I'd never known that they also have the same type of status page for developer-focused services:

https://developer.apple.com/system-status/

But this page is useful to more than just developers (and it doesn't require a login to view). Had I known about it earlier, yesterday it would've shown that they were having a problem with the Developer ID Notary Service, which is why apps wouldn't launch.

In typical Apple understatement fashion, they've posted the resolved status for that service today:

"Some users were affected" and "Users may have experienced issues with the service" certainly make it sound less painful than what it was, i.e. "A ton of users were unable to use their Macs" and "Mac users could not launch their apps for over two hours." Somehow Apple needs to come up with a better failure mode for the service, as the results yesterday were unacceptable.

Note: If it happens again, simply edit the /etc/hosts file as root, and add this as the last line:

0.0.0.0      ocsp.apple.com

That will prevent your Mac from trying to contact the validation server at all. Note: This seems to break the App Store app, but it let me keep working, which was more important at the time.

Copy links in Chrome, Firefox, and Safari in one step

Something I do a lot is copy links—whether for articles here, or for pasting into Messages or Signal or Twitter, or for corresponding with Many Tricks' customers, I copy a lot of links.

Web browsers—at least the "big three" of Chrome, Firefox, and Safari—bury their copy link commands in a contextual menu. If I want to copy a link, it's a right-click and then either using the keyboard (press C then Return in Chrome and Safari) or mouse (Firefox) to select then activate the Copy Link command.

If you use Chrome or Firefox as your browser, you're in luck: You can install a simple extension in each that lets you copy a link by simply hovering over the link and pressing Commmand- or Control-C:

Now, about Safari. I couldn't find a Safari extension to handle this seemingly simple task, so I turned to Keyboard Maestro.

(more…)

See dot files at top of ls output in Linux

In Terminal on macOS, the ls (list directory contents) command sorts the output of its "all files" listing so that hidden files (those that begin with a dot) appear at the top of the list, like this:

$ ls -Alh
total 47640
[email protected]   1 robg  staff    28K Oct 26 15:00 .DS_Store
[email protected]   5 robg  staff   160B Oct 23  2016 .TemporaryItems
... [trimmed for display]
drwxr-xr-x    8 robg  staff   256B Sep 19 08:31 .wine
drwx------   13 robg  staff   416B Apr 13  2019 Applications
drwx------+  20 robg  staff   640B Oct 26 12:36 Desktop
... [trimmed for display]

On the server that hosts my personal sites (as well as Many Tricks), however, ls doesn't sort the invisible files to the top:
(more…)

Simplify updates to oft-updated text documents

Here on my blog, I've been tracking macOS release dates and rates for nearly 15 years—if I'm doing my math right, I've edited and republished the post 115 times since then. Until the most recent update, all 115 of those updates were pretty much done like this:

  1. Update a Keynote document that calculates the release rate data and contains the two charts in the blog post.
  2. Edit the text of the blog post in a text editor, with Keynote visible, replacing all instances of variable data—dates, numbers, size, rates, etc.—wherever they appear.
  3. Upload the graphs and publish the updated post.

While this isn't an overly complex task by any measure, the second step in particular has gotten more time consuming over the years, because of the length of the post: It now contains over 50,000 characters. That's lots of scrolling and looking for the few bits that change—and I'd often miss a date or a number in some portion of the post.

I thought there had to be a better way, and there is…and of course, the better way uses BBEdit. In particular, BBEdit's support for including one file in another—and using variables in the included file—makes my update task much simpler. If you have text files that receive regular updates, you may find this method of interest, as it can be a big timesaver.

(more…)

Resolving ‘A problem repeatedly occurred…’ error in Safari

Yesterday, after updating to Safari 14 on my Mojave-running iMac, I noticed a big problem: I couldn't load many sites that contained either a login dialog or a shopping cart. For example, I could load Target's main site, but when I tried to open the shopping cart, it wouldn't work.

I'd briefly see the page, then it would clear and reload once or twice more, and then I'd be left with an error message:

A problem repeatedly occurred with "https://www.target.com/co-cart"

This was happening on many, but not all, sites—I could login on Amazon and my bank, but not on most of our credit card sites or typical retail shopping pages. Given this happened just after installing Safari 14, I assumed it was somehow related to the new browser version—the same pages that didn't load in Safari loaded fine in every other browser I tried. But they loaded fine on Safari 14 on my Catalina MacBook Pro, so then I knew I had a Mac-specific issue…the worst kind of issue to troubleshoot.

While troubleshooting, I found that I wasn't alone, nor was this a Safari 14 issue—there are lots of reports of the same problem over many years.

After tweeting about my troubles and what I'd done to try to troubleshoot the problem, Jeff Johnson of Lapcat Software got me on the right track by suggesting that my Safari install was broken. He suggested I check the date on this Safari framework...

/System/Library/StagedFrameworks/Safari/libwebrtc.dylib

When I did, I found that the version on my iMac was much older (Jul 13, 2020) than the version on my MacBook Pro (Sep 15 2020), where Safari 14 worked as expected.

It seemed that the fix might be as simple as reinstalling Safari 14…but Apple doesn't make it easy to do that, as you can't reinstall an installed update, and they don't include recent Safari versions on their download page.

After some searching, I found MacUpdate's Apple Safari page, which contains direct links to many versions of Safari—scroll down to the section titled "What's New in Apple Safari," expand it, and you'll see download links for Safari versions back to 13.0.3.

I downloaded the Safari 14 installer1And kept a copy, just in case!, let it do its thing, and the problem is solved. The date on the framework I checked now reflects a mid-September date, which matches the same file on the MacBook Pro.

I'm annoyed that Apple's installer didn't report any issues, and I wonder what a "typical" user might have done to resolve this issue—I only got it fixed thanks to Jeff's tip and the installer links on the MacUpdate page. I can't imagine how long I would have had to talk to Apple Support before they figured out that it was a bad Safari install, and not some app or utility or other "you caused this" issue on my Mac.

So thanks, Jeff and MacUpdate, for helping me find and fix this very annoying problem with my Safari install!

The Robservatory © 2021 • Privacy Policy Built from the Frontier theme