Archive for December 3, 2019

Tuesday, December 3, 2019 [Tweets] [Favorites]

VirtualHostX Pro Subscriptions

Tyler Hall:

VirtualHostX is now a subscription. You can pay $49 USD / year or $5 USD / month.

The annual price is the same as the old one-time cost. And I’ll note that I typically release a paid upgrade every 12 - 18 months. So, if you are like many of my amazing customers who do update to each new release, the cost of doing that vs a subscription are more or less the same.


If you sign up for an annual subscription, you can cancel it at any time. In fact, you can subscribe, get the confirmation email, and then immediately cancel. Your license for the app will continue to work through the entire year.

Even better. Your license will remain valid and working forever.

This sounds like the Sketch model, which I think is reasonable. Sketch’s file format issue likely won’t apply here.


Update (2019-12-12): Matt Gemmell:

The way I see app subscriptions right now is pretty simple. Here’s a brief thread on that.

First, Apple doesn’t allow upgrade pricing. Everyone would use it if they could. They can’t. That option is off the table.

Drew McCormack:

This made me think about the subscriptions I have for apps. It’s a grand tally of one: Tower. It’s a tool I need for work, and it cannot hold my data hostage. I don’t trust any other creational tool with a subscription. Perpetually renting access to my own data doesn’t appeal.

Tyler Hall:

Drew makes a great point. It’s the “lock down” that can be the key to a sustainable balance between what’s fair to customers and you staying in business.


So when I did my big release last week and announced my new pricing model, I was extremely nervous and wary of what the response would be. But so far I’m very lucky that I’ve have had few complaints.

Reading the Resource Fork Too Often

Mark Alldritt:

This problem happens after a document has been opened in Script Debugger and changes have been saved a number of times. If the saves are done in fairly quick succession, Script Debugger will begin reporting that it cannot save document changes. In some instances, errors -54 (permErr) or -43 (fnfErr) are reported. Additionally, once this situation arises and you close the document, it is no longer possible to open the effected document in Script Debugger.


At a technical level, the problem is triggered when applications attempt to read the resource fork of a document repeatedly within a given period of time. This behaviour by an application seems to trigger a security mechanism within Catalina that prevents further access to the document’s resource fork (the resource fork is used to retain meta-data in text and compiled AppleScript documents).

You’d think that old deprecated stuff like resource forks would just keep working in its frozen state. But both Mojave and Catalina introduced resource bugs that have hit my apps. There are more modern replacements for many uses of the resource fork, but they don’t always work. And, as with the AppleScript example, sometimes the resource fork is unavoidable, and the problems even hit Apple’s own apps.


Update (2019-12-12): Howard Oakley:

With Shane Stanley’s help, I’ve been able to reproduce this problem and to examine an excerpt of the log detailing what happened on that occasion. In this case, trying to access a resource fork in an AppleScript .scpt file which had just been repeatedly edited using Apple’s Script Editor triggered a request to the Catalina privacy system (TCC), which required the requesting app to have been granted a kTCCServiceSystemPolicyAllFiles entitlement.


One way to avoid that particular error is to add apps which need access to resource forks, like Script Debugger and Script Editor, to the Full Disk Access list in the Privacy tab of the Security & Privacy pane.

Peter Steinberger:

„After macOS 10.10, our users reported weird new crashers. As if the lock method in NSPersistentStoreCoordinator didn’t do anything anymore. Let’s look into Hopper... oh. [the lock was gone, method just was a NOP]

It’s not safe to rely on deprecated methods.

Disk Drill Guaranteed Recovery

Dave Wood:

I received feedback from my report I’d sent to Apple (Yay, they do work!). They pointed out that the issue was due to a third party app I have installed called Disk Drill by CleverFiles (which I have as part of my Setapp subscription). The app has a “feature” called Guaranteed Recovery that is supposed to help recover files later if you accidentally delete them. It “works” by creating thousands of hard links to what appears to be every file on your system in a hidden directory (/System/Volumes/Data/.cleverfiles/). This means when you delete a file, it’s not really deleted because there’s a hard link effectively creating a duplicate in the hidden folder.


Over the last month or so, I’ve been trying to free up space on my main SSD because the OS is constantly complaining that my drive is full. Because I kept getting alerts that I needed more free space, I kept moving/deleting files. Eventually I’d cleared/off-loaded over 500G of data and was still scraping by with about 30G of free space. Now that I’m aware of the issue, I’ve taken a look into the .cleverfiles hidden folder on my iMac and I see it has over 450G in it. Wow.

Wow indeed. First, the hidden folder should be excluded from Time Machine. And second, it seems like there’s a bug where it isn’t being pruned automatically.

Ordering the Typefaces in a Font

Gus Mueller:

The docs for -[NSFontManager availableMembersOfFontFamily:] say:

“The members of the family are arranged in the font panel order (narrowest to widest, lightest to boldest, plain to italic)”

Unfortunately, it looks like this is broken on MacOS 10.15.1. Running Acorn on 10.14 produces the order as described (and as seen below with Helvetica Neue).

Jiang Jiang:

As a workaround, calling CTFontDescriptorCreateMatchingFontDescriptors() with a font descriptor created from @{ kCTFontFamilyNameAttribute: familyName } should give you descriptors in the right order. Then you can get localized style names out of the descriptors.

Drinking the SK8 Kool-Aid

Cameron Esfahani (thread, via Daniel Jalkut):

One day my boss asked me to fly down to LA for the day. Apparently there was a developer there working on an app showcasing QuickDraw GX.


And right away I could tell something was weird. Structurally, most Mac apps look very similar. But this app was like nothing I’d ever seen before: heap and code were off.


“Oh, we’re writing it in SK8.”


SK8 was a weird Lisp-like multimedia authoring environment that Apple ATG was developing.

Needless to say, it wasn’t ready for production use.