Archive for Apple

Programming Pitfalls: iOS Simulator and Audio Codecs

PitfallThere are some bugs that you fix and brag about to your friends afterward, then there are the ones that are just plain embarrassing. Unfortunately, I’m writing about one of the latter today rather than the former.  You see this pitfall, though no more or less annoying than the others I cover in this series, is made all the more worse by the fact that I should have known better. If you’ve ever listened to an episode of Coder Radio in which I mention the iOS Simulator, then you know that I always warn developers to never trust it; the reason for this is that your code isn’t really running on iOS but rather a pseudo-OS X platform. Never ever trust the simulator. Ever.

Taking a step back, let’s look at the issue. I have a number of audio files and they all play just fine on the iOS Simulator, but my beta testers are reporting that they can’t hear any audio files at all on their devices. This is odd to say the least. I scoured my AVAudio implementation looking for the most obscure of bugs but still found nothing. The good news, using “good” very loosely, is that I was able to delete the app and reproduce the bug myself.

After a few hours of pouring over LLDB and various Test Flight logs, I found that everything looked fine: the audio URLs (the audio is coming from a server) all looked fine, there didn’t appear to be any NSZombie related issues, and the audio files themselves seemed fine.  I was totally lost.

Then I remembered something based on an offhand comment I found on a StackOverflow post — the simulator uses OS X’s audio subsystems which differ from iOS’s. In particular, OS X has access to a few more audio codecs than iOS. As it turns out, the API I  was interacting with has different calls that request the audio in different formats. I changed the call to request the MP3 formatted files and was good to go. Facepalm.

I hope you’ve enjoyed taking a look at another programming pitfall and please do leave any comments on Google+ or Twitter. Also, please keep in mind that I am always available for consulting projects.

Play Means War

google-play-logo11Google IO fever is in full swing and, though there are a lot of interesting things coming out of this year’s IO, but there is only one real threat to Apple’s leading position in mobile Monetization. This is Play Games. Play Games functions a lot like Game Center with a bit more and (naturally) a focus on Google+. Play Games allows many of the features that Game Center does but has one killer feature: it is cross platform, supporting Android and iOS. You might wonder why this matters, but the truth is (according to the Apple App Store top grossing and top paid charts) the developers that are making the most money are the game developers. It has been argued that one of the big advantages that iOS has is that it is the prefered platform for mobile game developers — meaning that they release on iOS only or iOS first.

Play Games looks really impressive, but the most attractive aspect of it is that it is a backed Game Center like service that is not run by Apple. Let’s be honest, Apple makes great devices and some pretty good client-side software, but their backend services leave a lot to be desired. Game Center in particular was crippled when Letterpress — one of the first games to actually take advantage some of Game Center’s more advanced functionality — was released and became an overnight success. The reality is that Apple left this door open by not focussing on backend-technologies and now Google is going to be able walk through it.

If Android is able to generate roughly the same revenue as iOS for developers, Apple will have to act quickly to preempt an exodus of developers. This might sound a little overboard, but there is a frustration in the iOS community in all but the most hardcore Apple fans that Apple’s policies are increasingly hostile toward independant developers, but as long as the business case is strongly in Apple’s favor, Apple can do whatever it wants. If Google was able to change the business story, they’d be changing the entire landscape.

 

No, The Market is not Fine

There has been a lot of discussion recently in the iOS community regarding the so called “health” of the paid application market. My feelings on whether it is better to pay for the software you use to ensure that you are the developer’s main customer are well documented both on this site and Coder Radio, but, for new readers, I am an advocate of paying (and charging) for software. The most recent developer to throw his hat into this debate has been Marco Arment – the famous developer of Instapaper and The Magazine. Marco is a great developer and someone whose work I respect. His post is well thought out and reasonable – up until the last line where he states: “The bar is higher, but the market is fine”. Before diving into how someone as euredite as Arment could be so mistaken, let’s first define what it means when we say the bar is higher – apps now require a “better user experience” and a good deal of marketing to even be noticed by a reasonable number of users.

