Yoink for Mac, the drag-and-drop improving utility, is now available in version 3.6.8.
What’s New?
There’s now a preference for having Yoink dynamically provide JPEG and/or PNG data for TIFF, HEIF and/or WebP image files you drag out of it.
I’ve also fixed a couple of bug fixes and made some quality-of-life improvements, like having a dedicated “Pinned Copies” sub-menu in Yoink’s contextual menu’s Clipboard History.
As always, it’s a free update for existing customers of the app.
It requires macOS Sierra 10.12 or newer and runs natively on Apple Silicon and Intel Macs. Yoink is available in English, German, French, Italian, Simplified Chinese, Japanese, Korean and Portuguese.
With Yoink for Mac‘s clipboard history working again on macOS Big Sur and newer, I’ve seen, in forums and such, some questions about how the clipboard history operates and what it stores, in regards to privacy. I’ve answered those questions, but figured I’d let everyone know about it as well here on my blog, since this *should* be publicly available info:
General Notes about Yoink’s Clipboard History
By default, the clipboard history feature is disabled. It has to be manually enabled by either clicking onto the widget in Notification Center, or in Yoink’s preferences, under Extensions.
The clipboard history feature can be disabled at any time (and will clear any stored items at that point) in Yoink’s preferences, under Extensions.
Individual items can be deleted in the Clipboard History browser, accessible by command-clicking onto an item in the widget, by selecting Clipboard History > Organize… in Yoink’s contextual menu, or by clicking Organize… in Yoink’s preferences under Extensions.
What the Clipboard History stores
By default, Yoink stores anything you copy or cut, be it some text from a document, an image on a website, or a file in Finder, for example. Please read “What the Clipboard History does not store” below for important exceptions to this.
The clipboard history can be configured by you to completely ignore copy/cut operations in certain apps. This can be done in Yoink’s preferences, under Extensions, by pressing “Ignored Applications: Edit…”
The clipboard history is stored locally on your Mac and does not leave your Mac, unless you do it manually.
What the Clipboard History does *not* store
Yoink completely ignores cut/copy operations from any app or process that has one of the following in its name: Keychain, Enpass, 1Password, KeePass, LastPass, Password, Kaspersky, mSecure, AppLocker, Keeper Password, Passwort, oneSafe, Secrets, Strongbox, RememBear, Dashlane and Bitwarden. Anything copied from an app whose name contains one of the above (case insensitive) does not get stored in Yoink’s clipboard history.
In addition to that, Yoink also ignores copied content from any app, if the resulting clipboard content contains any of the following data types (as suggested by developers, for developers, on nspasteboard.org): com.agilebits.onepassword, org.nspasteboard.TransientType, org.nspasteboard.ConcealedType and org.nspasteboard.AutoGeneratedType. If you copy something from an app, and that app writes, say, a string to the pasteboard, and also specifies one of the data types above, the clipboard history will not pick it up.
If you have any suggestions, possible additions, questions or feedback regarding this, please do mail me.
I’ve also updated my privacy policy to clarify all of this.
Long story short: I’m not interested in anybody’s data. I don’t do any tracking, no usage statistics, and, if my apps use your internet connection, it’s exclusively for a specific feature that it offers to you, the user.
Yoink v3.6.5 re-introduces its clipboard history feature and the accompanying widget. Here are a few details about its implementation for macOS Big Sur and newer.
The No-Button-Action Conundrum
Widgets on macOS Big Sur and up (and iOS, for that matter) can’t really react to a user’s click on them by themselves, so you cannot run any logic from a user’s input. A click onto a widget will always bring you back to its containing app, where you can then run logic accordingly. On iOS, that’s obvious, as it’ll open up the owning app and put it front and center. On macOS, that can be a little more subtle, because macOS allows apps to run in the background (like Yoink does, mostly).
When you click on an item in Yoink’s widget, it’ll tell Yoink to run the logic to copy the clicked item (or pin it, or add it to Yoink, or reveal it in the browser, depending on the modifier key you pressed during the click).
But there’s a problem with that in the case of Yoink:
The Foreground Conundrum
No matter where you click on a widget (either the background of it, or a SwiftUI Link() object), it will bring its containing/owning app to the foreground. For many apps, that will be fine. But Yoink is an app that runs in the background and only very rarely needs to actually become the active, keyboard-input-accepting app.
So I thought, perhaps I can have another application inside Yoink’s app bundle, which is LSBackgroundOnly, with a custom URL scheme that would be called from the widget using a SwiftUI Link() object. An app that has LSBackgroundOnly set to YES in its Info.plist cannot present any user interface, and cannot become “key”, even if the system tells it to. But there’s another roadblock – even though only the secondary app inside Yoink’s app bundle should be able to open the custom URL scheme, the widget will send that Link() to its containing/owning app only, no matter the url scheme. In this case, the main Yoink app.
The point of the widget is to quickly re-copy something and then paste it somewhere right away.
Say you're editing text in TextEdit, then open the widget, click on it to re-copy something and then press command-v to paste it into TextEdit only to hear a beep because the app isn't active anymore (because Yoink is). So you have to click into the TextEdit document to make it active, and only then can you paste. That can (and will) become annoying very quickly.
In order to have Yoink never become the active app from a click on its widget, I’d have to move the widget plugin/appex bundle out of the Yoink app bundle’s PlugIns folder, into the secondary target one’s. Only that way would the widget attempt to make the secondary target(and thus, not Yoink) frontmost – and fail because of LSBackgroundOnly, leaving the currently frontmost app active – and send the custom URL scheme link to it. The secondary target would then forward the link to the main Yoink app bundle.
Tada, it works. But that lead to yet another problem. (When did “it just works” turn into “it just won’t”? And while I’m at it, what’s with those widgets? They feel quite… neutered to me compared to what they were able to do before.)
The Widget Recognition Conundrum
So far, I managed to have Yoink not become active when an item in the widget is clicked. But now, with the Yoink app containing the secondary target containing the widget, macOS was unwilling to recognize and show the widget in Notification Centre. Interestingly, a double-click onto the secondary target in Finder would make it show right away. Infuriatingly, launching the secondary target quietly from within Yoink at launch won’t – and I had a lot of different approaches: – Launching the secondary app directly with NSWorkspace’s -launchApplicationAtURL:… – Launching the secondary app via its URL scheme – Having Finder open the secondary app – Running an NSTask open -a <secondaryapp> /path/to/somefile – Registering the app using LSRegisterURL
None of it worked. I figured, the problem was that it was Yoink launching the secondary app, not the “system” or “user”, like it was the case when double-clicking it in Finder.
Which made me think of login item helper apps. Inside the macOS app sandbox, an app cannot set itself as a login item. It needs to have another “helper” app inside its Library/LoginItems folder which it designates as a login item, and that app will then in turn launch the containing app. Nuts, but there it is.
The point is, the system launches those login item helper apps, not the containing app.
Heureka. In Yoink, at launch, I set my secondary app, which contains the widget bundle, as a login item with SMLoginItemSetEnabled, causing the system to launch it. Now, finally, Notification Centre recognizes and shows Yoink’s widget.
alternate clickbaity title: the update I learned Swift and SwiftUI for.
I’m happy to announce Yoink for Mac v3.6.5’s immediate availability. In addition to numerous quality-of-life improvements and adjustments, this update re-introduces the (judging from the inquiries I received about it) beloved Clipboard History feature, and its widget.
What’s Yoink?
Yoink offers you a temporary place (a “shelf”) for files you drag from Finder, or app-content like images from websites. It frees your hand and mouse cursor to let you more easily and quickly navigate to the destination of your files.
Yoink automatically appears at the edge of your screen when you start a drag a file, allowing you to place it there.
What’s New in Yoink v3.6.5?
Let’s talk about the most important thing first – the resurrected clipboard history and its widget. Up until earlier this year, I had virtually no experience with Swift, let alone SwiftUI, and I was pretty happy to continue with my Objective-anCient ways. But I realized it held me back. Things are clearly moving away from Objective-C and towards Swift, so at the beginning of this year (2022), I made a point of learning the basics of Swift as quickly as possible to have the option of using everything Apple’s platforms and APIs have to offer.
With macOS Big Sur, Apple got rid of its old-style Today Widgets (which could be written in Objective-C and a nice .xib-interface file) and brought over the new SwiftUI-style widgets from iOS. That’s why Yoink’s widget had been defunct for so long – I didn’t have the skills to replace it.
But enough chit-chat, here’s the nitty-gritty!
While the clipboard history recording still happens in Yoink itself in the background, the widget provides quick access to previous copies. It comes in two sizes: medium and large. The medium widget shows up to 6 copied objects, the large one up to 12.
Widget Configurability
That doesn’t sound like a lot, but you can have multiple widgets, and they can be configured to show 1) the most recent copies (medium: 1-6, large: 1-12) 2) older copies (medium: 7-12, large: 13-24) 3) oldest copies (medium: 13-18, large: 25-36)
So you can, for example, have one large and one medium widget to show the last 18 copied items, or three large widgets to show the last 36 copied items.
Apart from that, you can have the widget show only particular data types:
1) Only copied images 2) Only copied text 3) Only copied links 4) Only copied files 5) All copied items 6) Only pinned copies (pinning copied items is new in Yoink v3.6.5)
That allows the widget to be very flexible and useful.
How to use the Widget (Widget Clicks and Tricks)
– Click on an item in the widget, and it is copied to your clipboard – Option(⌥)-click on an item, and it gets sent to Yoink so you can drag it out at a later time – Shift(⇧)-click on an item, and it gets pinned (new in v3.6.5) – Command(⌘)-click on an item, and it is revealed in the Clipboard History Browser (new in v3.6.5)
Pinning Items (new in v3.6.5)
A pinned item in the widget
When the Clipboard History reaches its threshold (up to 36 items), it will begin clearing out the oldest copies to make place for new ones. In some cases, you might want to hold on to items indefinitely. That’s why you can now pin them. A pinned item will not be cleared out, unless you unpin it or delete it manually.
Clipboard History Browser (new in v3.6.5)
The history browser gives you a simple way to organize your copied items. Pin, unpin, delete, send to Yoink, copy, or clear out the entire history.
If you’d like to learn more about some of the implementation details behind this new widget, here’s a blog post for you.
What else is new in Yoink v3.6.5?
– It raises the minimum system requirements from macOS 10.10 Yosemite to macOS 10.12 Sierra. – Instead of a TIFF file, a PNG file is created when pasting image data into Yoink. In that vain, Yoink also transparently provides PNG and JPEG data when dragging out images of the types HEIC, HEIF or TIFF to broaden compatibility with other apps. – It also fixes a couple of bugs and improves compatibility with, among other apps, DEVONthink, where items dragged from DEVONthink to Yoink and then out of Yoink are no longer moved, but copied, to ensure the integrity of DEVONthink’s files database.
What do I need to use Yoink for Mac?
Yoink runs natively on Apple Silicon and Intel Macs, and requires macOS Sierra 10.12 or newer. It’s localized in English, German, French, Italian, Simplified Chinese, Japanese, Korean and Portuguese.
Where can I get Yoink?
Free Demo(direct download, ~28 MB, 30 days, notarized by Apple) Mac App Store($7.99, one-time purchase, no in-app purchases, update free for existing customers, as it’s been the case since v1.0) Mac Productivity Bundle(Mac App Store, 25% off Yoink, Transloader and ScreenFloat) Setapp(subscription service with over 200 Mac apps)
