The recent release of an application aptly titled Crackulous—which, as its name very subtly implies, can be used to automagically crack an iPhone an application purchased from the App Store so that it can be used for free on any jailbroken device—seems to have caused a number of developers to have a conniption fit.

In the process, many of these developers are rapidly falling in the same trap where the recording, software and movie industries have been stuck for the last many years: because they think of piracy as a loss, they get fixated on stopping it. And piracy can’t be stopped.

A race against pirate can only result in deepening financial losses and a PR nightmare:

• Implementing restrictive DRM measures only results in upsetting legitimate customers. If my honesty has to be rewarded with less freedom and ease of use than what someone who steals from you enjoys, then you deserve to die a horrible and painful death.
  
  
• Thinking that piracy can be stopped is simply delusional. The time you spend fixating on it—especially if you are a small developer—could be spent improving your application instead.
  
  
• DRM systems are, simply put, a bad idea and, while there are plenty of companies which will be more than happy to take your money in exchange for an anti-piracy system that will, sooner or later, be defeated, you really should be smarter than spending money on trying to solve an unsolvable problem.

If you are thinking right now that a DRM system is exactly what the App Store implements, do remember that Apple is in a unique position to implement and use one—especially with the App Store, they control the entire distribution channel, end-to-end. If you are a “normal” user, the entire system of DRM protection is entirely transparent to you from the moment you make a purchase to the moment the application runs on your device.

One could, of course, point out that Apple’s control of the iPhone distribution channel limits customer choice by filtering the applications and contents that they can take advantage of—but that’s a different story: assuming that what you want is available on the App Store, the process of acquring it and using it is as seamless as seamless can be. If you want to run apps other than what Apple lets through, you can jailbreak your phone—but jailbreaking does not equate piracy, because the act itself does not cause damage to anyone.

To play devil’s advocate, one could even point out that piracy is the people’s response to the lack of a try-before-you-buy feature in the App Store. We have a very technical term for describing that argument in the industry: bullshit. Every single person makes tens of blind decisions every day, and lives with their consequences: you don’t get to take a bite of an apple before buying it, or lick your sandwich before deciding whether you’ll want to buy lunch. It’s risk taking at the most basic level, and the money you pay is the opportunity cost of not enjoying the benefit of making a good decision.

Of course, you don’t buy a car, or a house, or even a computer, sight unseen. But the App Store doesn’t sell houses, cars or computers. It sells software, and the vast majority of that software is priced far below the double non-fat vanilla extra-foam latte enema you had for breakfast without a second thought about whether a shot coffee and half a cup of foamed milk are really worth $5.

Cost and Opportunity
Having established that piracy is theft that can’t be stopped and that DRM is a bad idea, I think that a smart developer should focus on the opportunity that piracy represents and the costs involved with pursuing it.

In the case of Crackulous, you only need to stop for a moment and think about who the archetypal user of that application is going to be in order to figure out that the cost is little, and the opportunity is tremendous.

The typical Crackulous user is what I think of as the “armchair pirate”—a person who doesn’t have the technical knowledge required to actually crack an application, but who happily does so “because he can.” Defeating this type of thief is easy: all you need is a simple copy-protection mechanism that you are sure will only activate when the application is cracked, and be otherwise entirely transparent to a regular user. Such a check requires barely a handful of lines, and there are plenty of examples on the web of how it can be easily accomplished.

The difference between relying on Apple’s DRM to be invulnerable and implementing your own simple copy-protection mechanism is a bit like the difference between fueling your car and changing the oil: anyone can do the former (well, almost anyone), but the latter, although simple enough that a monkey could probably be trained to do it, is well beyond the technical abilities that most people are capable of, or willing to acquire. Similarly, anyone can use Crackulous, but having to dig into the code to find your five lines of copy protection are probably beyond what 95% of the population can do.

