The Washington Coalition for Open Government  organized a conference this weekend to commemorate the 40^th anniversary of our state’s landmark Initiative 276 and the Open Public Meetings Act (and to discuss the past, present and future of open government).  I was one of the speakers at the conference and spoke about using technology to promote open government.  Here is an overview of what I talked about.

Why Open Government: Open government and increased transparency can lead to greater civic engagement, greater government accountability and better governance.  This can help government make better decisions and increase government effectiveness and efficiency. All of this creates social and economic value.

Technology to promote open government: Technology has lead to a new information age and vast amounts of information are now available to the common man. While we do have a digital divide, it is also true that the internet has provided an unprecedented level of information and opportunities to hundreds of millions of people across rich and poor countries. Technology can also be a great aid to promoting open government, but it is only effective if the technology efforts are planned and implemented well.

From our experience in developing popular civic apps with public data, here are some of the prerequisites that I see as necessary for technology to be effectively used to promote open government.

1. Clear articulation of goals: At the outset, it is important to clearly articulate goals of the open government technology effort and the reasoning behind these goals. The goal-setting process should also attempt to specify metrics that will be used to measure the effectiveness of these efforts.

2. Effective prioritization: The government should focus on exposing data that is useful to citizens and not just on what is convenient for the government (or convenient for a vendor implementing the technology-solution for the government). A large quantity of easily searchable data is good, but the quality of data (measured by usefulness) is even more important.