Yes, I know Apple has changed the world! Users now demand simple and elegant experiences. Isn’t that great? Well, no if you’re a developer, that’s terrible. That’s terrible, because, as a developer, you likely do not possess the design skills or experience to properly design an app of design caliber that a professional designer would. Like developers, designers do not work for free and a gifted designer who has been working in the field for any length of time command and handsome hourly rate. That means that to hit the required level of design, developers need to invest a good deal of capital in it.

Let’s say that you’ve got your design down and you’ve come to terms with your newly shrunken bank account – my condolences on that by the way. What now? Do you just passively wait for users to download your app? Perhaps you pray for users? Do a rain dance? Sadly, there is no evidence to suggest that any of the preceding will actually help your app become successful. Like any product (and yes your app is a product, not some work of self-expression), your app needs to be marketed. There are a lot of ways of to market it an app, though few of them are effective, but none of them is free unless you are a known quantity (like Arment) or able to convince one to push your app. That means you will need even more capital to get advertising for your app.

Like Arment, I agree that the bar is higher for apps than it was just a few years ago, but I contend that the bar being higher is a problem for the average independent developer. Many of these developers simply do not have the capital required to hire a decent designer and effectively market an app. So, if Arment seems to agree that the bar is higher, then how could he be so blind to the issues that poses for small independent developers? The answer is surprisingly simple: Arment is something of a celebrity in the Apple developer world. That means he doesn’t need to spend the capitol that others would to market his apps; In fact, his name and connections do that for him. In short, the bar is higher for all of us, but it is only half as high for Arment.

Wither Webkit?

As you are probably aware Google has forked Webkit and will be calling their fork Blink. Google does not intend to re-merge with the main project at any point in the future and is signaling that they will be adding new features to their rendering engine. As a developer who often has to work on the web or mobile web this is very interesting but also a little concerning.

 

Currently, Blink and Webkit are just about identical, so we can still feel secure in our Webkit “monoculture”, but the situation will likely change in a year or less. Even if Google makes an effort, as some have suggested that they might, to not break standards or chooses not to push Blink specific features, web developers are still going to have to deal with yet another rendering engine. Sure we’ve already been dealing with a number of them and have gotten used to having to append our CSS with “–webkit” or “–moz”, but Google is not adding a “–blink”. Instead, developers will have to dig into a settings screen to enable or disable functionality. Bottom line there is that there will be Blink specific functionality that some developers will likely want to user; for example currently NACL only works on Chrome and Dart VM works best on Chrome – in other browsers code written in Dart has to translated into traditional JavaScript. There are also a number of rumors floating around that Blink may focus on optimizing HTML5 graphics performance on ARM devices.

 

The question really becomes not what Google is going to do with Blink but rather what are the rest of the Webkit team going to do without them? Google and Apple have been the driving forces around the project and more and more Google has been taking point on a lot of the more cutting edge issues; for example, Google has been pushing performance more than any other contributor to the project but, for the most part, Apple and others have been able to benefit from Google’s efforts thanks to the free software nature of the project’s license. Given Apple’s less than enthusiastic embrace of developers using web technologies to develop for their platforms, it seems unlikely that they would be inclined to match Google’s pace. In a lot of ways, give that Apple’s business model is to sell expensive hardware, a good browser is just another feature on an Apple device, however, for Google, the browser is the primary platform.

Progress is a good thing for web and I am confident that Google’s decisions will yield web developers some pretty cool tech to work with, but there is also the risk that web developers will start relying on those tools too much and we will end up back in an IE 6 / ActiveX situation. Questions? Comments? Dogmatic rage? Please feel free to contact me on Google+ or Twitter. This post was brought to you by Code Journal for Mac.

Errors of 2012

Code Journal Logo2012 has been an exciting year for me, as I released my first commercial OS X App under Fingertip Tech, INC this year. Overall, the experience has been great and I am really enjoying all the great user feedback and am happy to report that a lot of users truly enjoy using the app. However, there have of course been a few missteps along the way.

Marketing: This is the biggest one by far. It is truly amazing what a positive effect a tweet about your product can have on your sales. Unfortunately, I didn’t realise this and failed to allocate enough capital for a proper marketing campaign. I am not talking about purchasing reviews here of course, but it is a reality of the current app marketplace that it is very hard to get a lot of traction without a significant marketing push.

