Siri and third-party apps: Part II

[ In a previous post we looked at some of the capabilities of Siri, Apple’s intelligent personal assistant. Now let’s venture a little deeper into how integration with third-party services might work.

I have to point something out that should be obvious: I have no inside knowledge of Apple’s product plans. This note is purely based on the publicly demonstrated features of Siri sprinkled with a dose of speculation.

Although I had hoped Apple would offer deeper Siri integration with apps in iOS6, what they ended up showing during the WWDC 2012 keynote presentation was far more incremental: new back-end data services (sports scores, movie reviews, and local search) and the ability to launch apps by name. ]

Apple Siri(Image via Apple)

In the previous section we ended by noting which services Siri currently integrates with and how. But how might third-parties, at some point, integrate into Siri as first-class participants?

Before we step into the deep end we should distinguish between several categories of services that Siri currently supports:

  • On device with a public API (i.e. calendar, alarms, location-based services).
  • On device without a public API (notes, reminders).
  • Those that require access to server-side features (Yelp, WolframAlpha, sports scores).


The Server-side

For any service to tie-in with Siri there are two ways to do the integration tango:

  1. Comply with an interface that Siri expects (for example, a set of RESTful actions and returned JSON data).
  2. Offer a proxy service or glue handlers to bridge the gap between what Siri expects and what the service/app offers.

This means Apple would have to publish a set of web APIs and data protocols and validate that third parties have implemented them correctly. What’s more the third parties may have to provide a guarantee of service since to the end-user any service failure would likely be blamed on Siri (at least, until it starts quoting Bart Simpson).

But Siri is a little different. Just following an interface specification may not be enough. It needs to categorize requests into sub-domains so it can narrowly focus its analytic engine and quickly return a relevant response. To do so it first needs to be told of a sub-domain’s existence. This means maintaining some sort of registry for such sub-domains.

For Siri to be able to answer questions having to do with say, real estate, an app or web-service needs to tell Siri that henceforth any real-estate related questions should be sent its way. Furthermore, it needs to provide a way to disambiguate between similar sounding requests, say, something in one’s calendar vs. a movie show time. So Siri will have to crack open its magic bottle a little and show developers how they can plug themselves into its categorization engine.

In the Android world we see a precedence for this where applications can register themselves as Intents (for example, able to share pictures). At runtime an Android app can request that an activity be located that can handle a specific task. The system brings up a list of registered candidates and asks the user to pick one then hands over a context to the chosen app:

Android intentsThis registry is fairly static and limited to what’s currently installed on the device. There has been an effort to define Web Intents but that’s more of a browser feature than a dynamic, network-aware version of Intents.

It should be noted that Google Now under the latest JellyBean version of Android has opted for a different, more Siri-like approach: queries are sent to server and are limited to a pre-defined set of services. We may have to wait for Android Key Lime Pie or Lemon Chiffon Cake (or something) before individual apps are allowed to integrate with Google Now.

Context is King

Siri has proven adept at remembering necessary contextual data. Tell it to send a message to your ‘wife’ and it will ask you who your wife is. Once you select an entry in your addressbook it remembers that relationship and can henceforth handle a task with the word ‘wife’ in it without a hitch.

What this means, however, is that if a similar user-friendly tack is taken, the first app to plant its flag in a specific domain will likely be selected as the ‘default’ choice for that domain and reap the benefits till the end of time. It will be interesting to see if Apple will allow for applications to openly declare domains of their own or create a sort of fixed taxonomy (for example, SIC codes) within which apps must identify themselves. It’ll also be interesting to see if the appstore review process will vet apps for category ‘poaching’ or even classic cybersquatting.

It’s likely such a categorization will be implemented as application meta-data. In the case of web-services it will likely appear as HTML metadata, or a fixed-name plist file that Siri will look for. On the client side it’ll likely show up the same way Apple requires apps to declare entitlements today — in the application plist.

So for a web server to become Siri compiliant, it’s likely it will need to:

  1. Respond to a pre-defined Siri web interface and data exchange format.
  2. Provide metadata to help Siri categorize the service into specific subdomains, and
  3. Optionally: offer some sort of Quality of Service guarantee by showing that they can handle the potential load.

Currently Siri is integrated with a few back-end services hand-picked by Apple and baked into iOS. To truly open up third-party access iOS would have to allow these services to be registered dynamically, perhaps even registered and made available through the app store as operating system extensions. This could potentially give rise to for-pay Siri add-ons tied into subscription services. 

’nuff said. Let’s move on to…

The Client Side

What if you have an app that lets you compose and send custom postcards, or order coffee online, or look up obscure sports scores? How could apps like this be driven and queried by Siri?

To see an example of this let’s look at how Siri integrates with the weather app. When we ask it a weather related question (“How hot will it be tomorrow around here?”):

Siri example - How hot will it be tomorrow around here

To answer this question it has to go through a number of steps:

  1. Translate the voice query to text.
  2. Categorize the query as weather related (“hot”).
  3. Find our current location via location services (“around here”).
  4. Determine when “tomorrow” might be, given the user’s current locale.
  5. Relay a search to the weather server for data for the particular date and location. It understood ‘how hot’ as looking for the ‘high’ temperature.
  6. Present the data in a custom card to the user. Note that it responded with both a text response as well as a visual one — with ‘tomorrow’ highlighted in the results.

Weather is one of those services where the search can be performed directly from Siri’s back-end service or initiated on the device — either through the existing stock weather app or a code framework with a private API.

Imagine where your app might fit in if the user were to make a similar voice inquiry intended for it.

  1. Siri might need to be given hints to perform speaker-independent voice-to-text analysis. It appears that at least part of this conversion is done on the server (turn networking off and Siri stops working) so wherever the actual text conversion code resides will need to have access to these hints (or voice templates).
  2. To categorize the text of the request as belonging to your subdomain Siri would need to know about that subdomain and its association to your app.
  3. Location would be obtained via on-device location services.
  4. Time would be obtained via on-device time and locale settings.
  5. The request would have to be relayed to your app and/or back-end service, in some sort of normalized query form and expect to get the data back in a similar form.
  6. The result could be presented to the user either via spoken text or shown on a graphic card. If it is to be presented as text there has to be enough context so Siri can answer follow-up questions (“How hot will it be tomorrow?” “How about the following week?”). If it is to be shown in a visual card format then the result has to be converted into a UIView either by Siri or your code.

For steps #1, #2, and #5, and #6 to work, Siri has to have a deep understanding of your app’s capabilities and tight integration with its inner workings. It also needs to be able to perform voice to text conversion, categorize the domain, and determine if it’s best handled by your app before actually launching your app. What’s more it would need to to send the request to your app without invoking your user-interface!

