Dealing with ‘new” OneDrive

So the changes that bit me in the tuchas in this post have come to production OneDrive, and I’m almost surprised to see my reaction was on the mild side. I’m not surprised, the forcing of FoD, aka “deleting a bunch of files from your hard drive without so much as a by your leave” was a shortsighted idea that on par with the decision to make the Oozinator and its infamous ad.

For the more technically astute, there are two technotes that apply: gives you some tips on configuration, including the infamous /setpin switch, which in theory would allow you to better automate keeping copies of things locally. In practice, it’s awful to use, see my original post for my experience. Like really, it’s a dumb implementation, and that is the kindest thing I can say. has more useful information, in particular the FilesOnDemandEnabled key, which can be set to off. The OneDrive team of course doesn’t recommend doing this. Right now, the effort involved in caring less about the OneDrive team’s wishes with regard to Files-On-Demand would be considerable, so I shan’t bother. Suffice it to say, their wishes on this issue have as much value to me as my turning off Files-On-Demand did for them.

To be blunt: were a random script or executable do what OneDrive is doing here, namely deleting data without so much as a warning, we would call that script malware and warn the world about it so suitable countermeasures could be implemented. That OneDrive gives you an as yet manual method to eventually get all the files that were already local back to that benighted state doesn’t change the malware-like behavior OneDrive is engaging in here.

As far as what I’ve seen from the OneDrive team on this:

We didn’t have many users turning off Files-On-Demand, this is not a real problem

The usage or lack of usage of Files-On-Demand is not the problem. It is OneDrive deleting large amounts of data without the user having any real warning about it, nor option to refuse. It is even worse for people such as myself who had turned Files-On-Demand off, and had OneDrive decide, “nah.”

We give you a way to still have all your files local

If I total your car while you’re asleep, and I pay for its replacement, you are still without a car for a non-zero amount of time. The fact that it’s not costing you any money doesn’t reduce the amount of time to get back to where you were before I totaled your car to zero. Same thing here. This also assumes that everyone using OneDrive has unmetered, high bandwidth (at least 100Mbps) connections to the public internet, and the time to restore potentially GB of data. 26.2GB in my case. Even with Google Fiber, that’s not zero time. There is no small amount of elitism and arrogance in that statement.

Apple’s API changes required this

They required you to move the OneDrive folder, they most certainly did not make you force everyone to Files-On-Demand, insinuating otherwise is quite insulting to your customers’ intelligence.

That there is still some method to undo this…nonsense does not make it zero bad, or zero damage. This needs to be fixed. There is nothing so amazing about Files-On-Demand that makes this decision worth the damage this has caused OneDrive, and I think it a shame that the team’s mindset comes from such a place of elitism and deliberate ignorance.

Portable PowerShell In an Application Bundle

So obviously, I have a fondness for PowerShell on macOS, but one of the downsides with really integrating it into things is being able to rely on it as a resource. It’d be nice if you could just include it with a script or bundle, so that it was available for that script or application to use as needed.

Well, turns out, you can, thanks to the PowerShell team making some really good decisions in how they distribute PowerShell on macOS. If you download the installer bundle from the PowerShell github site, (the current stable version as of this post), and you open the bundle up in something like Pacifist, you realize that all the important powershell bits outside of the man page and an app launcher are all in the same directory:

Everything is in that directory

When I saw that, I decided to do a really quick and dirty test of my “Portable PowerShell” thought. So using Script Debugger, I created a script bundle, which is an AppleScript, but in a bundle format, which means it has the Contents/Resources/ tree. I then copied the usr/local/bin/microsoft/powershell/<version> bundle from the install package into the resources folder. In the script bundle itself, I set up the path to that bundle:

set thePwshAlias to ((path to me as text) & "Contents:Resources:powershell:usr:local:microsoft:powershell:7-preview:pwsh") as alias
set thePwshPath to quoted form of (POSIX path of thePwshAlias)

Then the statement that does the test of this:

do shell script thePwshPath & " -c \"Get-PSDrive\""

And the expected result:

Name           Used (GB)     Free (GB) Provider      Root                                 
----           ---------     --------- --------      ----  
/                 782.49        149.06 FileSystem    / 
Alias                                  Alias 
Env                                    Environment 
Function                               Function
Temp              782.49        149.06 FileSystem   /var/folders/0_/h5qr4rfj2     
Variable                               Variable                    

Which was the expected result. Now, some caveats:

  1. This is literally the extent of my testing. Making this work with custom modules, etc, is going to involve more work on the setup, if that’s even possible.
  2. I HAVE NO IDEA IF THE POWERSHELL LICENSE ALLOWS THIS. If the lawyers get flustered and stern, telling them “Well John said you could do it” will result in me laughing and saying “Yes, technically this is possible, I made no claims as to legality. It may be fine, it may be verboten, I have not checked either way.

My thought on this is that if you were creating a cross platform app and you wanted to implement PowerShell for that app, this is a way to ensure it works on macOS without making the user do a bunch of separate installs. It’s a proof of concept that happens to work, so coolness. As I get time, I’ll beat on it more, there’s some real potential here.

Also, many thanks to the PowerShell team for doing things in a way that made this trivial to test and play with.

Things AppleScript does better