Service Dependency: This is a closed second to my marketing misstep. Like Tweetro and so many developers before us, I have found that developing and maintaining an app that is built upon a third parties service is more than a little challenging to say the least. I won’t beat a dead horse here, since you’ve probably heard this from a number of other developers, but do not do this. Just a small example of one the most minor issues you will face: yesterday Github.com went down and stayed down for an extended period of time and I recieved a deluge of e-mails from frustrated users who could not interact with the service via the app because of this. The unfortunate truth is that if all or even a significant number of those users had decided to one-star the app instead of seeking support from me, sales would have been significantly impacted.

Like so many before me, I am unlikely to develop an app based off of someone else’s service again.

Distribution: Code Journal is currently sold on both the Mac App Store and its own site. Sales have been about equal in both places — some weeks favoring the site and other weeks the App Store. Overall, sales have been good, but since the sales are split about equally, the App Store ranking is significantly lower than it would be if all of the sales had come from there.

On the other hand, it has taken at least twenty (20) days for each update to be reviewed and approved in the Mac App Store. That’s simply too slow, since I have been trying to iterate quickly.  Also, the App Store does not give me direct contact with my users and that’s something I greatly value

Focus: In many ways, Code Journal has been a success and I very happy with how it is performing. However, I’ve lost a significant amount of time and wasted a significant amount of energy attempting ports of the app to a number platforms using a number of tools. Code Radio listeners will know that there was a Mono port and a QT prototype already. What they don’t know is that there have been others — even a Java version. All of them were not satisfactory and were in many ways the lowest common denominator for whatever platform they targeted. I still hold some hope for QT in 2013 to bring truly powerful cross platform development, but, at least for now, the best apps will always be the ones written with the native toolchain.

So, what do you say, did you release a product / project this year? Questions? Comments? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.

Pricing: We’re Doing It Wrong

Like many of you I am an independant software developer and have found some success leveraging the App Store. Many developers, myself included, have bought into the low price / high volume business model and we’ve had some mixed results…. I’ve been considering the pricing issue for a while and have come to an odd, but by no means original, conclusion: we are all underpricing ourselves. Please note before you read this that I am excluding games from the equation here

This might sound strange given the rise of freemium software and the general wisdom that cheaper software sells in higher volumes. However, it doesn’t seem to hold up.  Taking a fast look at the current top ten grossing paid applications on the Mac App Store, the average price of an app is $75 and the most commonly appearing figure is $20. Now before you get too excited about that $75 figure keep in mind that the average is shot up by a few apps at $200 or more. Also, keep in mind that I am using the ‘top grossing’ for my metrics rather than ‘top paid’; I’m using ‘top grossing’ because it isn’t clear what it means to be a ‘top paid’ app but an app’s gross revenue is an accepted metric I can use to judge its commercial success.  A few other things I’ve noticed from looking at the top grossers: none of them is $0.99, none of them is $1.99, none of them is even $4.99, and the lowest priced apps are $20.

To be honest, I don’t know what price points we should all be hitting, but anything below $4.99 for desktop software seems like far too low; in truth, I am starting to feel like the $4.99 price point is even a bit too low given how much work we put in our products. All I know is that we (software developers) need to end this race to the bottom on price.

Comments? Questions? Drop me a line on App.net, Google+, or Twitter. Also, pickup Code Journal.

Macbook Air for Development

If you have been following me on Google+, you may know that my beloved Macbook Pro had a little accident; I was working late and was extremely tired and I dropped my full mug of coffee directly onto my Macbook. That’s right the entire mug of steaming hot coffee went directly into my almost two thousand dollar laptop. Desperately, I began to dry off the machine and attempted to use compressed air to force out the moisture. I did this for some time  but finally had to go to sleep. All I could do was wait. In the morning it became clear that my machine was a doorstop, so I drove to the nearest Apple Store and made a purchase.

 

The laptop being replaced is a Macbook Pro 13” i7 with 8GB of RAM. By any measure it is a powerhouse for a laptop; full disclosure it has had some trouble with kernel panicking that I believe were due to overheating.

 

