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:
  1. Start early when dealing with Apple
  2. Android development is faster than iPhone development
  3. iPhone users are different to Android users
  4. Don't expect sophisticated reports
  5. 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. ;-)

Monday, October 6, 2008

jTribe is going iPhone

jTribe has finished its first iPhone application. It's called FirePin and is a simple iPhone app that allows a user to track trips. We have chosen a minimalist approach and tried to avoid things that we found annoying on other iPhone apps.

Yes it is yet another tracking app. But this one is different. This is not a hard core GPS tracking system. It is about letting other people know where you are on a trip. Sharing and protection where the key design features of the app.

Introducing our "no sign-up"approach

When the iPhone came out I ended up with 5 new user accounts on the Internet and stopped using apps that ask me to sign-up. Our app does not required the user to sign-up. Install and use it straight away.

"no sign-up" and still protected

The location data that is send to our FirePin location store is kept anonymous. It is impossible (even for us) to conclude who has submitted locations.

Power to the iPhone user

The user can manage and control all data from the iPhone.
  1. Creating new trips,
  2. sharing trips with friends and family,
  3. accessing trip history and
  4. displaying trips in the iPhone Map application.
However, access through a non-iPhone web browser is also possible and supported and offers some more advanced feature such as post-editing trips interactively in our integrated Google Maps application.

We are using it too

The jTribe folks (who are owners of an iPhone) are using FirePin too. Our first-time users thought: "Why should I use this app?" But then we found heaps of useful things we could do with it and it became kind of addictive.

Things to do with FirePin
  1. Letting our partner know how far we away from home.
  2. Sharing our holiday trips
  3. Letting coworkers know how far we away (when stuck in traffic)
  4. Record outdoor activities such as running, bike riding, hiking (not swimming)
  5. Mark a fishing trip and keep it for later reference
  6. Share a trip with family members so they can track you on your way to a family gathering
We hope that other iPhone users find it as useful as we.

Ah yes, and it's actually free!