Copy Protection is not DRM
Do note that I made a point of qualifying the copy-protection that I describe above as simple. Your goal is not to defeat piracy, given that a motivated and technically inclined individual will inevitably find a way to break whatever you throw his or her way, but to turn the tables on the armchair pirate and turn his intent on causing you a loss into an opportunity to generate more revenue. Realistically, the additional revenue that will be generated by would-be pirates will be small, so anything that requires more than minimal effort on your part is a waste of time and resources that could otherwise be spent on more productive ventures.

An easy way to create an opportunity for yourself is to implement a timebomb: if your app detects that it has been cracked, all you need to do is let it run for a period of time that lets the user gain an appreciation for the functionality that it provides, and then force him or her to either buy a copy from the App Store or quit. Remember: Apple has already done most of the legwork for you, so that this shouldn’t take more than a timer and the aforementioned handful of lines of code, plus a handoff to the App Store application on the phone.

Your copy-protection mechanism should also be unobtrusive. Not pissing off the people who are willing to pay from the outset for your application should be more important than stopping those who have already made the conscious decision that they’d rather keep their money and take your work, too.

Case in Point…
I gave piracy little thought when I wrote the first version of Camera Plus to the store—I really wasn’t expecting anything out of it—and, as a result, it was cracked and made available to jailbroken users almost immediately. Interestingly, I didn’t notice a dip in sale when that happened (in fact, sales went up, probably skewed by the app’s unexpected popularity).

When it came time to write CP2 from scratch, I spent exactly 15 minutes implementing a simple timebomb into it: after approximately 20 seconds of usage, if the app detects that it has been cracked, the user is politely asked to either buy it, or terminate the application. If 20 seconds sounds like a small amount of time, you need to keep in mind that the app is designed as a replacement for the Camera application—and, therefore, in 20 seconds a user should have just about enough time to take a picture and see how CP works.

I haven’t been able to find a cracked version of CP2 in the wild yet, but two things have happened: first, sales are up—to the point where royalties for CP are in the order of several thousand dollars for the month of February. Second, customer support requests have grown consistenly with revenues, indicating that, generally speaking, there don’t seem to be many more users than customers out there.

I have no doubt that, sooner or later, a pirate copy will show up—and someone with the requisite technical knowledge may even bother to defeat my copy protection mechanism. By then, however, I plan to be working on a new version with more functionality—a much better way to spend my time and money than trying to defeat the boogie man.

Unlike many other distribution channels, Apple has chosen the curious path of making the App Store something as close to a true meritocracy as possible—you don’t get exposure to potential customers because of who you are or because of the amounts of money you are willing to pay the distributor for optimal positioning. Your app either sells on its own merits, or it doesn’t.

That most people don’t seem to grasp what a tremendous opportunity this is truly baffles me. I have worked in environments where the distribution channel was tightly controlled with the sole intent of extracting as much money from the publishers—note, the publishers, not the customers—as possible, and still work in one, the magazine industry, where the distribution companies themselves are rapidly destroying their own businesses by avidly screwing publishers of all sizes in every possible way.

In the App Store, content is king, and the customer is kingsmaker. Apple has taken a relatively hands-off approach to what happens to software once it becomes available in the store, as is witnessed by the fact that the top-rated list contains a wide variety of applications in which mainstay publishers like EA or Konami sit alongside (and, in many case, are subordinate to) one-man operations that are making a killing selling their own products. If you feel like complaining about the way the App Store is run, I invite you to try and sell boxed software at retail—you’ll be buying your first AK-47 in less than a week.

The market for iPhone applications has taken on a very definite shape, but so many developers seem to completely ignore it:

• Patience, alongside attention span, is one virtue that your typical iPhone user doesn’t have. If a customer cannot understand the way an application works in less than thirty seconds, you’ll be destined for the wobble bin and a one-star rating.

