Miguel Arroz (Mastodon):

PaperVault stores information as sequences of QR Codes you can print and scan easily, protected by a password only you know. Data is secured using industry-standard robust encryption algorithms.

[…]

Vendor lock-in is a bad thing. Your data is yours and I don’t want to hold it hostage. Therefore, I’m publishing the data format used when printing to QR Codes. View the data format technical documentation ≫

Neat idea, seems to be easy to use and thoughtfully implemented, and it’s free. Scanning—and verification—can be done using an iPhone controlled from the Mac via Continuity. Larger documents get split into multiple QR codes, printed in a grid, but I was surprised how much one QR Code can store.

In the ’90s and early 2000s I worked for UserLand Software — Dave Winer was founder and CEO — on a Mac app called UserLand Frontier.

The app was a scripting system and hash-table-oriented database that powered the early blogging and podcasting worlds. (That sounds grand, but it’s probably an understatement — but this post isn’t all about Frontier’s impact on the web, so I won’t go into details.)

The app was implemented in two pieces:

• The kernel, written in C, implemented the database, networking, inter-application communication, various built-in data types, script compiler and evaluator and debugger, and so on
• The scripts used the kernel and implemented most of the actual app behavior

Since it was an app, it had plenty of UI — menus, contextual menus, buttons, larger UI components, and so on. What was brilliant was that you could, for instance, add and edit menus, and when you chose a menu command it would run your script. (Or when you clicked a toolbar button, etc.)

You could write an entire static blog publishing system and the UI to go with it without ever restarting the app. Click a thing, then see what happens in the app — and if it’s not right you’d edit the script, which would be automatically recompiled when called the next time.

In other words, there was absolutely no friction when it came to iteration. Write some code without restarting and see your changes immediately.

How good was this really in practice?

You might imagine that we could do this for an hour or so before having to make changes to the kernel. Not so.

In fact, for the first three years I was there (might have been longer), I never even saw the kernel code. I worked all day every day as a professional developer at the script level, never having to restart the app. Just iterating like this all day long.

You might also imagine that the app was sluggish and slow since much of it was scripts instead of C code. It wasn’t! Scripts could be slow for the same reasons any code could be slow (I/O, of course, and algorithms and data structures not suited to the problem at hand) — but the app never felt slow.

I’ll remind you of the timing: this was the ’90s. We worked this way for real, and we were amazingly productive.

A scripting language plus key bits implemented in C was more than fast enough for an app. Even all those years ago.

A scripting language built for productivity

I’m not writing this article to praise Frontier — I’m talking about it to make a point, which I’ll get to.

But I wanted to bring up a second aspect to this: it’s not just frictionless iteration that was so great, it was also the scripting language and environment.

One of the best parts of this was how easy persistence was. I mentioned the hash-table-based database. Hash tables could contain hash tables (Swift developers: picture a Dictionary inside a Dictionary, and so on).

(We just called them tables for short — but remember that these are hash tables, not tables in a SQL database.)

In any script, at any time, without any ceremony, you could read and write from the database simply using dot notation: user.prefs.city = "Seattle" would set the value of city in the prefs table which was contained by the user table. This value would persist between runs of the app, because it was stored in the database.

(You could also pass around addresses of things too — it was quite common to pass the address of a table to another script, so that the other script wouldn’t need to hardcode a location.)

It was utterly automatic. And it meant that while we did have to choose where in the database to store things, and how to structure our storage, we didn’t have to choose a storage mechanism. It was the database.

(Note: of course we could read and write files, and did so when necessary. But the point is that the database handled almost all our persistence and in a super-easy way.)

(Also note: the database had a UI. It was visible and browsable. You could and often did hand-edit it. Even the scripts lived in the database, and were addressable via dot notation, like everything else.)

We had nice things!

I’ll say again — this was in the ’90s, more than 25 years ago, and it was a great way of working on an app.

I’m not saying apps these days need to be Frontier-like in any details. But it seems absolutely bizarre to me that we — we who write Mac and iOS apps — still have to build and run the app, make changes, build and run the app, and so on, all day long. In the year 2025.

