Deciding on a comprehensive mobile strategy

Question

I have an idea for a mobile application (initially targeting iPhone but would like to target others in the future) and am trying to decide the best way to package/sell the product. For lack of a better term, the app would be a "platform" that potential clients could use to create their own branded application. There will be a server-side portion of the app but I'm mainly concerned about the client-side. The possible scenarios I see are:

1. Multiple native apps, one for each client (e.g. iClient1, iClient2, etc...)
2. Single native app (e.g. iGenericApp).
3. Just make it a web app.

From a marketing/business perspective, I believe the app would only be successful if each client ends up with a branded application in the app store with its own name and home page icon (Situation #1). From a technical standpoint, this obviously is a maintenance nightmare as any update to the native application would require updates to all of the applications.

Clients who would purchases the application would not be technical, so I would want to release the app under my iPhone Dev account, shielding them from that process and the $99/year fee. I assume I would come up with some revenue sharing agreement with the client when it came to download revenue (more overhead as I would have to distribute app download proceeds). This setup would also mean I would be responsible for doing any application updates to the app store.

Situation #2 is a little more attractive in that updates are a lot easier. But again, I don't think clients would want an app that wasn't (entirely) their brand, even if I could pull down some branding assets from the server-side. It also opens up the possibility that Joe User buys the app from the app store, thinking he can use it to access info from a client who hasn't bought rights to the app.

Situation #3 is obviously the most flexible, but again, I think clients would want to be in the app store. I also think the user experience would be better in a native application (I realize I could use something like iui), and the native application wouldn't be too difficult to port to other platforms as needed. It's also convenient to have the app store(s) take care of collecting money from the end-user. I also realize I could just make a native shell application that uses UIWebView to access the web app, but again, I just think a native app is going to provide a better user experience.

So I am leaning towards scenario #1, realizing that if the app takes off (counting my chickens before they're hatched :) ), I'm going to spend more time maintaining apps in the app store than adding value to the application.

To finally get to my question, has anyone implemented solution #1 before and if so what did you do to reduce maintenance overhead (e.g. automating builds, testing, etc...)? Also, is there a limit to the number of apps you can upload to the app store under one account?

Answer 1

I am currently working on an app which should eventually have several versions dealing with different data so here is my take on your problem.

Most apps that use a UIWebView to display a web app are bad because they don't look iphone-esque and they don't work offline. Neither of these have to be the case. You can use dashcode to make a webapp look perfect and the apps can cache bits to work fine offline. Look at apple's http://help.apple.com/iphone/3/mobile/ on your iphone for an example (it works offline and looks like a native app).

Whatever you do it might be best to keep the most complicated stuff server-side. That way if you test the original app thoroughly enough you should never have to update it though the app store. All your updates could be done server-side to code shared by all your projects.

If you do chose to make it mainly a native app try to keep as many as possible of the .h and .m files generic and put much the project-specific data into plist and other data files. This way when you update multiple projects all you have to do is overwrite code files in all the projects rather than having to open each one and paste in code-alterations.

Hope this helps.

Answer 2

Don't forget to check out cross platform frameworks.