Offering Support via iMessage

In this article I am discussing the benefits and downsides of offering support for your apps via iMessage, which we started doing for our most recent app for OS X.

Our most recent application DockPhone is a very simple app. It lets you make calls from your Mac using a technology that is provided by OS X. Since sometimes linking two devices, your Mac and your iPhone, can be error-prone, things can go wrong, and DockPhone might stop working.

Or even worse, DockPhone won’t work at all.

In such kind of a situation, your app might receive a few bad ratings on the Mac App Store, which is already enough to destroy the months of work you put into it: Not all happy users submit their rankings, but the unhappy users almost certainly do. I think there is a fundamental flaw in the ranking and rating system of the Mac App Store. And to work against this flaw, one strategy can be to offer outstanding support to your customers.

Offering Support via iMessage

So a few days after releasing DockPhone publicly, we realized that we could offer the way we support our customers not only via email, but via iMessage as well. Thus, we decided to not only display a large “Get Support via Email”, but also a “Get Support via iMessage” button on our promotion and our help site. DockPhone users are iPhone users, so they are certainly iMessage users as well. Perfect fit!

To offer the support for DockPhone via iMessage, we have created a new Apple ID and have added an additional email address, which we advertise on our site(s) as the entry point for a support conversation. We then configured on some of our Macs accordingly. And so far it is working really well.

Customers Appreciate the Quick Support

We already could help lots of our users to set up their devices so that DockPhone started working. This not only saved us from receiving several poor ratings on the Mac App Store, but also gave us the opportunity to talk directy to our customers. The Mac App Store is quite an anonymous selling platform. Apps are not sold from producer to customer, but sold by Apple. Most of the seller-buyer relation is gone.

Once you start chatting with your customers, you learn about their use cases, their configurations, and their motivation to buy your app. It is not only beneficial for the customer to get the support, but also quite funny and informative for you. And by the way, you also get the chance to kindly ask for a nice rating on the App Store, once the problems have been sorted out.

But does it scale?

Certainly not. Support conversations via iMessage may last several minutes in total and stretch across multiple days, requiring re-reading the previous messages to get to know the customer’s problem again. But note that this is the case for email conversations as well.

Offering support via iMessage also involves the danger, that the customer is at the end even more dissatisfied then before. Since we all hate the feeling of not receiving an answer, even we saw our conversation partner has read our message, you probably want to switch off Read receipts in the iMessage settings. Or you force yourself to read an incoming message only if you have time to process and answer it immediately.


For us, offering support via iMessage will definitely be an option for each of our future projects we will consider, since the benefits are golden. Bad ratings have the potential to destroy your revenues, so developers should think about every possible opportunity to fight against them.

DockPhone for OS X and its Days of Success

We started building the app when we saw similar apps, that were available for beta-testing. The competitors had a weird look, and felt strange to use. Competition is always good, so we thought we could come up with a better solution.


We have submitted DockPhone to the Mac App Store review team on the 14th December, after several weeks of development. It is hard to estimate the amount of work we have invested. Four days later, the app was ‘In Review’ for more than three hours, until it has been globally published by the team. As usual, it then took several hours for the app to appear in all the listings of the Mac App Store, and the iTunes Preview webpages. I wish this content distribution process would not take so long.

Mac App Store Optimizations

For your OS X app, you can choose a primary and a secondary category. For the secondary category, DockPhone is listed in the Utilities section. I’ve chosen the Business category as the primary category of DockPhone, since it’s the first one in the list of categories, and more likely to be scanned by the Mac App Store visitors. Becoming the Top Paid app in a category is not that hard on the Mac App Store, and since your app will be used a the category’s icon then, choosing your category wisely is important. I knew that DockPhone’s bright, green app icon would greatly shine out on the Categories overview page. None of Apple’s applications is listed in the Business section primarily, which is crucial. E.g., in the Utilities category, OS X Server is always among the Top Paid apps, which I didn’t want to have to fight against.

From the glorious days of Chat Heads, I knew that once the app establishes a certain ranking for a longer period of time, it will also be listed (I think automatically) in the top row of its category page, with a bigger icon in a less crowded layout. Unfortunately, DockPhone so far has not been listed here. Fingers crossed!

Quality Assurance

