Here is a slideshare with our own predictions and trends around Mobile OS and Mobile Browsing Platform.
Showing posts with label Apple. Show all posts
Showing posts with label Apple. Show all posts
Wednesday, September 30, 2009
iPhone dominates the smart phone market in front of Nokia
The latest AdMob report for August 2009 shows that the iPhone has overtaken Nokia in the smart phone race. This is surprising even for us who always thought that the iPhone will rock the Nokia foundation but we expected that this would happen not before 2010.
Saturday, January 10, 2009
Why 99 cent iPhone apps wont work for you
You are an iPhone developer. You are a small software company. You are not a large company like Apple, Nitendo etc. Then this information is for you!
Why can large or popular labels charge 99 cent for iPhone apps?
Larger companies like Apple can afford to release 99 cent iPhone apps like a remote control for Keynote. Very cool app and probabely similar quality as iTunes Remote. Where iTunes Remote was free Apple now starts to charge for these kind of apps on the iPhone. I have no problem wtih that. They should charge for good software. But, hey, 99 cent. What is the thing to learn here? When you are big you can affort to sell your iPhone app for "just" 99 cent.
They know that they will get the volumes of users downloading the app and thus will be making enough money with a small price tag.
Why 99 cent iPhone apps wont work for you!
Seriously, you wont get the volumes of users like Apple, Tabulous, etc. Try it. I can tell you right now that it is a waste of time. It does not mean that your app is not as good the apps from the large lables. It just means that your app is one of 15,000 apps in the AppStore and not enough people will download the app to make it worthwhile. Unless you developed a blockbuster app such as iFart Mobile 99cent wont wont work for you!
What works for us
jTribe has released so far nine iPhone applications and we tried different prices to find out what the optimum price point is. Prices ranged from free to USD 3.99. We changed prices to see what happnes. We do not develop more "niche" apps and not the blockbuster apps.
Price that work for us is:
Why can large or popular labels charge 99 cent for iPhone apps?
Larger companies like Apple can afford to release 99 cent iPhone apps like a remote control for Keynote. Very cool app and probabely similar quality as iTunes Remote. Where iTunes Remote was free Apple now starts to charge for these kind of apps on the iPhone. I have no problem wtih that. They should charge for good software. But, hey, 99 cent. What is the thing to learn here? When you are big you can affort to sell your iPhone app for "just" 99 cent.
They know that they will get the volumes of users downloading the app and thus will be making enough money with a small price tag.
Why 99 cent iPhone apps wont work for you!
Seriously, you wont get the volumes of users like Apple, Tabulous, etc. Try it. I can tell you right now that it is a waste of time. It does not mean that your app is not as good the apps from the large lables. It just means that your app is one of 15,000 apps in the AppStore and not enough people will download the app to make it worthwhile. Unless you developed a blockbuster app such as iFart Mobile 99cent wont wont work for you!
What works for us
jTribe has released so far nine iPhone applications and we tried different prices to find out what the optimum price point is. Prices ranged from free to USD 3.99. We changed prices to see what happnes. We do not develop more "niche" apps and not the blockbuster apps.
Price that work for us is:
- USD 2.99 for a utility application (such as our PinPointMe app)
- USD 3.99 for more complex solutions (such as our "Coming Home Soon" app)
- Free for a platform app that is used to build niche products. We offer FirePin Trip Tracker for free. Then we use the same platform to build more complex but niche solutions we will charge USD 3.99 - 5.99.
- Would we use USD 9.99 as a price tag. Maybe. Currently, I cannot think of a complex enough application on the iPhone to justify this price.
Wednesday, December 31, 2008
Is the AppStore broken? Here are some indications
It looks like the Christmas break did something to the AppStore. First, the iTunes Connect was pretty much closed over the Christmas period, which is understandable. After iTunes Connect came back online again the review seem to take longer and the correspondence is not working well.
Here are four cases that indicate that the AppStore is broken.
Here are four cases that indicate that the AppStore is broken.
- We notices a spike of new users for our PinPoint app. Additional users did hit our sever and we know for sure that they are new users. However, the AppStore Trend Reports did not show any increased download at all. We are talking several hundred downloads that might have been missed. Since the daily trend reports may differ from the *real* download numbers we need to wait for the financial reports to see whether there is a problem with the AppStore operation. If the financial reports will not show the additional downloads then Apple needs to explain to us how that is possible.
- I received an email that our new app is Ready for Sale. After login into the AppStore it shows the app still under Review. (Remark: It is now set to ready for sale. More than 2 hrs after I received the email from Apple sayig it was ready. But the app is still not in iTunes.)
- Another app is shown as rejected. However, there is so far no email from Apple telling us that it was rejected or the reason why the app was rejected.
- I updated some screen shots for an application several days back but in iTunes it shows something different.
I Uploaded three images and all three are different. However in iTunes it shows only two different images and one is shown twice. Not happy with that because our customers might think we are idiots putting the same screen in there twice.
Monday, December 29, 2008
iPhone and Android can tell when you arrive
Location apps that tell people "when" you arrive not just where you are.
When we tell friends in non-technical terms what we are doing at jTribe we usually say something like:
The response we then get is:
jTribe has finished the first application that solves the problem of "personal ETA notification" (Has anyone a better term for that?).
The application is called "Going Home" and it is based on the problem many families have: Someone is waiting at home and would like to know when you arrive.
The underlying User Intention
#1: I want to meet someone at their place.
#2: I want to let them know how long before I arrive.
The 4 Ingredients
To solve the problem of letting someone automatically know when you are going to arrive we need four ingredients:
Stop, we still need a Solution for Notifications
TXT/SMS would be good for that because it a great mean to notify people instantly. Email would work too but does not have the instant characteristics of TXT/SMS. We settled for a combination of Email and TXT/SMS. At the start of the trip an Email is used to send a shared map link to the person who is waiting. TXT/SMS messaging is used to notify the person when you close to their place.
Unfortunately, the iPhone does not let you send TXT/SMS programmatically. Yes, it's true Apple still hasn't included it in their last iPhone 2.2 update. We thought there is no point waiting until Apple may or may not include an SMS API. So we had to integrate with a TXT/SMS gateway to send messages on behalf o the user. The issue with that is that these gateways are not free and someone has to pay for each SMS that gets sent. But without SMS the whole solution would be pretty much pointless. On the Android phone it would be possible to let the phone send SMS.
The Frontend
The primary frontend for the person that is travelling is either the iPhone (Android G1 is coming soon). As long as the iPhone application is running in the foreground it can constantly submit the current location to the backend server.
SMS will not be sent from the iPhone but from the backend server.
The person who is waiting has a different frontend. They receive an email with the shared trip map. They can then use the web browser to live-track the traveling person.
They will also receive an SMS when the traveling person is close enough.
The Backend
One key component of the solution is our FirePin platform. We use it as a backend to store all the user's locations so it can be shared with the person waiting. It also allows that person to track progress of your trip in real-time. (Sample of a shared trip)
FirePin Recap: The FirePin platform that allows recording and tracking of locations via the iPhone and Android G1 (and Symbian S60 soon). Basically, FirePin is a generic platform for location tracking and trip history. Because people store quite a number of trips on our FirePin servers we could almost call FirePin "personal GEO location hosting". (Rem: currently we got almost 2 million GEO locations in the FirePin database).
With the limitation of the iPhone we decided to extend the backend to include Notification services. Based on the locations that are constantly submitted to the FirePin server the service calculates the remaining distance to the destination. When a distance is close enough it will send out the TXT/SMS message to the person that is waiting.
Did I mention that the backend is written in Ruby On Rails.
The Integration
Integration between the iPhone and the Ruby On Rails backend is done via JSON and REST. Check out http://jtribe.blogspot.com/2008/11/json-and-restful-web-services-on-iphone.html
The End?
No this is not the end. It's the beginning of a series of apps from jTribe. Going Home is just the start. We have many ideas of location-aware applications that are getting more micro-social .
When we tell friends in non-technical terms what we are doing at jTribe we usually say something like:
" We make applications that allow your partner to know when you are coming home".
The response we then get is:
" That means I don't have to call or message constantly where I am and what my ETA would be? I could use that."
jTribe has finished the first application that solves the problem of "personal ETA notification" (Has anyone a better term for that?).
The application is called "Going Home" and it is based on the problem many families have: Someone is waiting at home and would like to know when you arrive.
The underlying User Intention
#1: I want to meet someone at their place.
#2: I want to let them know how long before I arrive.
The 4 Ingredients
To solve the problem of letting someone automatically know when you are going to arrive we need four ingredients:
- Destination - of the place we want to go (e.g. home)
- Contact - details of the person waiting for us at the destination
(e.g my partner waiting at home) - Current Locations - where we currently are
- Notification - let them know
Stop, we still need a Solution for Notifications
TXT/SMS would be good for that because it a great mean to notify people instantly. Email would work too but does not have the instant characteristics of TXT/SMS. We settled for a combination of Email and TXT/SMS. At the start of the trip an Email is used to send a shared map link to the person who is waiting. TXT/SMS messaging is used to notify the person when you close to their place.
Unfortunately, the iPhone does not let you send TXT/SMS programmatically. Yes, it's true Apple still hasn't included it in their last iPhone 2.2 update. We thought there is no point waiting until Apple may or may not include an SMS API. So we had to integrate with a TXT/SMS gateway to send messages on behalf o the user. The issue with that is that these gateways are not free and someone has to pay for each SMS that gets sent. But without SMS the whole solution would be pretty much pointless. On the Android phone it would be possible to let the phone send SMS.
The Frontend
The primary frontend for the person that is travelling is either the iPhone (Android G1 is coming soon). As long as the iPhone application is running in the foreground it can constantly submit the current location to the backend server.
SMS will not be sent from the iPhone but from the backend server.
The person who is waiting has a different frontend. They receive an email with the shared trip map. They can then use the web browser to live-track the traveling person.
They will also receive an SMS when the traveling person is close enough.
The Backend
One key component of the solution is our FirePin platform. We use it as a backend to store all the user's locations so it can be shared with the person waiting. It also allows that person to track progress of your trip in real-time. (Sample of a shared trip)
FirePin Recap: The FirePin platform that allows recording and tracking of locations via the iPhone and Android G1 (and Symbian S60 soon). Basically, FirePin is a generic platform for location tracking and trip history. Because people store quite a number of trips on our FirePin servers we could almost call FirePin "personal GEO location hosting". (Rem: currently we got almost 2 million GEO locations in the FirePin database).
With the limitation of the iPhone we decided to extend the backend to include Notification services. Based on the locations that are constantly submitted to the FirePin server the service calculates the remaining distance to the destination. When a distance is close enough it will send out the TXT/SMS message to the person that is waiting.
Did I mention that the backend is written in Ruby On Rails.
The Integration
Integration between the iPhone and the Ruby On Rails backend is done via JSON and REST. Check out http://jtribe.blogspot.com/2008/11/json-and-restful-web-services-on-iphone.html
The End?
No this is not the end. It's the beginning of a series of apps from jTribe. Going Home is just the start. We have many ideas of location-aware applications that are getting more micro-social .
Labels:
Address Book,
Android,
Apple,
ETA,
Firepin,
G1,
GEO location,
GPS,
iPhone,
Ruby on Rails,
sms
Tuesday, December 2, 2008
Application Segmentation in the AppStore
The Apple AppStore has now more then 10,000 applications on the shelf.
We thought it is time to talk about our findings and assessment of the different consumer and application segments we came across in the AppStore. For the sake of gloabalisation I am going to use US Dollar in this blog entry.
1. The Free App
New iPhone users like free apps because they are free. Isn't it part of our human nature to gather stuff? Yes, iPhone users that are gatherers go for the most popular free apps. What value do free apps offer? Promotional apps and light versions might be nice for a week or so. Apps that complement an exiting service such as Facebook. LinkedIn or Google are actually very useful. It kind of makes sense for those apps to be free since they make their revenue via their web site. I like the Facebook-like apps on the iPhone better than the web2.0 based overloaded desktop browser version. The iPhone forces the app to be simpler than on a large screen browser.
We found: The ratio between downloading a free app and using a free app is very low. Getting 50% of consumers that have downloaded a free app to actually use it regularly is a good result.
I personally decided to limit my number of free apps on the iPhone because it start to get cluttered. I can see how apps that offer some addition interaction channel for free can justify to be free (Facebook, Linkedin, Remember the Milk, Google, etc)
2. The Almost Free App (aka 99cent app)
New iPhone users also like the 99 cent apps. Statements like "limited time only" make the common app-gatherer to grab the app. Maybe it has to do with the fact that a song in iTunes is more expensive than a 99cent app - makes the app look like a bargain. Maybe the iTunes Store users are also conditioned by the music downloads. You download a song and keep it forever. Seriously, no one wants to keep an app forever on the iPhone.
Developers seem to use the 99 cent prize tag to make it from the "recent" page to the "most popular" page. If you don't become popular your sales numbers will degrade continuously.
We found: People are starting to realise that most 99 cent apps are trashware. Often the app description raises a false expectations and users are disappointed once the app is installed.
I personally do not longer buy 99 cent apps. I started to be very selective. Most 99 cent apps are trashware anyway. I often ask myself "why are they selling for for 99 cents. Is it value or just a cheap low quality app?". Started last week to delete some 99cent apps from the iPhone.
3. The Value App
Value apps are more expensive than 99 cent and less expensive than $3.99. Consumers see them as being valuable because they solve a particular problem well combined with a realistic prize tag. The app is stylish and simple. Often the developers of 1.99 app wants to distinguish themselves from free and almost free apps by sending the message "We think this is better than the 99 cent stuff"
4. The Quality App
The 9.99 apps covers this segment. I like apps like Things and agree with the price tag of $12.99. The developers did a great job and should be rewarded for their work because we want to see more of those well-designed apps.
5. The Niche App
These apps can pretty much ask any for any prize. Maybe justified because they will have only a small customer base. I have no niche app on my iPhone but I can imagine that some business or professionals are happy to get an app that makes their job easier.
I noticed some app in the navigation category that offers nautical maps. Why should they not charge $59 for those?
6. The Crazy App
There are always some smart developers that try to charge people $1000 for literally nothing. Get 2 customers and you made more money than the 99 cent apps selling 2000 times.
Prediction:
My predication is that the prizes will become more real and consumers have to expect to pay between 2.99 and 9.99 for useful apps.
My personal target is to have less than 7 free apps, 5 apps for 99 cents, 5 apps between 2.99 and 9.99, one app between $15 and $30.
I will not hesitate to delete 99 cent apps and through them out or replace them with new 99 cent apps. I think I would hang on to any value (2.49 - 3.99) and quality app (9.99).
Tuesday, November 18, 2008
How Apple rejected our iPhone app
Last week I submitted our second iPhone app called PinPoint. After 5 days Apple came back with a rejection.
Apple did find that the app did not comply to the iPhone Human Interface Guidelines. The app uses a standard "Action" button for an action which is not its intended purpose.

