Tag Archive for app store

Thank You!

Code Journal LogoCode Journal has done extremely well on the Mac App Store recently. It reached as high as number 31 for free apps overall and number 2 in its category. Needless to say I was shocked by the sheer number of users downloading the app. For the most part users are happy and the app is working as expected. However, there have been a few issues that have cropped up over the last week.

Like many API providers Github limits third party developers to a certain number of API tokens and requests per time period. What this means in real-world terms is that if you are a third party developer, like I am, and you see rapid adoption of an app that hits their API, you may start to see some issues for some users. This issue has been further exacerbated by the fact that iPhone version of Code Journal currently uses the same tokens as the Mac version available from the Mac App Store and my site. Steps have been taken to resolve this issue on two fronts: one Code Journal for Mac now has more tokens and two once the next editions of the Mac app and iPhone app are approved, they will be using different tokens — essentially doubling the pool for both apps!

I’d like to personally thank all of you for giving my little app a shot and I would especially like to thank those of you who have emailed me your constructive feedback and were patient during the token drought. Your continued support has meant more to me than any chart ranking and I am happy to report that I will be releasing another free app on an Apple platform in the coming month or so. Stay tuned! And thanks again!

I welcome comments or replies to this thread on Twitter or Google+. If you haven’t already, download Code Journal from the Mac App Store.

Lessons Learned: Code Journal Early Release

As you may know Code Journal had its early release last week and it has been a pretty good experience so far. I got lots of great feedback from users and have already been able to update the application based on that feedback.  The purpose of this post is to share some of the lessons I have learned and create a discussion around independant software development and distribution. I could enumerate all the nice things that have been e-mailed or otherwise communicated to me re Code Journal, but I believe that there is more to be learned from criticism than praise, therefore, I am going to discuss some of  the application’s critiques.

Critique #1: Mountain Lion Only!?!?
Yup, I heard this one a lot. I decided to develop the application for Mountain Lion, because I thought a few 10.8 specific features were essential and that most of the application’s users would quickly upgrade to the new OS. Turns out that even though Apple reported record adoption of Mountain Lion (OS X 10.8), a large set of Code Journal’s potential users are running older systems: mostly Lion (OS X 10.7). The good news is that despite my miscalculation, I was able to rectify the situation quickly; I have already updated the app to support 10.7+ and I am happy to say that the updated version has been live for several days now.

Critique #2: No Pasting Passwords?
This one caught me a little off guard but really it shouldn’t have looking back. You see I have this odd habit of memorising long passwords, so typing them out is a pretty routine task. Most sane people, however, are using something like LastPass or a similar tool. I am happy to report that I have an update to Code Journal in testing that does allow the pasting in passwords and, unless any issues are found, that version will be pushed live early this coming week.

Critique #3: No App Store Version?
If you are a Coder Radio listener (and you should be), you will know that I am doing something of an experiment with Code Journal. Basically, I have not released it on the Mac App Store intentionally to see how that would affect sales and what (if any) feedback I would get regarding its distrobution. Before I mention what feedback I got I should say that this was the single most common critique of the app. In short, a lot of people have a strong preference to get all of their apps from the Mac App Store and do not want to purchase apps from a website. This is good news for Apple, but bad news for devs; I still hold that there is significant value in having a direct relationship to the users of your apps and the delays caused by Apple review process (22 days for Code Journal’s first binary) can be incredibly damaging if your strategy is to build and iterate rapidly. Assuming that the feedback I received is representative of the greater Mac user ecosystem, it seems that the Mac App Store will soon be the only feasible portal via which to sell apps; barring games that might do well in Steam.

Critique #4: What is Gumroad and Why Isn’t It PayPal?
This is another one that really surprised me, but it seems that there a lot of users who are not really comfortable entering their credit card data into Gumroad. Taking a high level look at my data I have x sales but x * 30 sales have ended right at the checkout screen. Think about that for a minute. The vast majority of people who like the info page enough to click “buy now” got all the way through the checkout process and turned back at the final checkout screen. The data aside, I have heard from several people that they or others close to them were not comfortable with entering the credit cards into Gumroad and would strongly prefer that I switch to PayPal. So why Gumroad at all? Well, they do a lot for me for the same cost as PayPal including verifying receipts, sending app updates to users, and a number of other small things that I would have to implement myself with PayPal. I am still considering how to handle this issue.

