Public Relations

Here’s an update on the state of my apps regarding macOS Big Sur and Macs with Apple Silicon.

In short: All my apps are ready for both, and the updates mentioned below will be released when macOS Big Sur is available at the latest (depending heavily on App Review and whether or not macOS Big Sur’s release is going to be the same, fun catastrophe of a surprise as iOS 14’s).

Let’s get into a little more detail.

Yoink for Mac (website | Mac App Store)

Yoink 128 2xFor Yoink – your file shelf that simplifies and improves drag and drop on your Mac –, all I had to do to make it fit nicely within Big Sur was to resolve some UI issues.
Recompiling for Apple Silicon went without further intervention on my part.

– Firstly, I updated the preferences window to the new style (which you can read more about here).
2

– Secondly, macOS Big Sur introduces larger insets for most (if not all) of its scrollable views, so I’ve had to make Yoink’s window a little wider to make everything fit nicely again, while maintaining the new inset and selection look.
1

– Last but not least, I asked Alex Käßner to update Yoink’s icon, and he certainly delivered (see above).

ScreenFloat (website | Mac App Store)

ScreenFloat for Mac App Icon

For ScreenFloat – which lets you create floating screenshots to keep almost anything visible in whatever app, space or window you are – my priority was to get it running natively on Apple Silicon and fix the most glaring UI issues on Big Sur (like the preferences window, again).
A bigger update is in the works, so my attention goes into that, but I wanted to make sure that – until the big update drops – it’ll run as efficiently and well as it can.

flickery (website | Mac App Store)

flickery for Mac App Icon

flickery – a full-featured client for flickr – will run natively on Apple Silicon and received, like ScreenFloat above and the apps below, a minor face-lift of its preferences window.
I’ve also had to remove QTKit (which I mostly did with a previous update of the app for macOS Catalina – but some more references I had kept around came up as an error in Xcode, so those had to go as well).
It was used to allow the user to edit videos before uploading them. It’s gone for the time being, but there are plenty of free tools (including QuickTime Player) that can step up here for the user in the meantime.

Transloader for Mac (website | Mac App Store | iOS App Store)

Transloader for Mac App Icon

Transloader – which lets you start downloads on your Mac remotely from your iOS device – also will receive a minor update. I had to remove some shadows from texts so it would look nicer in Dark Mode (and who does shadows nowadays anymore, anyways…).
I’ve also had to update its use of CloudKit, because some APIs were deprecated and replaced (in particular, I was using CKSubscription instead of the newer CKQuerySubscription). In the end, it was easy enough.
Transloader 3.0 is still in the works (some bits of progress you can read about here, here and here), so, like with ScreenFloat, I wanted to make sure it runs on macOS Big Sur (and natively on Apple Silicon) until the bigger update is available.

Glimpses (website | Mac App Store)

Glimpses for Mac App Icon

Glimpses – an app that lets you effortlessly create still motion videos – will receive a more substantial update.
After I fixed a glaring UI issue where the progress bar that Glimpses shows for the render progress was almost invisible, I gave the video creation algorithm an overhaul, which makes it up to 4x faster than before, which I’m really happy with. Multi-threading ftw! The app, too, will run natively on Apple Silicon.

SiriMote (free, website)

SiriMote for Mac App Icon

SiriMote didn’t require any UI fixes for Big Sur, but v1.3.9 which I recently released fixes a couple of connectivity issues – and already runs natively on Apple Silicon!
The app allows you to control your Mac and apps with your Apple TV Siri Remote.

I’m glad I was able to make all my apps ready for macOS Big Sur, and am very curious where things are going with Apple Silicon!

– Matthias
mail | website | twitter | instagram | facebook

Read more

SiriMote App Icon

Today, I’ve updated SiriMote to version 1.3.9.

What Is SiriMote?

With SiriMote, you can control your Mac with your Apple TV Siri Remote.
A few examples:

  • Control your Mac’s volume
  • Control iTunes (play/pause, next or previous track, fast forward, rewind)
  • Control Keynote (next or previous slide)
  • Control QuickTime Player (play/pause, fast forward, rewind)
  • Control VLC Player (play/pause, next or previous track, fast forward, rewind)
  • Control Microsoft PowerPoint (start/stop slideshow, next or previous slide)
  • Control any Mac app that reacts to your Mac’s keyboard’s media keys

What’s New in SiriMote 1.3.9?

– Re-establishes compatibility with macOS 10.12
– Improves the connectivity to your Apple TV Siri Remote
– Now asks for access to your Mac’s accessibility features (which the app requires to operate) if not already granted
– Fixes a few minor annoyances
– Ensures compatibility with macOS 11.0 Big Sur
– Built to run natively on Apple Silicon

Pricing and Availability

SiriMote is a freeware app, which means you can download and use it – without limitations – completely for free. If you like it, please consider taking a look at my other apps – thank you!
The app is available for download from SiriMote’s website (direct download).
SiriMote requires OS X Sierra 10.12 or newer and an Apple TV Siri Remote.

If you’re interested in writing about SiriMote, you can download the press kit here, which contains screenshots and further information.

