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.

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.

The iPhone Economy app provides a snapshot of the US economy. It was launched on July 4 and went on to become the #1 paid app in the “Finance” category of the app store.  The app was featured in Apple’s (itunes) STAFF FAVORITES section and also in the media.

The iPhone Economy is probably the first iPhone app to use Twitter OAuth to post tweets. From a development-resource perspective, the Twitter functionality was easily the most expensive component of the V2 upgrade. Most of these costs came from implementing login with Twitter’s new OAuth authentication protocol. Later in the post, I’ll write more about costs and about OAuth benefits of security and privacy. Adding Twitter functionality to the Economy app was first suggested to me by @hivebrain, but at the time, both of us had assumed that this would be a fairly inexpensive feature.

The app creates a community of Twitter users of the iPhone Economy app with the #cEconomy hashtag. It auto-generates economic tweets on the latest economic indicators (e.g. GDP, Unemployment, Housing starts, inflation etc.). The default tweet text includes latest numbers and how it compares with the past (as an example, today, my twitter post with default text showed the November unemployment rate (published today by the Federal Government) and compared it with last month’s rate and last year’s rate.

Users may choose to edit the default text and these tweets are suffixed with #CEconomy. Standard/unedited tweets are suffixed with #cEconomy. Tweets from the iPhone Economy app can be identified by the source of the app (which will say iPhone Economy app). All tweets from the app will have the cEconomy (or CEconomy) hashtag and a search on #cEconomy will return all tweets from the app.

An explicit user action (tap of the “Post” button) is always required for posting tweets.

OAuth, Security and Privacy

As mentioned earlier, implementing Twitter login with OAuth turned out to be fairly expensive (in terms of dev resources). The Twitter.com website recommends that all applications use the OAuth login approach “to prevent security issues” and says that the basic login approach will be deprecated in the future. However, at the moment, it looks like the iPhone Economy app is the only iPhone Twitter app that uses OAuth for login and posting tweets.

Apps that use basic login ask users for their password and typically save the password on the device. With basic auth and with oauth, a malicious app can compromise security, but with basic-auth, a non-malicious app may also compromise security. It is possible to write secure code with basic auth, but several developers don’t do that and OAuth mitigates these risks.  At least one popular iPhone app used to save an unencrypted password on the device. Presumably, some PC/Mac/iPhone apps send raw passwords over HTTP. Regardless of whether they save the password on the device or not, all apps that use basic login, directly ask the user for their passwords before handing it over to Twitter.

In contrast, the iPhone Economy app uses OAuth and so it doesn’t get or use or save your twitter password anywhere. You log into a twitter web-page, provide your password to Twitter (not to the app), and inform Twitter that you’re authorizing the iPhone Economy app to update your twitter data. Twitter then provides the iPhone Economy app with a token that permits it to make twitter posts on your behalf.
The iPhone Economy app saves this token securely on your device. The token cannot be read by anyone else. You can remove the token by tapping the ‘Logout’ button on the ‘Post to Twitter’ page. You also have the option of revoking authorization through the Twitter.com site (without using this app).

The authorization token is not a password and it cannot be used by anyone other than the iPhone Economy app. The Economy app uses the token when you explictly tap the ‘Post’ button on the ‘Post to Twitter’ page.

To encourage OAuth adoption in new apps, Twitter will only show the source of tweets (status updates), if the new app uses OAuth. However, tweets from old apps that use basic auth continue to show the source of tweets. The source of the tweet typically shows below the the tweet (as …From AppName)

Twitter OAuth has been available since March 2009. However, the biggest disadvantage of using OAuth login (as of now, December  2009) is that Twitter’s OAuth login page is not mobile-friendly and users see a login page that is formatted for a laptop/PC, not an iPhone. We have been working with Twitter (the company) on this and they’ve assured us that they will work to “improve the mobile oauth” experience. Until then, unfortunately, users may find the login UI a bit difficult to use. Of course, another disadvantage (from a developer perspective) is that implementing login with OAuth is expensive (from a development time perspective). However, overall, I hope that users appreciate the usage of OAuth login.

I also hope it is fun to tweet the latest economic news (even though the news itself may not always  be good)

This week’s changes to the app store (and itunesConnect) process for developers prompted me to write about the app store’s evolution over the past 16 months.

The app store has created a market where users are willing to pay money to download mobile apps and (even though most apps make very little money) the app store has created a great opportunity for developers. However, the itunesConnect and app-store process hasn’t been very developer-friendly. Here is a list of some changes that have improved the process over the lifespan of the app store so far.

1. In Sep/Oct 2008, Apple prevented non-users from writing reviews for apps. Until then, many apps got angry 1-star reviews from users who didn’t even bother downloading the app. Limiting reviews to people who actually downloaded the app was a great improvement to the app store

