Update: After I posted this, Brad Oliver contacted me on Twitter about the frame rates for DiRT Rally—he commented that the fact that they were clustered around 60fps made him think I’d left vertical sync (Vsync) on…and he was right. I’ve updated that section with the modified results, as well as one additional comparison I forgot to include the first time.
Oh, and in case you don’t know Brad…he was directly involved in porting DiRT Rally to the Mac for Feral, so he knows his stuff! Thanks Brad!
In part one of the comparison between my old and new iMacs, I provided a brief overview of the new machine, tech specs for both, and a number of benchmarks. (I also tested the video card against a Windows GeForce GTX 1080, and posted a slide-over image that demonstrates the wider color gamut on the new Mac.)
In today’s second (and final) part, I’ll take a look at video processing performance (via iMovie), how well the new iMac handles gaming, and then wrap up the whole series.
My 2019 iMac has the new AMD Pro Vega 48 video card, the fastest video card Apple has offered in a (non-Pro) iMac. But just how fast is it? I’ll have more to say about it in an upcoming “games shootout” with my 2014 iMac, but I was also curious as to how (badly) it might compare to the video card—an NVIDIA GeForce GTX 1080—in my 2017 Frankenmac.
While I’d love to be able to compare the performance under macOS on Frankenmac, that’s not possible as I uninstalled it a while back—I’d been unable to update to Mojave due to a lack of NVIDIA drivers for Mojave. (Which is related to all of this, in that you cannot use an NVIDIA card—with acceleration—in Mojave, even in an external GPU box, because it seems Apple and NVIDIA aren’t on speaking terms right now.)
However, because a number of the benchmark apps I used in my 2019 iMac vs 2014 iMac—Part One comparison test also run on Windows, I was able to do some head-to-head testing, even if the difference in the OS adds a layer of unknown to the results.
Going in, I was pretty sure I knew what the results would show: The Windows PC was going to crush the iMac in anything graphically related, but lose in the CPU tests. While the AMD card is a big step up from previous-generation iMacs, it’s nowhere near bleeding edge—it’s more like “minor scrape” edge—in the Windows world.
Anyway, I ran a bunch of tests, and the results were pretty much as I expected…
When I replaced two aging laptops with a new MacBook Air, I posted a detailed analysis on the performance differences between the three machines. When Apple released the new iMac with a ninth-generation Intel processor and a higher-end AMD video card, I felt the time had come to replace my similary-aged 2014 iMac…and with that replacement, the opportunity to do the same sort of “old vs. new” comparison for others who may be at or over the five year mark with their desktop Macs.
As with the prior comparison, this is not a review of the 2019 iMac—I’ll leave that detailed work to others who do it much better than I. I’m mainly interested in comparing this machine’s performance to my current iMac—and for the Geekbench 4 tests, with the 10-core iMac Pro.
Note: If you read the first write-up, some of the following explanatory language will seem quite familiar (as in identical)—where it made sense, I simply pasted the same test explanations I used in the prior article.
Externally (at least from the front) I can’t tell the two iMacs apart—if there have been any user-facing changes in the last five years, they’re not visible to my eye. From the back, of course, things are a bit different, as Thunderbolt 2 has made way for USB-C/Thunderbolt 3. For me, this means I need a couple of adapters—my RAID is Thunderbolt 2, and I connect a second HDMI display via the other Thunderbolt port. I haven’t yet installed/tested these, though I’m hopeful they’ll work.
After logging into both machines, though, it’s apparent that something’s different with the new iMac’s screen. For example, here’s a screen from the GpuTest app. (I had to grab the frame from an animating scene, which is why they’re not identical shapes.)
As screenshots probably wouldn’t reveal these differences, I used the iPhone to take photos, then fixed any skewing and cropped them (but didn’t adjust color, brightness, etc.) in Acorn.
Both iMacs were set to the default color profile (iMac), and had identical brightness settings.
A fair number of my apps are still 32-bit—see how many you still have—though many I don’t really care about all that much. But there’s one suite of apps that I use every day, usually multiple times a day: Fujitsu’s ScanSnap apps. This is the software bundled with the ScanSnap ix500 scanner.
While Fujitsu has been good about updating their software in the past, I was a bit concerned about the upcoming 64-bit transition. So I both tweeted at them and sent them an email. I haven’t seen a reply on Twitter, but a (clearly form letter) reply to my email is at least somewhat encouraging:
There is no problem in the behavior of the application or the OS concerned. The message is only inform that the application needs to be modified for compatibility with next-generation macOS (which should be available near the end of the year). PFU is going to resolve this, but the resolution date is not set yet. In the meantime, please continue using the latest version of the software available.
This blurb was obviously prepared as a response to those complaining about the new 32-bit warning dialog in macOS 10.13.4, but it does seem to address the longer-term question: Fujitsu is planning to “resolve this,” which hopefully implies 64-bit versions are in our future, though at some not-yet-disclosed date.
There are very few things in my workflow that I couldn’t replace…but replacing my ScanSnap and everything it does for me would be quite difficult. Hopefully we’ll see a 64-bit ScanSnap suite before this fall’s deadline.
The other day while browsing the Mac App Store, I clicked on an app’s web site link, only to be greeted with this lovely “Can’t Find the Server” error message in Safari…
That got me wondering about just how often that happens—how many apps are out there that are still in the store, yet their developers have closed down their work and moved on to other projects? I thought it might be interesting to look at my App Store purchases and see just how many of them had broken web site links in their App Store entries.
Then I thought that as long as I was looking at each of my purchases, I might as well collect some additional data. So I put together a simple FileMaker Pro database with a few fields for each app…
During my spare time over a few days and nights, I went through every entry in my App Store Purchased list (after unhiding some apps that I’d hidden). I installed them (if they weren’t already installed), tried to run them, and completed the above data card for each app.
I then tried to answer some questions about my App Store purchases over the years…
How many apps have I purchased? 
How many do I still use? 
What types of apps do I purchase? [A variety; lots of games]
How many appear to have no-longer-there developers? 
How many of the apps are still in the App Store? 
How recently have those apps been updated? [Check the chart]
If you want more detail than the [bracketed tl;dr notes] provide, keep reading…
As part of this longer post on my purchases from the Mac App Store over the last seven years, one particular bit really struck me: Based on my purchases, at least, there are a a lot of rarely-updated apps—and games in particular—in the Mac App Store.
Of the 116 purchases (or free downloads) I’ve made since the App Store opened, 90 are still available in the App Store today. At first glance, that seems pretty good—78% of what I have is still in the App Store. But it doesn’t look quite so good if I examine when each of those 90 apps was last updated:
Yes, 51 of those 90 apps (57%) have been updated within the last year, and that’s good. But what’s not good is that the remaining 39 apps (43%) haven’t been updated in at least a year—and of those 39 apps, 21 of them (over half!) haven’t been updated in four or more years.
Digging into those 21 apps reveals that four of them are utilities, five are general use apps, and 12 of them are games.
The coming of “not without compromise” 32bit app usage in the fall 2018 macOS release finally forced my hand: I was going to have to update my single longest-used app, Quicken 2007. I’ve been using Quicken in some form since 1994, but stopped with Quicken 2007—I found the newer versions worse than Quicken 2007, so I never upgraded.
Yes, I was using an eleven-year-old app to track our family’s spending and investments. Why? Basically because it worked (most of the time), and I didn’t like any of the alternatives, which I would occasionally test. But Quicken 2007 was showing its age. In addition to its 32bitness, it had other issues: The UI was tiny and horrid, the windows never opened where I closed them (Moom‘s saved layouts to the rescue!), and online access to my accounts was nearly non-existent. Worst of all, it would crash on occasion, necessitating rebuilding all my data files. It was finally time to find its replacement.
After looking at all three, I surprised myself by deciding that Quicken was the best tool for our use. Going in, I was dead set against it, mainly due to its annual subscription structure. (I hate subscription software in general, but as it turns out, this one isn’t really a subscription.)
Read on for brief overviews of each of these three apps (with more detail on Quicken) and my rationale for deciding on Quicken.
I use a ScanSnap ix500 scanner to scan a lot of paper into PDFs on my iMac. And thanks to the ScanSnap’s bundled optical character recognition (OCR), all of those scans are searchable via Spotlight. While the OCR may not be perfect, it’s generally more than good enough to find what I’m looking for.
However, I noticed that I had a number of PDFs that weren’t searchable—some electronic statements from credit cards and utility companies, and some older documents that predated my purchase of the ScanSnap, at least based on some tests with Spotlight.
But I wanted to know how many such PDFs I had, so I could run OCR on all of them, via the excellent PDFPen Pro app. (The Fujitsu’s software will only perform OCR on documents it scanned.) The question was how to find all such files, and then once found, how to most easily run them through PDFPen Pro’s OCR process.
In the end, I needed to install one set of Unix tools, and then write two small scripts—one shell script and one AppleScript. Of course, you’ll also need PDFPen (I don’t think Pro is required), or some other app that can perform OCR on PDF files.
When this tip was first posted, it didn’t work right: The log command ignored the --start, --end, and --last parameters. Regardless of what you listed for parameters, you’d always get the entire contents of the log file. I’m happy to note that this has been resolved in macOS 10.13.4, as log now functions as expected:
$ log show --last 20s --predicate 'processImagePath CONTAINS[c] "Twitter"'
Filtering the log data using "processImagePath CONTAINS[c] "Twitter""
Skipping info and debug messages, pass --info and/or --debug to include.
Timestamp Thread Type Activity PID TTL
2018-03-30 09:26:15.357714-0700 0xc88a8 Default 0x0 5075 0 Twitterrific: (CFNetwork) Task <9AD0920A-7AE7-4313-A727-6D34F4BBE38F>.<250> now using Connection 142
2018-03-30 09:26:15.357742-0700 0xc8d7a Default 0x0 5075 0 Twitterrific: (CFNetwork) Task <9AD0920A-7AE7-4313-A727-6D34F4BBE38F>.<250> sent request, body N
2018-03-30 09:26:15.420242-0700 0xc88a8 Default 0x0 5075 0 Twitterrific: (CFNetwork) Task <9AD0920A-7AE7-4313-A727-6D34F4BBE38F>.<250> received response, status 200 content K
2018-03-30 09:26:15.420406-0700 0xc8d7a Default 0x0 5075 0 Twitterrific: (CFNetwork) Task <9AD0920A-7AE7-4313-A727-6D34F4BBE38F>.<250> response ended
Log - Default: 4, Info: 0, Debug: 0, Error: 0, Fault: 0
Activity - Create: 0, Transition: 0, Actions: 0
This makes it really easy to get just the time slice you need from the overly-long log files. You can use s for seconds, m for minutes, h for hours, and d for days as arguments to these parameters.
This article provides a nice overview on interacting with log and predicates to filter the output—there’s a lot you can do to help figure out what might be causing a problem.
Today I wanted to do something that seemed simple: Add a pin to Apple’s Maps app on macOS High Sierra, then rename the pin.
But after trying everything obvious, I was stumped, and took to both Twitter and web searching. About the same time I found the answer on the web, I also received a tweet from @tmneff with the same answer.
This seems absolutely crazy, but here’s how you name a dropped pin in Maps on macOS—these are just the instructions from the linked web page, with a few added screenshots:
Drop the pin.
When the info box appears, click the small circled ‘i’ at the right.
In the new window that appears, click the heart (Favorite) icon, to make your new pin a favorite.
Click in the search bar, then highlight the Favorites entry and click it.
When the list of favorites appears, you’ll see an Edit box at the lower right corner; click that, and you can then click-and-edit any of the pin names as you would a filename in Finder.
You can also delete favorites here by clicking the ‘x’ icon.
Click Done, and your custom name should be saved with the dropped pin.
Apparently in iOS, you’re prompted for a name when you tap the Favorite icon—that makes a lot sense, and macOS should follow the same convention. But it doesn’t, sigh.