Crash reports are these long, cryptical text extracts, that are generated by OS X whenever an application stopped working or suddenly crashed. They contain a lot of hex codes, thread information and other stuff which a non-developer usually does not how to handle. For the developers they provide very precise information about the reason for the crash, and thus, are highly valuable. Apple does collect these crash reports of your application automatically, but only provides a few of them to you as the developer on iTunes Connect. It is not very clear to me, what exactly influences the number and the filtering of these crash reports, but I can only say that we want every single crash report from my users, in order to see which are the main sources for unexpected behavior, and eventually, bad ratings.

Therefore, we are using the glorious HockeyApp service, that automatically collects all crash reports automatically and even symbolicates them, so that we get to know the precise source for the bug. I claim you will not survive if you release your applications without even thinking about how to take care of crashes. So HockeyApp is worth every penny. It also helps distributing beta versions of your app, and offers lots of more additional valuable features.

Selecting Features

For start-ups you often learn that it might be a good strategy to launch quickly and expand your feature set steadily. I don’t think this works for apps. Once you have launched, you will hopefully get some press coverage, and that is the only chance to reach these millions of users, which rely only on editorial reviews. It is hard to get press coverage, and it is even harder to get additional coverage for version 1.1 or 2.0 or your application. You do not only have to convince your potential customers, but also the PR guys to write the review. So your application should definitely provide some very good reasons to buy it from the very beginning, and you should not forget to implement the obvious features everybody would expect: For example, we are now receiving a lot of feature request emails to add a global shortcut to bring DockPhone up front. This should have been part of version 1.0. So next to a thoroughly testing phase on several Macs in different environments, wisely choosing the initial feature set usually defers the launch.


On Friday, December 19th, Doney fortunately posted DockPhone on ProductHunt. Since this page is being watched by several bloggers and techies, we got a few app reviews without any further PR. We made use of the immediate feedback to find out what the users were yelling about, and how they reacted on the fact that DockPhone does not provide any groundbreaking technology, but only acts as some kind of a shortcut to an existing functionality provided by the OS. Fortunately, most of the users appreciated the way DockPhone works. Obviously, it makes sense to join the ProductHunt discussion, in the role of the creator of the application, as soon as possible, to cultivate a discussion, and attract more up-votes.

On ProductHunt, iOS apps and web services tend to get more traction than OS X apps. The day DockPhone has been listed (in the afternoon), the DockPhone website got around 2000 visits. On the following day nearly 1800 hits were registered. The third day, less than 1000 visitors were on the website. I expected far more clicks, actually. Of course most of the downloads so far were generated by visitors of the Mac App Store, not by visitors of the web page.

Press List

I knew that we had to send out emails to all major OS X and iOS related websites quickly before they all leave for the holidays. So on Sunday, 21st December, after being listed on ProductHunt, I have prepared and sent out a press release to nearly 30 pages I considered to be potential reviewers. I have had already collected a list of email addresses for our recent MyPhotostream press release, but I still needed to guess some email addresses of some of the authors. We got the first reactions the same day a few hours later.

By the way, I had again a lot of troubles sending out personalized emails with attachments to a set of 30 recipients at once. I was trying to use Automator, but once the emails were generated, Apple Mail always crashed. I must have generated more than 20 crash reports during that time. If anyone has a recommendation on this, please let me know. I don’t want to use a web service for this, but native apps instead.

Press Release

The press release is crucial for the success of the app. You need to provide a brief overview about the app’s capabilities, its unique selling points and a story they can pick up to write an engaging article. You should also prepare a Press Kit, which contains the icon of your app and screenshots in multiple resolutions, and a short, medium and longer description of the app. I have also added the technical requirements of DockPhone, and one sentence about the new group. Last but not least, details on the pricing strategy, and a Promo Code which allows them to download the app for free, should also be part of it. The general goal is to simplify the reviewing process as much as you can, and to provide a significant reason why they should invest time in reviewing your application.

I am also tracking the number of downloads of the Press Kit and till now it has been downloaded roughly 80 times.


I often hear that the price of our applications is too low, and we should charge more. The point of selling an app for just one dollar to me has the following benefits: A $1 price is a no brainer to lots of Mac users. Next, a customer (hopefully) will not sue you if the app is not working properly for this price. A $1 price also helps becoming the Top Paid application, and more importantly, residing in the charts, which of course is important for a sustainable long-term development of your sales after the first few review articles on the bigger websites.