In other words for Siri to work with third party apps, apps would have to provide a sort of functional map or dictionary of services and to provide a way for Siri to interact with them in a headless fashion.

Sound familiar?

It’s called AppleScript and it’s been an integral part of Mac desktop apps since the early 1990’s and System 7.

AppleScript editor

For desktop apps to be scriptable they have to publish a dictionary of actions they can perform in a separate resource that the operating system recognizes without having to invoke the actual app. The dictionary lists the set of classes, actions, and attributes accessible via scripting. 

For Siri to access the internals of an app a similar technique could be used. However, there would have to be additional data provided by the app to help Siri better match the natural language needs in the user’s language.

The dictionary would have to exist outside the app so the OS could match the user query to an app’s capabilities quickly without having to launch the app beforehand. It would likely be ingested by the OS whenever a new app is installed on the device just as the application plist is handled today. Siri in iOS6 will have the ability to launch an app by name. It is likely it obtained the app name via the existing launch services registry on the device.

But a dictionary alone is not enough. Siri would need to interact with an app at a granular level. iOS and Objective-C already provide a mechanism to allow a class to implement a declared interface. It’s called a protocol and iOS is packed full of them. For an app to become Siri compliant it would have to not only publish its dictionary but also expose classes that implement a pre-defined protocol so its individual services can be accessed by Siri. 

The implication of making apps scriptable will be profound for the developer community. To be clear I don’t think the scripting mechanism will be AppleScript as it exists today. The driver of this integration mechanism will be Siri so any type of automation will have to allow apps to function as first-class citizens in the Siri playground. This means natural language support, intelligent categorization, and contextual data — capabilities beyond what regular AppleScript can provide. But given Apple’s extensive experience with scripting there is a well-trodden path for them to follow.

Once an app can be driven by Siri there’s no reason why it couldn’t be also driven by an actual automated script or a tool like Automator. This would allow power-users to create complex workflows that cross multiple apps as they can do today under Mac OS. If these workflows themselves could be drivable by Siri then a raft of mundane, repetitive tasks could be managed easily via Siri’s voice-driven interface.

Let’s also consider that if apps are made scriptable it may be possible for them to invoke each other via a common interface. This sort of side-access and sharing between apps is currently available on the Mac but is sorely lacking in iOS. If allowed, it would open up a whole world of new possibilities.

During a conversation over beers with a fellow developer it was pointed out that Apple has no incentive to open up Siri to third-parties. Given the competitive comparisons drawn between Google Now and Siri I’m hopeful Apple will move more quickly now.

When will Apple open Siri to third-party apps

See… it shouldn’t be long :-)

Siri and third-party apps – Part I

Siri on iPhone 4SApple’s Siri personal assistant was one of the main advertised features of the iPhone 4S. It is a marriage of speaker-indepent voice-recognition technology and domain-aware AI. What sets it apart is how it’s integrated with back-end and on-device services and how it maintains context across multiple requests so it feels like you’re having a conversation with an intelligent assistant instead of barking orders at a robot minion.

Once you get past the immediate thrill of having your phone understand your commands, talk back, and crack jokes, you quickly realize how much more powerful this all could be if Siri could do more than the relatively limited range of tasks it can currently perform.

That is, until you discover that Siri is a walled garden.

The entire iOS platform is predicated on the premise that third parties can add new features to the stock system provided by Apple. But here we have a seemingly closed system in which third-parties can not participate. As usual, Apple is mumm about whether a Siri SDK will ever be released.

But the question of how third-party apps could participate in Siri has been nagging at me since I first got my hands on an iPhone 4S and started playing with it. As I thought about it more I realized that for a third-party app to play in the Siri playground, there would have to be some profound changes in the way we develop iOS apps.

To first realize the scope of what Siri could do we should walk through a few use-cases of its current capabilities.

Let’s take the case of creating an appointment. We invoke Siri by holding down the home button which brings up a standard modal interface and turns on the microphone. We speak the words “make lunch appointment with John tomorrow at noon.” Siri goes into processing mode, then generates a voice-synthesized message asking which “John” you would like to schedule a meeting with. The list of possible particpants has been garnered from the addressbook. You respond by saying, say, “John Smith”. Siri then displays a mini-calendar (which closely resembles a line entry in the standard calendar), makes note of any other conflicts, then asks for you to confirm. You respond ‘yes’ and the event has been entered into your calendar (and distributed out via iCloud or Exchange).

Let’s break down what Siri just did:

  1. It put up a system-modal dialog.
  2. It captured some audio for processing.
  3. It processed the audio and converted it to text (often without previous training to adapt to a specific person’s voice).
  4. It managed to elicit enough context form the text to determine the request had to do with a calendar action.
  5. It extracted the name of an individual out of the text and matched it against the addressbook.
  6. It determined that the request was not specific enough and responded with a request for clarification. This request contained more data (list of other Johns) based on a search of the addressbook.
  7. It converted the request to a synthesized voice.
  8. The response was again recorded and processed for text recognition. It should be noted that one of the marvels of Siri is by going through a dialog, where each individual response is considered in the context of previous requests. When Siri offers a list of Johns, your response is ‘John Smith.’ Taken out of context, it would not make any sense, but Siri maintained context from a previous request and handled the response properly.
  9. Once confirmed, the event was scheduled with the calendar service.
  10. The system modal dialog can now be dismissed.

First, let’s consider whether Siri does voice-to-text recognition on the device itself or uses server resources. This is easy to verify. Put the phone into airplane mode and Siri can no longer operate so it’s likely it uses the server to do some (or all) of its recognition.

But how did Siri recognize that this was a calendar-related request (vs. a navigation one). It appears that once the voice data has been converted to text form, that the system categorizes the request into domains. By categorizing into well-defined domains the range of actions can be quickly narrowed. Having support for a sufficiently rich set of primitives within each domain creates the illusion of freedom to ask for anything. But of course, there are limits. Use an unusual word or phrase and it soon becomes obvious the vocabulary range has boundaries.

Once the action has been determined (e.g. schedule event) a particular set of slots need to be filled (who, when, where, etc.) and for each slot Siri apparently maintains a context and engages in a dialog until a minimum viable data set has been properly obtained. For example, if we ask it to ‘make an appointement with John Smith’ Siri will ask ‘OK… when’s the appointment?’ and if we say ‘tomorrow’ it will come back and ask ‘What time is your appointment?’ Once you’ve narrowed it down to ‘noon’ it can proceed to make the appointment with the calendar service.

