Archive for October 3, 2024

Thursday, October 3, 2024

PDFpen/Nitro and Cleverbridge

Matt Henderson:

There used to be a great PDF app for the Mac called something like PDFPro [PDFpen]. At some point it got acquired by @NitroHQ, and began to ask to upgrade to a new version seemingly every time I launched it—up to version 13.

Today, on macOS 15, I needed it, but it wouldn’t launch. So I visited the website and it’s been acquired by a faceless enterprise company called @cleverbridge.

Version 14 for Mac is $170 (!) but I needed it so off to checkout. I enter my details, all fields light up green, and—purchase failed, please fix the “incomplete fields”. Wtf.

They double-billed him and signed him up for an unwanted subscription.

Not only that but I get activation instructions for the Windows version of the app! The Mac version simply shows a login screen.

But I don’t have an account! Create an account with the same email address, and their system doesn’t recognize I’ve purchased the app.

[…]

Visiting the “customer support portal” and trying to submit a request results in a—blank page.

As far as I can tell, Nitro purchased Cleverbridge and is using it to process payments:

Online orders of Nitro PDF Pro are processed (payment and order fulfillment) by our partner, Cleverbridge, Inc.

If you are an account admin who has purchased a Nitro Pro subscription through our partner reseller CleverBridge, you can now purchase additional licenses directly from within the Nitro Admin app.

[…]

When your payment is successfully processed, you will be directed to a Purchase Confirmation page with your CleverBridge Order number and invoice.

But if you need a refund you’re supposed to contact Nitro:

If you recently purchased Nitro Productivity Suite and wish to request a refund, please contact Nitro directly via their website. They would be happy to assist you with your request. While Cleverbridge is a partner of Nitro, we do not currently process their refunds.

It’s too bad that Smile didn’t want to keep developing and supporting the app.

Previously:

Finder Sync Extensions Removed From System Settings in Sequoia

ZigZag (also):

Even though Finder Sync extensions are embedded and distributed in their containing applications (like containing application FileUtils embeds its extension FileUtilsSync), the actual hosting application for those extensions is Finder. They modify Finder’s appearance and behavior, adding menu items and icon badges. Hence, fundamental things related to these extensions, like registering with OS, start and termination, as well as enabling and disabling them, aren’t controlled by the containing application, but by Finder and macOS instead. Registration with OS is done by Launch Services. It usually happens at the time the containing application is launched for the first time (after passing TCC quarantine check). Starting and termination of Finder Sync extension is also controlled by Finder/macOS and there may even be more processes of the same extension running, depending on how many Finder windows and file selectors (open/save panels) are open. The containing application can surely try to start and terminate its embedded extension, but the documentation clearly discourages that, since it can collide with how Finder controls them.

Finally, there’s enabling and disabling Finder Sync extensions. Even though an extension can be installed and registered, per user request it can be disabled (thus, completely ignored) and enabled. Containing application can do this programmatically, by tasking pluginkit command line tool to list, enable and disable (any, not just Finder Sync) extension, or using private NSExtension class found in FoundationKit framework. End users traditionally performed this task in System Settings application (System Preferences on macOS 12 Monterey and earlier). Well… Until macOS 15 Sequoia! In the latest incarnation of macOS, there isn’t any graphical UI way to manage Finder Sync extensions!

[…]

Revealing “Extensions” settings in System Settings on Ventura shows the same subsections like in System Preferences on Monterey, with one, for this story very important, change… “Finder Extensions” subsection is missing! The only place to find Finder Sync extensions settings is “Added Extensions” subsection. Early versions of Ventura even had “Finder Extensions” subsection, dedicated to Finder Sync extensions, but it was buggy and unreliable.

[…]

And then macOS 15 Sequoia came some 17 days ago. In its third reincarnation, System Settings application experienced third rearranging and shifting. “Extensions” settings are now under “General” section, “Logging Items & Extensions” subsection. […] Yes, you see it right, there is no “Added Extensions” section!

Managing extensions using the pluginkit command-line tool is not very friendly (and can’t be invoked by a sandboxed app), so Dragan Milić has written a free app called FinderSyncer that puts a nice user interface on top.

It’s not entirely clear what Apple is doing here, but the impression I get is that these days Apple is focusing on the File Provider Extension architecture that’s used for cloud syncing. It’s a shame because this does not allow all the same functionality as Finder Sync Extensions:

I believe many other developers understood it the same as me, especially considering the fact that Finder Sync extensions provide a way to add custom menu items to Finder’s contextual menu. I think most developers saw it as a sort of continuation of old CMPlugin API from MacOS (yes, the capital ‘M’) 8/9 days, which was available until Mac OS 10.6 Snow Leopard. It’s seen as a way to extend Finder’s capabilities, by executing custom operations (not limited to “synchronize the contents of a local folder with a remote data source”) on files selected in Finder.

I think I know about 50 - 60 applications embedding Finder Sync extensions at the moment, and only a dozen of them actually “synchronize the contents of a local folder with a remote data source”, mostly coming from huge and well known cloud providers (Dropbox, Google, Microsoft…). All others, mostly coming from independent Mac developers, offer some custom operations of files selected in Finder, nothing related to any sort of syncing. I believe MR_Noodle’s case is the similar one, “outside of its recommended use case”. Taking the above into consideration, I think it’d be a huge mistake for Apple to discontinue and deprecate Finder Sync extensions without providing functionally equivalent replacement. That would break a lot of third party Mac software and render those applications completely useless.

Previously:

IDA Pro 9 Switches to Subscriptions

Alex Petrov (release notes):

This release is amplified with new disassemblers and decompilers, such as the RISC-V decompiler, the disassembler support of T-Head instruction set for the XUANTIE-RV architecture, the nanoMIPS decompiler and disassembler, and the Web Assembly (WASM) disassembler.

Balaji N:

The latest version of the Interactive Disassembler (IDA) software introduces a unified licensing model, allowing users to operate a single license across Windows, Linux, and macOS platforms.

Also, there are no more perpetual licenses, only subscriptions. The home version (2 cloud-based decompilers) is $365/year, while the Pro Expert 2 version (2 local decompilers) is $2,999/year.

Stefan Esser:

In light of recent changes to the IDA license model my training courses will be adjusted to fully support Ghidra scripting within the next 12 months. Existing IDA 8.x scripts will not be ported to IDA 9.

No idea what happens to the free version but for pay versions will become a yearly subscription that actually expires one month after it runs out. IDA will stop working then. Furthermore the subscription with 2 decompilers will cost nearly double what I pay now for 4 dexompiers

And it seems like they are reneging, in that if you had recently purchased a perpetual license for version 8, you were supposed to get free updates for a year. Instead, they are giving access to version 9 for a year, but then it stops working and you have to go back to version 8 or sign up for a subscription.

Previously:

Restoring Shift-Key Slow-Motion Minimizing to Dock

John Gruber:

What I’d forgotten is that Apple had removed this as default behavior a few years ago (I think in MacOS 10.14 Mojave), but you can restore the feature with this hidden preference, typed in Terminal:

[…]

defaults write com.apple.dock slow-motion-allowed -bool YES; killall Dock