(This is the "standard" Action button provided by Apple)
So this means that Apple is actually reviewing the apps seriously.
Yes, I did read and understand the purpose of the standards "Action" button. The "Action" button is to be used to open an action sheet that allows users to take an application-specific action.
I have currently only one application action (open the email app) but I am planning to have more in the future (twitter, text/sms). I decided to use the "standard" action button and I also decided to not display an action sheet with one action to choose from. Seriously, it's not really a choice if you have only one thing to select from. In the next release I would offer more than one application using the same standards action button and the subsequent action sheet. (Wrong!)
The solution for now is that I got rid of the the Apple "standard" button. I have added my own button that displays an email icon. Great, this way Apple cannot complain about violating the Human Interface Guidelines. I am not convinced that this helps the end-user in the long run because developers are encouraged to come up with their "custom" icons to avoid non-compliance with Apple guidelines.
Anyway, after initial annoyance and self-criticism I accepted that this stuff happens. The fix and re-submission took me only 30 minutes and I hope I don't have to wait another 5 days.
What have I learned?
- If in doubt do not use standard buttons (especially the ambiguous action button)
- Cater for rejection in your development time table
- It's good to know that Apple takes reviewing the app seriously
Tuesday, October 28, 2008
Our top five tips for iPhone and Android developers
Apple and Google have changed the way applications are distributed to mobile devices.
We have released FirePin on AppStore and Android Marketplace and want to share our experience.
The Apple AppStore gave Mac developers a great opportunity to get their applications out there and some did really, really well. Now Google does the same thing with its Android Marketplace. Both storefronts give developers relatively easy access to a large user base. But there are differences in terms of ease of development and distribution.
Our top five:
- Start early when dealing with Apple
- Android development is faster than iPhone development
- iPhone users are different to Android users
- Don't expect sophisticated reports
- Keep it simple
1. Start early when dealing with Apple
First you have to sign-up for the iPhone Developer Program for a joining fee. In our case it took actually weeks to get it all approved. This might have to do with Apple checking actually the details of our company and the fact that we are an Australian company. I could imagine that the process is faster for a US company.
If you plan to let people pay for your application then there is some additional forms to be filled out. Especially if you are non-US developer (we are in Australia) there are some additional TAX -related forms you nee to fill out and some need to be send in as paper copies. So you better kick that process off early.
You should allow about 5 days for Apple to review your application. Every update takes another 3-5 days to review. Apple really reviews an app before it goes into the AppStore. They do not just let the app sit there for a week and then press a button to release it, no, they actually test the app. So you got your application through what I would almost call "user acceptance test" which is performed free of charge by Apple staff. Which is nice. If you have been involved in larger projects you might know that "user acceptance testing" takes time. Which sucks.
Here is a good description Oliver Breidenbach on how to get a EIN from the IRS that is required for non-US developers who want to sell their app.
Publishing on the Android Marketplace is sooo easy. The developer is trusted to publish "good" applications and therefore there is no review process. The app just goes live and the users can start downloading. Google obviously relies on the "wisdom of the crowd" to promote good quality applications based on user feedback. It looks like Android users are more willing to leave a feedback than iPhone users.
2. Android development is faster than iPhone development
Even though I use a Mac for all my software development I haven't actually developed with the Apple SDK or the Cocoa framework. Apple's SDK is actually not as bad as I thought. After a while I got really in touch with XCode and find it actually simpler than Eclipse. One thing that decreased my productivity was Objective-C which was completely offset by the good quality sample code provided by Apple. The iPhone Simulator works well but not for location-based applications (see previous blog entry). Unfortunately, the community of Objective -C programmers is much smaller than, lets say, Java or Ruby. Finding information on the web was harder than it needs to be.
On Android we had the same application up and running in a fraction of time. The reason is "openness" of the Android platform and the large community of developers. The emulator comes with a number of development tools that make automated testing pretty easy for location-based apps. You can replay a KML file. Very nice.
3. iPhone users are different to Android users
Our app is only since 1 day on the Android Marketplace, but we can already see that the review and feedback from Android users is completely different to what we got in the AppStore. Even for the same application. (More info will be blogged soon)
4. Don't expect sophisticated reports
Analytics suck for both, AppStore and Android Marketplace.
5. Keep it simple
So you are a mobile application developer now. There is a lot of new stuff you have to deal with. Best you keep your application as simple as possible. We found that users like simplicity in mobile phone applications. Our app is very simple and we actually spend much time to make it so simple. Other apps in the same category are overloaded with features and users give up early. We see that users come back and use an application when it is simple.
Monday, October 20, 2008
The top iPhone thing we don't like
The best relationships are the love-hate relationships. They keep things interesting and spicy. No, I am not talking about my personal relationships - I am talking about my relationship with my iPhone 3G.
One day I love the iPhone for its stylish and innovative appearance and user friendliness. Next day I hate the iPhone 3G for it's restrictiveness and for treating me like a child.
When I am in the "hate my iPhone" stage I usually go to http://pleasefixtheiphone.com/ and click on features I miss most. That has some therapeutic effect.
What is missing for location-based developers?
As an iPhone developer you experience a whole new dimension of iPhone love-hate. The device is actually really great but what about the tools to develop iPhone applications? The iPhone SDK and the Simulator?
When we started developing our first iPhone application we thought it would be easier - I mean it's Apple - right. Surely, the Apple SDK developers must figured out a way of simulating the GPS function in the Simulator. Wrong! In fact Apple did not think that one through.
The Simulator simply does a bad job in location-based app development support. The only thing the Simulator does is that CoreLocation returns always the same Location (the infinite loop in Cupertino). That functionality is enough for simple applications that want to determine your "current location". However, that is of limited use for a tracking application where locations "change".
How to test the "real" GPS behaviour?
So, you really cannot test the "real" GPS function in the Simulator. The way we tested it was to install the app on my iPhone. Then I would leave the building with the iPhone in my hand and run around the block to capture some locations. Does not sound too bad? It was bad! To produce a thoroughly tested application we had to spend the majority of the development time testing with the real iPhone device.
How could GPS testing be simpler?
There should be a way to play back a set of Geo-locations in the Simulator. This is actually not too hard but was probably not one of Apples top priorities at the time. Hopefully Apple will release such a playback tool with the next version of the Simulator or iPhone SDK.
Android is ahead
In the Android SDK there is a way to play back a KML files. That is nice. This function saves the location-based application developer days of testing. If only this would be available for the iPhone.
Hey, at least I am staying fit with all that running around outdoors with my iPhone. ;-)
One day I love the iPhone for its stylish and innovative appearance and user friendliness. Next day I hate the iPhone 3G for it's restrictiveness and for treating me like a child.
When I am in the "hate my iPhone" stage I usually go to http://pleasefixtheiphone.com/ and click on features I miss most. That has some therapeutic effect.
What is missing for location-based developers?
As an iPhone developer you experience a whole new dimension of iPhone love-hate. The device is actually really great but what about the tools to develop iPhone applications? The iPhone SDK and the Simulator?
When we started developing our first iPhone application we thought it would be easier - I mean it's Apple - right. Surely, the Apple SDK developers must figured out a way of simulating the GPS function in the Simulator. Wrong! In fact Apple did not think that one through.
The Simulator simply does a bad job in location-based app development support. The only thing the Simulator does is that CoreLocation returns always the same Location (the infinite loop in Cupertino). That functionality is enough for simple applications that want to determine your "current location". However, that is of limited use for a tracking application where locations "change".
How to test the "real" GPS behaviour?
So, you really cannot test the "real" GPS function in the Simulator. The way we tested it was to install the app on my iPhone. Then I would leave the building with the iPhone in my hand and run around the block to capture some locations. Does not sound too bad? It was bad! To produce a thoroughly tested application we had to spend the majority of the development time testing with the real iPhone device.
How could GPS testing be simpler?
There should be a way to play back a set of Geo-locations in the Simulator. This is actually not too hard but was probably not one of Apples top priorities at the time. Hopefully Apple will release such a playback tool with the next version of the Simulator or iPhone SDK.
Android is ahead
In the Android SDK there is a way to play back a KML files. That is nice. This function saves the location-based application developer days of testing. If only this would be available for the iPhone.
Hey, at least I am staying fit with all that running around outdoors with my iPhone. ;-)
Subscribe to:
Comments (Atom)