Seeing as I’ve (deservedly) been slightly hard on the Apple automation team(s), I’d like to point out that for all its faults, there are things AppleScript does far better than PowerShell, and things that Microsoft could learn from to improve.

  1. Basic UI functions: I’m talking about really basic things that you might want to put in a script, like a UI for choosing a file, a folder, etc. Like this isn’t even close, PowerShell at best is almost as easy as AppleScript for some things, but at worst…ugh. Like to choose a new file, that’s pretty simple:

    $FileBrowser = New-Object System.Windows.Forms.OpenFileDialog -Property @{ InitialDirectory = [Environment]::GetFolderPath('Desktop') }

    $null = $FileBrowser.ShowDialog()

    That’s not significantly worse that AppleScript’s “Choose File” dialog, which forgoes only the ShowDialog() method. The issue is that depending on how you’re running the script, the file browser may show up behind other windows, and there’s no easy way to force it to the front.

    Where PowerShell falls over is if you want the user to enter text in a dialog box. For AppleScript, it’s literally a single line:

    set theReply to text returned of display dialog "I am a dialog" default answer "default text"

    That’s it. That’s all you need. You can also get the button returned or if the gave up flag hit, it’s all in a single record if you want all three.

    In PowerShell, this is like around 30 lines of code where you’re building the OK and Cancel buttons by hand, setting their sizes, etc. That’s ridiculous for something that simple. The same thing for building a list of text items to choose from. In AppleScript:

    set theChoice to choose from list {"one", "two", "three"} with title "Choose from the list" with prompt "Pick something" default items {"one"} with multiple selections allowed without empty selection allowed

    The result is a list of choices.

    PowerShell, again, you have to build the entire dialog by hand. Like, if i’m doing .NET dev in a text editor, sure. But for what should be a higher-level scripting implementation, that’s ridiculous.

    Ironically, in PowerShell in macOS, you can integrate PowerShell with AppleScript UI primitives like Display Dialog easier than you can do the same thing in Windows. Y’all, come on. This is just stupid.
  2. Interacting with applications. The syntax for AppleScript gets a lot of guff, but launching an application in AppleScript and similar is far more intuitive and easier to learn than in PowerShell.

    tell application “Microsoft Excel” to launch

    or if you want it to launch and become active:

    tell application “Microsoft Excel” to activate

    With PowerShell, it can be simple if the application is in a known location, but if not, you have to know the path, etc. Which can be more than a little painful, but that’s an OS issue.

    Being able to just tell an application to do stuff, “tell application “Microsoft Excel”… is also nice when actually interacting with the running application. As opposed to working with the running copy of Excel:


    This is the part of a higher level language that shouldn’t require this level of work. The level of detail needed to do simple stuff in PowerShell is way higher than it should be.

There’s other items, but some of them depend on syntax preferences. I find the english-ish nature of AppleScript to be helpful, other people hate it, I hate dot languages, I find them unnecessarily obtuse. The two items I listed here cover rather a lot, so it’s not just “oh two things”.

Honestly, this is part of the reason I find Apple’s hostility towards user-created automation via things like AppleScript so infuriating. The OS has a good base, only needing a better system-level automation framework so you can have more coherency across the board for automation, but instead of building on that foundation, it really seems like Apple is moving to gut the entire thing and force you into Shortcuts, Swift or nothing. That’s really quite dumb.

Call PowerShell Commands from AppleScript/JXA

This will probably work within ASOC too, since do shell script works there. On macOS, the powershell “executable” is pwsh, usually in usr/local/bin/pwsh for the non-beta versions. If you run pwsh -h, you see that the pwsh utility is quite versatile, and by using the -c parameter, you can treat it like osascript, in that you can pass it a single command as a string, or an entire script block. You can also pass it a PowerShell script with the -f command. So to use this from within AppleScript/JXA, (AppleScript syntax shown), it looks like:

do shell script "/usr/local/bin/pwsh -c \"Get-PSDrive\" "

You can also use this with custom modules:

do shell script "/usr/local/bin/pwsh -c \"Get-MacInfo HardwareModelID\" "

So if you want to use a slightly more coherent shell environment like PowerShell from within AppleScript, you can.

Manually Install PowerShell Modules in macOS

Okay, this is really just so it maybe gets picked up by Google. If you have a custom/homegrown PowerShell Module you want to install in macOS, and have them “live” there as it were, you want to copy the module folder with at least the .psd1 and .psm1 files in it to: ~/.local/share/powershell/Modules. Make sure the module folder has the same name as the module. So in the case of my Get-MacInfo module, (yes, I know, the EFIVersion is a bit weird at the moment), you would create a folder named “Get-MacInfo” in ~/.local/share/powershell/Modules, and copy the Get-MacInfo.psd1 and Get-MacInfo.psm1 files into it, then restart any running powershell sessions. At that point, Get-MacInfo would just work:

% pwsh -c "Get-MacInfo HardwareModelID"
HostName: not set
Name                          Value 
----                          ----- 
HardwareModelID               MacBookPro16,1   

No need to deal with Import-Module et al.                                                                                      

A Fine Tale

How I discovered that OneDrive has become a very risky app

Note that this has laready been updated 2-3 times, so god only knows if it will ever be “done”

So first, this has little to do with security (except for the root thing). I’m sure OneDrive:Mac is as secure as it is on any other platform. What I’m talking about are a series of things that would be comical if they weren’t so awful.

As some background, my main rig is a 2019 16″ MacBook Pro, 64Gb of RAM, running the current drop of Monterey.

One fine day, I realize, as I have before, that I’ve hit the limits of Pages. Over the years, I’ve learned that once you hit around 130 pages, Pages starts becoming unusable. Simply can’t handle it. Which is sad for a word processing app, but Apple only cares about Pages and the rest of iWork in how well they round-tip with iOS. Kind of like any of their “cross-platform” apps. How well they work is less important than they work exactly the same for macOS and i(Pad)OS.

So I do what I always do in that sitch: export to docx to keep working in Word. I then go to copy that export to my OneDrive folder and there, reader, therein begins an adventure that starts with the immediate discovery of two sins, one venial, one mortal.

The venial sin is that where I had my OneDrive folder is now an alias pointing at ~/Library/CloudStorage/OneDrive-Home/ This is annoying, primarily because OneDrive has severe issues with path lengths. But okay, as long as it keeps working. My guess is that this is a Monterey thing, as OneDrive now shows up like my iCloud folder in the Finder. This may be more convenient for some folks, so whatever.

20 Sept. Update: So it turns out that because the OneDrive folder has been relocated, you have to re-allow Office apps to work with the OneDrive folder. Thus far, it seems that only applies to Office apps, but really? Y’all do this and do an incomplete job of it?

21 Sept. Update: It’s not just Office apps, i got the same warning for Acrobat Pro. However, this is not the OS folder access warning, but one that is specific to OneDrive. It’s not available in the OneDrive app, so I’m sure it’s a goddamned plist file somewhere, but I’m too tired to look. But why is this setting not in the minimal UI OneDrive has, and why is it separate from the OS version?

