This post has a long introduction that appears to go off in a direction opposite of what the title suggests, but bear with me – I’ll get to it eventually.
Everyone takes photos and videos on their phone, yet only few have robust backup schemes in place. Most rely on the cloud provider of their choice keeping their photos safe, which is fraught with risks: Someone could social-engineer their way into one’s account and wreak havoc. Algorithms gone rogue banning user’s accounts isn’t unheard of, either. Silent sync breakdowns can go unnoticed for months. I could go on. And what happens to the data if the service goes out of business on short notice?
As a result, the way I handle photos taken with my phone is somewhat idiosyncratic and, admittedly, unnecessarily complicated. So idiosyncratic, in fact, that I’ve written an extensive Python script which crawls the Photos.app-internal database and archives its contents in a format I like.
How I archive my photos
At the time of writing, my process is basically this:
Capture media on my iPhone 71, which is backed up to iCloud whenever a wifi signal is within reach.
That’s just temporary – in case I drop my phone off a cliff or into an ocean, or both at the same time, before I can get back to my computer and proceed with step 2.
Import those photos, videos, slomos, timelapses, and panoramas (or at least any new arrivals since the most recent import) into Apple Photos on my aging MacBook.
This also imports other media that’s ended up in the phone’s Photos library, such as photos edited and posted with Instagram (great, I want to keep those), but also photos and videos I’ve received via WhatsApp (which I’m not yet sure whether or how best to archive).
This is where my bespoke Python script comes in: It queries the SQLite database2 that Photos is built around, copying any not-yet-archived media into my archive3 while categorizing and renaming them to my liking. How this works is explained in the readme, it’s not important for the remainder of this article.
Now, this could in theory continue for a couple of years without either my phone or my laptop running out of space, but I like to be proactive about these things. So, not yet sure how to handle WhatsApp photos, I was looking for a way of batch-deleting photos off my phone without touching anything in the WhatsApp album.
Shortcuts to the rescue!
Shortcuts makes this filtering step incredibly easy, and it works surprisingly well – much better than other components of this photo purge process, as I’ll relay in a minute. Here’s the shortcut in all of its two-step-plus-a-stern-warning glory:
After around a year of using an iPhone, I had accumulated just shy of 6000 photos, so it took a few (very4 paranoid) invocations of the shortcut to clear them all out. The limit of 1000 photos at a time is arbitrary, it’s mostly there to keep any is-it-working-or-stuck anxieties at bay – deleting more than 1000 photos at once can take a minute.
Some cleanup required
I followed this up by wiping the Photos library on my Mac (after making sure5 my Python script had done its job correctly), which was just a case of pressing ⌘A, then ⌘←, and finally emptying the trash that’s kept inside Apple Photos – this took a good 15 minutes, I’m not entirely sure why.
Note that “Delete Photos”, the final step of the shortcut, just means moving them to the “Recently Deleted” section in the Photos app. Media banished to this section disappears on its own after 30 days, so that wasn’t an issue directly – rather, Photos.app on the Mac doesn’t seem to ignore this section as it should, instead showing the just-deleted media as fresh and ready to import.
As a result, I needed to completely remove the discarded photos from the phone, but this wasn’t wholly trivial: Whilst there is a “Delete All” option in the “Recently Deleted” section, it kept churning for a long time without any discernible effect (apart from most thumbnails going blank). In the end, I needed to select all photos individually and delete them in batches, which was made sort of tolerable thanks to the swipe-to-select functionality provided by
Yes, getting all of this set up and documented took the better part of a morning and wasn’t going to be necessary for a while – but having figured it out, I’m sure it’ll go faster next time, or if I’m ever in a hurry. Or so I tell myself.
Frankly, I’m surprised that it exists in a non-encrypted, sort-of-user-accessible way, and I wonder how long it’s going to remain exposed, with Apple being Apple. This is one reason why I haven’t upgraded to macOS Catalina yet (the other main reason being Photoshop CS6’s 32-bit-ness). ↩
The archive takes the shape of neatly sorted files located on a bunch of mirrored, independent external hard drives. That’s far from ideal, but thanks to the versatility of “dumb” files, this scheme could trivially be extended to include a NAS and an S3 bucket. ↩
Another quadruple take was performed at this stage. It might’ve been a quintuple take, actually. ↩