And it seems retro in the worst way that we’re still using anything other than a scripting language for most of our code. We should be using something simple and light that can configure toolbars, handle networking callbacks, query databases, manage views, and so on. And maybe with a DSL for SwiftUI-like declarative UI.

Almost none of that code needs to be in a lower-level language like Swift or Objective-C. It really doesn’t. (I say this as a performance junkie!)

It could be in Ruby, Lua, Python, or JavaScript. Better still would be a new language invented specifically for the problem of writing apps, something designed to make the common challenges of app writing easier.

We did have this stuff decades ago. Not for app making in general, sure — but now it’s 25 years later, and a company like Apple could make this real for all its app makers.

It’s easy to see why things are the way they are right now, and you can point to a string of good decisions. No doubt.

But we can think outside of what we have now and ask: what would make app writing easier? What would make it a better experience? How could we get more done for our users with fewer bugs and faster turnaround?

I’m not saying that Frontier’s specific choices are the answer — I’m saying that the combination of frictionless iteration plus a purpose-built scripting language was extremely powerful, and we could use those things now.

And at some point I suspect these things are going to be table stakes for any platform that wants to attract developers. If you were a new developer right now, would you pick Xcode’s build-and-run, edit, build-and-run, edit — plus the growing complexity of Swift — over something like Electron and JavaScript?

Random notes

Yes, I know about PyObjc and RubyCocoa. Without first-class support in Apple’s developer tools, these were never going to work as popular alternatives.

I also know about (and use) Swift playgrounds and SwiftUI previews. Neither of these are as satisfying to use as I’d like, and neither of these are nearly as great as frictionless iteration in the actual app.

I also remember Xcode fix-and-continue, which didn’t work well enough to solve the problem of frictionless iteration.

Anyway… One more thing about Frontier: we had a system where people could get updates to the app automatically via the web. Those updates were just serialized versions of scripts at various database locations, which would get unpacked and stored in each user’s database. (Those who opted-in, of course.) The app would not have to be restarted to get bug fixes and new features! And of course the updates were very small, since they didn’t include the entire app. This seems so futuristic, but we had this in 1999. Why couldn’t we have this now?

One of the most exciting additions in macOS Tahoe is Shortcuts automation, which (among many other things) allows Shortcuts to act when things move or change in the filesystem. More than two decades after Folder Actions brought those features to Mac OS X Jaguar, Apple has built a modern take on the feature that’s been popularized by third-party utilities like Hazel.

Unfortunately, Apple’s implementation of this feature is pretty basic—it’s a trigger that fires off a Shortcut and passes it all the information about what’s changed in the filesystem. The job of parsing, filtering, and acting on that information is entirely in the hands of the shortcut itself. This means that to take advantage of this feature, users will need a grasp of some Shortcuts fundamentals.

That’s what this article is for: to provide a quick guide to building a shortcut that acts on the contents of a folder when items are added to it. In this case, we’ll create a drop folder that moves Markdown files elsewhere when they’re added.

To get started, open Shortcuts and click on the Automation item in the sidebar. Then click the plus button in the top right corner. For this example, we’ll be choosing a Folder automation. In the ensuing dialog box, you’ll pick the folder you want to act on—mine’s called Drop It Here—and then check the box that specifies our shortcut will only run when an item is Added to that folder. I’m also going to click the Run Immediately option and uncheck Notify When Run, because I like my automations to run silently, like a submarine.

When that’s all done, you’re given the option to pick an existing shortcut, but I recommend choosing to make a new one that’s explicitly tied to this action. (It just keeps it tidier. And if you have a routine that you want to call from within the action, you can always use the Run Shortcut block!) With that, a new window will open containing a blank shortcut other than the first step, which is Receive Folder Change Summary As Input. That’s the step where the system will pass a Folder Change Summary item to your shortcut. The rest is up to you!

The simplest way to deal with this input is to add a Repeat With Each block, so the shortcut can loop one by one through all the added files and process them individually. Instead of acting on the raw shortcut input, click on the Shortcut Input field that’s automatically filled into the Repeat With Each block and, from the parameters offered by the Folder Change Summary variable, choose Added Files.