3. Mandate legal disclosure requirements:  Voluntary disclosure by government (e.g.  http://www.data.gov/)  is good, but ad-hoc efforts by government aren’t sufficient to establish a strong open government foundation.  Governments should be required by law to provide relevant information to the public. This should be accomplished through the legislative process or through the initiative process (in states like Washington, California etc.) or other means.

If governments provide data through web-servers, they should also be required to provide service-level-agreements (SLAs) regarding the stability of these web servers. This is an area where the federal government Office of Management and Budget (OMB) has done a very poor job.

4. Sustained government support: Governments need to plan on sustained long-term support for open government technology initiatives. Some local governments tend to hold lottery-like app contests, but these short-term gimmicks often result in a clutter of unsustainable disposable apps.  A couple of years ago, the CTO of Washington DC discontinued their “Apps for democracy” because he concluded that the contests didn’t provide long-term value.

Sustained government support includes allocating resources to answer data-related questions and respond to bug (i.e. problem) reports from developers. From what I’ve seen, the Department of Energy, the Federal Reserve and the Bureau of Transportation Statistics have all done a great job in this regard and that helped us immensely in developing our civic apps.

5. No restrictions: There should be little or no restrictions on how the data will be used. Public data is compiled with public money and the end-goal should be to promote open government. Therefore public data should be free for anyone to use for any purpose. Ideally, data usage shouldn’t be encumbered by any government requirements or restrictions. This will empower third-party developers and lead to greater innovations. The more restrictions/requirements around data usage, the lesser innovations we are likely to see.

Limitations of technology: As a cautionary note, I’d like to add that technology can help promote open government, but it is not the panacea for today’s government’s failures.  Bloomberg Businessweek has an interesting report on how India’s Right-To-Information Act has had a powerful impact and yet caused a lethal backlash. A recent news report in the Seattle Times describes how the Bainbridge Island police department hired an officer in spite of his criminal history, but told him to quit after the history became public. The report also mentions that the police guild had tried to block the public from seeing records related to an officer’s alleged misconduct. The state Supreme Court had to step in and stop them from doing this. This is a good example of how government agencies might try to block the disclosure of inconvenient truths.

Any government can throw together a website, throw some random data on it and proclaim their open credentials, but it takes much more than technology to really establish open government. It requires a sustained citizen/government effort and an alert, independent media to ensure that inconvenient, but important, useful information is disclosed by the government and ensure that there is no retaliation against open government activists.

However, I do want to provide an excerpt from Steve Jobs’ Stanford speech in 2005.

“Remembering that I’ll be dead soon is the most important tool I’ve ever encountered to help me make the big choices in life. Because almost everything — all external expectations, all pride, all fear of embarrassment or failure – these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.

About a year ago I was diagnosed with cancer. I had a scan at 7:30 in the morning, and it clearly showed a tumor on my pancreas. I didn’t even know what a pancreas was. The doctors told me this was almost certainly a type of cancer that is incurable, and that I should expect to live no longer than three to six months. My doctor advised me to go home and get my affairs in order, which is doctor’s code for prepare to die. It means to try to tell your kids everything you thought you’d have the next 10 years to tell them in just a few months. It means to make sure everything is buttoned up so that it will be as easy as possible for your family. It means to say your goodbyes………………..

Death is very likely the single best invention of Life. It is Life’s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.

Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.”

1. Launch the iPhone or iPad (Economy or Government Spending) app. Navigate to the page that has the graph you’re interested in. Scroll down, if necessary.

2. Press the Home button on your iPhone/iPad and hold it down. (Note that in potrait mode, the ‘Home’ button is the button below the iPhone/iPad display screen)

3. While the Home button is held down,  press the Sleep button and quickly release it. Release the ‘Home’ button after this (Note that the Sleep/Power button is on the opposite side of the ‘Home’ button. It is on the top of the screen on the right side)

4. After step 3, you will see a white flash on your screen and hear a camera click sound. The screenshot will be added to your iPhone (or iPad) camera roll.

5. You can now close the app and launch Apple’s Photos app. You’ll see the screenshot at the end of your camera roll. 

Now that you have the picture in your camera roll, you can use itunes on your Mac (or PC) desktop/laptop to copy the picture/screenshot to your computer.

Alternately, you can use the following steps to email the picture to yourself.

1. Launch the ‘Photos’ app. Tap the picture you’re interested in

2. Tap the “Send photo” icon on the page and then select the ‘Email photo” option. If you don’t see the icon, tap the screen again and the icon will appear.

3. Email the photo/screenshot to yourself. On your desktop/laptop computer, open the new email and save the attached screenshot/photo.

Killing the zombie with a private API:  It was (late night) 3:30am when I realized that the zombie keypad issue was a bug in the iPad SDK and not in my code. At that point, I should have probably called it a day, but didn’t. As I investigated the bug further, I found that the (dismissKeyboard) private API took down the keyboard perfectly. With exception handlers and checks for respondsToSelector, the code seemed reasonably safe (though – in general – I agree with Apple’s reasoning that private APIs shouldn’t be used)

App-store rejection: After a 9-day review cycle, we got a very politely worded email stating that the app had been rejected because of its usage of private APIs. Since the private APIs were being used to work-around a bug in the public API, there seemed to be a reasonable chance that Apple might make an exception. So I filed an appeal with Apple’s app-review board. 

An impasse: Apple’s review team did a great job in following up with me (email and phone calls) and we discussed the matter in detail. However, I couldn’t find out the approximate timeframe within which the app-review-board might make their Yes/No decision on the appeal. The appeal seemed to present a difficult problem. On one hand, the private APIs were used because of an SDK bug, on the other hand, approving the private APIs would have set a bad precedent. In the meanwhile, the app was no closer to being released. That is when I decided to email Steve Jobs.

“Ram, this is Steve”: A couple of hours after I sent the email, I was at a noisy soccer (for kids) arena when I heard my iPhone ring. The caller-id, the caller saying “Ram, this is Steve” and that he was calling from Apple did suggest that it could really be Steve Jobs. He confirmed it when I asked.

Steve Jobs’ decision: Steve Jobs talked to me about my appeal and the “no private APIs” policy. I then asked him whether an exception could be made to the policy because the private APIs were necessitated by the SDK bug. He reiterated his point and I accepted it. I told him that I would replace the modal form sheet with alternative UI. Removing the form sheet (and therefore its bug) would eliminate the need for the private API.

A conscientious guy: Steve Jobs has a well-deserved reputation for creating great quality products and for his passion for excellence and user experience. I’ve also read that he is a detail-oriented executive and a hands-on guy who is intimately involved with his company’s work (in a way that few other CEOs are).
His phone-call reinforced those notions and went further to suggest that he was also a very conscientious guy who cared about people. The fact that he took the time to read my email, think about the app and then personally call me was amazing.

Upshot: I resubmitted the ‘Economy for iPad’ app after removing private APIs. The app uses Federal data to give you a snapshot of the US economy. The app review board and app review team graciously expedited the review of the app and it is now available for download at the app store. We have been releasing iOS apps since 2008 (the year when the app store was launched) and this one has the most fascinating submission story among all our apps. I’m now looking forward to seeing how the app does in the iPad app store.

The Yes answer: For developers who have experience with C/C++ , memory management or/and for developers who like learning new technology, I would suggest learning Objective-C and Cocoa-Touch to create iOS apps.
In general (without talking about mobile-specific platforms), cross-platform frameworks are not very good and add a level of risk to projects. Using 3rd party frameworks could also lead to potential performance issues in the app.

Full functionality: The frameworks are almost always going to offer a *subset* of native iOS functionality. For example, a new iOS 5.0 feature will be available to all native-app developers when Apple releases iOS 5.0. Anyone relying on a 3rd party framework will have to wait until the 3rd party implements that functionality into their framework.
Reduce risk of bugs: Just last week, I found two bugs in the iPad SDK. (Apple said that one of the bugs was a known problem that they’re investigating, no news yet on the second bug). I was able to workaround both bugs, but such workarounds will become a lot more difficult if you have to deal with one more layer in front of your code and that layer has bugs in it.
User experience and Platform-specific UI : In general, using the platform and tools that Apple provides is going to be the easiest way  to create apps that conform to Apple’s guidelines/recommendations for great apps.
This is also going to be true for other platforms. For instance, an iPhone app ported to Windows Phone 7 may be better off if the UI design is changed to show panoramic views. Using a 3rd party framework and not learning what works best on each individual platform will make it easier to blur differences between different platforms, but that wouldn’t create the best user experience for any of the devices/platforms.

The No answer: For developers who don’t have the time to learn new Objective-C/Cocoa-Touch or for developers who are uncomfortable with more-hardcore programming, using the cross-party frameworks will be a good idea (and this will also help reduce the chances of memory leaks, crashes etc. in the app).
Working with a 3rd party framework means that developers will have to accept some of the limitations described above. However, for many apps, the cross-platform frameworks will probably be able to do a decent job.

Porting app to other mobile platforms: Using most 3rd party frameworks will also make it easier to port the app to other mobile platforms. However, as described earlier, the caveat here is that a good app will need to provide the best experience on each platform and that will require customization on each platform.
Rampup time:  In general, developers are likely to use 3rd party frameworks to make it easier to develop apps. For instance, an experienced Flash developer will be able to develop a game with Flash in a much shorter time than what they might have to spend with the Apple tools. However, in many cases, developers will need to spend a fair amount of time on learning how to use 3rd party frameworks. For instance, a C# developer will still need to spend time on learning the MonoTouch framework, a web programmer will need to learn the PhoneGap framework and the rampup time to learn these frameworks isn’t going to be neglible (although it will be lesser than the time to learn Objective-C etc.)

Number of touch-optimized mobile websites: The speaker provided data to show that the number of touch-optimized mobile websites was a multiple of the total number of iPhone and Android apps. He also made the point that mobile websites had more users than native mobile apps.

The data on web-app numbers and user-numbers are interesting, but I think that for many businesses, they are far less important than other factors such as Revenue potential, Discoverability/Distribution and User experience. On these counts, native apps and the app store generally do much better than mobile-web apps.

User Experience: In general, as a practical matter, on the iPhone, native apps offer a far superior user experience to mobile web apps. In almost every instance where the iPhone user has a native app option, they are more likely to use the native app instead of an equivalent web site.

At the talk, the speaker promoted mobile web apps and mentioned that the New York Times app on the iPhone was just a “web application” with a “native shell” and hosted Safari web controls and “web content”, but I pointed out that this assertion was incorrect. The iPhone NYT app is a native iPhone app and (from its V1 days) it seems to have been using standard Cocoa Touch classes such as UITabBarController, UITableViewController etc. Almost every iPhone NYT reader uses the NYT app instead of the NYT website.

Revenue potential: In my opinion, native apps sold through the app store offer a much superior revenue model for mobile apps. Web apps generally find it a lot more difficult to charge users for products/services and ad-funded models for web apps often don’t yield much revenue. As an example, the developer of the iPad Elements app said that their iPad app earned more revenue in one day (through the app store) than what their equivalent web app (PeriodicTable.com) had earned with ads in four years.

Reach: A single mobile web app can generally run on several different types of mobile devices and therefore it will offer a wider reach than any one single native app. So if being accessible from a wide range of devices is very important (or if the appearance of providing equal service to all phones is important), the mobile web may be a better option than building multiple native apps. However, there are caveats with the assumptions of wider reach.

A decade ago, at Microsoft, one of the teams I led worked on the development of mobile apps. Based on that experience, I’d caution against assumptions that a mobile web app tested on one device will run well on all mobile devices. For that matter, cross-browser issues have been a problem on desktop browsers as well.

Is it possible for the web to crush native apps:  Anything is possible, but it is unlikely that HTML5 or other mobile web apps will win over native apps in the near-term.

A resource-rich organization can certainly invest inmobile web apps *and* native mobile apps now. That would be a good way to hedge their bets. However, many organizations may not have the resources to invest in web-apps and native apps and will need to decide whether they need to invest on sophisticated mobile web-apps or (one or more) native mobile apps.

Programmer-Journalist: I sometimes describe myself as a programmer-journalist. All our iPhone and iPad apps disseminate news (for example, our second #1 app uses Federal Government data to provide a snapshot of the US economy) . Our apps deliver the news on a daily basis, but we are clearly not a traditional news organization. That said, I do find it difficult to identify with the philosophy of a lot of “new media” folks.

New Media rhetoric: The newspaper industry is clearly in trouble, but a lot of the new media rhetoric about newspapers is off-base. Last year, I had addressed another new-media criticism here

Today, I read a story about the “Newspaper of the future“. The story was about an iPad app that aggregates news from a large number of sources and provides a personalized reading experience to users. I haven’t tested the app on my iPad, but all indications are that it is a very good and well-developed app.

The story goes on to say that this app will “deliver the final blow to the newspaper industry” . In promoting their own beliefs by attacking the traditional news industry, they are following the familiar zero-sum game that many new-media folks like to engage in.

Real Reporting: Someone does need to actually investigate and report the news and for the most part, it is traditional news organizations that do most of the heavy lifting in this regard. They are the ones out there investigating corruption in Washington DC, atrocities in Congo, the war in Afghanisthan and local city council meetings.

New media folks often talk about Twitter, Blogs and Citizen-journalism. All of them are undoubtedly valuable, but haven’t provided much evidence of being a viable replacement for the old-fashioned reporter.  

Top news aggregator apps on the iPhone and the iPad get their news from the traditional news industry. So regardless of their rhetoric, it seems clear that they do highly value the traditional news industry.

If they ever do “deliver the final blow to the newspaper industry” , their apps would quickly go out of business, unless they (or someone else) stepped in to do the job that traditional reporters do today. I hope new-media folks get a better understanding of journalism, how it has served people for centuries and how it can best serve the public in the future, instead of mindless rhetoric about how news aggregators will  “deliver the final blow to the newspaper industry”.

Bias ?  The app-store is a fairly polarizing topic and so I’m going to start by describing my experience with different platforms/companies. If any readers perceive a bias, it might be interesting for them to see how my experience might have contributed to the perceived bias.

We have shipped two #1 ranked iPhone apps and my primary phone is an iPhone. I wrote an Android app long before the first Android phone was launched and replaced my secondary phone with an Android G1 in 2008. I was a Principal at Microsoft for several years and some of those years were in the Windows Live Mobile team where (among other things) I led a great team and received Microsoft Gold Star awards.

Smartphone Market Share: As per Gartner Research’s Q1 2010 numbers, Symbian had 44.3% of global smartphone sales, RIM had 19.4% and the iPhone was 3rd with 15.4%. However, the iPhone pioneered today’s modern smartphone design (which Google, Microsoft,RIM etc. are attempting to emulate).

It was the launch of the iPhone and its app-store that led to a tipping point in the mobile app ecosystem and today, its strongest challenger is Google’s Android. Symbian, Windows Mobile and (Blackberry) RIM have been losing market share among consumers and they also haven’t generated a lot of new developer interest. However, I should add that Symbian is more popular outside the US, than it is in the US.

The first Symbian touchscreen device (Symbian 3) is expected to be released in October 2010 and it is also rumored (in a not-so-great 2009 movie) that James T Kirk used a Symbian (Nokia) touchscreen device. Microsoft’s new touchscreen-based Windows Phone 7 platform is also expected to launch in October 2010. Yesterday, a news report indicated that RIM may release a new touchscreen Blackberry device before October,2010. So the iPhone and Android may face more competition next year.

Language and ramp-up time:  iPhone (iOS) app development requires Objective-C expertise. For most developers, learning the iOS platform (with Objective-C) is likely to be a lot more challenging than learning the Android, Windows Phone 7 or Blackberry platforms.

Developers for Android and developers for the Blackberry platform use the Java programming language, and developers for Windows Phone 7 will use the C# programming language with Silverlight and XNA.

Note that Android and iOS support the (optional) usage of C/C++ for coding some (but not all) portions of the apps. Android apps can be developed on Windows, Mac and Linux. iPhone apps can only be developed on a Mac.

Language (Java) fragmentation and Android: Java was once advertised as a “write once, run anywhere” cross-platform solution, but that hasn’t been true in practice. Android uses a non-conformant implementation of Java and Google chose to create its own standards for new libraries and APIs. This means that an Android app will have to be rewritten for a Blackberry device, even though both platforms ostensibly support the Java programming language.

In the past, in the desktop world, Microsoft has taken a lot of heat for creating non-standard versions of Java, but the digerati doesn’t generally mention that Android created a new non-standard version of Java.

Developer Fees and App Prices: Apple charges an annual developer registration fee of $99, Google charges $25 and Blackberry charges $200. The Apple and Google registration fees let developers release an unlimited number of apps, while Blackberry limits the number of apps to 10 and charges additional fees for more app-submissions.

Unlike Apple, Google etc. which set a minimum price of $0.99, the minimum price for a Blackberry App World app is $2.99

Growth prospects, iPhone and Android: A recent Nielsen study indicated that 80% of iPhone users wanted their next device to be another iPhone. 70% of Android users wanted their next device to be another Android device. These numbers were in stark contrast to the low numbers of other platforms such as Blackberry and Windows Mobile. The Nielsen report also indicated that iPhone users are older, wealthier and more educated than their Android peers.

The biggest constraint to the iPhone’s growth in the US is the fact that its exclusive carrier is AT&T.  Android is available on the country’s four largest carriers. The iPhone’s current growth in market-share will be accelerated (at the expense of Android’s growth rate) if it is available with all four carriers next year.

Revenue prospects, iPhone wins: An old cliché says that the plural of anecdote is not data, but in the absence of variable-controlled, vetted data, it seems reasonable to consider app store anecdotal evidence. Many developers with apps on both platforms have suggested that the revenue generated from an Android app is generally 10-20% of the corresponding revenue of an identical iPhone app. This ratio is in spite of greater competition in the iPhone app store (which has roughly 3-4 times the number of apps as the Android market) and in spite of the large number of Android phones.

So it seems reasonable to conclude that a typical Android user spends far less on apps than a typical iPhone user and that, for now, the revenue generated by most iPhone apps will be a big multiple of the revenue generated by their Android counterparts. At WWDC,2010, Apple announced that they had paid more than $1 Billion to app-store developers.

On a more cautionary note, my assessment is that on any given day, *most* paid apps make zero or close to zero dollars.

Ideology and First-mover advantage? : I’ve heard bloggers suggest and retweet that “Apple developers” should “Code for Android first, and iPhone/iPad second”. This is a classic case of non-developers providing developer-advice based on ideology. The reasoning used was that Android offers “first mover advantage”. However, the Android market was launched within months after the iPhone app store and there have been tens of thousands of Android apps since 2008. So I think developers should evaluate the Android market based on its past track record and future prospects, not on a bogus “first mover advantage”.

Of course, if “first mover advantage” was really important, the recommendation might have gone to Windows Phone 7, but Microsoft has never been popular with the digerati.

Openness – App submission and Review process: Android offers the most developer-friendly app-submission and review process and that makes it a fairly attractive choice for developers who don’t want to deal with the uncertainty of whether and when their apps might be approved.

iPhone apps go through a review-process before getting into the app store. Microsoft also plans to create a review/certification process for its Windows Phone MarketPlace.

Some iPhone apps get rejected in Apple’s review process, some others spend weeks in review purgatory. Unfortunately, these apps aren’t limited to the ones alluded to, by Steve Jobs, when he famously said that “folks who want porn can buy an Android phone”. Apple has conceded mistakes and reversed course on some app rejections, but the problems go beyond the few high-profile cases where Apple reviewers did a U-turn on app-rejections  

To be clear, I’m not suggesting a preference for any specific app-publishing model. The (“open”) Android model of instantly publishing apps (without Google’s review) has obvious benefits, but it also has risks. For instance, the 12/22/2009 report from First Technology Credit Union notes that a “rogue Android” app launched a “phishing attack” to get users’ banking passwords. In a reactive move, the app was later removed from the Android market. Apple’s review process attempts to be proactive in rejecting such apps.

My perspective is that there are several tradeoffs in choosing between an open app-submission process and a review-based app-approval process. However, a review process (like the one for the iPhone app store) that lacks transparency, clear guidelines and consistency isn’t helpful to developers and doesn’t help users either.

More openness, Adobe Flash: Apple requires all app-store apps to be built with Objective-C and explicitly prohibits the use of cross-platform tools such as Adobe’s Flash-to-iPhone compiler. Google has no such prohibitions and permits cross-platform tools.

However, it should be noted that Adobe’s “cross-platform” tools only work for the iPhone and they haven’t yet created a Flash-to-Android compiler (presumably because they believed that the iPhone platform was more important than Android)

More openness, open-source: Android scores points with several people because it is open-source. Symbian is also open-source. The iPhone and Windows Phone platforms are closed source. Note that several Google Android apps (such as the Market, Google Maps, Gmail etc.) are closed-source apps.

Openness and Platform Fragmentation: When Twitter released their official iPhone app, every iPhone owner could have downloaded the app. Every iPhone owner can also download iPhone OS 3.1.3 (the latest OS)

However, when Twitter released their official Android app, only 27.3% of Android owners could even consider downloading the app. The other 72.7% users didn’t have the ability to download Android 2.1 and therefore couldn’t download the app. In this case, the “open-source” nature of Android and Google’s carrier-friendly-policy make it possible for carriers to create their own version of Android and deny users the ability to download later versions of Android.

As illustrated by the Twitter example, Android fragmentation problem makes life difficult for developers and consumers. In addition, the carriers and Google generally don’t attempt to backport bug-fixes into earlier versions of Android. This means that apps that run on both old and new versions of Android may need to implement different code for different Android versions. While fragmentation is not non-existent in the iPhone world, its impact in the iPhone world is tiny in comparison to Android.

Managing different devices, hybrid approach for Windows Phone 7: When I was at Microsoft, one of the biggest challenges we saw with mobile web apps (a decade ago) was the fact that we dealt with hundreds of different devices from different carriers around the world. These devices followed different specs (for instance, some supported cookies, come didn’t), implemented the same spec inconsistently and sometimes had bugs.

To a great extent, similar problems exist for Android apps – as devices from different manufactures (or even the same manufacture) may have different screen resolutions, different device sizes, different hardware features, different bugs etc.

The iPhone eliminates most (though not all) of these problems as all devices come from Apple. From a developer perspective, the impact of different device capabilities (e.g. iPhone camera apps can’t work on iPod Touch) is fairly small in comparison with Android.

Interestingly, Windows Phone 7 plans to follow a hybrid approach. Like Android phones, Windows Phone 7 devices will be created by several different manufacturers. However, all manufactures will be required to follow the same spec (e.g. 400×800 screen resolution, 4-point touch etc.) So UI design and implementation for Windows Phone 7 should be easier than corresponding work for Android devices.

App store Revenue share: Apple created/pioneered the 70-30 revenue split model (with Apple getting 30% and the developer getting 70% of app sales). Other smartphone app stores have followed suit with a 70-30 model and Amazon has also adopted the 70-30 model for its Kindle content.

While Android also uses the 70-30 model, Google doesn’t get the 30% revenue-share from app sales. Instead the carriers (e.g. Verizon) get the 30% revenue share. It appears that Google signs advertisement-revenue sharing deals with carriers who pre-install Google apps (like Search, Maps etc.) on the phone. This model seems to conform to Google’s overall strategy of focusing on search and advertising which are its primary money-makers

Refunds: The Android market lets users get a full refund for apps that they return within 24 hours. One complaint I’ve heard is that the refund feature leads to app piracy (with some users saving a copy of the app, returning it for a refund and then reinstalling the saved copy)

However, a revenue perspective, my sense is that Android’s refund policy is good for developers, because the refund policy makes it more likely that users will try out a paid app.

Apple doesn’t have a refund policy, though a determined user may be able to get a refund in some circumstances.

Microsoft plans to support a refund policy for the Windows Phone 7 marketplace and I’ve heard that they’re considering whether to go with a fixed 24-hour refund policy (like Android) or let developers configure/set a different refund policy (e.g. one based on how many times the user has launched the app)

App store – More comparisons: The iPhone platform lets developers sell additional features from inside an iPhone app. For instance, a $0.99 app could offer 10 features and a user of that app may have the option of purchasing 5 additional functionalities for an additional $0.99. Android and other mobile app platforms don’t seem to offer the in-app-purchase functionality

Many consumers suggest that the Android market is fairly primitive in comparison to the iPhone app store. For instance, app prices are displayed in currencies of the developers who published the app and not in the local currency of the Android phone. So a Canadian consumer would see a British app-developer’s apps priced in British pounds instead of the Canadian dollar.

Developers can sell Android apps through the Android marketplace and other channel they choose and this gives developers more options to monetize their apps. However, iPhone apps can only be purchased through the app store (with a narrow exception for large enterprises). Microsoft’s current plan is to limit app sales to the Windows Phone marketplace.

iPhone app developers benefit from being able to develop iPad apps with very little effort and most reports indicate that iPad apps sell fairly well. When/if other tablets (with app stores) become popular, developers can expect to make money from other platforms as well.  

I haven’t compared advertising-revenue options for apps on different platforms, but a discussion on advertising-revenues probably belongs in a separate post.

Overall, the mobile app landscape has gone through a lot of exciting changes and it should be very interesting to follow this over the next few years.

Recently, while on vacation, I was pleasantly surprised to get an email from Wiley Publishing Inc saying that the iPhone Economy app had been selected to be featured in their book on Incredible iPhone Apps. This was great news.

The iPhone Economy app is one of the apps featured on the cover of the book. The app (which can be downloaded from here) is also featured in chapter 5 (which focuses on the “Finance” category of iPhone apps). In chapter 5, the book also features other great apps from the ”Finance” category and this includes apps from the big guys like Bloomberg, E-Trade etc. So it was great to see that the Economy app was chosen to represent (chapter 5,) the “Finance” category in the Table Of Contents of the book.

Incidentally, one of the author’s two feature requests for the app (landscape mode support for the graphs) has already been implemented for the app. His other feature suggestion was for the ability to see news stories/analysis relating to each economic indicator.

The author, Bob “Dr. Mac” LeVitus has done a great job of compiling a list of incredible apps for the book and writing up a description/commentary/review for each one of the apps.  He mentions that he spent several months on narrowing down the list, testing the apps, writing notes etc.  The author also mentions that he tried to talk his editors out of naming the book as ‘Incredible iPhone Apps for Dummies’, but that he couldn’t get them to drop the word ‘Dummies’ from the title. Regardless, it seems like a great book for anyone who has trouble wading through the 150,000+ apps in the iPhone app-store to find quality-apps.

Of course, I should add that Wiley Publishing sent me a complimentary copy of the book and I’d like to thank Wiley Publishing as well as the author for featuring the iPhone Economy app in their book. The book is available at http://www.amazon.com/dp/0470607548 , http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470607548.html etc. and at book stores.

Two of our four iPhone apps went on to become #1 paid apps within their categories and it is hard to say whether these apps would have hit the #1 spot if they weren’t priced at $0.99. All of our four apps are ‘civic software’ apps, but news/civic oriented apps aren’t big revenue generators. These two caveats need to be kept in mind even though the post isn’t specific to pricing principles used for our apps.

1. Capital Efficiency:  The pricing of the app is not going to be proportional to the investment made into the app(e.g. our Economy app is priced at $0.99 even though the dev-investment for the app far exceeds that of more expensive apps).  However, it is a good idea to think of the total investment required to build an app. For example, if you expect to spend 100 hours on developing a product and value your time (or your team’s time) at $100/hr, you should consider the fact that you expect to invest $10,000 to develop the product.

Keep in mind that total expenses will exceed the initial capital expenditure of $10,000. For instance, you may have expenses related to recurring server operating costs, time spent on customer support, promoting the app, creating website content etc. I haven’t set revenue targets for any of our apps, but in general, I think that is a good idea to think of the total investment/expenses and a target number for revenue/returns.

There are tens of thousands of paid apps in the app store and my estimate is that on any given day, the revenue returned by most of these apps is either zero or close to zero. This should be kept in mind when setting capital efficiency (i.e. revenue/expense) targets.

2. Value to the customer: Benefits/Value delivered to the customer should be a key pricing consideration for the app. Users may consider a crude entertainment app as worth $0.99 even though the app may have been developed very cheaply. Several top-paid apps have proved this point over the past year. Users may also consider frequently crashing apps as worth $99.99 and $89.99. This is proved by the fact that the top-revenue/grossing list has consistently included $99.99 and $89.99 apps that “crashed several times” in a New York Times review.  

In contrast, our Economy app cannot be crashed and it required a lot of dev-investment and offers great value to a segment of the market. Yet, that –in itself – wouldn’t justify increasing its price, because (for most users), the value of the expensive(but crashing) apps and the value of the crude entertainment apps is much more than the value of an app that retrieves the latest numbers for key economic indicators and draws graphs based on current and past values of economic indicators.

3. Perceived value and competition: The (customer/user) perceived value of the product may be different from the true value of the product for many reasons. If a product’s benefits aren’t apparent to the potential customer, the perceived value is going to be lesser than the real value.  

In some cases, the perceived value of the product may become higher if the app is priced at a higher price and a lower-priced product may signal lower-quality to some users (even though the product itself may be a very high-quality product)

The perceived value is also impacted by the value of competing products. As an example, last year, I had originally thought of pricing our Election app at $1.99 and there were no other election-related apps at this time.  However, by the time, our Election app was released, there were five other election-related apps at $0.99. In many ways, (as demonstrated by the fact that it became the #1 paid news app), our Election app was better than the other apps. Yet, we priced it at $0.99 because of competing products (and also partly because the October release date meant that the product would have a shorter shelf life than what it would have had with a September release date)

4. Market fit for the price: While value to the customer is a very important consideration, the price ceiling should be guided by the market fit for the price. For instance, the product may have a high economic value for a few people, but a lower value for other people. The market fit is going to be based on the perceived value among different segments of the market and how big each segment is.

5. Market segmentation and in-app-purchases: Our Economy app follows a penetration pricing strategy and the $0.99 price helped it attain high market penetration. Yet, the $0.99 price also meant that we were leaving a fair amount of money on the table with some customers, because these customers would have recognized the app as a high-value app and been willing to pay a higher price that reflected the true value of the app (for them).

One way to offset the “money on the table” problem is to create a new higher-priced version of the app with “premium” features that appeal to higher-paying customers. A second option is to use in-app-purchases for “premium” features. The v2 version of the Economy app has in-app-purchase features (one priced at $0.99 and another one priced at $1.99).

Until the v2 release (which introduced in-app-purchase, two weeks ago), I was sure that in-app-purchase was the best way to manage market segmentation. In retrospect, it looks like the in-app-purchase option may not have been the best approach, but I’ll write more about this topic in a separate post.

6. Questionable gimmicks: We wouldn’t use any of these gimmicks, but I’ve seen developers successfully use “sale price” gimmicks. A few months ago, the #1 paid app in one of the categories said that its $0.99 price was an ‘only today’ sale price. They’ve been selling at that price for several months now. Some other apps have used the “on sale today” line to advertise a $0.99 price for several months.

The “only today” line is clearly false. Though one may argue that “on sale today” is not false, it is somewhat misleading to use the line to describe an app that sells at $0.99 for several months. A more innocuous tactic has been to list a sale price of $0.99. At least one app (that was #1 in a category) used this approach, even though that app has never been sold at any other price. Overall, it does appear that the market looks favorably on these gimmicks.

7. Top Paid List versus Top Grossing List: Many developers have suggested that Apple’s Top-Paid list ranking criterion (number of purchases/downloads) encourages a race to the bottom because $0.99 apps are likely to get downloaded at a higher rate than higher priced apps and developers would price their apps at $0.99 in order to get a placement in the top-paid app list. As discussed in the App-Store-Evolution post, a few months ago, Apple introduced a new Top-Grossing list (where apps are ranked on net revenue) and this should mitigate some (though not all) concerns about the race to the bottom.

A study of the two lists shows that (on most days), around half the apps in the top 100 paid list are $0.99 apps and that less than 20% of the top 100 grossing apps are priced at $0.99.

At the moment, the highest grossing $0.99 app is ranked 20^th in the top-grossing list. While 28 of the (current) top 100 grossing apps are priced at $4.99, only 15 of the top 100 grossing apps are priced at $0.99.

The $0.99 price isn’t going to be sustainable for most good-quality apps, but for some apps, it does have a couple of benefits in terms of market penetration and also in terms of increased visibility for apps that are in the top-paid lists of each category. A $1.99 price may increase the revenue of most good $0.99 apps (for example instead of 100 users willing to pay $0.99, the $1.99 price may find 65 buyers). However, the increased revenue will be accompanied by reduced volume and the reduced volume will mean a lower rank in the top-paid list. A lower rank will then lead to reduced visibility for the app and this may reduce sales further.

8. Each pricing decision is unique: We launched four apps in the first year of the app store and two of these apps (Election and Economy) went on to become the #1 paid apps in their categories. Both have always been priced at $0.99 (though the Economy app now includes premium in-app purchase features and premium features increase the price of the app). It is unclear whether these two apps would have become #1 apps if they hadn’t been priced at $0.99.

All our apps have been “civic software” apps and one of the key goals of these apps was to contribute to the civic good and provide useful information to the people. So these apps have not primarily been about maximizing revenue for the company. However, revenues are important for any business to survive and this post talks primarily about right pricing strategies that are applicable to many different types of apps.

I haven’t discussed experimenting with different prices, but pricing experiments may also be worth considering.

It is also a good idea to keep in mind that each app needs to evolve its own pricing strategy and that, not all the pricing principles (discussed in the post) are going to be applicable for every single app.