2. In November 2008, Apple introduced the “top paid” app list for each app store category. This was another great improvement.  Given the vast amount of junk in the app store, it is hard for good apps to stand above the fray. In this context, the top-paid app list (within each category) has done a good job of improving the visibility of many apps. As examples, our iPhone Government Spending app (released more than six months ago) and  our Economy app are both in the category-specific “top-paid apps” list and have benefitted from this over several months since their release dates. This is not to say that other apps (i.e. apps that aren’t in the ‘top paid’ list) are bad. Our Global Warming Personal Calculator app is a good app, but it is not in the top 100 list for its category. 

3. For several months last year, some unscrupulous developers exploited a bug that let them update the “release date” of their app on a regular basis. Since apps were sorted on release-date, these developers were able to game the system to push their apps to the top of the list and get more visibility easily.  Apple fixed this  “release date” logic bug in December, 2008.

4. In June 2009, Apple released iPhone OS 3.0 which supports in-app purchase. From a dev/business perspective, this is one of the most interesting developments in the past year. The V2 version of Economy uses in-app-purchase and I’ll write more about in-app-purchase in a later post.

5. In September 2009, Apple introduced a “Top Grossing” list in addition to the “top paid” list. The latter uses rankings based on the number of users/downloads, while the former is based on net revenues. In recent weeks, the “top grossing” list  shows that only around 15% of the top 100 grossing apps are $0.99 apps. This list can encourage developers to charge higher (and more fair) prices for their apps and users get more visibility to these apps through the top-grossing list.

6. In October 2009, Apple  introduced freemium support (i.e. support for in-app purchase in free iPhone apps). This was an important development, but I don’t think it was as big as many others made it to be. My analysis of the new freemium policy is here.

7. Until this week, the app-store “release date” category sorted apps by the “release date” of the last version of the app. Some developers gamed the system by releasing frequent updates (without any significant new work) and these updates pushed their apps to the top of the list. That won’t be possible anymore. With this week’s change, apps will be sorted based on their first “release” date and updates will not push an app to the top of the list. This is bound to reduce the number of frivolous app-updates and that may reduce the load on Apple’s app-reviewers. One potential problem is that some developers may re-release the same (old) app as a new app.

8. This week, Apple added a little bit of transparency to the app-review process. In the past, developers had no idea of how far along their app was in the review process, but Apple has now added a new “Status History” page for app submissions. I could see this with my submission of the “Economy V2.0″ update. Yesterday morning, my submission of “Economy V2″ was moved from the ”Waiting for Review” status to the “In review” status by user “Apple” and I could see that in the status-history page. This is a small, but very-good improvement and the added transparency will help developers.

Note that I haven’t attempted to address one of the most controversial aspects of the app-store-review process - the rejection of apps like Google Voice etc. - However, I think it will be a mistake for the government (the FCC)  to force Apple to carry any apps. I also hope that Apple works better at clearly communicating the criteria that they use for rejecting apps.

On another complaint, I agree that good apps are sometimes buried in a deluge of bad apps and that it isn’t easy to discover all good apps in the app store. However, I don’t have any specific solution for Apple on this matter.

As an aside , it looks like this weeks itunes update broke the ranking system for paid apps. On Wednesday, Nov 4  (around 4:30pm PST – Seattle time -)  , I noticed that the top 100 paid app rankings had gone through a dramatic transformation. The (previously) top-ranked apps were missing and a whole lot of unknown apps were now ranked in the top 100. The problems were fixed shortly before 6pm, but the pattern was repeated again Thursday morning. After that, it looks like Apple restored older (correct) rankings and then froze the rankings until Friday in order to eliminate distortions created by the ranking-system-bugs. Since then, the system seems to be functioning correctly again.  

So what more can Apple do ? I think that they should continue making improvements to increase the transparency of the whole review process. This week’s changes are a good step in that direction.

At last year’s (Apple) tech-talk event in Seattle, I had asked the Apple guys to give developers the chance to respond to user review-comments in the app store. Often users ask questions or make feature suggestions and it will be great if developers get a chance to respond to these questions and suggestions. Some reviews tend to be misleading or just outright false and it will be good if developers get a chance to comment on these reviews as well. At the moment, the review section of the app-store is a one-sided dialogue and I think that the app store will improve a lot and users will be better served if Apple gives developers the chance to respond to app store user-review comments.

Apple should do also do a better job with the “release date” field for apps. Currently, by default, the release-date for apps is set as the date on which the app was submitted by the developer (to the app store). If developers set a later release date and the app is approved earlier, the “approval” date is set as the release date. Instead, Apple should just set the release date as the date on which the app is actually released to the app store.

Overall, I’m happy that Apple has been making several improvements to the app store and it will be great if they continue making more improvements such as the ones I’ve mentioned above.