If your goal is to take every single item dropped in the folder and then act on it in some way, we’re done. You can delete them or copy them or zip them or move them, all within the repeat loop, and it will happen.

In this example, I want to take it a step further by applying a set of rules so that only certain files are acted upon. This being shortcuts, there are numerous ways to filter the list of added files to include only the ones we want. For very simple sets of rules, the easiest way to do it is probably to use the Filter Files action to act upon the Shortcut Input, and then set the Repeat With Each action to act on the filtered files.

Another approach is to use an If statement within the repeat block, and use that statement to test for the same attributes you’d use in the Filter Files action—in this case, I’m filtering on the File Extension being md for Markdown. Filtering files at the start is probably more efficient, but it doesn’t allow for some complex situations that I’ll address later.

You can also mix and match these approaches, doing basic filtering up front and then performing more specific tests down below. The goal is to, ultimately, have your shortcut only process the right kinds of files, as defined by you.

A complication: subfolders

Now here’s where it gets tricky. Apple’s automation doesn’t offer any choices regarding processing subfolders within your folder—any changes, any level deep in a subfolder hierarchy, will trigger the automation. Dan Moren and I spent some time working on this problem, and while the right solution is for Apple to offer a checkbox so users can decide if these automations should include subfolders, there are a few other ways to approach the situation. (Another alternative would be for Apple to supply the path of the folder the automation is acting on as a variable so that we could test against it.)

Dan’s approach is to strip the filename off of the incoming path using a regular expression and then strictly filter against the exact path of the top-level folder:

Mine takes more steps but is a bit more Shortcuts-y. I split the path of the incoming file by the slash character, creating a list containing all items in the file’s path. The last item will be the file’s name, but the next-to-last item will be its enclosing folder. (C’mon, Apple, why is enclosing folder not a variable available to me?!) Unfortunately, you can’t tell Shortcuts to get item -2 from a list like you can in Python, so instead I count the items in the list, subtract one from that number, and then get that item:

Once that’s all done, I can use the If statement to compare that enclosing folder to the name of the top-level folder I’m filtering, and only proceed if the file is in the top-level folder.

The bottom line

Automations for Shortcuts in macOS Tahoe really open up a lot of possibilities. I’ve built a half-dozen of them already. Yes, Apple should really make it easier, but once you get the hang of processing the folder change summary, you can really do amazing things. Here are some of the actions I’ve already built:

• Reveal files in the Finder when items are added to my Dropbox
• Copy files to my Desktop when the Upgrade MP3 files are added to Dropbox by our editor, Jim Metzendorf
• Convert certain image files to JPEG when they’re dropped on my Desktop or added to my Downloads folder
• Delete that Zoom installer that Zoom keeps downloading at the moment when I click on a web link before it launches Zoom
• Convert Southwest Airlines ics files into a proper format via a Python script before adding them to my calendar

Once you get used to building filters and using Repeat With Each Item blocks, this is a feature that can save you a whole lot of drudgery. And isn’t that exactly what user automation is supposed to do?

Devin Davies, the developer of Crouton whom Federico and I interviewed after he won an Apple Design Award in 2024, has released a new app called Cassette. It’s an app for browsing videos from the photo library on your iPhone or iPad that has a fun design twist.

Leaning heavily into the nostalgia of watching old videos of friends and family, Cassette sorts your videos using a VCR metaphor. Videos are organized by year and by collection, with video cassette art and a label identifying each. At the top of the screen is an old CRT TV with a built-in VCR. Tap a year or collection, and it loads into the TV with satisfying haptic feedback on the iPhone.

Videos running full-screen.

Tap the virtual TV, and the video goes full-screen with date and location data that’s reminiscent of a VCR’s UI. While watching videos, the app offers standard playback controls along with a shuffle button, buttons to share and favorite videos, and an eject button to return to your video collections.

