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.

1. 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.
   
   
2. 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.)
   
   
3. 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.
   
   
4. 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.

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:

" 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:

1. Destination - of the place we want to go (e.g. home)
2. Contact - details of the person waiting for us at the destination
   (e.g my partner waiting at home)
3. Current Locations - where we currently are
4. Notification - let them know
   

Hey, the iPhone or Android G1 is providing exactly what we need. It has an Address Book with contacts. The contact often have an address which we could use as destination. The GPS in iPhone or Android phone provides current location. Great, almost done.

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 .

Pushed out a new iPhone Travel and Location app

Yes, we where busy recently. Daniel got his Google phone and Armin did work on some more iPhone apps.

As a result we are happy to announce that "going home for Christmas" has been released into the AppStore today.

Here is what the app does:

Are you on a road trip and want to let someone know that you are close by.

This app can automatically send a TXT message when you are approaching home.

Driving home from work or traveling to visit your family or friends? Let them know that you are coming and where you currently are.

Allow them to see your travel progress in real-time.

Going Home for Christmas gives peace of mind to the people waiting for you.

FEATURES:

- Simply select a person from the Address Book

- A TXT/SMS message is sent when you are close enough

- An Email is sent so the person can track you live via the Internet

- Uses the location services on your iPhone (GPS)

- The distance to the persons address will be constantly calculated and once you are closer than 5 km (3 miles) a TXT message will be sent

NOTES:

TXT sending is included in the price for this application. No additional costs for TXT/SMS will be charged by your phone provider.

This application relies on the information in your Address Book. It uses the home address of the person you choose to visit. If they have a mobile number it will use it to send them a notification TXT/SMS message.

JSON framework with iPhone SDK 2.2

This is something that has cost me several hours after I upgraded to iPhone SDK 2.2. I have also documented it in the iPhone Discussion Forum but here is a brief summary.

If you going to use the JSON framework with the iPhone SDK 2.2 then there will be some problems. I could no longer link the framework to my application. For some reason Apple has changed the code signing behaviour. To get around it you need to add the JSON framework source code to your XCode project. 

1. Get the source code from:

svn checkout http://json-framework.googlecode.com/svn/trunk/ json-framework-read-only

2. Then copy that source code into your project directory (or use XCode add existing file...). 

3. Where you used :

#include <JSON/JSON.h> 

now you have to use:

#include "JSON.h"

and (as Dom pointed out)

#import "SBJSON.h"
#import "NSObject+SBJSON.h"

#import "NSString+SBJSON.h"

4. Build should be OK now.

Check out also http://jtribe.blogspot.com/2008/11/json-and-restful-web-services-on-iphone.html for more JSON / iPhone information.

Sending MMS with Android

Following on from my last post about saving a view as an image, today I want to demonstrate how to send this image via MMS. We used this technique in our application, PinPoint to send out maps via MMS. 

I have previously written about how to send SMSs with Android intents and while sending MMS via intents goes to the same application, the intent that needs to be constructed is quite different. The intent requires the following items to be set:

• the action set to be ACTION_SEND
• the mime type set to image/*
• a Uri extra inserted with the key Intent.EXTRA_STREAM
• optionally some text body with the key sms_body

Intent sendIntent = new Intent(Intent.ACTION_SEND); 

sendIntent.putExtra("sms_body", "some text"); 

sendIntent.putExtra(Intent.EXTRA_STREAM, Uri.parse(url));

sendIntent.setType("image/png"); 

The url being passed to the Uri.parse method should be of the form used to access the media store such as content://media/external/images/media/23. The previous article of views and images returns a url String that can directly be used by this MMS intent. 

Saving a view as an image with Android

Our Android application PinPoint can send map images via MMS and email. We used the following technique to be able to convert the MapView into an image that could be used across applications. 

Firstly create a Bitmap object with the appropriate width and height of your view, along with a configuration. RGB_565 seems to work just fine for the MapView canvas.

Bitmap image = Bitmap.createBitmap(view.getWidth(), view.getHeight(), Bitmap.Config.RGB_565);

Next create a canvas with the bitmap and pass that into the draw() method of the view. This will ask the view to draw it's contents onto the canvas and therefore the associated bitmap.

view.draw(new Canvas(image));

Next insert the image into the Media library. This returns a URL that refers to the stored image and can be reused across applications. In our case we could pass this URL to the MMS application to have it embed the image in a message.  I'll post some sample code of how to send this image via MMS shortly.

String url = Images.Media.insertImage(getContentResolver(), image, "title", null);

To test this in the emulator you'll need to setup an external storage device otherwise you'll see an error like :-

java.lang.UnsupportedOperationException: Unknown URI: content://media/external/images/media

First you'll need to create a storage image using the mksdcard from the tools folder of the emulator

mksdcard 10M sdcard.iso

Then when you start the emulator you need to pass the -sdcard parameter 

-sdcard /sdcard.iso

In my next post I'll write up how to send this image via MMS

Sending SMS using Android Intents

You've got an Android application and you want to send an email, sms and mms via your application. But you don't want to have to write a whole mail/mms/sms client. Thankfully Android provides a flexible way to forward responsibilities onto other applications installed on the device.

Android uses the concept of intents to enable applications to make requests for other applications to handle their tasks. For example, an application finds your location and wants to send it as a map via MMS. 

This can done by by constructing an Intent object, loading it up with the appropriate action, data and sending off to the operating system. 

Intent sendIntent = new Intent(Intent.ACTION_VIEW);

sendIntent.setData(Uri.parse("scheme://data"));

sendIntent.setType("mime/type");

sendIntent.putExtra("key", "value");

startActivity(sendIntent); 

Android then decides which activity can best handle this intent based on various attributes such as scheme (mailto, http) and mime type (image/png). 

If multiple applications could handle the intent (if you're sending an image), then you can even prompt the user to choose which application they want to use (email,MMS, IM)

startActivity(Intent.createChooser(sendIntent, "Title: ");

This all sounds too easy to be true. And it is. The reality is that in order to invoke mail,sms and mms I have needed to dive into the Android source code (thank goodness for Open Source!). I wanted to invoke each of these applications, filling in as much of the content as possible. The documentation for Intents even suggests this is possible to attach images, set subjects and body text. 

To invoke the SMS application via intents you have to do the following:

• Set the action to ACTION_VIEW
• Set the mime type to vnd.android-dir/mms-sms
• Optionally add any text by adding an extra String with the key sms_body 

Intent sendIntent = new Intent(Intent.ACTION_VIEW);

sendIntent.putExtra("sms_body", "The SMS text"); 

sendIntent.setType("vnd.android-dir/mms-sms");

startActivity(sendIntent);   

Android also enables you to send SMS directly using an API without bringing up the SMS application. However it is much more transparent to the user to allow them to see what they are sending and maybe add or edit before it goes out. Using Intents also means you can minimise the permissions your application requires.

Sending MMS and email is a much longer story which I'll get into in some later posts.  Stay tuned!

Android is listening but still has a way to go

Thank you Google for listening when we told you what we hated about Android.

The whole platform wasn't initially looking very democratic. Firstly the Market place was loaded with applications from a private selection of developers. After a period of no information, suddenly the market was open to everyone. Well everyone who could get access to a physical device.

If you live in the US and you're prepared to sign up to a two year contract with T-Mobile, then you could test your application on a physical device (as you should) and you could view the Market Place. Everyone else could only develop with the emulator and hope for the best when releasing it to the Market Place. Even worse, most developers could not see what other applications were already out there. Maybe that application already existed, maybe with the same name!

Ignoring this potential for conflict, once the app is out in the Market Place, developers can see the rating and the number of comments. What they can't see is the content of the comments (although from what I'm told the content is mostly of a youtube level anyway).

On top of all this, developers have also had to contend with a very buggy interface that sometimes showed incorrect download counts and reset everything when uploading an update.

Thankfully, Google are listening. This past weekend Google started offering unlocked devices for $399 to developers worldwide. I've even noticed the Market Place statistics are a lot more stable. What is really missing now is being able to view the Market Place on the web outside of a T-Mobile device. Hopefully this, along with the ability to charge for apps will be their next move in early Jan 2009.

Becoming Micro Social

Anyone wants to go for lunch?

How would you use your social networks to find out who is around and wants to come along for lunch right now? Would you twitter or would you ask your Facebook friends?

Venus vs Mars Social Network

Someone told me a while ago that Facebook is the feminine social network and Twitter is the masculine social network. Why? Because Facebook is rather closed and personal where friends are known and trusted (hmm). Twitter is more a leader-follower platform where you can follow your micro tribe leader or become one yourself. Makes kind of sense to me - I prefer Twitter and I am male.

Address Book vs Networks

Facebook and LinkedIn are great tools to manage large networks of contacts that grow organically. One thing that really becomes more and more a problem is that the Address Book on the mobile phone does not reflect the contacts in our social network sites. It seems like most social network sites like to import our contact list (e.g. from Google).

Who controls your contacts?

I feel in total control of my contact list that lives on my mobile phone. Who is in control of my contacts on Facebook & Co? I guess it's me too. I personally feel still more comfortable with the phone list.

Power to the user!

I would like to state here that I want to use my contact list on my mobile phone as the basis for my next social network. So the contacts stay with me and I have complete control and privacy about who I know. No, I am not paranoid - I am just annoyed that more and more people give away the control over their address book. They give it to the large social network sites. I believe it belongs to the user!

Micro Social Networks based on your Address Book

Last week we had a great discussion at jTribe based around the problem "Anyone wants to go for lunch?". We would like to build a social application for iPhone and Android that can be used to help answering the question of "who is around and what are they doing". One thing was clear straight from the beginning: We don't want to create Yet Another Social Network Website like BrightKite. 

We basically have these three constraints:

1. Not another Social Network Site
2. Works on iPhone and Android
3. The Social Network will only need to exist for a limited time

Sometimes it is great to work under constraints because it forces your mind to think differently and to follow avenues you would not have thought of before. The solution for our problem was so simple.

Use the Address Book on the mobile phone as the basis for a Micro Social Network. 

Some theory

Some articles define Micro Social Networks as networks with special interest. We want to use the word Micro in Micro Social Network as something that describes the limited scope of the social network that is established in an ad-hoc manner from a small subset of contacts in your address book (that's a mouth full. Nano Social Network would be another option to name this baby). So basically, I have an intention right now and would like to know which friends would react to this intention. In our case it is the intention of having lunch with friends. This intention has only a limited time span. To organise a spontaneous lunch I would only need 1 hr. Within that hour I could establish a micro social network which would cease once we meet for lunch. During that time any contact in the micro social network can invite any of their contacts. Any participant in the micro social network can add any participant to their address book. This provides an easy way to add a friend of a friend to the address book.  

What's next?

jTribe is going to develop social mobile device applications that allows a user to establish tiny social networks on the fly to address the challenges that mobile social people have right here and right now. Our first concept application is now running on Android. The iPhone version is following soon. 

Anyone who wants to get involved is welcome!

Related articles:

• Micro Social Networks will explode in 2007
• The Micro Thread to Big Social Networks

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).

jTribe has released the forth iPhone app

We were pretty busy over last couple of weeks to release some iPhone apps. We are happy with the progress and the fact that met all our timelines and milestones (thanks to trac).

After the second app in the AppStore the process has been much smoother. Building and submitting a new iPhone app is now so easy compared to the painful experience of the first app. We actually ate our own dog food following Our top five tips for iPhone and Android developers.

Currently we got two apps in the navigation category and two in the entertainment and lifestyle category.

The most popular app is still Firepin Trip Tracker , the free GPS tracking app.

Our first paid app is PinPoint, a simple location sharing app. We spend most of the time making the email formatting look nice. This was a major challenge because the email app on the iPhone required us to go the extra mile to embed images.

The other two apps are in the entertainment category and we developed them originally to test the consumer behaviour in the AppStore. We learned the most astonishing things about consumer behaviour worth to put in a separate blog entry soon.

Ok, this was brief update around our latest iPhone development activities.

Other things that happend at jTtribe this week were the fact that our Android app statistics came back (Daniel, you should write about that).

And we worked on the Application Definition Statement of our next iPhone/Android app. I am so excited to write about it soon.

JSON and RESTful web services on the iPhone

We use JSON on the iPhone to access RESTful services on the Internet.

JSON seems to be the dominant and easiest way to use web services over the Internet. 

We used it in our native iPhone app (PinPoint) to integrate with Googles Geo Location APIs. Fortunately, Google supports JSON and XML. I have chosen to use JSON over XML for no particular reason other then "want to play".

 

What kind of app do you have?

1. A web-based  app that runs on Safari
   
2. A native iPhone app that uses Objective-C and Cocoa.
   

Both flavours of JSON-iPhone integration are covered in this blog entry.

1. A web-based  app that runs on Safari

JSON form web apps based on WebKit / Dashcode

The first iPhone JSON integration I did was for a web app that I developed with Dashcode. The app required only the list of trips from our Rails app. No associations or nested objects were required. The JSON response was an array of simple objects. This list was displayed as a typical table view and tapping an item opened the detailed view without making another http request. 

This exercise was surprisingly simple because I could deal with well-known technology (JavaScript, HTMP, CSS, DOM, AJAX).

2. A native iPhone app that uses Objective-C and Cocoa.

JSON using Objective-C / Cocoa / XCode

I have to admit this is not as nice as for the web app using WebKit/Javascript. Not really a surprise since JSON is actually a serialiseed JavaScript object and no mapping is required.

Using JSON in Objective-C / Cocoa is less natural. The Objective-C / JSON framework I used does return the JSON structure mainly as a NSDictionary and NSArray.

If you are using the JSON framework with the iPhone SDK 2.2 then check out this article.

I used JSON to get Geocoding data from Google. The Google JSON API was actually not documented at the time I developed my app, which made it a bit more exciting. The JSON structure that is returned by Google is a mix of nested objects and arrays. I would say that the Google Geo location API returns a pretty complex but well structured data structure.

The JSON framework  for Objective-C does all the hard work of mapping the JSON structure into Cocoa data structures (NSDictionary and NSArray). Now that the data is in Objective-C object my code needed to access the parts I am interested in. The code needs to be aware of the returned JSON structure and that is where I feel things become a bit hardcoded. I needed to access parts of the NSDictionary objects that where pretty nested and had to traverse the tree through pretty long statements.

Show me the code:

Here is a simple example that shows how I get the JSON data for a reverse geo coding call to Google. The exampled will get the address string from the JSON structure.

NSString *jsonRep    = [[NSString alloc]        
      initWithData:data  encoding:NSUTF8StringEncoding];  

NSLog(@"Got this form JSON");

NSLog(jsonRep);

NSDictionary *dir = [jsonRep JSONValue];

NSArray *arrPlacemarks = [dir valueForKey:@"Placemark"];

NSDictionary *dirPlacemark0 = [arrPlacemarks objectAtIndex:0];

NSString *address = [dirPlacemark0 valueForKey:@"address"];

NSLog(address);

The code to get the more granular part out of the Geo location  JSON string is not that simple but in principle the same approach.  

1. You need to know where the particulare information resided in the JSON strucutre.

2. Navigate the structure to the particular NSDirectory or NSArray and get it.

What could break:

As soon as Google changes their API I am sure my app will break. The above approach will not survive any serious schema changes. As soon as Google changes the nesting of objets in their JSON response I will need to modify my code. 

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?

1. If in doubt do not use standard buttons (especially the ambiguous action button)
2. Cater for rejection in your development time table
3. It's good to know that Apple takes reviewing the app seriously

iPhone development for Rails and Web 2.0 developers

Interestingly, many of the new iPhone developers seem to come from a Rails / Web 2.0 background. I am one of those guys who did Rails projects and now is sitting in front of XCode doing iPhone development.

I really like developing in Rails and appreciate it's simplicity and elegance. So here I am, I went through the process of morphing from Ruby on Rails to Objective-C/Cocoa.

Are there any techniques and skills I could transfer from Rails to iPhone development?

1. Model-View-Controller (MVC) pattern
   MVC is the key pattern in COCOA. So, great there is one thing you would understand already when playing around with iPhone development.
2. Asynchronous UI on iPhone / AJAX on web 2.0
   AJAX-based web apps are great. If you have used AJAX and tried to understand the structure of how AJAX is used to make web 2.0 apps simple then you will be in a good position to make it "simple on the outside and complex on the inside". Cocoa on the iPhone can get information asynchronously from any web source. Check out NSURLRequest in asynchronous mode.
   
3. Database on iPhone
   There is SQLite support on the iPhone. Great if you are planning to build a self-contained app that needs to manage some data locally on the iPhone. I have found that I have less need for a database on the iPhone. The way we build our iPhone applications are mostly using the User Preferences locally on the iPhone to persist any UI state. The heavy lifting in terms of Data Storage is done on Rails-based applications and I integrate both through RESTful APIs. If you need SQLite in your iPhone app then you might want to look into Schema Migration support for the SQLite library FMDB
4. RESTful
   I like to keep the iPhone app lean and this is why I make good use of REST. The iPhone app is my REST client and our Rails applications offers the RESRful APIs. We integrate both through the RESTful APIs using a JSON framework for the iPhone. Actually, in some cases we use a simple POT (Plain Old Text) approach to transfer simple atomic text data from the Rails application and database to the iPhone front-end. This approach has proven as highly successful due to it's simplicity. (I hope I can find some time to post some receipes soon)
   
5. Metaprogramming on the iPhone?
   If you have used Metaprogramming in Ruby before you will have some benefits when you work with Objective-C/COCOA but I haven't seen as much use of it. Objective-C does support dynamic typing and you can send any object any message and decide during runtime what to do with it. You will come across a method called respondsToSelector that can check whether an object can respond to a particular method call. I am just starting to realise what can be done in Objective-C in terms of Metaprogramming. Not a much as in Ruby but better than C++.
6. Test-Driven-Development (TDD) or Behavior-Driven-Development (BDD):
   Sorry, not a lot of support on the iPhone for TDD or BDD. Unit testing and RSpec are not available. Considering how many Rails developers are also playing around with the iPhone SDK I am certain that there will be tools soon that will support TDD/BDD for the iPhone. So, how do you do proper testing? I will need to dedicate a separate blog entry to that topic. Stay tuned. (There are some tools that let you use Ruby to run test and migrations for iPhone code.)
7. Delegation Pattern:
   I found the Delegation Pattern the most powerful pattern for iPhone development. Delegates are used everywhere in the Cocoa framework. I started to use it heavily to realise notifications between different controllers via protocols. Take some time to get comfortable with it. It will make things so much easier when you develop a more complex iPhone app. Check the Apple Developer Documentation. Check out this nicely written article abut the different ways of listening, observing and notifying in Cocoa
   

I hope I can find some time to post some of the architecture decisions we made along the way as we developed some pretty complex iPhone apps with various integration points.

Releasing an iPhone app to the AppStore - Dillema

The rush on the AppStore is on. More than 5,500 app are already in the AppStore. iPhone developers are in a race to get their app in before some one else releases a similar one.

So far I heard everyone saying "You need to be the first one to releases a new app".
I am not sure about that any more. Maybe it's better to be a fast follower?

The Dilemma :
1. Let someone else get the credit first
2. Let someone else get it wrong first

Obviously each iPhone developer fears scenario #1 (Someone else is getting the credit first).
But to get credit and good reviews the app needs to be "really" awesome. A app that is kind of half-baked wont get you any credit but will put you in scenario #2 (get it wrong first).

So what to do? We at jTribe decided to stick to some key principles about releasing an iPhone app and not to focus on the Dilemma mentioned above:

Our top three iPhone application release principles:

1. Don't release in a rush.
2. Let the app mature.
   Keep a development version of the app on your iPhone for a couple of days without using it. Then use it and you will see the flaws of your app straight away. Fix the flaws and maybe go through another maturity cycle.
3. Stick to your original app design.
   The longer I spend in developing an app the more I get carried away and invent new features. Adding more features along the way is great fun and I usually learn heaps about the iPhone SDK. However, more feature usually remove me from my original app design goals. As hard as it is, I found myself actually removing feature before the app is submitted to the Apple AppStore.

Must read reviews of Android and iPhone

Here are two blog entries I found very useful.

An Android G1 review looking at many facets of the phone:

http://arstechnica.com/reviews/hardware/android-g1-review.ars

An here is good review of the iPhone and its SDK:

http://www.urbanspoon.com/blog/34/iPhone-SDK-The-Review.html

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.

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. ;-)

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!