• This, however, does not mean that applications cannot have depth—you simply need to ease the user into it in small steps, so that the learning curve is not too steep.
• Presentation is important—people choose iPhones for their eye-candy value, and they expect the same of the applications they buy. Note that this doesn’t mean that you need shiny icons all over the place—Blocked, currently in the #2 spot in the best-selling list, is anything but fancy and still offers a clean, functional and well-designed interface.
• Simplicity is paramount. For all the complaining that some developers like to do, I happen to believe that it’s not Apple that is driving the prices of applications down: it’s the customers. And the reason is simple: they don’t want to use their phones as all-purpose computing platforms. Thus, the key to a successful iPhone application is to come up with one idea, and pursue it to the best of your abilities.

Given that the first collection contained books written by one of my favourite authors, it seemed only fitting that, for the second one, I should pick from the opposite end of the spectrum.

Hence, the new app is called Charles Dickens — Masterpieces Collection. It contains five classic stories from the master of human misery and the drabber aspects of British life during the industrial revolution.

As with the other collections, I have a handful of free coupons on hand. DM me on Twitter if you want one (but first, take a look at the instructions on this post to make sure you can use it).

My second iPhone App—Jules Verne Masterpieces Collection—is now available at the App Store. You can skip to the end to get your very own free download coupon if you don’t want to read my ramblings

For the past ten years, I have been trying to find a way to read books on a PDA without going blind or crazy—and I have a virtual cemetery of devices, all the way back to a Casio Cassiopeia from 1996, to show that I mean business. I have never quite been able to find either a device that had the capabilities of displaying the correct amount of information, or an application that capable of delivering a good reading experience.

When I finally got my hands on the JesusPhone, therefore, I expected that reading applications would abound, and that the combination of display capabilities and interface would have finally delivered what I wanted.

Alas, I have been much disappointed. Reading applications in the App Store can be roughly divided in two groups: apps that try to make you believe they’re books, and apps that make you wish you could never read a book again. The former take full advantage of the iPhone’s hardware to deliver wall-to-wall eye candy, which to me sounds like a waste of perfectly good brainpower—if I want something that looks like a book and sounds like a book, I will buy a book, which also smells and feels like a book. The latter are simply unusable—if I want to use browser technology to read a book, I’ll use my damn browser, thanks.

All this ranting led me to write the Masterpieces app. I tried to drink my own coolaid and focused on a few features that I thought were imporant:

My goal was to create a reading experience, not duplicate a book. Therefore, my first step was to create an interface that takes full advantage of the iPhone’s capabilities and is designed for the kind of use that iPhones get.

First of all, I figured that most people use iPhones in situations that requires one to frequently put their devices away and shift their attention to other things—think airports, bus stops, trains, etc. In these scenarios you want the app to not only keep a bookmark for you, but also automatically take you back to the last page of the last book you were reading when you launch it. Taking the user back to the list of books is a bit like going to bed at night with your book on the nightstand only to wake up and discover that someone has moved it back to the bookshelf during the night—it gets annoying pretty fast.

Additionally, I wanted the interface to be as snappy as possible. Again, if you have to continuously start and close the app, you want to spend your time reading and not waiting. Everything in Masterpieces is designed to keep the fluff to a minimum and get you right into reading the next page: there are no gorgeous animations to watch, no sounds to play, no pretty graphics to load. I was aiming for an interface that is elegant, but not intrusive.

I’m going out on a limb, here, but I’m guessing that the fact that a person may like, say, Jules Verne doesn’t necessarily mean that he or she also likes Jane Austen or Charles Dickens. Call me crazy, but collections of random books are silly in an electronic medium, where you should be able to have better choice.

That’s why I designed Masterpieces to be a collection of collections—Jules Verne is only the first one because I happen to really love his books, and I wanted to challenge myself to use the application before unleashing it on others. I have more collections in the works.

Typography is very difficult to get right under the best of circumstances, and a 3.5″ screen doesn’t make things easier. Here apps usually go on two tangents: they either use the built-in fonts, which have very poor typography compared, say, to regular OS X rendering (no ligatures, no antialiasing, and so forth), or go for super-antialiased traditional type, which looks great on paper, but not so great on the screen.