Videos cycle from one to the next and then loop back to the beginning, where playback continues. You can also swipe through videos TikTok-style, skipping over any you don’t want to watch. Finally, there’s a ‘Take Me Somewhere’ button at the bottom that drops you at a random location in your video collection, eliminating the need to pick something yourself.

Most of the functionality found in Cassette is available in other video players, but that doesn’t make it any less fun or delightful. What sets the app apart is its focus on design and framing. From the drop, Cassette is designed to transport you to the past with its VCR-inspired UI and singular focus on videos, transforming into a sort of handheld time machine.

Cassette is available on the App Store as a free download. Certain features are only available via a $0.99/month or $5.99/year subscription or a $7.99 one-time payment.

Access Extra Content and Perks

Founded in 2015, Club MacStories has delivered exclusive content every week for nearly a decade.

What started with weekly and monthly email newsletters has blossomed into a family of memberships designed every MacStories fan.

Club MacStories: Weekly and monthly newsletters via email and the web that are brimming with apps, tips, automation workflows, longform writing, early access to the MacStories Unwind podcast, periodic giveaways, and more;

Club MacStories+: Everything that Club MacStories offers, plus an active Discord community, advanced search and custom RSS features for exploring the Club’s entire back catalog, bonus columns, and dozens of app discounts;

Club Premier: All of the above and AppStories+, an extended version of our flagship podcast that’s delivered early, ad-free, and in high-bitrate audio.

Learn more here and from our Club FAQs.

readingtoinfinity:

Wonder Woman Historia: The Amazons

I have been reading and enjoying Absolute Wonder Woman for some time. In reading about the series, I discovered it was considered a spiritual successor to Wonder Woman Historia, and so I sat down to read it. I am… not sure how to feel about it.

Sing, o muse, and tell me a story of women scorned
Of suffering inflicted by the violence of men
And sing of the seven goddesses, six defenders, one lapsed
Who sought to warriors make, and so brought gifts
And from these were born those women who could act
To protect women in their time of need: the Amazons!

It is not often writers remember that Diana of Themiscyra is a creature of myth and legends. She is not just a superhero, she’s an advocate and ambassador from the mundane to the strange. And if she comes from a people of myth and legend, what legends then must they have to tell?

For the good: God, what artwork! Every page drips with character and glorious, glorious detail. The goddesses alone are rendered more abstract than normal, in a way that makes them alien but also understandable; Athena has an invisible body but for a mask of steel for a face, and she’s the least freaky thing about the gods.

The story feels mythic as well, as befits the title. I can see where Absolute Wonder Woman set its similarities, for the gods are capricious and vain, and the male gods, especially, represent an order enforced on women to control them. The things they say are deeply uncomfortable and realistic, which is surprising when Zeus looks like a blue thundercloud most of the time. It’s a book that sticks to its guns and does its best to make the best version of this story.

And that story is… questionable.

I’m almost certainly not the best resource for what feminism and stories about feminism should and should not be. But one thing I always found inspiring about stories of the Amazons were that they were oppressed people who rose up and attained strength and self-actualization. To have the Amazons, then, be created by the six goddesses as defenders of women, unrelated to the suffering inflicted by men… it leaves a bad taste in my mouth. I had heard the Amazons were a group of women who learned to be strong, but in this story it was actually a bunch of other women warriors who did all the saving? I know that’s not the most charitable interpretation, but I can’t make this feeling go away, and I still don’t like this element of the story. (EDIT: on reading more about the story, they appear to be made from the souls of women slain by violence. While I think this design choice is excellent, the characters created by this processes are functionally their own people with no memories of who they were before, so the complaint stands)

Speaking of characters: the framing of the story flattens the characterizations of the gods. I am aware it’s framed as a story the Amazons tell themselves, so it’s not exactly unbiased. But the problem exists among the female and male gods, and not just the males.

Like, of the six goddesses - Demeter, Athena, Aphrodite, Artemis, Hestia and Hecate - only Athena, Demeter and Artemis get focus and characterization. Hecate is just “the person who says things cryptically” in their group, and Aphrodite is just the hot one (though the art does show she is very hot!). There’s a particular breed of girlboss feminism that’s on display here, implying the heavens would be better if the women were in charge, when we have seen all six act as badly as Zeus, if not quite so heinous in their actions.