But then, I discover that Files On-Demand, which I had turned off had been turned back on and applied to all my files. The explanation for File On-Demand, or FOD as I put it, is here. I don’t have a problem with FOD as a concept, but I had it turned off for specific reasons, one of which is that I regularly work disconnected, which makes FOD kind of useless. But not only is it turned on, I have no way in the UI to turn it off. This is what I see in the preferences now for FOD:


Goddamnit, this is not okay. You want to make it the default for new users? I guess, although I think that’s stupid. But when I have *turned it off* and not only do you turn it back on, but you don’t give me a way to turn it back off, like how I wanted it? That’s unacceptable.

A little bit of googling leads me to this page and the FilesOnDemandEnabled key, along with warnings that I should not use that, but rather the information on this page. Okay, so I try the /getpin on a single file. Blows up, doesn’t work. Sigh. I try /setpin on the same file. Cue endless lines of how OneDrive’s cache.db file is corrupt. Why OneDrive can’t fix this itself, dunno, but that’s an easy fix. Quit OneDrive, delete cache.* files in that folder, restart OneDrive.

OH! I almost forgot! So while you can use /getpin while OneDrive is running, you cannot, can. not. use /setpin while OneDrive is running. SIGH. Fine, quit OneDrive, run /setpin, which…starts OneDrive. Y’all, this is not the way to use the primary executable for OneDrive. This is why $DEITY created helper utilities. And UI options so I don’t have to mess around with this. So now, wait 2-3 minutes for OneDrive to start and log back in to my account, (MS365 business, and this is on Google Fiber, so I have a fast connection.) Cue the endless cache.db warning lines. Kill /setpin which…exits OneDrive.

So that means, since I think I’m reading this correctly, that even if /setpin worked, (which as we shall see, it does not), if you ran it five times on five different items, you would have to go through the launch/login/run/quit cycle once per item. At about 3-5 minutes for just a single small file, nevermind a larger folder tree. Which begs the question, why even bother? Because /setpin and related let you modify the FOD settings for files and folders recursively, which the Finder options do not. No, you didn’t misread that. Changing the sync settings in the finder don’t recurse through folders. Here, this is the folder tree for some stuff I got from a security class I took a while ago:


So you see the how there’s four folders on the left, then the highlighted folder has subfolders, which have subfolders which have subfolders and so on? Now, one would expect that if I click the “download” icon for the “CCD-Provided attack tools” that one of two things would happen:

  1. Everything in that folder would also be downloaded recursively
  2. OneDrive would point out there’s a lot of files and subfolders in that folder and do I really want to download all of those?

One would expect either of those two behaviors, because they are both fine behaviors, but one would be quite wrong. If one clicks download on “CCD-Provided attack tools” the only thing downloaded is the one single “document.docx” file in that folder and nothing else. You have to manually do every folder and subfolder separately.

I say this and mean this with my whole chest: WAT? Or more accurately:

The best part? FOD doesn’t work with WordPress upload dialogs, so I had to manually download this picture in OneDrive to use it. Yet another FOD fail.

IT GETS BETTER. After posting this, I had a thought. In terminal, I went to one of the directories with subdirectories, and before I opened it in the Finder, I did an ls -al. Then I did it again. This is what I got:

jwelch@Blackbird VMware Workstation 15.5 Player % ls -al
total 0
drwx——@ 2 jwelch staff 64 Dec 18 2019 .
drwx—— 33 jwelch staff 1056 Dec 18 2019 ..
jwelch@Blackbird VMware Workstation 15.5 Player % ls -al
total 0
drwx——@ 4 jwelch staff 128 Dec 18 2019 .
drwx—— 33 jwelch staff 1056 Dec 18 2019 ..
drwx—— 65535 jwelch staff 45798222336 Dec 18 2019 Prerequisites
-rwx—— 1 jwelch staff 144754512 Oct 1 2019 VMware-player-15.5.0-14665864.exe
jwelch@Blackbird VMware Workstation 15.5 Player %

Wait, what? Oh this can’t mean what I think it does…let me try something a few levels up. So I go up a level, and run ls -alR, and see that every folder save the ones I’ve already looked in is empty? That cannot be correct. So I run it again and see the directories are suddenly filling in.

Goddamnit, OneDrive and FOD are at this point lying to me. It’s not even completely downloading the file placeholders for folders until you click on them. So if you weren’t aware of this, and were offline and clicked on a FOD’d folder, you’d think it was empty, that you had lost data. There’s not enough letters in “unacceptable” to show how unacceptable this is. But it explains why recursion fails in the Finder when you click download: There’s literally nothing in the subfolders TO download. Jesus wept, this is bush-leage stuff. This will cause people to freak out. This has to be changed.

So yeah, FOD failures left and right, but we aren’t done yet. You know bundle files? Like minor things like .rtfd files, .xcodeproj files, .scriptd files, .app files? You know, files no one would ever use? Yeah, so if OneDrive has uploaded and FOD’d them (I love calling it FOD because I used to work aircraft maintenance and that use of FOD? IT APPLIES HERE TOO!) and you go to click the download icon? Fails. You get a finder dialog:

This is now a joke