By all appearances it maintains a set of questions that require an answer in order for it to accomplish a task and it iterates until those answers are obtained. Note that in this context a place was not required but if offered it is used to fill out the location field of a calendar entry. Some slots are required (who and when) but others are optional (where). It should also be noted that in its current state, Siri can easily be confused if given superfluous data:

Make lunch appointment with John Smith at noon tomorrow in San Francisco wearing a purple suit.

The actual event is recognized as Purple suite with John Smith with the location marked as San Francisco wearing.

Once all the required slots have been filled the actual act of creating a calendar entry is pretty straightforward since iOS offers an internal API for accessing the calendar database.

But Siri is not limited to just calendar events. As of first release the list of services available via Siri include:

  • Phone
  • iPod/Music
  • Messages
  • Calendar
  • Reminders
  • Maps and Directions
  • Email
  • Weather
  • Stocks
  • Clock, Alarm, and Timer
  • Address Book
  • Find My Friends
  • Notes
  • Web Search
  • Search via WolframAlpha
  • Nearby services and reviews via Yelp

Several of these services (e.g. weather, stocks, Find My Friends, notes, and WolframAlpha) do not advertise a publicly accessible API. This means that for Siri to work with them, the service had to be modified so it could have an integration point with Siri.

It is the nature of this integration point which would be of interest to software developers and in the next post we’ll explore it a little more to see how Apple might integrate with third-parties if it chose to open up Siri to other apps.


Simple Solution to iPhone 4 Antenna Problem





I’m not an antenna engineer but it seems like the simplest solution would be to move the ‘gap’ between the two antennae where it’s unlikely to be covered through casual touch. This would work for both left and right-handed users.

From a hand-placement point-of-view the ideal spot would be in the middle of the cable connector but that could introduce structural issues with the plug.

A Visitor’s Guide to WWDC and San Francisco


It’s time, once again, for the annual love-fest that is WWDC and that starts next week. I’ve been to each one since the iPhone launch (I know, that makes me a relative newbie) but having spent a good chunk of the past two decades living in San Francisco, I figured I’d combine tech-tips for first-time attendees with social things to do for out-of-towners.

Tech Tips

  • You can register and get your badge on Sunday, the day before WWDC starts. That saves you a bit of time doing it on Monday when everyone stands in line to get into the keynote speech. If you do go in on Sunday then you may want to pop into sfMacIndie at Jillian’s in the Metreon at 6pm. It’s across the street from Moscone West. Grab a drink and chat up fellow developers. You may want to pace yourself. The next day is the big event and you want to be able to get there early — at least by 8am if not sooner. They don’t start letting you in until 9:30am so wear comfy shoes. Make sure to say hi to fellow line-standers as you hop from foot-to-foot trying to stay warm.
  • This is San Francisco. In June. This means chances of early morning sun are slim to none. Standing in line for the keynote means no moving for hours in the cold, blowing fog. Unless you’re seriously thick-skinned (like the poor, freezing iPorn girls of last year) bring layers and be prepared to discard them as the day wears on and temperatures rise.
  • The on-screen keyboard on the iPad is nice, but don’t forget your laptop. You will want to take notes. Lots of notes. And fast. As Marco Arment says WWDC is one giant info-dump and there is no way to absorb everything. You’ll need a real keyboard to keep up. I like to create separate folders for each session and save note files in TextMate. Under each folder you can also save sample code for the sessions. Then I throw the whole top-level folder into TextMate as a project so I can quickly search and find what I’m looking for. I suggest you try to capture as much as you can while there and take time later to go over things. They were pretty quick about posting up the videos of each session last year, but there’s no replacement for one’s own notes.
  • Head down to the lunch area on the ground floor around noon. The food’s nothing to write home about (yeah, I’m being polite) but it’s a good chance to meet people and find out common interests. Most of the other times you’ll be standing in line or in-session. This is your chance to have a decent conversation and who knows, learn a thing or two from fellow developers. I’ve always enjoyed these random encounters.
  • If you have questions or want to get feedback from Apple engineers and designers, sign up for the labs and do it early. Spaces fill up fast, especially for the UI Design reviews. Drift down to the cafeteria area on the ground floor and find out what the sign-up protocol is. On the rare occasion there isn’t an interesting session, hover around the lab areas. You’ll pick up great info just by listening to Apple folks explain how things work.
  • Try to bring a Verizon or Sprint MiFi. The Apple-supplied WiFi network is OK, but most of the time it gets overloaded. Forget AT&T’s 3G network. It’s a joke. With most people carrying a MacBook, an iPhone, and an iPad, your best bet is to bring your own network. The downside to this is you probably won’t be able to access the WWDC attendee-only content accessible to those on the network there. But once you’ve snagged all the goodies you can switch back to your own network and zip along. [Update: OK, maybe not such a good idea if everyone turns them on at once.]
  • If you bring your own network, make sure you set a secure password for access to the wireless hub. And for crying out loud, don’t make it the 40-bit WEP. Go for the WPA2. Way too many people running Wireshark or Kismet out there. Also, while you’re at home set up all your network devices to log in, then set the hub to not broadcast its SSID. That way all those other people around you won’t have to scroll through a gajillion wireless hotspot names.
  • Bring a comfortable backpack. The one they’ve been handing out to WWDC attendees the last few years is pretty minimalistic. If you need space for all your gear (and an extra sweater) then bring your own. Don’t worry about food, unless you need to snack often. They provide bagels and cookies and whatnot to keep you fueled up.
  • Sync up your dev iPhone or iPad at home and back everything up. There’s a good chance there will be a new SDK drop there with a bunch of new goodies. Recommend you not try to download over the WiFi. Walk over to one of the round tables outside the session rooms and plug into the Ethernet firehose. Much, much faster.
  • Please, oh please remember to turn down the volume on your phone/iPad/Mac during sessions. Yes, you know you’re on Twitter and now we do too. You can thank chirping bird man for that.
  • If your backside is sore from all the sitting down or you feel like taking a quick nap, there are bean-bags on the top floor. First come-first serve.
  • If you’re looking for a job or have a job to post there are white-boards in the bean-bag lounge area.
  • Stash a power-strip in your pack — it’s a good way to make friends.  Among tech conferences WWDC is one of the better ones for providing power to attendees. Even so, they sometimes run out of plugs. I’m partial to the Monster Outlets to Go units. They’re small and you can charge up most of your devices in one sitting. Some models even come with built-in USB charging ports. While you’re at it remember to bring separate power-to-USB adapters for your iPhone and iPad. The iPhone is happy with the small 5W units but the iPad needs the beefier 10W adapters. If space is a premium you may want to grab a couple of retractable USB cables too.
  • If you’re missing anything or forget to bring any hardware, your two nearby geek supply outlets are the Apple Store on Stockton Street and Central Computer on Folsom at 4th.