Estimating the value of an application, and mapping it onto a certain price is really hard. So I usually try to think what price I personally would pay for such an app, instead of thinking about customer classes, and other fancy marketing rules. At the end you never can tell, which would have been the ideal option, since A/B testing on pricing is actually not feasible. I was also scared of lifting the price after the first reviews, since the users would start complaining, as the $1 was noted in all the reviews. Also, I have noticed in the past that changing the price led to a state of the app in the Mac App Store where it cannot be downloaded temporarily (“The app is currently being changed, please try again later”, or something similar). It is incredible that this is the case, but since I have noticed it once, I lost my trust here.


DockPhone is the first app we have prepared a simple promo video for. We are far from being a professional video editor, so the quality of the result is questionable, but I think it answers the purpose: One one hand, the press has a chance to get to know the look and feel of the app without even downloading it, and on the other hand, the viewers of your website get a glimpse as well. The video is hosted on Vimeo with a Pro account in order to make use of the HD embedding. Fortunately, the video has been embedded by many of the reviews so far, so it turns out to be truly valuable and worth the iMovie tortures. Unfortunately, since the Mac App Store does not seem to be Apple’s top priority platform, you still cannot provide videos on your Mac App Store application page, which is a shame.

We have chosen vimeo as the hosting service, since they provide lots of beneficial features for promotion videos. Also, Youtube to me personally has always been a place of arbitrariness, junk and bad quality. The video has been played ~11k times and received roughly 5 likes, yay!

Yay, TechCrunch!

I have set up my web page to send me a mail with every 25th click on the download button on the app webpage. The button simply redirects to the Mac App Store. I noticed we suddenly were receiving lots of these emails, so I checked out slimstat, a simple alternative to Google Analytics, what was the source of traffic. When I saw it, I didn’t even read the TechCrunch article, but focused on immediately improving the website significantly instead, to make sure to make the most of all the new visitors. I have added a dedicated section for the technical requirements, and the announcement to build an iOS companion app, that makes use of HandOff, which should indicate that the app is still in active development after launch, and it will provide even more value to the user in future.

Here I noticed again how important a well considered selection of the initial feature is. The iOS companion should have been part of release version 1.0, since significant new features usually later do not receive the expected press coverage. Instead, these features have the potential to provide yet another reason to ultimately cover your 1.0 version.

TechCrunch led to a visitor boost on the website: 5000 visitors on that day. Not that much, right? Yes, right. There a lot of factors influencing the number of visitors after being covered by bigger websites. The article must be seen, its headline must be exciting enough to click it, the app that is being reviewed must remind the viewer that it could solve a problem, and many more. Conversion rates multiply, and the resulting stream of visitors is much smaller than one would initially think.

Post TechCrunch

It was a pleasure to see the effects of the TechCrunch article. I usually observe Twitter to get a feel for the current interest in my apps. Next to countless auto-generated tweets based on auto-scraped TechCrunch contents, I noticed several Top Tweets, such as Mr. Feld’s buying advice:

DockPhone received additional reviews on other sites, such as,,, These may have been triggered either by the press releases I sent out, by the TechCrunch article, or by the sudden good ranking of the app in the Mac App Store.

The app became the Top Paid business app in a lot of countries fairly quickly. In some countries, it fortunately even reached the overall Top Paid ranking. In the US Mac App Store, the best position was the 4th, and residing the Top Ten for the three days after TechCrunch. As a side note, I was also happy when I saw my name on, next to ‘Apple’, ‘Aspyr’, and others. Life goal achieved:


Is it worth developing for the Mac? Hard to say! It clearly depends on the developing costs you have invested. Since we are students, and developing apps is a funny hobby we enjoy, this probably won’t be the last OS X app we have developed. However, I currently could not imagine making a living out of it. There are too many risks involved, and the general outcome is so hard to influence and control.

AppAnnie has been a great tool to observe the daily development of the downloads, and the resulting rankings. It has not been perfectly accurate, since I noticed better rankings in some countries, than listed in the stats, but the tool definitely provides some valuable data.

It is important to note, that the Top Paid app rankings not only depend on the sales, but also take into account the current rating.

