Apple

Control your Mac with your Siri Remote – with SiriMote (for free)!

What’s New in v1.4?

  • SiriMote now supports Apple’s new Siri Remote (2021) on macOS 11 Big Sur and newer.
    I’m looking into bringing support for it to older versions of macOS as well, but I haven’t found a way yet.
  • A new App Icon

If you connect a new Siri Remote to your Mac, you’ll be greeted by this new drawing:

Just like the old remote, this new one is drawn in code so it scales nicely 🙂

There’s not much more to tell about this update, except that SiriMote is Freeware – as it has been from the beginning.
However, if you’d like to support my work, please do check out my other apps – it’d mean a lot to me!

Enjoy!

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

As some of you may know, getting Yoink for iOS through Apple’s App Review was, to say it lightly, a bit of a pain.
In the end, I was able to release it, but a month late. Had this been my first app as an indie developer, there’s a good chance I would have had to declare bankruptcy now.
I am fortunate enough to have a couple of apps out already that create a steady income, but still, I spent about two months exclusively on this app, so it’s still scary thinking about how I got rejected over and over.

Long story short, here’s a couple of thoughts I’ve had during all of this.

TestFlight App Review

From the very beginning, I’ve had Yoink available to a couple of (awesome) testers via TestFlight.
Now, when you add a new app or a new version of the app to TestFlight, it has to go through a review before testers can download and test it.

My question, then, is: Why not reject the app right there if it doesn’t comply with the rules in the App Reviewer’s eyes?
If this is not checked, why have a review for TestFlight apps in the first place?

Or if that’s unrealistic for some reason, perhaps TestFlight App Review could give sort of a “likelihood of getting through the ‘real’ App Review”. Maybe on the levels of “yea, good luck with that” to “possibly, tentatively not going to be rejected”.

It would have saved me (and the App Review person) a *lot* of time and nerves had, for example, the File Provider extension been rejected right then and there for not being cloud-storage based. Or the keyboard, for not having a traditional method of input. Those are all things that could have been avoided, had TestFlight App Review caught these things.

Reasons for Rejection

Yoink was rejected for different reasons and in different areas of the app.
But those reasons were given to me one by one, one submission and “Waiting for Review” -> “In Review” cycle after another.
That’s *such* a waste of time (not only for the developer, but also for the reviewer. But *especially* for the developer).
Why not keep going after finding a reason for rejection and see if there are other issues after that? If so, the reviewer could note them all down and give them to the developer all at once, not one by one.

Notice of Escalation

When an App Reviewer isn’t sure about an app, the review is “escalated”, meaning it goes up one instance in the App Reviewer hierarchy to be reviewed by a “superior”.
That would be the perfect time to let the developer know in advance that, “look, review is going to take a little longer because we’ve run into an issue with your app. Please stay tuned, we’re working on it.”.
Not only would the developer know that it’s going to take longer for the app to be reviewed, they’d also have reassurance that the App Reviewer hasn’t forgotten about the app – anybody who had an app “In Review” for more than twelve hours knows that feeling 😉

In closing, I’d like to say that I have nothing but respect for App Reviewers. Their job is difficult and, mostly, unthankful.
But I believe a lot of grievances on both sides could be avoided if some of these suggestions were put in place.

Eternal Storms Software Logo

– – – Do you enjoy my blog and/or my software? – – –
Stay up-to-date on all things Eternal Storms Software and join my low-frequency newsletter (one mail a month at most).
Thank you 🙂

Read more