Coming up with a proper rendering engine for the type was, by far, the single most difficult and time-consuming part of writing Masterpieces. I literally went through dozens of font combinations and rendering techniques—again, looking for the best possible rendering results.

I ended up settling on a slab serif font rendered with minimum antialiasing. This is interesting, because slab serif fonts are normally used for children’s books due to them being nicely rounded and easy to read, but shunned for adult literature because they look too “simple.” To me, their relative lack of sharp corners and tight angles is perfect for readability on a handheld device.

Finally, I went crazy trying to find the right amount of contrast between type and background. Too much, and your eyes get tired from the apparent brightness of the display; too little, and you get tired because you have to squint too much to tell the type apart.

As a litmus test, I went for what I’d consider a “comfortable” reading posture: arms length without glasses (something that I, for example, can’t do with a regular paperback). I figured most people would likely read either in bed or on the seat of some sort of vehicle, and having to keep your hand up too close to your eyes would tire your arm.

The most difficult decision was—how many books? Originally, I wanted to simply write a book reader app, and let people download books from the Net. I decided against this because, in my opinion, it detracts from the experience of buying a book on the go and being able to read it right away.

As for the right number of books, I made the decision that I’d try to fit as many relevant books as I could while keeping the overall app size to below 10MiB. The reason for this is that you have to be on a WiFi connection in order to download an app that is larger than that size, and that won’t work too well if you’re trying to buy a Masterpieces collection on the go.

With a new app release come some more of those juicy coupons that let you download it for free, so I’m giving some of them away. I only have a handful, and they usually go fast, so drop me a message on Twitter if you want one. Just remember:

• These coupons are valid only for the US store (yeah, even I can’t use them—but that’s just the way Apple does it)
• I will DM you the coupon if I have one left, and you need to be following me in order to receive my DM. This is not a cheap ploy to get more followers—it’s the way Twitter works; you can unfollow me right after if you like. I won’t get offended, I promise.

Since using these coupons is not all that obvious, here are some steps to help you out:

1. Open iTunes
2. Go to the iTunes Store’s main page
3. Click on “redeem”
4. Enter your coupon code
5. Follow the instructions from there on
6. You will need to sync your iPhone in order to install the application (obviously)

On the other hand, February is usually when the many fun and interesting activities that surround our spring conference php|tek start taking place—and this year is no exception. In fact, this year that are more people working—hellbent might be a better word, given their enthusiasm—on making |tek a memorable occasion for PHP developers from all over the world to meet up, learn and network. Here are some highlights:

• Andrei Zmievski—who is now Open Source Fellow at Digg—will be our featured keynote speaker; as you probably know, Andrei has recently started steering the development of PHP 6 again—it will be interesting to hear him talk about his vision for the next release of the platform and figure out how we can all facilitate the inevitable porting of our software packages to it. I am also proud that, for the first time in the six or seven years that I’ve known Andrei I have, apparently, managed not to misspell his last name in any of our PR materials. Of course, I misspelled everything else, but, hey, you can’t win them all.

• My colleague Keith Casey is pulling double duty, organizing both a series of free webcasts and an unconference-within-the-conference at php|tek. Adobe is going to be our main sponsor for the webcasts (although the signage is not up yet), and we’re very grateful for their help.
• Speaking of colleagues, Matthew Turland, consultant extraordinaire at Blue Parabola, is also putting together a Hackathon to take place one of the evenings during the conference. This will be a great opportunity to contribute to one of a number of open-source projects (including PHP itself) while picking up a new trick or two from fellow developers.

It’s been a month since I announced the availability of Camera Plus, my first iPhone OS application, in the App Store. I figured it’s as good an opportunity as any to give a short update, and to talk about a few things that I have picked up in the course of being an iPhone developer for a month.