This problem of characterization also exists amongst the Amazons. With the gods, I am at least understanding that the men had their worst traits and the women their best traits emphasized for the story. But the Amazons are almost wholly original characters, and we’re introduced to thirty of them right away. I cannot remember one distinct character trait among them beyond the shallow (this one is big and strong so she is boastful, and this one is of Aphrodite’s clan so she is curious and catty). They felt like Magni and Modi in God of War (2018), where they are less their own characters than their own, smaller versions of Thor, and so the original thirty Amazons mostly feel like alternate versions of the goddesses that spawned them.

This problem does not exist amongst the purely human Amazons. They are all of them defined by something other than their connection to the goddesses and so are free to form their own path. Hippolyta, in particular, gets a strong, focused lens on her personal journey and growth as an Amazon.

I do not wish to prescribe what stories “should” have been. I want to take the stories at face value and determine where and how they succeed or fail at connecting with me. But the version of this story I wanted is included in miniature with the seventh tribe of Amazons: scared women on the outskirts of society, rising up to defend themselves and liberate others like them. It feels so obvious to have the story just be about them, and their empowerment by the goddesses.

But that was not the story they wanted to tell. The story they told is gruesome and sad, but also frustrating and tiring. For the art alone I would recommend reading the book, and there’s a good chance you’ll find something worthwhile along the way. Bring it back and share it with me when you get the chance.

I recently wrote about duplicating iCloud Drive and iCloud Photos to a network-attached storage (NAS) system. This struck a nerve for folks who want to keep full-resolution backups of their Photos Library when they don’t have enough local storage. (That column was focused on not needing to keep your Mac powered up to handle these iCloud offline backups when the Mac was otherwise not in use.)

Readers wrote in or replied via social media with strategies and workarounds, as well as suggesting three software options that can let you sync iCloud Photos outside of Apple’s limitations. Meanwhile, a developer dropped a line to Jason about his new app, which can sync and archive iCloud Photos and files from iCloud Drive.

This feels like it shouldn’t work, but it does

Six Colors reader Mark has a rather elaborate process of keeping a local backup of his Photo Library without enabling full-resolution downloads for his primary account and startup volume.

He started by creating a Photos Backup macOS user. While logged into Photos Backup, he logged into his primary iCloud account, the same one he uses in his main macOS account. On that backup account, he set up an external 2 TB drive and, holding down Option while launching Photos, created his Photos Library on that drive.

He then used Photos > Settings > General to click Use as System Photo Library, which is required for iCloud Photos syncing. He also enabled Download Originals to this Mac in Photos > Settings > iCloud. Because he also has a Backblaze subscription, he enabled that service to back up his external 2 TB volume as an additional off-site protection.¹

This was all a one-time setup. Now, whenever he wants to perform his on-demand backups, Mark:

1. Attaches the 2 TB drive.
2. Logs into Photos Backup, which effectively starts the background syncing.
3. Uses Fast User Switching to return to his main account.

When he needs to leave his current location, he swaps back to the Photos Backup account, logs out of it (Apple Menu > Logout Account Name), unmounts the external volume, and he’s all set. I have not tested this, but Mark says it works, despite the complexity.²

Mark asked, “Am I crazy, or is this an OK solution?”

You’re not making an irrational decision, Mark! This is a perfectly reasonable way to achieve results with limited options.

The only failure point I can see is very unlikely:

• You’re on the road.
• You create, modify, or capture new images on devices you carry with you.
• Those devices are lost or destroyed after syncing.
• And your iCloud.com account becomes inaccessible, or the data stored there is corrupted.

Losing your device or having it damaged beyond recovery before syncing is a scenario you can’t avoid in the above method, anyway.

Image Capture and offloading

Reader Jonathan wrote in with a strategy he was using for media management because his family opted to pay for just 200 GB of iCloud+ storage. He also has a Backblaze subscription. Instead of keeping everything in the cloud, he would offload images from time to time:

