Apple has announced that 32-bit apps have a limited future on the Mac: They’ll be fully supported in this fall’s High Sierra release; macOS’ 2018 release (“Really High Sierra”) will “aggressively warn” users about 32-bit apps, and I would assume, they won’t work at all in the 2019 version of macOS (“That Was My Skull!”).
But how do you know which apps on your Mac are 32-bit and which are 64-bit? MacObserver has an article that discusses the easy way, via the System Information app—just look in the Software > Applications section, and you’ll be able to see a list of apps and a 64-bit Yes/No column. But seeing the list is all you can do—you can’t easily save the list for future reference, for instance, nor can you copy/paste the info to another app.
So here’s a geekier solution to generate a list of your 32-bit apps, saved into a text file for easy future reference. Open Terminal, and paste this command:
system_profiler SPApplicationsDataType | grep -B 6 -A 2 "(Intel): No" > ~/Desktop/non64bit.txt
This does the same thing as the System Information app, but it dumps the data in text form; the greater-than sign redirects the output to a text file named non64bit.txt, saved to your desktop. The grep is used to show only the 32-bit applications (the full line reads 64-Bit (Intel): No), and the -B and -A options are added to capture the lines before and after that line in the output.
This is probably not overly useful to most people, but I wanted a way to capture the list of apps, as I have over 290 32-bit apps on my machine, and it takes a while to run the System Information report each time.
I use VMware Fusion often—I have virtual machines that span Mac OS X 10.6 to macOS 10.12.4 beta. I use the more-recent of these for supporting our customers on older versions of the OS, and keep the really old versions just for nostalgia purposes. (I have a bunch of non-macOS virtual machines, too, but they’re not relevant to this tidbit.)
In all the time I’ve been using Fusion on my retina Macs, though, I’ve never enabled this setting…
…well, I enabled it once, but turned it off, because the end result was too small to see: In Retina mode, every pixel is an actual pixel, not a doubled pixel. On my 27″ iMac, that meant the macOS VM thought it was running at (for example) 2560×1600 instead of a retina resolution of 1280×800. VMware even warns you of this in their Knowledge Base:
Mac OS X running in a virtual machine is limited to an approximate resolution of 2560 x 1600, and treats the display as a standard DPI device. This makes the text and icons to appear small in the OS X interface.
However, today I stumbled across this solution from Patrick Bougie—and it’s brilliant in its simplicity. Patrick’s post has all the details; I’ll reproduce them here in abbreviated form, just in case his page ever vanishes.
This is another oldie but goodie from Mac OS X Hints, explaining how to enable the Debug menu in Safari. To do that, quit Safari, open Terminal, paste the following line, and press Return:
defaults write com.apple.Safari IncludeInternalDebugMenu 1
When you relaunch Safari, you’ll have a (really long) Debug menu on the far right of Safari’s menus. And just why might you want a Debug menu in Safari? Kirk McElhearn offers up one good reason:
Auto-play videos suck. They use bandwidth, and their annoying sounds get in the way when you’re listening to music and open a web page. …
But you can stop auto-play videos from playing on a Mac. If you use Chrome or Firefox, it’s pretty simple, and the plugins below work both on macOS and Windows; if you use Safari, it’s a bit more complex, but it’s not that hard.
In Safari, they key is the Debug menu, as Kirk points out. Go to Media Flags and select (activate) Disallow Inline Video, and that should be the end of auto-playing video. See Kirk’s blog post for ways to do the same in Firefox and Chrome.
Beyond auto-play video, though, there’s lots to geek out about in the Debug menu…
As you’re probably aware, Apple changed the functionality of a green button click in Yosemite: it not longer “zooms to fit” (which could have different behaviors per app), but instead it enters Full Screen mode (if the app has one; otherwise, it does zoom to fit). If you want zoom-to-click, you can option-click the green button; there’s no apparent way to toggle these two functionalities.
But today, I discovered a second zoom-to-fit shortcut: double-click the window’s title bar. This is easier to do, as you don’t have to hit the small green button target; just get the mouse anywhere in the title bar, and double-click.
Note that this won’t work if you have “Double-click a window’s title bar to minimize” enabled in the Dock System Preferences panel.
I was cleaning out some old images from the site, and found over 150 apparently unused images. Whoops, that’s what nine years of bad housekeeping will get you.
One of the leftovers, though, was kind of interesting. At some point in time, I graphed the number of hints published each day on macosxhints.com, from launch through 2008—a total of 12,051 hints.
Even if unlabeled, it’d be pretty easy to figure out where the major OS X releases occurred (except for 10.1, not sure what’s up with that?). And you can see a general downward trend in hints per day, as the OS became more established (and more locked down) over time.
In any event, I thought it was an interesting chart, and figured I’d toss it into a quick post instead of just sending it to the dustbin.