However, Apple has now decided to allow “in app purchases” for free iPhone apps. So “free” iPhone apps can now become “freemium” apps  and developers can sell additional content or functionality/services from within their free apps. We’ll have to wait for a few weeks or months to see the impact of this change. For now, here are my thoughts on the new policy.[Warning: Long post]

1. Piracy: Apple’s announcement explictly mentioned that the new policy will “help combat some of the problems of software piracy by allowing you to verify In App Purchases.” I agree with this assessment and think that the new policy is going to help combat piracy. In-app-purchases don’t introduce any downside with regard to combating piracy, so it is easier to call a win for the new policy on this particular issue (the other issues are more complex)

Piracy is not a problem for us (Cascade Software Corporation) because the demographic profile of our users is likely to be different from that of those who pirate apps. However, piracy is a problem for many other developers (especially games developers) and so the new policy can help increase app store revenues for developers who are hurt by piracy today.  

2. App Store clutter: Apple’s announcement also states that in-app-purchases in free apps eliminates “the need to create Lite versions of your app.” Today, many developers create a free/lite  version and a paid version of the same app. With the new policy, developers may not need to release two separate versions of their apps. So some of the clutter may be reduced. However, see below for reasons why some developers may want to continue releasing two separate versions (Incidentally, so far, Cascade Software Corporation hasn’t released any free/lite apps. All our apps are paid apps.).

The “lite” apps contribute to a fairly small fraction of the total “clutter”. Most of the clutter is caused by poor-quality, cheap-to-implement apps and by the fact that many companies release 10-100 copies of the same app with the same code-base, but different content. So I don’t expect the new policy to have a big impact on app store clutter.

3. App Review ratings: I haven’t done a rigorous study of the numbers, however, from what I’ve seen over the past year, free apps have a much lower review rating than paid apps. Lower  priced apps often tend to have a lower review rating than higher priced apps.

It is tempting to assume that there always is a correlation between the price of the app and the quality of the app, but that isn’t necessarily true and it doesn’t always explain the differences in review ratings. I’ve seen lite/free versions of apps get lower ratings than paid versions of the same app and I’ve seen apps (with higher ratings) get lower ratings after price reductions. Today, all top five grossing apps have 4-star (3 apps) or 4.5-star ratings (2 apps), four of the top 5 paid apps have 4-star (3 apps) or 4.5 star ratings (1 app), while only one of the top five free apps has 4-star rating and none have a 4.5 star rating. The #1 free app (Photoshop.com) has a 3.5 average rating, meanwhile, the #4 top grossing app (as of today) is priced at $89.99 and has an average 4-star rating (out of more than 2000 ratings). Yet a recent review in the New York Times mentioned that this app and similar high-priced apps ”crashed several times”.

My sense is that some users are more likely to download a free app without reading the description of the app. Partly, because of this, they are more likely to be unhappy with the app once they try it out (and these users are more likely to rate the app, compared to happy users). Users are also more likely to delete free apps from the iPhones and this is more likely to lead to a low review rating. On the other hand, the user of a paid app (and especially a higher-priced paid app) is more likely to have read the app description and is more likely to be someone in the app’s target market. So paid apps (and particularly higher-priced apps) are likely to get higher ratings. Freemium apps are likely to get lower ratings than they would have gotten as paid apps.

4. App Rankings: It is unclear on whether Apple will tweak its app rankings as a result of the new policy. Until now, the “top free apps” rankings and “top paid apps” rankings were both easy to understand. However, now the “free apps” listings will include freemium apps as well. A couple of months ago, our Economy app was #1 paid app in the “Finance” category. However, the Economy app has a niche audience and if it had been a freemium app, I’m not sure if the app could have become the #1 free Finance app.

I’m also guessing that some users look more closely at the “paid apps” listings because of the perception that ”free apps” aren’t good quality apps. This may be another reason for some developers to release their apps in the “paid apps” section. (Note that I’m mentioning the “perception”, but -in this post-, I’m neither agreeing nor disagreeing with that perception)

Ultimately, unless Apple changes the current ranking system or introduces a new ranking system for freemium apps, it is possible that many developers may prefer to keep their apps in the “paid” category and release a seperate lite/free version of their app.

5. The old “race to the bottom”: Over the past year,a number of developers have talked about the race to the bottom and how most developers go with the $0.99 price for their apps because of (real or imagined) competitive pressures.

It is unclear on as to how the new policy will impact the race to the bottom. On one hand, “free” could become the new “$0.99″ and many developers may release free(mium) apps instead of paid apps . On the other hand, some developers may feel liberated to charge a higher (and fair) price (through in-app- purchase) if users have already previewed the free portion of their app. (Note that I’m talking about pricing trends, but not discussing whether the $0.99 pricing strategy is good or bad. )  