Today, on the 29th December, DockPhone has generated a lower 5 digit number of total downloads, within the first ten days after the release. Compared to the press coverage I received, this may sound a little bit disappointing. However, again, since we are students, we gratefully appreciate the revenues. I am releasing this information because I believe there is a lack of current data about market size, and advice on common pitfalls one should avoid when developing applications for iOS or the Mac.

Come to the Dark Side — WAYTheDarkSide

I remember it clearly when we were at the WWDC ’14 and Craig Federighi on stage announced that OS X Yosemite will feature a brand new Dark Mode — the cheering crowd responded.

Still, several weeks after OS X Yosemite has been released, there aren’t that many Mac applications out there that truly take into account the new global preference which influences the look of the whole system quite substantially. In some situations, it may be appropriate to adapt the dark look in your application.

For example if you have large, bright areas in your UI, you should consider customizing them for a dark appearance, so that your app is still soft to your users’ eyes late at night.

One of the reasons why developers haven’t made use of the new OS X feature might be that determining if the user has switched to the Dark Mode is not as easy as it could be. There are no obvious APIs to ask for the current setting and be notified about changes.

Today we’re releasing WAYTheDarkSide, which utterly simplifies the adaption of the Dark Mode in Yosemite. This is how it works:

Distributed Notifications & the Global Persistent Domain

Let’s look at two things to properly handle the Dark Mode:

First of all, to detect the current state while starting your application, there are multiple ways to go. One of them involves running an Apple Script that reads from the system settings. However we are using a clean, pure Cocoa based approach: reading the NSGlobalDomain persistent domain and asking for the BOOL value of the AppleInterfaceStyle key.

Next, to observe the state continiously while running, we need to listen to the Distributed Notification with the name AppleInterfaceThemeChangedNotification. This notification will be fired by the system whenever the user toggles the Dark Mode on or off. NSDistributedNotificationCenter is your friend.

Handling the Dark Mode with WAYTheDarkSide

We have wrapped the two techniques into a class, which provides multiple interfaces, that make handling the Dark Mode as easy as pie.

In the simplest case, you simply define a block which will be performed when the Dark Mode is switched on, and one for when the Dark Mode is switched off:

// The application decided to join the dark side
[WAYTheDarkSide welcomeApplicationWithBlock:^{
    [weakSelf.window setAppearance:[NSAppearance appearanceNamed:NSAppearanceNameVibrantDark]];
    [weakSelf.contentView setMaterial:NSVisualEffectMaterialDark];
} immediately:YES];
// The application decided to leave the dark side
[WAYTheDarkSide outcastApplicationWithBlock:^{
    [weakSelf.window setAppearance:[NSAppearance appearanceNamed:NSAppearanceNameVibrantLight]];
    [weakSelf.contentView setMaterial:NSVisualEffectMaterialLight];
} immediately:YES];

Well, we had fun finding the naming here. The two blocks will not only be triggered upon a preference change event, but also while starting the app, since we have set immediately:YES. See the headers for details.

Since you hopefully have architectured your application with several NSViewControllers and NSWindowControllers, you will however probaly rather make use of the per-object based API. This will let you define handler blocks individually for each controller, that owns any UI which should reflect Dark Mode changes:

[WAYTheDarkSide welcomeObject:self withBlock:^{
     /* ... */ 
} immediately:YES];
[WAYTheDarkSide outcastObject:self withBlock:^{ /* ... */ } immediately:YES];

That’s it. Note that the class does not provide any automic NSAppearance or NSVisualEffectMaterial handling. It is up to you how you define your application’s look in the respective states.

The class also provides some helper methods, such as applicationReadyForTheDarkSide; and applicationIsOnTheDarkSide;.

Find the repository on GitHub.

PS: Have a look at [NSImage setTemplate:]; concerning your NSStatusItem images!



Today we have published WAYSourceListWindow, a beautiful subclass of NSWindow that provides a Master-Detail view pattern.

We developed WAYSourceListWindow to simplify the creation of tool applications that make use of a source list sidebar paradigm. Think of of or, and you will know how it works: a blurred full-height view on the left side, and a big content related container view on the right side.

Note that this class is OS X 10.10 Yosemite only.

Find the demo on GitHub.