First of all, do keep in mind that I develop iPhone apps in my spare time—and that I don’t have that much of it to begin with. Therefore, my impressions here are necessarily skewed by my particular perspective; someone who writes apps for a living will probably see things differently.

The results are in…
In the short 30 or so days that it has been in the App Store, Camera Plus has done fairly well—as of today, it was the #9 application in the photography section of the store, which translates in a reasonably good number of sales.

Although I won’t provide any numbers, I can tell you that, while I won’t get rich from CP, I have most definitely recouped my development costs at a very generous hourly fee (even by my standards, which are, probably higher than the average). Plus, of course, I don’t expect the application to die right away, which will hopefully set me up for an even higher profit.

I’ve also received a lot of feedback—mostly positive, but some negative, which I have tried to deal with in the best possible way: respond to reasonable requests that I can satisfy without compromising the application, and ignoring those few idiots who can’t be bothered to read the description of an application, let alone try to use it properly.

Lessons learned
Despite my short life as a part-time iPhone OS developer, I have picked up a number of important lessons, which have helped guide me through the process of maintaining my application, and creating the next one (currently awaiting approval—or rejection, who knows).

Here they are, in no particular order:

1. Understand your market
I was an iPod and iPhone user long before I decided to become a developer. It’s not so much that my lack of Objective-C knowledge was holding me back (although there was a certain amount of inertia caused by the idea of having to learn yet another language)—I really wanted to understand how iPhone development worked from a strategic perspective.

It is now clear to me that there are four types of iPhone apps: Great Apps, Stupid Apps, Half-assed Apps and Apps that Belong Somewhere Else.

• Great Apps all share one commong characteristic: they know what they want to do, and they do it really well. All these applications perform one primary function, and every other decision—including pricing—revolves around facilitating the One Primary Directive. These applications closely follow the UNIX philosophy (although they are handicapped by the lack of a true equivalent to pipes)—and they are very popular as a result.

• Stupid Apps, charitably referred to as novelty apps, are applications that serve no particular purpose and amuse because they are crass. These apps are popular, but, in my opinion, it’s difficult to write a good Stupid App—that’s because (a) the stupidity of these applications is often superficial, and they are in fact rather complex, and (b) the novelty wears off at the first copycat, meaning that you only really make money if you’re the first out to cover a specific idea.
• Half-assed Apps are the true crapware of the App Store. They do one thing, if they do it, and they do it poorly. As far as I’m concerned, this is the worst kind of app, because it brings nothing useful to the table. On the plus side, these applications can be a great source of opportunities for someone who wants to improve on them and knows how to.
• Apps That Belong Somewhere Else are applications that try to do too many things. There are a number of problem with this approach, but, primarily, they boil down to (a) trying to use the iPhone as a general-purpose computing platform, which it isn’t, and (b) investing too much in one product, which results in it being priced outside the boundaries of what most people are willing to pay.

2. Focus, focus, focus
When I started writing CP, I had much grander plans for it, and kept bouncing against limitations in the iPhone platform. It took me quite a while to understand that I was trying to write a Great App—and that requires an enormous effort to focus on one particular goal.

Deciding what you want your application to do should be the first thing you do. Once you find that one problem that you want to solve, every other decision will stem from it—including how much you will want people to pay for your product.

3. Spread your risk
I have heard of people investing tens of thousands of dollars to being an iPhone application to market. In my opinion, that’s stupid.

The reaction of the iPhone market to an application is very difficult to gauge. Apple makes sure that that’s the case—you can’t release betas, you can’t release the application as trialware or shareware (yes, I know, you can release a “free” edition, but that’s not the same—in order for that strategy to work, you must have already invested time and money in building the application anyway), and it’s really difficult to create a testing environment without guiding your testers through a ten-step setup process.

