Software Development

November 1, 2016

iTunes Affiliate Program – One Year In

Last year, I started using the iTunes Affiliate Program.
The program allows you to make a little money by linking to your apps with your affiliate token and lets you track where clicks and purchases come from, as well.
I thought it’d be interesting to do a little retrospective, now that a year has gone by.

Using Affiliate Links

Turning an (Mac) App Store link (or almost any other iTunes – based link) into an affiliate link couldn’t be simpler.
All you need to do is append your affiliate token (like &at=your_token).
Additionally, you can provide context with your links so you can track them more easily later on.
For instance, I “tag” my links with “twitter”, “facebook”, “blog”, “website”, “newsletter”, “yoinkdemo” and so on.
That makes it very easy to track where your customers come from.

I use affiliate links for every iTunes link I share – be it an app of my own or that of another developer.

Tools and Info

There are tools available to you to make affiliate linking even easier, like John Voorhees’ Blink (for iOS).
I personally don’t use any extra software – I have a note in Notes.app with all my affiliate links and then just change the aforementioned context string.

If you’re interested in an in-depth look at the iTunes Affiliate Program, I recommend you read John Voorhees’ excellent comprehensive guide about it on MacStories.
It’ll get you up to speed on how to set it all up.

Where do Clicks Come From?

A very interesting aspect of the iTunes Affiliate Program is its tracking capabilities.
When someone clicks your link, you know:

the country the user is in
when the link was clicked
the context string you provided for the link (like “website”, “blog”, etc)

A click presented in the live-view of iTunes Affiliate Program’s dashboard. I can see the click came from the US, and from within Yoink‘s “Demo Expired” window.

Furthermore, it tracks what the user purchased – a Mac app, an iOS app, a song, a book, etc.

Top 5 Countries

Based on the number of clicks, the top 5 countries from where people click on my links are:

United States
22,498 clicks
$254.15
Brazil
924 clicks
$4.96
Germany
570 clicks
$76.70
United Kingdom
91 clicks
$46.10
Spain
50 clicks
$19.17

Apparently, more clicks don’t automatically equal a higher payout.

Conversion Rates

The program allows you to see the conversion rates for your links.
Who really purchased after clicking my link? Here’s what I found out:

38.62% purchased an app after clicking a link on my website
25.70% purchased an app after clicking on the link from the “demo expired” window inside the app
(I haven’t had the affiliate link in the “demo expired” window in Yoink for the entirety of the year, more like only half a year)
00.72% purchased something when they clicked on a link on my blog

I can’t be sure what the user purchased – once a user clicks a link with an affiliate token, that token is used for the next 24 hours for that user.
Which means that they might click on a link for Yoink, but don’t purchase it. Then, some hours later, they purchase a book on the iBook Store – that will count towards that link’s conversion rate.

A Year of iTunes Affiliate Program Links

Here’s the gist of my first year in the iTunes Affiliate Program:

Clicks: 24,647
Items Bought: 4,465
Revenue Generated: $ 9791.12
Payout: $ 685.38
Average Conversion Rate: 18.12%

Granted, $685.38 isn’t a lot, but it’s money I wouldn’t have seen otherwise, and as an indie developer, every bit counts 😉

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 🙂

October 29, 2016

How to Badge an App’s Icon in the Dock

A recent conversation I had with Jeff Johnson (of ClickToFlash fame, @lapcatsoftware on twitter) prompted me to look into how badging an app’s icon in macOS’ Dock works.

There were a couple of questions that needed answering:

Does badging happen automatically when sending an NSUserNotification?
If not, how do I apply a badge to my app’s icon in the first place?
How do I retrieve and respect the user’s Notification settings for the app in System Preferences?

Automatic Badging by Sending a NSUserNotification?

Nope, automatic badging doesn’t happen. Even though System Preferences -> Notifications suggests that badges and notifications belong together, in code, they’re separated.
That means you have to add the badge to your app’s icon yourself. Also, you need to keep track of whatever number you want to display with the badge and update or clear it at appropriate times.

For example, Mail.app uses the badge to display the amount of unread eMails you have. The badge doesn’t clear when you activate Mail and only decreases when you mark mails as read.
Transmission, on the other hand, informs you about how many downloads have finished since you last had the app active. Once you activate the app again, the badge gets cleared and re-starts from zero.

How to Badge the App’s Icon?

Badging is straightforward:

NSApp.dockTile.badgeLabel = @"Badge";

Please note that putting text into the badge is not a good idea – I did it here just for fun, but text in the badge is very limited and if you have a longer string, what you’ll end up with is something like “A….z”.
It’s best to stick with numbers.

Respecting System Preferences’ Notifications Settings?

If you only use badges (without notifications), you’ll notice your app is missing from System Preferences’ Notifications preference pane.
That can pose a problem, because now you either have to create your own user-setting for badges or the user will have no way of turning them off.
The trick, then, lies with NSUserNotification. Not in the API itself, but in two crucial steps:

Code sign your app.
Add this key-value pair to your Info.plist: NSUserNotificationAlertStyle with a string value of either banner (recommended by Apple) or alert.
Supposedly, there’s another value, none, but that hasn’t worked for me yet – the app won’t appear in the Notifications preference pane.