OK, so much for the conference itself. What about the social life?

Organized Events

Here’s a good reference for organized after-session gatherings: On Tuesday between 7:30 and 10:30 pm, however, a lot of people will likely head over to the Apple Design Awards ceremony. A large number will stick around for the Stump the Chumps Experts session. On Thursday night Apple throws a bash in Yerba Buena Gardens. You’ll need your WWDC badge to get in. If you’re of drinking age you’ll need to get a wrist-band at Moscone before heading over. Pace yourself on the booze if you plan on hitting any other places afterward. You get all the food and beer you can consume plus a (surprise) live musical act. And there’s still Friday’s sessions left.

Quick Eats

If you get tired of eating pre-packaged sandwiches and are hankering for something slightly different, here are a few places within easy walking distance of Moscone. However, no guarantee they’ll get you in and out in time for the afternoon sessions:

  • Food court at Metreon – Walk across the street, grab yourself something and go sit outside in Yerba Buena Gardens to decompress. Absolutely glorious if it’s sunny.
  • Taqueria Cancun – Bit of a hike up on 6th and Market, but decent enough Mexican fare.
  • Out the Door – (sorry, Flash site) is by the same people who run the outstanding Slanted Door in the Ferry Building. This one’s in Westfield (Nordstrom) shopping center on Market and 5th.
  • Specialty’s – Great sandwiches. Best part is they have an iPhone-friendly ordering service. Closest one is on New Montgomery between Mission and Market.
  • The Sentinel – I haven’t eaten there yet, but people keep recommending it and it’s top of my list for lunch places to try. Fancy-looking sandwiches.


The swill they serve at WWDC may be fine for getting you over your previous night’s hangover, but you owe it to yourself to get some decent coffee while in town. Good places within walking distance:

  • Blue Bottle – Just go. Get the Latte if you’re in a hurry or the drip coffee if you have time. Don’t worry, it’ll make sense once you get there.
  • Peet’s – Closest one is on Mission between 3rd and New Montgomery. Strong coffee. Puts hair on your chest, whether you want it or not.
  • Chatz – Bit of a hike on 2nd Street between Howard and Folsom, but good place to go if your feet need some stretching.

Local Watering Holes

For some reason after a day of technical brain-melding a lot of people are extra-primed to kick back and partake of adult beverages. Go figure. If that’s what you’re looking to do, here’s a number of local hangouts where you are sure to bump into fellow WWDC attendees:

  • Jillian’s – It’s across the street, doubles as a sports bar, has a large selection of beers on tap, and has pool tables in the back.
  • Thirsty Bear Brewing – Upscale brewpub. Decent beers and Tapas-style dishes, only a block away.
  • Chieftain’s – Grungy Irish pub. First stop for a lot of die-hard old-timers before they inexplicably head all the way out to…
  • Tommy’s Mexican Restaurant – A favorite of Apple folks, but it’s all the way out in outer Richmond. With places like Tres Agaves or dive bars like City Bar in the Mission you’d think someone would try to find something more accessible. It’s far away, in the fog zone, and the place is usually mobbed but if you do decide to head out to Tommy’s try to snag a ride with someone else–preferably a teetotaler. There’s a chance you’ll end up slamming tequila shots and trust me, you won’t want to be driving, flagging down a rare cab, or being at the mercy of Muni late at night.
  • Harlot – Decent, but small. Odds are there will be a line to get in.
  • XYZ bar at W Hotel – Upscale drink spot. Excellent place to hang out if you’re on a corporate expense account or your app just cracked the Top 10.

A little further out — but still worth it

Want to pretend you’re a local? Some are a bit of a walk, but if you get in with a group of fellow developers and want to get out of the Folsom/Howard zone, here are a few places to try (in no particular order):

  • Johnny Foley’s – Irish Pub within walking distance. It can get a bit touristy, but there’s nightly live music and (natch) Guinness on tap.
  • Zeitgeist – Sort of a cross-road of cultures and styles. No other way to describe it.
  • Orbit Room Cafe – Best damn Bloody Marys in town.
  • Hotel Utah – Grungy local spot, sometimes with good music.
  • Bottom of the Hill – Great place for local live indy bands. Out in Potrero Hill (accessible via the Muni T-line) but the music’s usually worth the trip.
  • AsiaSF – The waitresses double as transgender stage performers — and they’re awesome.
  • 21st Amendment Brewery – Big with the local tech types floating around 2nd street. Decent brews.

Obviously I’m leaving a lot out, but this should give you a decent starting point. Feel free to post any corrections or favorites in the comments. Hope to see you all at WWDC. If anyone wants to look me up and say hi, I’m @raminf on Twitter.


Update: Added a few more places — for those in a hurry to get back to hacking and getting their mind blown.


Eval iPhone apps: the good, the bad, and the ugly

[ This ended up being a fairly long and somewhat technical post. I edited it down as best I could, but I think it’s an important topic in the iPhone world and something that has to be laid out in its entirety. I suspect it won’t be of much interest unless you’re an iPhone app developer, a highly technical end-user, or a masochist masquerading as a layperson. You have been warned. – Ed.]

The news dropped like a bombshell on the iPhone developer community yesterday: Apple is now allowing In App Purchasing in free applications. Hip Hip Hooray!

But wait. What does that mean?

I won’t repeat what I’ve already said in a previous post but the upshot is it’s now possible to ship a free application on the iPhone appstore then ask the customer to purchase an ‘unlock’ token once they’re done evaluating it. The common consensus (as much as what is said on blogs, mailing lists, and twitter can be considered so) in the developer community is that it’s a positive move. Marco Arment (the developer of Instapaper) called it a “… great move for both users and developers.

The Good

With this seemingly small change in policy consumers can (finally) try out an app before they have to pay for it. No more buying an app then realizing it doesn’t work and getting stuck with a dud. The immediate effect will most likely be fewer impulse sales–which means lower short-term revenue–but in the long-term users are more likely to be happy customers instead of accidental ones.

It’ll also mean that app developers should be able to increase their asking price for well-made apps, because users will have had a chance to take it out for a test run. On the other hand, there’s no guarantee this will end up increasing per-app revenue given the low conversion ratio from free to for-pay apps. In fact, I’d strongly question the logic of $0.99 apps even bothering to offer an evaluation version. All those impulse and let’s try this purchases probably account for a more substantial portion of sales than most developers care to admit.