6. Value to users: The most important impact may be the value that users get (or lose) because of the new policy. 

I’d like to believe that users will get more value out of the new policy because they’ll be able to preview the free portion of the app, gauge its quality and then decide whether to pay more for additional functionality. If that happens, it will be good for users and also for developers (because developers will get more downloads and it will also be easier to set a fair price for their apps without the concern that users may not consider buying an expensive app). On the other hand, some of the potential negatives – discussed earlier - (and the fact that users may expect free apps to be truly free) may result in confused users and lower app sales.

With the old policy, free apps could include links to their corresponding ”paid apps”. So one can make the case that the new policy will not have a big impact on upsell possibilities. However, I think that more developers will use the upsell approach because of the new policy and users may prefer to make a purchase without exiting the app. Overall, I’m slightly leaning towards the thought that the new policy may have a neutral or slightly positive impact. 

For me, the introduction of in-app-purchases was one of the most interesting things about the 3.0 OS.  (V2 of the Economy app – which will be released to Apple this month – includes some new “free” features and it also includes “in-app purchasable” premium features. I’ll write about this in a new post after the release). So it will be interesting to see how the new policy of in-app-purchases-for-free-apps impacts the app store.

[UPDATE: Dec 21, 2009] It is now more than two months since Apple introduced in-app-purchases for free iPhone apps. At the moment, only one of the top 100 grossing apps is a free(mium) app. That app/game is ranked 91st. When I checked a few times last month, there was only free(mium) app in the top 100 grossing apps. I think that app/game got into the top 10 grossing-apps list and stayed there briefly.

However, overall, for now, current data does seem to indicate that my original assessment (about the new freemium policy not having a big impact) was correct. Just around 1% of the top 100 grossing apps seem to be free/freemium apps.

1. By the end of August, around 90% of our users were on OS 3.0 (or later). The overwhelming majority of iPhone users were on OS 3.x, roughly 3 out of 4 iTouch users were on OS 3.x. By the time Economy 2.0 is released (mid October), we expect an even higher number of users to be on 3.x versions.  In itself, this was not a sufficient reason to be OS 3.0+ only, however, this was an important consideration.

2. Future versions of the Economy app will include iPhone OS 3.x only features such as in-app-purchase and in-app-email. Some of the iPhone OS 2.0 apis are being deprecated by Apple. For example, the “font” property of UIButtons has been deprecated and Apple recommends setting the  “font” property of the button’s “titleLabel”. However, titleLabels didn’t exist in any of the iPhone OS 2.x versions.

3. Apple’s policy on previous versions: Supporting iPhone OS 2.x (for old functionality) and yet using new iPhone OS 3.x features (that will only work on OS 3.0 or later updates) is possible, but it is somewhat expensive because of the testing hit. Specifically, as per http://support.apple.com/kb/TS1275, Apple says that “Downgrading to a previous version is not supported”. So it isn’t possible for us to move an OS 3.0 device to OS 2.x for test purposes. While it may be possible to borrow or buy an old iPhone with the 2.0 OS on it, this would exacerbate our time constraints and further delay release of the Economy 2.0 app.

4. The most important consideration was the fact that the 1.0 version of the Economy app is a high-quality app that offers great value. So I’m comfortable with a small minority of users continuing to the use the 1.0 version of the 99-cent Economy app and not picking up free upgrades with the 2.0 version.

(PS: Incidentally, the 1.1 version of our Election app was released last year and yet  our servers get some requests from the 1.0 version of the Election app; some users upgraded to the 1.1 version several months after release, some other users continue to use the 1.0 version. This indicates that some of the iPhone OS 2.x users of the Economy app will probably stick with the 1.0 version of the app, even if the 2.0 version of the app supported iPhone OS 2.x)

If you have any concerns or thoughts about not supporting iPhone OS 2.x, please email us or post your comment as a response to this blog post.

The iPhone Economy app was released on July 4 and it got to the 4th place (in “Finance” ) within a week after release. We have received a number of emails from users and most of them said they loved the app. Many (though not all) feature requests/suggestions from our users will be implemented in our 1.1 release. The 1.1 version is due to be released in the first half of August.

http://CascadeSoft.net/Economy.aspx has more details on the app and the app can be downloaded from the app store.

Incidentally, the iPhone Economy app is the 4th app from Cascade Software Corporation.

It is also the second #1 app from Cascade Software Corporation. Last year, our first app (the iPhone Election app) was – at one time – the #1 paid app in the “News” category.

http://CascadeSoft.net/Economy.aspx has more details on the app and the app can be downloaded from the app store.

It is one of the 8 featured apps on the first page of the “STAFF FAVORITES” section (in an app store that has more 65,000 apps)