– Matthias
mail | website | twitter | instagram | facebook

Read more

Screenshot showing Yoink and its update-timestamp on the Mac App Store

7 months. I look in disbelief at the Mac App Store’s timestamp of Yoink’s last update, and I’m deeply embarrassed.
As a user, I’d think the app is abandoned. As its developer, I know that’s not true, because soon after I’d released v3.5.8 of Yoink for Mac, I began working on the next one:

Yoink for Mac's GIT commit messages, showing the date of the v3.5.8 commit and the date of when work on the next update began (3 days later)

The user, however, doesn’t know.

The situation isn’t any better for Yoink for iPad and iPhone, either, where the App Store states 5 months since the last update (v2.1.6).
Here, too, I began working on its subsequent update the day after submitting it to the App Store:

Screenshot of GIT commit messages of Yoink for iPad and iPhone, showing the date of v2.1.6, and when work on the next update began, a day later

I cringe even mentioning ScreenFloat (10 months), flickery (11 months), Glimpses (11 months), or Transloader (5! years!).

The problem, I think, is that I do not plan ahead much. I give my attention to the app that – in my view – currently needs it most (which has been mostly Yoink for Mac, and Yoink for iPad and iPhone lately), and whenever I feel the update is done (an arbitrary line I draw spontaneously most of the time), I release it and move on to the next app (or the same one again, if need be).

I want – and need – to do much better here.

So here’s how I’d like to improve:

  • Release what’s ready once a month
    If there have been changes made to apps and those changes are ready for prime-time, release the updates
  • Unless absolutely necessary, after an update, move on to the next app, not keep working on the one I just released an update for
    Aside from the positive effect of giving other apps the attention they need and deserve, it also reduces the possibility of me getting burnt-out working on the same app all the time
  • Be more vocal about what’s going on
    I should be more transparent about what I’ve been and am working on – it’s fun to share!

Here’s hoping. Thank you all for bearing with me 🙂

– Matthias
mail | website | twitter | instagram | facebook

Read more

With iOS 14 comes a new privacy feature – a little banner at the top that shows you whenever an app accesses the clipboard.

Screenshot of iOS 14's Simulator showing the clipboard alert banner

I recently was asked in a tweet whether this was a bug. It’s not. It’s a feature 😉
But please let me explain in a little more detail what Yoink is doing here exactly.

Yoink accesses the clipboard without direct user-input in three cases:

Case 1 – Yoink’s Clipboard Bar

As you can see in the screenshot above, Yoink displays a small bar with the contents of the clipboard, allowing you to quickly store that content in Yoink (or, if it’s a URL pointing to a file, download that URL in Yoink).
To be able to display this bar, Yoink asks the clipboard whether it has new contents. It asks once when the app is put into the foreground, or regularly, in an interval whenever Yoink is used as a Side-by-Side or Slide-Over app (to be able to update the contents of the bar).

The clipboard bar comes in three settings (which can be changed in Settings.app > Yoink) :

  1. Ask
    This will make the clipboard bar appear whenever something new is on the clipboard (and will “monitor” the clipboard when the app is used as Slide-Over or Side-by-Side)
  2. Automatically store
    This turns off the clipboard bar, but will still check the clipboard for new content and automatically store it in Yoink.
  3. Never
    Turns off the clipboard bar and the auto-store feature, so the clipboard isn’t accessed

What I’m changing about this with the next update

Right now, the default setting is 1 – Always Ask for new clipboard content. This I want to keep, because I believe it to be a nice feature (and I’ve seen it used a lot).
However, I’m making it more obvious to turn it off, as you currently have to navigate into the Settings.app to change it.
So, whenever the ‘x’ button is pressed (to tell Yoink no, don’t store the clipboard’s current content right now), I’m asking the user directly if they’d like to keep the bar, turn it off, or always store new content automatically.
It’ll look something like this, after the bar has been dismissed:

Screenshot of new settings options

Case 2 – The Add from Clipboard Button

In Yoink’s top left corner sits the Add from Clipboard button. It is either active or not. To enable and disable it, Yoink queries the clipboard’s contents regularly (if it’s used in Slide-Over or Side-by-Side), and thus also causes the “clipboard accessed alert” to be shown.
It’s just a UI thing I thought would be neat, but ultimately, it’s unnecessary.

What I’m changing about this with the next update

I’ll remove the clipboard checking for this button and display an alert instead if there was nothing to be pasted on the clipboard.

Case 3 – Download a URL

Whenever you select “Download URL” from Yoink’s “+” menu, Yoink will check your pasteboard to see if you’ve copied a URL. If there is a URL, it’ll insert it automatically for you, if there isn’t, it leaves the URL field empty (and ignores the clipboard, of course).

Screenshot of Yoink's Download URL UI

What I’m changing about this with the next update

In iOS 14, Apple provides new API which allows developers to see if there might be a URL on the clipboard without actually accessing it. I’ll be using this going forward.

I hope that clears things up about Yoink’s usage of your clipboard.
And just to reiterate: I’m not interested in anybody’s data at all, and you can review my privacy policy here.

Read more