But the initial developer reaction seems to be positive. Most indy developers in it for the long run would rather have fewer happy customers vs. a lot of unhappy ones.

The Bad

First, let’s take a little detour and define what we actually mean by an evaluation app.

In the regular computer world (versus, you know, the iPhone Candyland) a developer creates an application then offers it to the user for evaluation in one of two possible ways:

  1. Degraded mode: this is where the application has some of its features disabled, for example, no saving or only printing with a watermark. The user gets to experience what the app does, but only up to a point. How much functionality is included is up to the developer but it’s in their interest to allow as much as possible to make the sale without giving up too much.
  2. Time-limited mode: this is where the application is fully functional for a limited amount of time (usually two weeks to 30 days). After that either the user buys the app or it stops working. A slight variation is where the app reverts to degraded mode when the eval clock runs out.

The main difference between a Time-Limited and a Degraded app is what the developer allows the user to experience during that period of time. That’s an important distinction because the end-user experience was noted by Apple as the main reason they initially didn’t allow In App Purchasing in free apps. The reasoning was that a user should not be told an application is free, then be forced to pay for it. But it appears that concerns for application piracy and loud complaints from developers have overridden those worries. But the problem is still valid. Hopefully Apple will make changes to the Appstore to better communicate the actual fully unlocked price to avoid end-user confusion.

There’s also a subtle issues unique to the Time-limited app on the desktop and that is what to do when the user tries to get around the evaluation restrictions — ostensibly to keep using the application in full evaluation mode ad infinitum without having to pay. The two most common methods are settings back the system clock (to make the app think the eval time hasn’t run out), or to uninstall then reinstall an app to reset the meter.

The solution to both of these problems is fairly simple: the app can write an already run token and periodically save a time-stamp in such a way that persists beyond an application getting uninstalled. Then it’s fairly easy to detect if the clock has moved back or if an app has been reinstalled.

But that’s the desktop. What about the iPhone? The problems are the same. Some users may be tempted to keep an eval app (especially a high-priced one) running. Can the clock reset trick work? Yes, it can. Most users leave their phone’s clock in its default auto-update mode so they can use their phone to keep track of time. But it’s fairly easy to reset it manually. All you have to do is run the Settings application, go under General tab and disable Set Automatically then set the clock to whatever date and time you want. The down-side to this is that so much of what you do on a typical iPhone relies on the system clock so it’s unlikely someone will be willing to put up with having a constantly skewed clock on their phone for the sake of just one application. But you never know.

What about the delete/reinstall method? On the iPhone, once an app has been deleted all associated files are also removed so there would have to be a way to save a persistent token that outlasts the app install-delete cycle. On the iPhone, unlike the Mac, no such place exists. The app developer could always save the unique device ID (UDID) of the phone on a server, but the Apple developer license explicitly forbids saving private user data off the phone. Does the UDID count as private data? It certainly is unique. We’ll have to see. But at the very least, it means each developer has to maintain server infrastructure to track this sort of thing.

So as it currently stands it’s too easy for a user to simply remove and reinstall an app or to fiddle with their clock and continue using an app in its fully-functional eval mode. I’m pretty sure this isn’t what Apple had in mind when allowing In App purchases.

That leaves Degraded mode. This means that the application the user would download from the Appstore for evaluation wouldn’t be the full version. In an earlier draft of the developer license agreement shipping this type of app was explicitly forbidden. In the newly revised version, well, it’s not so clear. In Attachment 2.4 it is clearly stated that:

2.4 You may not use the In App Purchase API to send any software updates to Your Application or otherwise add any additional executable code to Your Application. An In App Purchase item must either already exist in Your Application waiting to be unlocked, be streamed to Your Application after the purchase transaction has been completed, or be downloaded to Your Application solely as data after the purchase transaction has been completed.

This means that the full application functionality must be installed on the phone–no way to send up updated binaries. So all the code is there ready to go but a little key is needed to unlock it. On the desktop this type of app is derisively (and deservedly) called crippleware.

In other words, as of today, what Apple is allowing app developers to ship is crippleware for your iPhone. I could be wrong on this but this clearly falls under the category of Unintended Consequences.

The Ugly

The user plays with the eval app for 30 days (or so) then purchases the unlock token via In App Purchasing. The token is saved on the system so from now on the app launches in its unlocked state. But what form is that token going to take and where is it going to be stored? Given the current sandboxed architecture of the iPhone app, There are two places where an application can actually write data:

  1. The filesystem under the application’s Documents folder. This can be a text file, a user preference plist, a record in a SQLite database, or a CoreData store.
  2. In the keychain as a secure key/value data item.

Apple has intentionally stayed out of the business of what shape or form this add-on functionality or unlocking feature should take. It’s up to the individual developers to decide but odds are it will be one of these two methods.

Trouble is both these methods will actually make it easier for apps to get pirated.

On a regular iPhone no app can cross the sandbox line and access another app’s private data. But on a jailbroken phone no such lines exist. So a few minutes after the app is installed on a jailbroken phone, that special token can be easily extracted and plastered all over the internet. Now you don’t even need to resort to apps like Crackulous to get your free fully-functional apps.

The solution is for each individual app developer to implement tighter security around the application, by implementing secure unlock tokens, perhaps even tied to a specific handset so even if they’re removed from a single phone they won’t be usable on any other phone. But that involves knowing quite a bit about the pros and cons of cryptography and your typical iPhone app developer is not going to have the time and patience to implement anything like that.

So they’ll take the quick and expedient way–they’ll offer crippleware and save the token into a user preference plist or keychain — and hope and pray nobody bothers looking there. Or they’ll sign up with outfits like Urban Airship, iLime, or Push.IO to take care of it for them for a fee.

But this doesn’t mask the fact that with no Apple-defined standard, it’s going to be a free-for-all.

The final bit of ugliness heading our way has to do with user reviews. In the early days of the AppStore anyone could leave reviews — regardless of whether they had bought the app or not. This rendered the system useless since most of the initial write-ups consisted of, um, price-resistant customers (endearingly called freetards by developers) complaining about the price, no matter how low. It didn’t take long for Apple to clamp down on this by requiring only those who had actually purchased an app to review them. This substantially cut down on the noise and helped keep Appstore reviews an important part of the consumer decision-making process.

But now with the advent of free evaluation apps we’re going to go back to the halcyon days of price-gripes, where a user will download the free version of the app, take a look at the price for obtaining the unlock token and submit a 1-star review, complaining about, yes you got it, the price of the app. The current AppStore filter will not work since they’ve officially downloaded the app and technically count as having purchased the app.