Normally, I would log into iCloud on my Mac, go to Photos, and then download the latest files to my external hard drive that gets backed up to Backblaze. Is that the best method?

As we corresponded, I found that Jonathan was also curious about how he would copy files that were not downloaded locally if optimization were enabled.

I had not thought of this strategy, either, which can work:

• If optimization is off: You can move media from your Mac’s Photo Library at any time without preparation. The size of your library on your drive is within about 20% of the storage it takes up on iCloud.
• If optimization is on: You have to stay more on top of adding images and videos so you don’t accidentally fill up your iCloud storage.

To remove media from a Photos Library for an archiving operation like Jonathan employs:

1. Select the media in Photos for Mac.
2. Choose File > Export and one of the options described below.
3. Press Delete or choose Image > Delete Photos.³
4. This moves media to the Recently Deleted folder. After ensuring you have an additional backed-up copy, such as through Backblaze, Time Machine, or other methods, go to the Recently Deleted folder, click Delete All, and confirm deletion.

Which of the two Export submenu items should you opt for?

• Export X Photos: The export includes any modifications made in Photos and any metadata changes. The photo is converted to the format (Photo Kind) with any quality, color profile, and size options set. (Set to Full Size to preserve the original dimensions.)
• Export Unmodified Originals for X Photos: The original photo as imported or created will be exported, including in any supported RAW format, with all modifications ignored.

You can also make life easier on yourself by springing for PowerPhotos 3 ($40), a robust Photos Library management app. It can move items between libraries, split and merge libraries, and much more. The operation above would be far simpler: just hold down the Command key and drag the media from one library to another within the app.⁴

Jonathan has used Image Capture in the past to copy media from his iPhone to the external drive, although he had optimization turned on for the phone, so he wasn’t sure if he was copying full-resolution images or low-resolution thumbnails.

Apple will never copy low-resolution images through sharing or copying from the Photos app or using Image Capture. However, with optimization enabled, Image Capture shows only images and videos that are downloaded to that device. On my iPhone, for instance, Image Capture showed about 7,000 items available for copying; my Photos Library has nearly 70,000.

I command you to download and sync

There are four software solutions—two fully developed apps, two Python command-line packages—to back up an iCloud-linked Photos Library, even when optimization is enabled. Each has unique elements, including one of the Python tools working via a web connection. (I have not tried any of these packages or apps yet! And using Python for this is definitely on the edge of my personal geekiness level.) I also shout out Carbon Copy Cloner for iCloud Drive backups.

Here are the details. The three Mac apps are:

Photos Backup Anywhere (App Store, $10): Allows simple background backup of the Photos Library to any local destination, including NAS. The app temporarily downloads any newly synced images that aren’t stored locally. (Referral via reader Ted)

Parachute Backup (App Store, $5): A slightly more elaborate background Mac tool that lets you choose to backup either or both the Photos Library, including iCloud-stored images and iCloud Drive. (Newly released, referral via the developer, Eric Mann)

Carbon Copy Cloner ($50): If you’re looking just for iCloud Drive file backups, CCC can download iCloud-stored files and then dismiss the local copy after backup—usually. There are oceans of provisos, as Bombich Software explains in this support note.

If you’re into command lines, installing packages, reading documentation, and tweaking results, you may find that either of the two options above will let you back up or create different kinds of archived copies that hit the sweet spot for you:

iCloud Photos Downloader: Adam Bodner pointed me on Mastodon to iCloud Photos Downloader, a Python-based system that lets you perform various syncing and download operations, including copying media out of your library and then deleting it from iCloud Photos. The app communicates with Apple’s servers directly via a web connection. I’m not sure how they have made this all work, but it apparently does!⁵

OSXPhotos: Another Python-based option, also from a Mastodon colleague, comes via geraint, who pointed me to OSXPhotos. Rather than talking to iCloud.com, OSXPhotos routes its requests through the Photos app. However, it also has a remarkable range of capabilities, including detecting if an optimized image is in place and forcing a download with the correct options selected.

[Got a question for the column? You can email glenn@sixcolors.com or use /glenn in our subscriber-only Discord community.]