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.