One step forward. Two steps back. In other words, it’s going to get ugly. Again.


You’ve been so patient. I won’t keep you waiting. Here are a few steps Apple needs to take for this eval system to work:

  1. Offer a simple, official API for supporting both Time-limited and Degraded evaluations. This means associating some application metadata with each app when it’s installed and forcing Springboard (the iPhone application launcher) to honor these settings before running the application. Springboard already does this when it installs an app–that’s how the App Store application updated can tell what version you’re running vs. what’s on the store.

    To prevent the remove-reinstall workaround, there has to be a way to save some information that lives outside the sandbox and survives application removal. This can be on the phone or on a server. Again, Apple already does both these things. It saves data to the system keychain and it keeps track of what apps you’ve “bought” on the AppStore (so when you go reinstall, it knows not to charge you twice). So it would be easy for them to let the app-developer mark the application as eval, whether Time-limited (and or how long) or Degraded.

    I would even argue that anything having to do with application installation or unlocking belongs in the AppStore/OS domain, not left to individual applications. Anything having to do with In App purchasing of extra grenade-launchers, leave it up to the app.

  2. Far, far more importantly (and I can’t emphasize this enough) Apple should provide a simple API for an application to verify that the current user has purchased the app. This will do far more to cut down on application piracy than allowing free evals. The app developer can periodically and at random times invoke this API and ask two simple questions: Has the current user bought this app? and When?.

    A developer would be wise to sprinkle calls to the API throughout the app. Yes, the application binary can be patched and the API call removed, but that’s a higher wall for your typical cracker to climb than simply modifying a single entry in a text file.

  3. In the absence of a network connection, the default would be to let the application run a limited number of runs (until the user gets back to the network).

    But what about the When? question? The answer would be a timestamp indicating when the user paid for the app. That piece of information is important to app-developers who currently have multiple free/pay versions of applications on the appstore (or who want to continue using that model). For these folks to move from a free/pro model to an eval/buy model means that their end users would have to obtain a new version of their application. There would have to be a way to tell whether the current user paid for the full version of the app during the pre-eval period and not force them to go through the whole purchase cycle again.

    I should also emphasize that with this API the application will never have to be given access to any private user-credentials. Something like the following added to UIApplication will work wonders to ward off app piracy:

    + BOOL isAppPurchased;
    + NSDate* dateOfPurchase;

  4. The last thing Apple could to do help eval/buy apps a success is implement a policy where only users who had purchased the unlock token would be allowed to post comment and reviews on the AppStore. Let’s maintain the status quo instead of taking a step back. The problem, however, is given the totally unstructured way the current In App Purchase model is implemented, there is no viable way in which an extra rocket-launcher token can be distinguished from an unlock application token.

    I would argue that unlocking eval applications, verifying proper ownership, and restricting access to the review system should be the responsibility of the entities that control application installation and launching–i.e., the operating system and iTunes–instead of individual developers. But in lieu of that, Apple should give developer tools to properly implement an evaluation system that welcomes legitimate users and cuts back on potential abuse.

In summary: The In App Purchase mechanism is a great system for supporting application add-ons. But it’s wholly unsuited for supporting eval applications and does nothing to fight application piracy. Having properly implemented eval apps is important to the future of this ecosystem. Apple shouldn’t leave it up to individual developers to figure out how to get there. It should be part of the core functionality of the operating system.

Problems with Push


I agree with most everything Karl Adam says about the limitations of the Apple Push Notification Service, especially the problem with its failure to stack notifications so they’re not missed.