Which means the only way to deal with that, to get to your files is to download them via the web interface (after you turn FOD off, because otherwise, you’ll have this problem again, then copy them to where they should go, and let OneDrive resync them. Oh, and if you do this on a lot of files, OneDrive will temporarily halt until you tell it “yes, delete all those files so I can replace them with the exact same files.” Oh, it fails on Swift Playground files as well, so basically, if you want to use OneDrive with any form of Xcode development, you have to make sure FOD is disabled or it will prevent you from doing any work at all. Good job MS.

So back to /setpin et al. Once the cache.db issue was taken care of, I tried /getpin. Got some useful info:                         

2021-09-19 12:28:46.442 OneDrive[3106:104456] MSEnvironment: returning 0
2021-09-19 12:28:46.607 OneDrive[3106:104456] invalid mode 'kCFRunLoopCommonModes' provided to CFRunLoopRunSpecific - break on _CFRunLoopError_RunCalledWithInvalidMode to debug. This message will only appear once per execution.
2021-09-19 12:28:46.693 OneDrive[3106:104456] pin state=None

Okay, cool, so let’s try setpin. On a single file. Even allowing for the OneDrive relaunch shit, it can recurse, so that will save me some time, right? LOL. No. Failed. I started it on a single, small Word file at 1148. By 1228, enough time for me to kill Potema in Skyrim including travel and NPC dialog, still hadn’t finished. Last message in the terminal window was:

11:51:21.951 OneDrive[2781:91209] Warning: +[NSStream getStreamsToHost:port:inputStream:outputStream:] is deprecated since OS X 10.10. Please use +[NSStream getStreamsToHostWithName:port:inputStream:outputStream] instead.

So let’s be clear: OneDrive moved from where I’d put it (annoying, but not huge, changed a setting I’d explicitly set to the thing I didn’t want because the new default state for OneDrive is Files On-Demand is on unless you change it in the plist file, told me about command line utilities that don’t work, showed that downloading via Finder integration doesn’t work for a very common file format on the Mac, (and before someone brings it up, it’s not about executables. .exe and .msi files, onedrive has no problem with. It’s the bundle format, not the content of the bundle format), and since it doesn’t recurse if you use the Finder integration to download, requires you do do a lot of work.

What the hell?




Look I know, or used to know people on the OneDrive team. They aren’t stupid. They aren’t malicious. But they literally built this, and I’ll be damned if I know why. Other than the /setpin issues, this isn’t about bugs or not enough unit/etc., tests. I’m sure they test the hell out of their code in their CI pipeline. But that’s not the problem. The problem or problems are:

  1. The OneDrive team has clearly decided their only use case, customer-wise either never involves someone using files in OneDrive without an internet connection, or they will know ahead of time every file they’ll need and download those prior to disconnecting. This is only valid if your prime disconnection case is light work/personl stuff on a vacation or something similar. If you’re, I dunno, working for extended periods of time in a disconnected state and you decide OneDrive is pretty cool before you’re disconnected, you’re screwed, because OneDrive doesn’t warn you that it’s about to empty all those files off your drive sans placeholders, nor does it give you an easy way to un-FOD your files. That is almost malware-esque behavior, the main difference being, you can at least get to your files without paying a specific ransom. Although i do wonder what happens if you don’t know about this, decide OneDrive/365 isn’t for you and kill your sub. Because I don’t think MS downloads all that back to your hard drive, so there is a very real, not too outré case where you could lose a lot of data if you didn’t have a separate backup system. That’s not okay.
  2. The OneDrive team has clearly not tested the current/new implementation of FOD outside of some carefully scripted, highly limited situations, and they aren’t testing for the right things. It reminds me of the one time I ethered some version of Lotus Notes (I was bored and Notes is an easy target) and both IBM and Notes Stans (They exist, I am as mystified by that as anyone) started lecturing me about all their UI testing and I responded with a screenshot of a menu wherein the key combo shortcut was displayed as the copyright symbol, asking if they could, pray tell, show me where on a standard computer keyboard, regardless of platform, the copyright symbol key was. To quote the amazing Chelsea Hart, THEY DID NOT LIKE THAT. I am quite positive the OneDrive team has an extensive test suite given how few “bugs” i’ve found, and I am equally positive none of that involves actually using OneDrive and FOD on a Mac with anything but the most simplistic of folder structure setups.
  3. The OneDrive team needs to get some people who aren’t the same as them, who don’t all live in one place, and all work and live the same into the room where UI/UX decisions are made. Because none of the idiocy I’ve been dealing with was snuck in. There have been deliberate decisions at multiple levels that created this, and that is a problem.
  4. FOD is actually lying to you, actively, with its “no placeholders until you click on the folder” nonsense. That’s inexcusable in the extreme. It means that if you look in your FOD’d OneDrive folder and you’re disconnected from the public internet, you are going to see…nothing. Not even placeholders. This is beyond unacceptable. There’s no justification for this. None. Miss me with the attempts.
  5. Oh, I just remembered one nigh-hilarious security issue: if you execute any of the OneDrive commands, like /setpin with sudo, OneDrive tries to set up /var/root as a OneDrive folder. I just can’t with that, how does that pass the laugh test? That’s like Oozinator-level “how did this get approved” stuff.
  6. WAIT, THERE’S MORE. You know how normally, if you hit cmd-delete on a folder or file in the Finder, it moves that thing to the trash? Well OneDrive decided that’s WAY too confusing for you, so if you do that on anything in the OneDrive folder, it’s a “permanently delete now” action. So basically, OneDrive makes finder items act like they’re not local at all. I can’t. Just stop. Make the pain stop..

Fortunately for MS, I use 365 for a lot more than OneDrive, else I’d be moving my shit over to any other service, even (ugh) Google. Okay not Google, even I have limits to my spite. But this is not a very “sticky” performance in terms of making me want to use OneDrive more. And I will bet I’m not the only person this stealth application of FOD has bit in the keister. I’m just louder than most.

OneDrive operates in the backup space. Regardless of whether or not it is a proper backup service, and it is not, that is how people use it, a lot. It does not have the luxury of silently removing data from someone’s computer and making it so stupidly difficult to get back. Fix your stuff y’all, this is inexcusable.

A list of file types OneDrive + FOD don’t seem to work correctly with (this will probably grow):

  1. .scriptd
  2. .xcodeproj
  3. .playground
  4. .rtfd
  5. .key
  6. .app
  7. .band
  8. .pages (the bundle version that shows as a directory in Terminal)
  9. .pkpass
  10. .epub (the bundle version)

Crashplan and Monterey

If like me, you’ve been testing Monterey on your Mac, and been frustrated by the code42service constantly crashing due to looking in the wrong place for libjli.dylib (specifically: /usr/lib/libjli.dylib), install the 8.7.1 update, that fixes that issue.

I just installed it on my MacBook Pro (16-inch 2019) running Monterey, and it’s back to doing it’s backup thing. (currently scanning. If the backup doesn’t work, I’ll post back here with any info.)

Shortcuts in Monterey Beta 5

Has Anything Actually Improved?

When last I talked about Shortcuts, there wasn’t much there. It seemed clear that the entire purpose of Shortcuts was for iOS Shortcuts and that the AppleScript and other functionality only exists as a path away from Automator. Shortcuts support in the OS was kind of meh at best, unsurprising given Apple. So has anything improved? Sort of.

Shortcuts is “Scriptable”

The quotes are deliberate, because this is the barest implementation one could have and still be technically scriptable. There’s one class in the suite, “shortcut” which has for properties a collection of identifers:

  • color
  • id
  • name
  • subtitle

and Action Count, which is the number of actions in the shortcut. All these are read-only values, so you can’t use this class to create a new empty shortcut. That’s fine, because there’s only one command, “run”, and that is all this dictionary is designed to do: let you run existing shortcuts via AppleScript/JXA/whatever. So it’s not “automation” in any useful sense. There’s one handy feature, the addition of the “Shortcuts Events” app, which is a helper app that lives in  /Applications/Shortcuts/Contents/Library/Helpers/Shortcuts Events, and if you target it within a tell block instead of Shortcuts, then you can run the shortcut without having to start Shortcuts.

I mean, that’s handy, right? But that’s the extent of the usefulness of this dictionary. You can get a list of existing shortcuts and run one of them.


Other Support

The support for Shortcuts in the OS and associated utilities is about what it was, and as uneven and uncoordinated as one would expect from Apple. For example, I can create an event on my Exchange Calendar in the “Add New Event” shortcut, or any calendar Calendars can see, (which is something you can’t do via AppleScript, and has been that way since iCal first supported Exchange. Can’t imagine why I am so cynical about Apple’s automation “commitment”), but you can’t do that for Contacts. Disk Utility has some basic shortcuts and no other way to automate it other than dumping into the shell environment, which bypasses Disk Utility entirely. FaceTime lets you call/FaceTime a contact in Contacts. That’s it. The Finder shortcuts are still so basic as to be not useful. You can’t just make a new file. You can’t make a new folder. I don’t know why Apple bothered with it if they’re going to limit it that much.

Mail has two shortcuts around measurements(??) but they both say “this requires an app but it may not be installed” Really Apple? Really. That’s good UI? How? All but one of Messages shortcuts involve iTunes for some reason, and the one actual messaging shortcut doesn’t even let you attach a file to a message. Again, why even bother? In an unsurprising limitation, Shortcuts shortcuts are every bit as limited as its “scripting” dictionary.

In what is a truly WAT moment, the macOS version of Shortcuts has a “Set Flashlight” shortcut. For Macs. Which, last I checked, don’t have flashlight functionality. But sure, Shortcuts main priority isn’t roundtripping shortcuts between macOS and i(Pad)OS. It’s not just that one. There’s a whole host of shortcuts that make no sense on a Mac, unless Apple plans on actually merging iPads and Macs. I know I often wish I could more easily manage my Voice & Data settings on my Mac.


Oh, and the UI in Shortcuts is kind of awful. Good luck finding the close control for a shortcut. It’s a wee tiny dark grey “x” that is almost invisible on a black background. Doesn’t even highlight when you mouse over it, which makes me wonder is there anyone over the age of 25 on the Shortcuts team? Heck, anyone over 19? Anyone with any form of vision acuity issues? Because that is a design that only works for young, perfect eyes. It wouldn’t be so bad if I could remove a shortcut from a workflow any other way. But I can’t.

Evidently, I need to get new iGlasses.

See what I did there?

There’s one Siri shortcut: to dismiss Siri. Why? Why is that a thing at all? System Preferences has no shortcuts, but shows up in the app list.

So no, there is nothing about Shortcuts on macOS to be even interested in, much less excited about. There’s nothing particularly useful about Shortcuts, unless you’re just into automation that doesn’t let you really automate anything.

Which describes, again how Apple views user-created automation. They don’t like it, they haven’t since the return of Jobs, and the only reason Shortcuts exists on macOS, based on what I’ve seen, is to have feature “parity” with iOS. I mean, I can set my Mac’s flashlight with it. So there’s that.

Virtual is not “the same” as in-person

But that doesn’t mean it’s bad

So after the 2021 all-virtual Apple WWDC, once again I see the meme of “you don’t need in person, virtual is just as good, see?”

Okay, based on the way Apple did this, that’s an utter load of bollocks. Like, literally.

For example: after a session, any session, did you, the audience have a chance to ask questions of the presenter(s)?

No, you did not. For one, as best as anyone can tell, the sessions were recorded well before the event. So they weren’t “live” in any sense of the word.

Did the presenters give out their emails so you could ping them later with a question? As best I can tell, no. So even if you have a question, you’ve no way to ask the presenter(s) unless you happen to know them, or you can track them down on some form of social media. The option presented was to ask a question in the dev forums with a WWDC tag.

If anyone is going to seriously try to tell me that forum communication is just as good or better than in-person, I will wonder if you have ever actually met another human being. Because there’s no way that’s true. Like none.

This is one of the serious disadvantages of virtual conferences: the heavy control of all interactions. You can’t ask questions after a session unless the conference decides to allow for it. You can’t wait outside the room and have a quick hallway chat.

Now, Apple did have some slack channels going. That you had to register for and in a very limited set of offerings. None of them directly applied to the questions I had, so why would I waste space in a SwiftUI/DevTools/Accessibility/Machine Learning channel/lounge asking questions that had nothing to do with those subjects? Regardless of the legitimacy of my questions, in those settings, they would be nothing but noise.

The same thing the labs. I would have liked to have gone to the Shortcuts lab, but as a 1:1? That sounds like “I have a specific actionable issue with this code here” thing, not a “I have a larger question that may take multiple people to answer.” As well, in the past, one of the huge advantages of labs was having someone say “I can’t answer that, but I know someone who can, they’re right over there, c’mon.” I didn’t see any way that could happen, since again, this wasn’t “live” in any real form of the word. And since everyone at Apple is dispersed, even if someone did know a person who could help, that’s finding if they’re online, asking them if they have time, and even with slack/messages/email, that can take a while, and in the meantime, that slot is effectively wasted.

Also, there was exactly one Device Management lab, and only two shortcuts labs, and you had to get an appointment to each. Trying to rush to get an appointment for a lab slot is the exact opposite of fun.

There’s also the lack ability to into someone who may not be presenting or running a lab/lounge, but just there, and they’re a person you want/need to talk to. Again, that’s a big thing, and it’s something that’s regularly been as useful, if not more than the sessions. Quiet corner chats are great ways to get questions answered that would never be answerable in a session that will be recorded and reviewed, at least internally. “Off the record” for any value of that term is simply not possible with how the WWDC was set up.

The conversations you walk past that accidentally turn out to have great value? Nope, not happening.

The “hey, here’s this person you should meet” and this person is not an “official” presenter? Possible, but tricky, because you have to give out the kind of contact info this person may not be comfortable giving out for me (a complete stranger) to meet them, and handing out my contact info to them (a complete stranger who may not work for Apple) is similarly dicey. But there’s an odd kind of anonymity in just talking to someone. That conversation doesn’t have a record. It can end and either party will have no way to continue it if that’s what one or both people want. That’s not even counting the conversations with non-Apple devs and other attendees, which again, huge value.

Also, when you’re talking about WWDC numbers, a video conference? Yeah, not scalable, and now there’s a push, backed by some actual data, that for remote communication, video is actually worse than audio only because of what video does to humans trying to use “normal” in-person context clues. You’re very much “on” with video. Anyone on a video conf. with me who thinks I’m relaxed and not hyper-aware of being on-camera, yeah, such a nope.

So let us dispense with the idea that both can be the same. They aren’t. And that’s not even dealing with the gatekeeping a video conference has for people who don’t have access to unlimited bandwidth. I know more than a few folks who even if they’d wanted to couldn’t watch more than a handful of sessions in less than a month, because their satellite internet, which is their only real option, is so metered they’d eat their monthly bandwidth allotment but quick.

Like definitely in the US, this assumption that everyone has the same bandwidth options as you do in larger cities is just beyond any form of reasonable. Like literally during the pandemic, there have been gobs of articles about how many places in the US do not have proper high speed internet access. Here, some data:

How do those folks even watch the sessions, much less do anything else. Y’all, the US is a damned mess when it comes to high-speed internet, so for every person who didn’t have to deal with long flights but could still watch the sessions, there are a lot of people for whom the WWDC will take months to actually look at, if they can at all. (Dial-up is not dead, really.)

However, that does not mean you can’t get closer. There’s a few ways.

Why not both?

First, this is not either-or. You can absolutely have an in-person conference with remote options. You can even allow remote folks to ask questions during the Q&A. This is a well-solved problem. Like this is not even vaguely new. Secondly, don’t make people stalk presenters to ask them a question. Even if it’s a WWDC-specific email and not their normal work email, give people a way to contact them afterwards. Thinking about it, a WWDC-specific email would probably work pretty well. Allows for interaction, but helps keep bad actors out of “real” email. Q&As after a session have real value.

Secondly, have a larger range of lounges in slack/teams/whatever. If you have a session on it, have a channel on it. There absolutely should have been a device management/shortcuts lounge, especially given that Shortcuts on macOS was so new and honestly unexpected. Like, there’s a lot of detailed questions that I know came out of that. Also, have a form of “just hanging out” channel for different Apple folks to be able to interact with remote attendees. Yes, that would have to be carefully monitored for bad actors, but banning people is quick, and since you have to have a developer account to even get in, letting people know that being a tool in Slack may get their accounts terminated has a way of getting people to think about their behavior.

Thirdly, and I know this seems anachronistic, but again:

…Have a physical collection of conference videos and presentations. There are a lot of people living in places where streaming/downloading is either expensive as hell for them, or simply not possible in under a year. Thumb drives, Blu-Ray, don’t just assume the entire audience has GigE to their house.

Too many people are being binary about this, and I honestly don’t understand why. Both methods, in-person and virtual have real advantages. From folks who live very far away from Cupertino not having to deal with international travel (a pain in the best of circumstances, which these days are not) and folks with a variety of physical issues for whom travel of any kind is fraught with real problems to people who don’t do well with remote communications or don’t feel comfortable speaking in front of a room full of strangers (which is kind of what Slack is), a combination conference is not only possible, but preferable.

Both sides miss out. The virtual folks lose out on a lot of the “a-ha” convos/hallway convos/after hours convos (it’s not all alcoholic fogs, there’s some serious work done at a table in a restaurant/bar), the people in person lose out on being able to attend and interact in the comfort of their own homes, sans pants. The expense of a WWDC in person is not small, so the virtual option is great for people who want the info, but are unable to get their jobs to pay for it, or just don’t have the scratch for airfare, hotel, and food.

Like this is absolutely doable in a way that isn’t all or nothing, and combining both in a thoughtful manner would, I think, make for a really good experience for everyone. Would it be perfect?

Dude, if anyone in tech is going to lecture me that it has to be perfect to be acceptable, I’m going to wonder if you’ve ever written “hello world”.

Apple and Automation

Boy, there’s a title fraught with weirdness and uncertainty. Like going back to System 7 Pro and the introduction of AppleScript.

But anyway, watching the 2021 WWDC keynote, I realized that for all intents and purposes, Apple doesn’t have a single automation model/framework. It has like elebenty and they ignore each other almost entirely. Want to operate at the user level? You’re going to use AppleScript, Apple’s very weird JavaScript for Automation implemenation, sharing panes, etc. Individual apps may implement OSA (the framework behind AppleScript and Automator) or they may roll their own.

Oh, did I say Automator? Well other than the fact that’s going away in a few years to be replaced by Shortcuts, you could write Automator Actions using like four languages.

Then there’s the various scripting bridge lanugages like AppleScriptObjectiveC, (ASOC), PyObjC…and at the shell level, well, shell, Python, PowerShell if you like…

And other than within Automator, none of these work well together. You can build actual apps in ASOC, but you can’t debug them in Xcode. Well, display dialog and log statements. So 1990s debugging. Roundtripping between shell and AppleScript is annoying and fragile, and you’re doing a lot of write to a file/read from a file.

AppleScript is barely functional outside of the user GUI context and shell doesn’t really work well in there.

And then there’s Shortcuts. Which do a good job of taking over for automator, and surprised me with the ability to run AppleScript/JSX/Shell commands.

But that’s not a unified automation model, and that’s what Apple needs. Along with documentation, because Apple’s Dev/Automation documentation is, to put it as kindly as I can, pants. Like just pants. What they need, and I try to avoid saying that, but in this case, it works, what Apple needs to do is basically steal the idea behind PowerShell and the documentation of powershell.

Before the shellistas come for me, PowerShell is an object-oriented implementation of .NET, which is way, way more powerful for scripting across all OS levels than shell, which assumes everything is text and is tedious as hell for a lot of things. Like anything where text as your i/o medium doesn’t work well. Shell isn’t bad, but PowerShell is better. It also has some things going on that Apple should use.

PowerShell and .NET

Basically, (and I am drastically simplifying), PowerShell is an object language that takes the .NET frameworks and infrastructure, and simplifies it in a way that makes it more useful to scripters. The syntax is very similar to “real” .NET/C# (Even though you can code for .NET in other things, C# is the “default” and I’m going to use them fairly interchangeably here.)That’s not to say PowerShell is “dumbed down”, not by any means. But, it does mean that PowerShell as a language is targeted more at scripting and automation than full app development. For example, (unlike AppleScript), PowerShell has no UI primitives, which is quite the pain in the keister for when you need scripts that interact end users. Things like choosing from a list, etc., are much easier in AppleScript than in PowerShell. For example, in AppleScript, display dialog is a single line, where it is a bit more complicated in PowerShell.

The AppleScript version:

display dialog "You have to be an admin to do this"


$wshell = New-Object -ComObject Wscript.Shell
$wshell.Popup("You have to be an admin to do this:,0,"Script Info",0x0 + 0x10)

Not hugely more complicated, but still, having to manually create objects that way for simple things is tedium, and the syntax is a bit more awkward.

But, the thing is, PowerShell out of the box gives you access to basically the entire .NET frameworks, which means you have access to basically all of Windows. And, because of Microsoft not only pushing ISVs to adapt PowerShell as an automation language, and leading the way, you get a lot of support for using PowerShell throughout windows.

PowerShell is also regularly updated, and they’ve even managed to do this in a way that breaks very little. Now, that can be a pain, because the current version is 7.x and Windows, by default, ships with 5.1, but still, you can easily get 7.x. In addition, thanks to things like PowerShell Get, they have a whole setup to add new packages as needed via different “official” and unofficial repositories, something that to my knowledge, Apple never even attempted with any of their automation tools. Not even shell, not really. Maybe sorta/kinda Swift, but still, very thin.

So with PowerShell you have a consistent OS-wide object model that works at all levels, remotely, Application automation, whatever you need. It has a way to create modules for packaging up well, libraries to be easier to use for other folks. Creating modules is far too painful for its own good, but it’s there.

And then, there’s the documentation, and this my friend, is where PowerShell shines. Like Apple has nothing close to the level of documentation, not at the API/Language level, and my god, not even close to the implemenation level. Apple has literally nothing close to this:, and the old “Hey, Scripting Guy!” blog has, now that the guy who created it retired, been turned into a community resource. Here:

On the best day of its life, Automation at Apple never. ever. ever. had that level of support for implementation help just there on a web site. (DTS never supported automation outside of low-level ObjC/Swift for creating OSA implementations in apps. Even ASOC, which mind you, is still a part of Xcode 13 gets you no DTS support, just a “go use a mailing list/forums.” response. Boy, that makes me want to take the time to learn ASOC. Even better, Xcode has NEVER had any debugging support for ASOC. sigh) But that’s not all. The actual language, model, and implementation documentation for PowerShell is light years ahead of what Apple has, especially in terms of consistency.

Apple did, a few years back, finally, finally port the AppleScript language guide from a PDF to a part of the Apple Developer site, and that is pretty solid, because it was written a long time ago when Apple’s core AppleScript team was more than like three people, (and I may be overestimating the current size of that team), but that’s it. There’s nothing compared to what PowerShell has going on. For example:

While you’re looking at that, take a gander at the lefthand column. Note that it shows different versions of PowerShell. Yeah. Apple doesn’t even document ObjC and Swift that well, much less automation. Also, at least with PowerShell, I have full access to the clipboard. Apple still can’t give us that, or won’t, or whatever. That dates back to System 7 Pro I think. So what, 20 years? 30? Meanwhile, PowerShell has a full suite of clipboard commands. That’s what taking automation seriously does.

So the upshot is, because PowerShell is based on .NET, and gives you such access to it, as you find yourself outgrowing PowerShell, moving into .NET, or mixing in full .NET commands as needed is really easy. Way easier than even moving from ASOC to ObjC or Swift. Like right now, I might be able to code macOS apps easier with .NET than I can with Swift, because I’m more familiar, thanks to my PowerShell work, with .NET than I am with Swift. Given my background with writing code for both macOS and Windows, that’s really sad. But Microsoft gives you that path, Apple does not.

That is something that Apple has, to be frank, failed at. Miserably. Apple’s support, as a company for keeping their automation frameworks and implementations consistent and supported and using them themselves is really quite awful, and as a result, no one else has consistently cared. I doubt it’s even occurred to Apple to structure things so you could move easily from AppleScript to ASOC to ObjC/Swift. I can damned sure tell you Apple has nothing out there to help you with macOS automation from an educational perspective. Which is why, even though the new macOS Shortcuts look cool, I’ve real doubts, because I’ve seen this same thing from Apple before with regard to automation:


Customers: Oh cool, where’s the documentation?


Customers: Oh…okay, are you going to have any courses or training for it?


Customers: Okaaay…you going to lead the way and use this internally and in your own applications?


Customers: …you going to support people building solutions and systems with this beyond stuff like forums and mailing lists?


Customers: …you ever gonna update this?


Customers: …


The list here is long. Again, for ASOC, which has been a part of Xcode since…10.5…you can’t even debug it. Even though, there’s actual AppleScript/ASOC IDEs that will debug AppleScript, aka Script Debugger.

So even though Shortcuts on macOS looks really cool, based on past history, it’s going to get ignored as anything other than a way to run iOS Shortcuts on a Mac.

I would love to be wrong here, but Apple has been jerking people around hard in terms of OS automation on the Mac for longer than some of its current employees have been alive. (I’m not exaggerating here, AppleScript is 28 years old, introduced in 1993.) So telling me I have no reason to be so doubtful is going to get you a very long rant.

However…let us pretend that Apple is serious here. That they want to fix the deficiencies. Let’s take a look at those.

Current Issues with macOS Automation

The biggest issue the macOS has is that unlike Windows, there’s no consistent way to do stuff. If you want to do interapplication automation, there’s AppleScript, JavaScript (multiple implementations depending on application developer), custom application-specific stuff, some shell and python.

AppleScript actually has a decent object model, most of the inconsistencies come from the number of different applications supporting it. There’s no way to avoid that, ISVs are going to do things differently. No syntax in the world makes up for that. As well, syntax preferences, for the most part, are personal and a lot of the hate for AppleScript as a syntax is just the worst kind of elitism and nerd gatekeeping.

The problem with the object model is that it really is only designed to work locally, in the context of a logged in user. Remote Apple Events have always been ugly, and a security issue. Even then, Remote Apple Events are simply not designed for a Unix-based OS. Unsurprising, given they predate OS X by about half a decade.

For remote stuff, you’re now in the shell environment, which is its own mess, since you may be using shell, you may be using python, SQL…and the security on those ain’t that great either. Relying on SSH keys et al causes its own special set of problems. Then there’s exchanging data between AppleScript/Apple Events and the shell. Ugh. Yes, you have a lot of options, but after a while, it’s all just more ways of shooting yourself in the foot, with wildly inconsistent syntax and no organized, secure way to communicate across the network.

Oh, and it doesn’t help that the OSA stuff uses Apple Events to exchange data and the shell environment thinks everything is text. sigh

Then there’s the previously detailed issues with Apple’s lack of support for this beyond the barest of efforts. Aka, Apple is lazy as hell some times.

So how do you fix it?


Yeah, stupid name, but I’m not in marketing. So there’s a few things we want out of real automation on macOS (and this could easily carry over to i(Pad)OS et al. More easily than the current…stuff.)

The current list:

  1. An OS-wide object model. This, by the way, already exists, it’s the Cocoa frameworks. We literally have a solid foundation for an updated object model that can be used between applications, at the shell level, at the user level, it’s all there already. Even has a cool name: Cocoa. Okay, it already has an accepted name.
  2. A consistent OS-wide way to pass data. This is a big weakness of the current system. Honestly, I think adapting the way PowerShell does things and doing a major revamp on the OSA object model so that it extends down into the core os is not just more painless way to go, it’s the way to go that will last the longest. We already can exchange text and objects, let’s just create a single model that creates a consistent, known, documented and supported way of doing this. Since it’s based on Cocoa, it’d work pretty well for i(Pad)OS as appropriate.
  3. Security. Since this is going to be slanging data o’er the land, it should just be encrypted from the start. Apple has a nice infrastructure for this already, so this would be an extension of that. This would also make it easier to handle transparent, effortless secure remoting, and yes, it has to be effortless. The most secure way, (and not that Windows PowerShell ExecutionPolicy idiocy) has to be the default. Build it right the first time, your life gets so much easier.
  4. The syntax should basically be Swift, only like how PowerShell:.NET. That’s pretty braindead, and yes, I know what this would mean for AppleScript, but part of this has to be using Swiftscript as a way to move into “full on” application development in a way that’s not as…Swift Playgrounds are too artificial, I can’t use them to solve the problems I have in my day to day. The Swiftscript syntax being similar, although not identical to Swift would be a huge help. That’s not to say you jettison AppleScript completely. There’s a few concepts from that language that work really well, for example, directing code at an application via a tell block.

    tell application “Finder”
    blah blah blah
    end tell

    may not appeal to the Swift purists, but a) I don’t care about them, and b) it’s pretty intuitive. I’m telling the Finder to do stuff. That’s pretty straightforward. Also, I like “Using terms from” where you have to intermingle code from different applications (a problem you don’t see in Swift now, because that’s not a use case.) It’s a quick way, within an existing code block or a tell block to jam in a bunch of code for a different application. Again, straightforward. What am I doing here? I’m using terms from Microsoft Word.

    Also take a good look at just how the current OSA object model works. It’s old, but it really works well. It needs attention to be sure, but it does a lot of things right. Don’t be afraid to plagiarize yourself, you’re the best source for your own needs.
  5. Documentation and Support. To be fair, Apple’s existing developer documentation is kind of meh anyway, so use this as an excuse to fix that too. Hire technical writers and let them do that. I know Apple has the money, it’s a will issue, not a resource issue. Add Swiftscript into DTS. For the first time, put some real wood behind that damned arrow. Like seriously.
  6. Dogfood it. Apple is horrible here. (I have receipts, please save yourself some grief, don’t challenge me on this.) Everything Apple does has to have the best scripting support in the macOS ecosystem. Period. Again, Apple has the resources, they just don’t care enough to actually do it.
  7. Evangelize it. Like y’all need to create a legion of Chloe Condons and let them loose. Not just at Apple events. Y’all need to be everywhere, and annoyingly so.

I think that covers most of it. Like you don’t have to jack things up too much. Just have this be a slightly higher level of Swift. For example, as AppleScript does now, the runtime should support all the core OS functions (think Standard Additions + Core Language + System Events here) without having to reference any other modules. If a module is needed, consider the PowerShell concept where you add the module/framework to your setup and then just use the methods and properties it brings in. If a script detects a missing module that’s part of the standard OS build, offer to add it in to that person’s setup.

Oh, right, almost forgot:

  1. Create a repository for third-party modules. You already know how to do this, it’s called the App Store. Like Swift packages, only not full-on that. But a place for people to contribute and access third-party modules that they can trust. Only maybe be more transparent. Somtimes, y’all’s App Store shit is extra.
  2. If you wanted a way for third-party languages to plug into this, that wouldn’t be awful.

Is any of this easy? No. But if Apple wants people to take new things like Shortcuts for macOS and whatever else is coming down the pike seriously, then Apple has to do more than the “if we build it and sort of make it possible to use, maybe they’ll come…whatever” stuff they’ve been doing for the last three decades. There’s a lot of ill-will with “official” Apple automation initiatives, and honestly, it’s fully and totally justified. Apple is just the master of the half-assed effort here.

And, if they really want to make automation work the way it should on the OS, well, I started a solution here. There’s good examples in wide-scale production use now (POWERSHELL) that can be improved upon and made more suitable. Apple has the money, the question is, do they have the fucks?