Therefore, a better business approach to app development is to create an application, release it as soon as possible, and then continue to update it if the market warrants it. If your app is a dud, it’s time to cut your losses and move on. If it’s not a dud, you will have ample opportunity to improve it and expand it organically—with the added benefit of doing so in response to customer input.

4. Release early, update often
I have now updated CP 3 times since its original launch—each time with a small incremental addition (as well as any bug fixes that came along with it), and my customers love it!

This approach goes hand-in-hand with the point I made in the previous section—an application that is updated often will be perceived as a better investment by your customers. At the same time, updating your application gives you an opportunity to get in front of more and more customers, as your app gets bumped to the top of the new releases list every time you push an update out.

5. Never, ever give out a paid app for free
I’ve seen some folks give out their application for free for a limited time as a way of boosting up their ratings and reviews. Invariably, this approach fails miserably, because, as someone put it, the threshold between free and $0.01 is insormountable for many people.

When you give out your application for free, your “customers” have no vested interest in it. They will try it, and most likely toss it away without a second thought. After all, it cost them nothing—why should it be worth anything to them?

This, incidentally, is the same reason why I think that the absence of a “try-before-you-buy” feature from the App Store is a good thing. As a matter of personal experience, people put no effort in seriously evaluating something until they have invested in it.

6. Never, ever sell your app for $0.99
A base price of $.99 is a bad idea for a number of reasons. First of all, you can’t back out of it—the only way to go is up. This means that you will never be able to boost your sales by running a promotion (and, in case you’re wondering, the value of a promotion is not in the reduced price, but in the reduction in price).

Second, if you can’t run a sale, you will miss out on a lot of potential sales because so many people access the App Store precisely with the idea of getting a bargain on an application that others had to pay full price for—that’s why apps like App Sniper are so popular.

7. Hope for the best, prepare for the worst
There is but one number one spot in the App Store and, frankly, your (or my) chances of getting there are pretty slim. If it happens, that’s great, but I’m fairly sure that there is no way, currently, to reliably predict whether an application will be a hit or not, which, in turn, means that you shouldn’t bank on it.

That’s why you should consider spreading out your risk. Instead of spending 100 hours building an app that will only make you money if it reaches #1, build five applications that require twenty hours each, then refine and improve the ones that generate the most revenue. I’d rather have 10 applications that make $100 a day each than one application that makes $1,000 a day.

8. The App Store is a marketing medium
Ignore the pundits: the App Store is much more than a distribution medium. If it were only a way to get applications to your clients and collect money from them, the 30% commission that Apple keeps would be highway robbery.

Ignoring the App Store as a marketing and sales medium is a big mistake—I have hardly made any investment in marketing (I don’t do this for a living, remember?)—but I have paid considerable attention to the way my app is presented on the store. I have been running sales, paying attention to customer feedback, and worked hard to make sure that my screenshots actually look like they were taken on an iPhone (as opposed to a competitor whose pictures were clearly doctored). It’s paid off. It’s worth it. It could be your best shot at making your product popular—take advantage of it.

9. Don’t get mad at Apple
The internal developer forums are overrun with people who complain about how unfair Apple is; how it’s out to screw them; how they had to wait forever for their application to be approved; and so on, and so forth.

That’s wasted breath. As far as I’m concerned, Apple has been pretty forthcoming in terms of what they will and won’t let in the App Store. While I’m sure that there have been isolated incidents of people who have been treated unfairly, as long as you steer clear of the touchy areas you won’t have any problem getting your application in the App Store. How do I know? Simple: there are 55,000 apps in there, and they didn’t get approved by giving Steve a free manicure. My first app took just over two weeks from submission to approval (because of the holidays), while CP took six days.

Moreover, as I mentioned in my previous post, the folks from Apple have generally been pretty good about returning my e-mails. Maybe I just got lucky—or maybe I just asked pertinent questions in a polite way. Who knows?

Thanks to the update, I now have 5 more coupons for a free copy of CP to give away. DM me on Twitter if you want one—and remember, these work only in the US store!