I posted a bug report a while back (rdar://7054632) offering a simple solution to get around this particular problem: save each incoming push payload into as a separate entry. That way if I get a push and don’t have time to get to it I can ignore it and come back to Messages later on and retrieve it and all received Push messages are kept until I choose to get rid of them.

The entry could be in the form of a special URL link that shows the alert message, but when clicked generates the same JSON payload format as a regular push event and invokes the app in the same manner so no extra coding would be needed (OK, maybe just a little bit of code on the server to check against processing duplicate requests). It would take care of a lot of problems with push usability.

An even more pressing issue I have with Push is if you are on a WiFi network behind a bunch of firewalls and more than one NAT server. This happens often in corporations or in homes with multiple routers acting as range-extenders. In these cases pushes fail to reach you — until you get back to a 3G network.

For some people Push is doubling as a remote event timer (since Apple won’t let us access the phone’s alarm database or submit local cron tasks). This makes it really hard to issue reliable time-based alerts.

If Apple would just open up true background tasks and/or timed alerts and let the user decide whether they trust an app to let it access those services (much like location-based or push services) a lot of these hassles would go away.

Also, a European friend brought up that whereas SMS is included in most phone plans, push incurs data usage charges. Could be a hassle if you’re traveling and continue getting pushes.

Over all, I’d say push on the iPhone is a work in progress. As much as I’m intrigued and excited by its potential, I’m frustrated by its current implementation and limitations.

Semi-Modal (Transparent) Dialogs on the iPhone

Popping up a modal dialog on the iPhone is a fairly straightforward process:

modalDialogViewController *modalController = [[modalDialogViewController alloc]          initWithNibName:@"modalDialogView" bundle:nil];  [self presentModalViewController:modalController animated:YES]; [modalController release];

Dismissing it then is a simple matter of the modalController invoking:

[self dismissModalViewControllerAnimated:YES];

But what if you want to show only half a page’s worth or maybe you need the underlying view to continue being available for user viewing or interaction. Or maybe you want to show a pop-up toolbar where users are asked to choose something before continuing. You might think “Aha! I’ll just have my modal dialog view be half as tall and make the background transparent.”

Go ahead, give it a try. We’ll wait… (* … the girl from Ipanema goes walking … *)

So now you know that the standard modal dialog can only be full-screen and maintains a solid black background. What’s more you can’t interact with what’s behind it because, you know it’s modal — and modal means users shouldn’t be able to do anything else until they’re done with the front-most task (unless you’re the search box in the Contacts app in which case apparently it’s OK to be kindasortamodal).

So what we’re going to do is have a view that can be modal but takes only part of the top view, the space above it remaining visible. What’s more, you can choose to have it so tapping on the background view hides the modal view, or even go full-bore and let the background remain responsive to user input. This technically makes the view semi-modal so let’s ignore the sirens and the UI Police banging on the door and go with that.

The first thing you need is a view that has something interactive on it. The easiest way to build one is in interface builder, so go ahead and make yourself one. For the sake of expedience make it only a fraction of the screen. Here’s an example of a half-height view along with some user controls. The background is set to fully transparent. The view is connected to a UIViewController that reacts to user input:


In this case, the view is the same height as the whole screen because we want the upper portion to be see-through but not react to user input. If we wanted it to be truly interactive, we could make the view height be as tall as the actual content (i.e. half-screen) but that would make it a bit strange for the user because it would be hard to tell apart the actual content from the modal view. But hey, it’s your app. You can do what you want. Another option is to set the background of this view black and partially transparent. That would look cool and show a nice smoky cover while we’re in modal mode… unless you’re mucking with color (like we are in this example) in which case it’s best to leave it fully transparent. Next throw the following code in the parent UIViewController. Load up the UIViewcontroller/UIView you just created and pass the view to this routine instead of calling the standard presentModalViewController method (substitute your application delegate for MyAppDelegate):

// Use this to show the modal view (pops-up from the bottom)
- (void) showModal:(UIView*) modalView {   UIWindow* mainWindow = (((MyAppDelegate*) [UIApplication sharedApplication].delegate).window);   CGPoint middleCenter =;   CGSize offSize = [UIScreen mainScreen].bounds.size;   CGPoint offScreenCenter = CGPointMake(offSize.width / 2.0, offSize.height * 1.5); = offScreenCenter; // we start off-screen   [mainWindow addSubview:modalView];    // Show it with a transition effect     [UIView beginAnimations:nil context:nil];   [UIView setAnimationDuration:0.7]; // animation duration in seconds = middleCenter;
[UIView commitAnimations]; }

What this does is add your view as a top-level above the main window, effectively rendering it modal. It also uses Core Animation to move the window from offscreen bottom up until it’s fully shown. You should adjust the timing to suit your view’s actual height. I’ve found that the taller the semi-modal view, the more time you should give it to become fully visible. Now let’s go through the hiding action. Note that we use the animation completion handler to do the actual removing of the item from the parent view and cleaning up. We also use the context parameter of the animation call (which was thoughtfully provided for exactly this sort of thing) to keep track of what view to clean up afterward:

// Use this to slide the semi-modal view back down. - (void) hideModal:(UIView*) modalView {   CGSize offSize = [UIScreen mainScreen].bounds.size;   CGPoint offScreenCenter = CGPointMake(offSize.width / 2.0, offSize.height * 1.5);    [UIView beginAnimations:nil context:modalView];   [UIView setAnimationDuration:0.7];   [UIView setAnimationDelegate:self];   [UIView setAnimationDidStopSelector:@selector(hideModalEnded:finished:context:)]; = offScreenCenter;   [UIView commitAnimations]; }  - (void) hideModalEnded:(NSString *)animationID finished:(NSNumber *)finished context:(void *)context {   UIView* modalView = (UIView *)context; [modalView removeFromSuperview]; } 

[ Update: As noted in the comments, there was an extra release on modalView in hideModalEnded. This code was excerpted from a larger code-base and the release was left in inadvertently. The code listing here has been updated. Thanks for catching it, folks. ]

What I’m not showing you here is the way to trigger the show/hide action. That’s entirely up to you. In standard iPhone modal dialogs this is often a button in the toolbar or navigation bar. In the case of the semi-modal dialog, however, you have even more flexibility. Basically it comes down to the show/hide elements being:

  • Explicit: Provide an Accept or Cancel button on your view.
  • Implicit: You can simulate an action toolbar that shows and hides this way. Put a row of buttons on the view and wire it so tapping each one invokes hideModal before going on to the actual action.
  • Other: Tapping anywhere else on the screen dismisses the dialog. You can do this by placing a full-screen sized view (or custom transparent button) behind your modal dialog and wiring it so it a tap-down action dismisses the dialog . For best results, try making this full-screen view black and semi-transparent (e.g. opacity=0.2). This way the user’s main view darkens so they get a sense your modal dialog is in focus but they still get to see what’s behind.

Here’s a movie of the above semi-modal view in action. It lets the user select a color then confirm or cancel the action. The modal view in this case also has interactive controls on it. As the user changes color the background image changes in real-time so they can visualize what the end-result will be like. Once they’re done they can tap the checkbox or X/cancel buttons to make the modal go away.

The semi-modal dialog is a handy UI interaction component but it’s important to think about how to dismiss the dialog and what to allow in the rest of the visible region on the main window to avoid confusing the user. Also note that there are no restrictions on the shape or size of the overlay view as long as the background color is set to [UIColor clearColor]. You can use the same method for irregularly shaped pop-ups.

Go nuts and have fun.

[Update: Nathan in the comments below has posted some code on github. You may want to check it out. ]

WWDC 2009 Predictions

Word came today that Apple’s WorldWide Developer Conference is going to be running from June 8-12 2009 in San Francisco.

Since Apple’s no longer going to be participating in MacWorld this is one of the few public conferences where Apple and its partners can make public product announcements. So now’s a good time to start floating outlandish rumors
predictions as to what’s going to be announced.

Since Apple already announced its intention to release iPhone 3.0 software around that time, a lot of products will be taking advantage of those features. One of them was access to the external USB port. The announcement demo featured a heart-monitor. My prediction is it will be totally upstaged by one of these:

Eval applications on the iPhone AppStore

One of the loudest complaints about the iPhone AppStore has been the lack of support for eval or demo applications. In the desktop world users can often download an application and use it for a period of time before deciding whether it’s worth paying for. But in the iPhone AppStore universe (where all transactions occur) there is no such support. Developers are then faced with the option of offering a lite version for free (or inexpensively) and a full version of their apps. The problem is that this still doesn’t allow the end-user to test out the full app and then choose to buy it if it fits their needs. And switching from a free to a full app involves installing an entirely independent application.

What we really need is a way to upgrade an eval app to the full version once the user decides the app is worth paying for.

Yesterday Apple publicly announced the developer release of iPhone 3.0 software (it won’t be publicly released until this Summer). To the dismay of many developers, there was — once again — no mention of support for eval applications among the 100 new features and “1000 new APIs.” So again, we are left without the option of letting users download an app, take it for a test run and then pay for it.

Or are we?

One of the features announced publicly was support for In App Purchases. This was presented as a way for users to obtain add-on levels or objects directly within games. The transaction (or more precisely, micro-transaction) still goes through the AppStore and gets charged to the same account. Despite public detractions I belive this is a Good Thing — especially since the feature can be used to legitimately support eval applications, even if the AppStore doesn’t officially support it yet.

Here’s how:

  • Developer offers application for free on the app-store. This is a fully functional version (i.e. not lite or crippleware).
  • User downloads and runs the application and is informed that the application is in eval mode and will stop working after a period of time.
  • After the eval period (say, 1-4 weeks) the application puts up a notice indicating the eval period has expired. It can either stop working or drop into a degraded mode.
  • At this point the user is given the option of performing an In App purchase of the full application.
  • If user accepts, the application contacts the AppStore and purchases the add-on — which would be priced at what the full-price of the App would otherwise be. Once completed, the app downloads an add-on key indicating the app has been purchased.
  • The presence of add-on indicates that the full app has been purchased and the timeout is taken out. All the application has to do each time it is launched is to look for the presence of this add-on.
  • Everyone’s happy.

There’s a key assumption here — that the AppStore keeps track of already purchased In App purchases the same way it does with full applications today. In other words, if the user tries to re-download an In App purchase that they’ve already purchased with the same iTunes account, they shouldn’t be charged twice. If a user deletes the app or moves to a new phone, all they have to do is download the free version of the app, perform another In App purchase (for free this time) and off they go.

However, if this assumption is not true and In App purchases are tracked separately than full applications (or the application itself is responsible for keeping track of those transactions) then the developer will have to implement a way to track In App purchases that works across multiple app installs — most likely a simple web-server to keep track of eval vs. purchased apps. Let’s hope it doesn’t come to that (the documentation on the Store Kit is not out as of this writing and even if it was, developers under NDA won’t be able to talk about it publicly until the public release of the 3.0 software).

There are some other issues that need to be hashed out, mainly what happens if unscrupulous third-parties find out what this add-on looks like and make it available for free download? The iPhone application sandbox makes it a non-issue since only the application itself is allowed to write to its Documents directory or modify its user settings — unless the phone has been jailbroken, in which case the concerned developer may want to support more complex security (like cryptographic signing) for the add-on. Given that the AppStore DRM appears to be compromised using this technique does not significantly increase the risk of software piracy.

Another potential issue is the user who downloads the fully functional eval version, uses it for the full eval period, then deletes it, re-download and installs it so they can get another free eval period. If this is an area of concern, it can be handled through a simple web-service that keeps track of how many times the same user has installed an app. Personally, I don’t think it’s worth the hassle given that deleting an app also gets rid of all user-generated data. But that’s me.

Note also that when I’m talking about downlaoding something, I don’t mean literally downloading a chunk of code, but some sort of token that takes away the eval time limit. The whole operation can be performed very quickly once the In App transaction is completed.

I firmly believe having support for eval apps is critical for medium to high-priced applications to flourish on the AppStore. A user will hesitate to fork out a high price for a full-featured app without having the option to kick the tires beforehand. This method can easily solve the problem and let developers do eval apps as soon as the 3.0 software is officially released.

Update: Apple has since announced that free apps can not use StoreKit. This is to avoid a potential bait-and-switch situation where the consumer downloads what they think is a free app and then get hit with a fee. However, I think it’s a misguided policy. A developer who does that will quickly get down-reviewed (if they even make it out of the app-review chute). A more likely scenario would be to allow users to use an app for a limited period of time, but give them the option to unlock the app for continued use.

Another more fundamental issue, however, is whether app developers even want an eval feature. I’ve heard from several Android developers that the Android store return policy has severely impacted sales of their apps. Their argument is that returns should be based on faulty apps, not because someone found their game too hard. Presumably, enabling eval apps will cut down on a lot of impulse-then-discard purchases that go on today.

Certainly a topic worthy of further discussion.

Thoughts on Professional iPhone Development

Idea vs. Execution

Raven Zachary in a post on the O’Reilly Inside iPhone Blog raises the old idea vs. execution argument. *Sigh*. This is the same debate I’ve been hearing (and having) for the past twenty years and it keeps popping back up again.

Folks, it’s not zero-sum / either-or. It’s both. One hand holding the other. Yin and yang. It’s like saying who was more important in your creation: your mother or your father? (OK, some might say it was the Rum and Coke, but remember that’s just the catalyst.)

A lot of people bandy about the phrase “Ideas are a multiplier of execution.” As near as (Google) can tell, this phrase was popularized in a short post by Derek Sivers. What most people ignore is the conclusion he posits:

To make a business, you need to multiply the two.

In other words: I * X = success

If either I (idea) or X (execution) values are low (or zero) the outcome suffers–or stays at zero. Without a good idea, the best developers will sit around and play games or post rubbish on Twitter. Without a good implementation the best ideas will sit around till the cows come home. And the converse is true as well (bad idea/bad execution).

Architects can draw as many designs as they want, but without the builders nothing will get built. The builders can build the most fabulous walls but they won’t quite connect because they don’t have good plans.

Shall I go on? (NNNNoooo!)

So the next time you discount somebody’s idea by assigning it a value of $0, you may want to pause and give it another listen. Naturally, there are lot more ideas than implementations, but that doesn’t mean ideas are worth $0. It just means you need a knack for sifting the good from the bad. And let’s not forget good and bad are subjective valuations. If it wasn’t so, all movies and games would be instant hits.

OK, ’nuff said. I’m sure this isn’t the last time I’ll be hearing this debate again.

Product vs. Project

On a different topic, if you go by Raven’s numbers your typical developer making $125/hr working full-time will gross ~$250K a year (most developers I know work only part-time, however). If they write an app, put it on the app-store and it sells, say, 30,000 copies for the year (a conservative estimate) they would need to price it at around $10.99 in order to match the consulting rate. Write a hit (say, 100,000+/yr) and at that price, you’d be waaay ahead of the hourly rate.

The dilemma most professional iPhone developers will face is whether to take on a consulting project or spend the time working on their own product. I can tell you from personal experience, it’s pretty damn hard doing both. In a perfect world, you could do one for a while then switch to another. But it rarely works that way. While doing consulting, you’ll have to battle the constant nagging feeling that you’re actually losing money by not having your product out there and the opportunity may well slip away when someone else beats you to the market. On the other hand, while working on your product and not generating income, it’s hard to say no to someone offering you cash.

It’s a tough choice (and you should drop to your knees and kiss the ground if you’re lucky enough to be facing such a dilemma.)


The other thing to keep in mind is that if you’re planning on writing an app for yourself and pricing it low (say, $0.99) then you’re looking at a heckuvalot of copies to make it worth not going the consulting route. iPhone developers wanting to do product development for themselves and make a good living at it might want to take Andy Finnell’s sage advice and price their apps at a more reasonable rate–something that would at least cover their costs and allow them to turn down subsequent time-intensive consulting gigs.

My personal feeling is no competent developer should be putting out $0.99 apps. They’d only be shortchanging themselves. The iPhone store is in its early stages. It’s too early to have all the shelves be stocked with apps retailers put in the discount bargain bins.