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 reviewing lists of alternatives—and asking on Twitter—I focused on three apps: Bantivity, Moneydance, and Quicken 2018 for Mac.
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.
March 29 2018 Update:
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.
And now, here’s the rest of the original post…
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.
A friend asked if there was a way in Photos to see which albums a selected photo had been added to. This is one of those things that would be incredibly easy for Apple to provide: Select a photo, press Command-I, and in the info window, you could see a list of all albums containing the selected photo.
Unfortunately, Apple doesn’t seem to think people might care about what albums a photo is in, so this feature exists only in my mind. Thankfully, Mac users Jacques Rious and léonie wrote an AppleScript to solve the problem. I used the first instance (version 4) of the script in that post and it worked fine in High Sierra. (In case Apple ever decides to remove its forums, I’ve recreated the script below.)
To use the script, paste it all into AppleScript Editor and save it as an application (or you can just run it in AppleScript Editor). In Photos, create a top-level album (I named mine Find Albums Photo Is In), and place the photo you want to know about into that album. Leave it selected, then run the AppleScript. You’ll see one dialog stating what photo is being used, then after a bit, you should see a results dialog, like this:
As you can see, the album used for the search is included in the results; someone with better AppleScript skills than I could probably modify the script to exclude that album (any takers?). While I’d much prefer Apple include this feature directly in Photos, at least there’s an alternative when you need this information.
This morning on Twitter, Antonio asked…
I thought “Well, that’s an easy question to answer—via the Mac App Store, of course.” As it turns out, that’s the right answer, but it was much harder to find than I expected it to be. I started on the Purchased tab in the Mac App Store app, where you can (theoretically) see all past purchases, including prior Mac OS X versions. However, those old releases stop with Mac OS X El Capitan from 2015; neither Sierra nor High Sierra are listed.
Next I tried searching the Mac App Store for Sierra, but that nets only Server and High Sierra, and a few apps that appear to have gotten away with using “Sierra” in their descriptions:
I then tried the Apple Developer site, but they don’t offer Sierra for download either.
Somewhat stumped, I then started searching, and after way too many attempts, I finally landed on this useful page at Stack Exchange, which attempts to explain how to download all older versions of Mac OS X/macOS. Here’s the relevant bit for Sierra:
For OS versions since Sierra.
Sierra itself has now vanished from everybody’s Purchase History. However, Apple are keeping Sierra fully available, even though High Sierra is out. No Apple ID is required.
Apple KB – How to download macOS Sierra
Sierra – Direct download link from the App Store
Given how much trouble I had finding this page, I thought I’d post it here for anyone looking for Sierra. Going forward, keep that Stack Exchange link handy, as it should be updated in the future as new releases come out.
When the third release of macOS High Sierra came out, I charted the pace of its updates compared to all prior Mac OS X/macOS releases. I said I planned to keep that chart current, so here it is now that the fifth High Sierra update (10.13.3) is out. (Note that 10.0 has vanished from the chart, because it had only four releases.)
Click the above image for an in-window larger version, or just view the full-size version directly.
As you can see, macOS 10.13 took just 120 days to reach its fifth update; that’s nearly half the time (229 days, macOS 10.11) as the next quickest release.
Is it better software updating, catching more bugs earlier and pushing releases faster, or is it just buggier software receiving multiple quick-release critical updates? I obviously don’t know, but my perception as a user is that it’s the latter.