Bottom Line
In many ways I feel direct distribution has been incredibly successful, mainly because it allowed me to react quickly to user feature requests (back porting to Lion etc), however, the Mac App Store issue is a troubling one; if the percentage of Mac users who strongly prefer to purchase apps via the Mac App Store continues to grow, developers will have little choice but to conform to the somewhat draconian sand-boxing policies of the Mac App Store. Having said that, I am not against distributing Code Journal via the Mac App Store. In fact, if the numbers continue as they have (numerous users declining to purchase until an a version is on the store), then I probably am not going to have much of choice.

Comments? Questions? Find me on Twitter or Google+.

A Look at Control and the Mac App Store

Much like they have in the mobile space, Apple is leading the charge to commoditize software from independent developers, making it more affordable and convenient for users to purchase and keep up to date. The signs seem to suggest that this has on the whole been a boon for most developers but it has also put an unprecedented amount of control in the hands of Apple regarding what apps Mac developers create and what functionality they can and (more importantly) cannot have. Given that control, Apple has chosen to enforce a few policies that are not in the best interest of Mac developers: they refuse to support paid upgrades for large scale apps, enforce a rather rigid and restricting form of sandboxing, prevent developers from using some of the platforms newest and most interesting APIs on apps that are not distributed via the Mac App Store.

Developing software is difficult, time-consuming, and expensive. Traditionally, developers of large applications have used upgrade pricing schemes to maintain recurring revenues as a way to fund future development of their apps; an extreme example of this would the Adobe suite of tools.  Apple currently does not allow developers to charge for updates. Think about that for a second. Users are going to, as they have been trained to for years, expect  their apps to be kept up to date and, in some cases, provide increased functionality as time goes on. However, the current App Store model forces developers to either betray users’ expectations or somehow finance perpetual development of their apps on whatever one time cost they manage to charge on initial purchase; it should also be noted that apps on the Mac App Store have a tendency to be relatively low cost. Some have suggested that developers could take advantage of the Mac App Store’s in app purchasing APIs to make up the lost revenue. In some cases this might be a serviceable option but falls short of being a full replacement for true update pricing. The issue here is that this limitation discourages the continued development of large scale software for the ecosystem.

Security hasn’t been much of an issue for OS X historically. Despite what Apple fans would tell you, that has nothing to do with any sort of enhanced or inherit security on OS X. The truth is that OS X did not have a sufficient install base to make it an attractive target for malware authors. As Apple has been ever so eager to share, Mac sales are growing rapidly when compared to the overall PC industry. In short, OS X is becoming an increasingly attractive target for malware authors. Apple has responded swiftly to these increased threats in what is probably the most excessive heavy-handed PC security policy to date: sandboxing. If you are reading this, I assume that you already know what sandboxing is, so I won’t bore you by reproducing the definition here. In theory, sandboxing is a good way to make an operating system more secure, but in practice, it is more a restrictive mess than anything else. Basically, sandboxing does not provide enough benefits to be worth the onerous restrictions that it imposes on apps’ functionality.

For us developers, APIs are our windows into the platforms we work on. We depend on those APIs being documented, stable, and consistently available. On those first two counts, Apple has done a tremendous job in recent years. However, with the introduction of Mountain Lion, Apple has restricted a number of its newer and more interesting APIs to applications that are sold on the Mac App Store; if you are interested in what APIs are restricted, there are a number of them, but on the whole, they tend to be the ones that have to do with iCloud or the Notification Center. This is something of a Catch 22 for developers, since users are going to increasingly expect apps to provide the functionality provided by these APIs but may not necessarily want to purchase their apps via the Mac App Store. Once again, we have a case of Apple’s policies forcing developers to run afoul of users’ expectations.

What does this all boil down to? Apple’s recent policies make OS X development a lot more complicated for developers who want to keep up with the operating systems newest APIs but also are unable to comply with the restrictions associated with sandboxing. My take is that if you are developing a powerful application for OS X, odds are that you are going to have sell outside of the Mac App Store, due to sandboxing,  and live in fear of Apple one day using GateKeeper to further restrict the distribution of non-App Store apps. For another take on this, have a look at popular iOS developer Marco Arment’s post on the issue.

I know I have made some pretty strong statements here but I stand by them. If you would like to debate me on these issues or have any other feedback, find me on Google+.