As usual the Apple Store was jam packed, so I had to wait to speak to an employee, but that was fine, since I had not yet decided what to buy. I knew I wanted an Air; my experience with my XPS 13 has sold me on the virtues of SSD’s and frankly traditional spinning drives feel a bit antiquated to me know.

 

I also looked at the retina model for a few minutes. I can’t deny that it looks very pretty, but the web is not retina yet and the cost is a bit more than I want to spend; I have been going through a Mac laptop about one every eighteen months, so spending over two thousand dollars on a machine seemed foolish to me. Another point regarding resolution is that the Macbook Airs are all higher resolution than the machine that I was replacing and they look stunning.

 

If you can’t figure it out already, I bought an Air. I had thought that I needed to have the same amount of RAM as my pro, but, having done some research and having worked on my XPS a bit, I came to the understanding that an SSD really makes the most difference for the type of work I do on my Macs: iOS and Mac development.

 

For the stat minded, I got the 13” Air with 4GB of RAM and the 128GB SSD hard drive. Or in other words the base 13” model. How’s it going? So far so good.

 

Comments questions? Find me on Google+ or Twitter.

Effects of App Store Distribution pt1

Those of you who follow me here or on Coder Radio or on any of the social networks that I frequent will know that I have been running a little experiment with my new Mac Application Code Journal; for those of you who randomly got here via a search or something like that, the experiment was trying to sell a consumer target Mac OS X application outside of the Mac App Store. No need to go into too much detail, since if you want more info you can go check out episode ten of Coder Radio, but the experiment did yield a result and a lot of feedback. Basically, there is ample evidence to support the idea that, in general, apps that target OS X will do better on the App Store than via direct sales.

As with the mobile space, I believe that increased reliance on app stores will have some considerable effects on the business of app development, the developers, and the apps themselves. So I am writing this three part series to discuss those issues and am taking something of novel approach (novel to me at least): I am going to look at this issues by comparing two very different apps Mars Edit, and my own Code Journal. I picked Mars Edit as a point of comparison because it is established and is in a different space than Code Journal, so there isn’t any risk of bias. Additionally, in many ways Mars Edit can be seen to represent the traditional Mac application model while Code Journal more closely resembles the single purpose “app ideal”.

The eight hundred pound gorilla in the room is app pricing. In general it is becoming increasingly hard to sell an app for more than a few dollars; some would argue that even getting the few dollars at all is really hard. Of course, there are exceptions to this, but those tend to be from either large game companies (think EA, Activision, etc) or from established Mac developers. An example of the latter would Daniel Jalkut’s Mars Edit, an app that is currently selling for $39.99 on the Mac App Store. Mars Edit’s success is a great story but also very atypical of pricing for productivity apps in the store and a lot of that may be due to Jalkut’s and the app’s cache’ in the Mac developer / enthusiast community; again for those who don’t know Jalkut was a former Apple engineer and has been fairly active in the community. Additionally, Mars Edit was successful long before Jalkut took it over; he actually bought the app from another developer in 2007.  A quick survey of competing apps in the same space on the store showed that most of Mars Edit’s competitors tend to be in the ten to fifteen dollar range and seem to have poorer placement in the store, which suggests weaker sales. One notable exception is the $39.99 MacJournal; Yes, there are of course other applications on the store that charge more, such as OmniGroup’s OmniPlan, but  we are looking at its competitors here.

What does this all mean? Honestly, Apple is the only who has the data to be able to truly say if the store if pushing prices down across the board. There certainly seems to be a correlation in applications being priced lower and the rise of the app store model, but there is an alternative argument (with an alternative villain) that could be made: free web apps may be forcing prices of native apps down by training consumers that a large class of applications should be free, such as Google Docs. Again, Apple is really the only who can disprove or prove the first point for sure and the web app debate is something for another day.

Check back soon for a look at what the App Store seems to be doing to independent software developers.

If you have some feedback please find me on Google+ or Twitter. Also, if you like my posts or work on Coder Radio, please consider purchasing Code Journal either from the Mac App Store or direct.

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+.