Having the key-value pair in your Info.plist has no downside if you don’t use NSUserNotifications. There’s only the upside of having the user be able to disable your app’s badges if they like.

Now that the user can change the setting for your app’s badges, how do you read it out to see if you should badge or not? It’s easier than you think: you don’t.
Just like the system doesn’t show your NSUserNotifications if the user has disabled them for your app, the Dock simply doesn’t display your badge if the user has disabled it in System Preferences.

All you have to do is keep track of the number that should be displayed in the badge, and that you update or clear it at appropriate times.
For example, you might not want to have the badge visible when the user quits your app, so you could set -badgeLabel to nil in -applicationWillTerminate:.

By the way, if you ever need to reset System Preferences – Notifications for your app (or all apps), there’s a nice how-to on stackoverflow.

Happy badging 🙂

Update: Jeff Johnson follows up with some more tips and tricks about NSUserNotification in this blog post.

October 27, 2016

Follow-Up: Inactive Checkboxes Are Poor UX

[This is a follow-up to this blog post. It was inspired by the response I received through social media and different websites.]

In a previous version of Yoink, I had the following conundrum:

Yoink 3.2 Preferences Inactive Checkbox

The checkbox “Show window near mouse pointer when drag is initiated” is inactive and needs extra steps to be activated.
If I’m a new user of the app, at first, I have no idea how to activate that checkbox. At best, it’s something I need to set in this preference panel, at worst it’s a setting in a different one.
As a new user, my only option is to blindly change settings, waiting for one to activate the checkbox so I can select it.

There are different solutions to this problem, of varying degrees of effective- and usefulness:

A tooltip. If the checkbox is inactive and you hover over it, a tooltip appears, explaining what to do to activate the checkbox.
It’s a quick and easy solution, however, it’s almost undiscoverable. I know of many users who don’t even know tooltips exist.
Hiding the checkbox instead of having it be inactive.
That’s better, as it reduces clutter (as the checkbox would be inactive anyway). But it introduces another problem – nobody knows that the option even exists.

“For that UI, I think maybe an additional improvement would be to actually hide and show the checkbox completely instead of disabling it.
Also, indent the second checkbox so that it feels like it’s a sub-section of the first.
Another option might be to split things out into radio buttons instead of checkboxes and the popup menu.
That way you could expose the additional option tied to the appropriate radio choice, which you can’t exactly do with the menu item.”

– Manton Reece, via Core Intuition’s slack channel

Speaking of radio buttons, Adrien Maston wrote me a very detailed mail with some ideas he had about resolving the issue:

Since there are only two options for « automatically show when », maybe the setting could be radios instead of a select.
Then each option would be formatted as a column and each column would contain specific settings (the « drag starts » column would contain the « Show window near mouse pointer when drag is initiated » checkbox. Then it would make sens that clicking the checkbox would also set to « drag starts ».

– Adrien Maston, via eMail

What I ended up doing in Yoink v3.2.1, the release that followed this discussion, was this:

Yoink 3.2.1 Preferences Active Checkbox

Instead of having the checkbox inactive, it’s active at all times and can be clicked right away. The advantage of this is that for one, the user knows the option exists and two, the user can select the option right away without having to figure out how to activate it.
The downside, and this has been pointed out to me a couple of times, and I agree, is that clicking the checkbox changes two settings at once (the checkbox and the popup, as you can see in the GIF above). It changes a setting the user has made before. And that’s bad UX design on its own right there.
My thinking was, it’s in the same preference pane, so the user sees what’s happening right away. It still was the wrong decision (as has been pointed out to me in the comments on designernews.co).

For Yoink v3.2.5, I re-thought the whole thing and decided to make it three options in a popup.
This is the result:

Yoink's Behavior Preference Pane in v3.2.5

It solves a couple of things:

The inactive checkbox is a thing of the past
The options you have for when and where Yoink should appear are much clearer
You get a preview video for every option so you know right away how each setting affects Yoink

Additionally, I think it’s the nicest Yoink’s Behavior preference pane has ever looked, so that’s a plus 😉

Eternal Storms Software Logo

October 21, 2016

Yoink’s Revenue a Month After Localizing

Translating your app into different languages is becoming more and more important. And articles like this one (techcrunch) seem to confirm that.

With Yoink 3.0 (mac app store, website), I localized the app into Japanese, Simplified Chinese, French, Portuguese (European and Brazilian), Korean and Italian (in addition to the languages that existed from the start: English and German).

Yoink in Portuguese

Here’s how revenue of Yoink increased a month after its 3.0 release (compared to the month before):

Japan: 305%
France: 212%
China: 144%
Portugal: 120%
Italy: 80%
Canada: 76%
Brazil: 45%
Belgium: 37%
South Korea: 16%
Switzerland: 4 %

There are great services available to help you: iCanLocalize, Gengo, wordcrafts, brlingo, just to name a few.

Yoink in Japanese

So, if I have one tip for you today, try to localize your apps at least into Japanese and Chinese – it will be worth it.

Eternal Storms Software Logo