1. iOS Running on iPhone, iPod Touch, iPad and most likely AppleTV
2. Android, running on handsets from Samsung, HTC, Sony Ericsson, Motorola (and many others), and a plethora of Tablets
3. Windows Phone 7 – Running on handsets from Nokia, Samsung, LG, Dell and many others

If you’re a brand manager, and you are considering a mobile strategy, you probably want to ensure that your mobile strategy has the widest reach possible, so will probably want your apps on all of the above. This is possible, but costly.

Allow me to get technical for a moment. iOS is developed in Objective-C, using a Mac, with Tools supplied by Apple. Android is based on a Java Eco System, and Windows Phone 7 is based on a .NET ecosystem.

This may be gobbedlygook to you, but what this means is they are very different, and very little crossover occurs. An app written for iPhone essentially needs to be re-written (at similar levels of effort an cost) for Android, and again for Windows Phone 7.

And at this point we usually get asked a fairly obvious and sensible question

Isn’t there some sort of tool that can publish on multiple platforms?

Here’s the definitive answer to this:

NO. There isn’t

But, this needs elaboration. There are plenty of toolkits out there that claim to offer this. Be careful. If you want to use these you can but the results always end up the same.

I’m cynical about these toolkits for very good reason. This is pretty much the third time around for this kind of thing for me. In the early 90′s there were a slew of toolkits that offered compatibility across X/Windows, Microsoft Windows and Mac OS. In the early 2000s the Eclipse people gave us SWT the “Standard Widget Toolkit”, and in fact, there a few others such as QT or wxWindows I can name.

The one thing that always stood out when they were used was

You could spot them a mile off

Applications written using SWT looked like an SWT application, not a Windows application when running on Windows, and a Mac Application when running on Mac.

These cross platform toolkits always ignored one thing

When you attempt to provide something that runs on many platforms, the best you can hope for is “least common denominator”

So the end result? Consistency – Yes. But consistently bad.
Applications written using cross platform toolkits work consistently bad on all platforms. So you end up with a rubbish application on Windows, rubbish application on X/Windows and, you guessed it, a rubbish application on Mac (or.. a rubbish application on iOS, Android and WP7)

I think this can only get worse on Mobile. The devices are so specific, with a broad range of capabilities. Trying to cross them is just folly. In addition to this, the “good taste” barrier has leapt upwards since the introduction of the iPhone. Imagine giving an “android 2.0″ experience in an iPhone app, or attempting the “iPhone experience” on Android – Neither user will thank you.

And let me get back to the Brands. If you’re a brand manager, your job is to enhance the brand. If you put out something which gives a poor experience on any mobile device you’ve done worse than not releasing – you’ve in fact tarnished the brand. Now if you do that across many mobile platforms, the damage will be multiplied.

So do yourself a favour; If you want quality, and a native experience for your end users there’s only one way to go. Get it developed natively, and avoid the short term savings a cross platform toolkit claims to get you.

You’re reading the tapadoo blog. Did you know that as well as publishing our own applications, we offer iPhone development services and consultancy? If you have an idea, project or something you think we can help you with, please get in touch through our contact page.

@adamkmccarthy

When not writing iPhone apps, tinkering with his mac, and babysitting the mac mini Adam is a keen sailor who has steered some very famous boats indeed. He also races mountain bikes, and is a staunch Munster supporter.

Adam is a Cork man, so I for one am looking forward to the O2 jersey meeting the Vodafone Jersey in the Summer!
Do join me in wishing Adam all the best for his new role.
Dermot.

• Waiter taking orders at a table
• UPS Delivery guy
• Gas man coming to take a reading
• Charity worker – getting sign-ups but also using the multimedia capabilities to show where the donations are going to good work

etc. etc.

Right now, there are three ways to distribute iPhone apps:

1. The App Store – This is designed for general purpose apps that anyone may want to use
2. Enterprise Distribution – This is designed for “in house” only apps. This is where a company wants to supply apps for their staff use only, and not put them on the app store.
3. Ad Hoc Distribution – This is where a developer can distribute the apps privately to a group of people. It is primarily aimed at developers who want to get real-world feedback before really releasing the app through 1 or 2 above

When we consider that some of the app ideas (e.g. the waiter concept) is really an “in house” app. But each of the distribution mechanisms has its drawbacks:

• You may not want to put it in the app store, because it only works with your restaurant management system.
• You’ll not qualify for Enterprise distribution, because Apple restricts this to companies of 500 employees or more
• You could use ad-hoc, but this does take a fair bit of management for the developer. The developer needs to know each and every device id that the app will be installed on (and has a limit of 100 slots per year; which cannot be re-used during the year).

None of these are insurmountable, but they are niggles. Basically, there isn’t a simple way to distribute “private” apps. This is by design; It is a commercial decision by Apple. If there was a way, people would use it to bypass the app store (to avoid the apple cut), so its unlikely to change.

One thing it could lead to is an explosion of “new” software as a service offerings. Consider the “menu ordering” SAAS system; The restaurant signs up online, and enters their menu details. The Menu Ordering App is sold through the app store, and the restaurant simply enters their restaurant id and password when they use the app for the first time. This could work, but its a big education job to explain SAAS to restaurant owners.

I think all of those who want to put iPads into their businesses will find the distribution options confusing and consider it a hinderance.

That’s a challenge for us developers.

You’re reading the tapadoo blog. Did you know that as well as publishing our own applications, we offer iPhone development services and consultancy? If you have an idea, project or something you think we can help you with, please get in touch through our contact page.