Creating a Native iPhone OS Application versus a Web-based Application

    I tend to do some programming both in my job and on the side. So naturally I would probably like to tackle the idea of creating a native iPhone OS Application. With the desire of programming a native iPhone OS application I got to thinking of what type of applications actually warrant the creation of an native iPhone OS application, versus just creating a web-based application. I thought I would explore each option.

    Things to consider with any application:

    • Is the application going to need network connectivity?
    • Is this going to be an application that’s free or is it going to be paid. If it’s paid, how much do I charge?
    • Is this application a game?
    • Is this an application just a front-end to an already existing web-based application?
    • Must the user be connected to the network all the time in order to access this application?
    • Is there an API already present or am I going to have to build one?
    • Is this going to be an internal application only or is this going to be available to anyone?

    Native Application
    Pros:

    • Programming is closer to the hardware.
    • Access to over 30 million iPhone OS based devices.
    • With Over 1.5 Billion applications sold, there is definitely a potential revenue stream available.
    • iPhone OS devices allow for external hardware options.
    • All applications are in a sandbox and can affect the other installed applications.

    Cons:

    • If you come from a web-based programming background, learning a new programming language can be daunting.
    • Currently, no flash support. So any applications that are flash are out.
    • Limitations of the iPhone OS SDK.
    • Possibility that your application may be rejected by Apple.
    • There are now different speeds of iPhone OS devices, therefore application performance may be different based up on the device.

    Web-Based:

    Pros:

    • Data, structure and function of application already exists.
    • Modifying CSS to fit the format of an iPhone OS based devices is easier than building from scratch.
    • If the application needs to be connected in order to function, a web-app may be the answer.
    • All web-based applications will run on the same mobile safari on iPhone OS devices.
    • A web-based application can potentially be the only view into an application, thereby reducing resources needed for development.

    Cons:

    • If the user has to be connected to the web all the time, an iPod touch without Wi-Fi may not be able to use the application.
    • Potentially less exposure due to not being in the iTunes App store.
    • With a web-based application there is more maintenance. You have both the standard web-browser CSS files, along with the iPhone OS optimized css files. to maintain.

    Both Native applications and web-based applications have their pros and cons. Determining which application is best for your situation will take some time. There are definitely some projects that make more sense as a Native application. For instance, let’s say a game like Aurora Feint. Yes, it could definitely be a web-based application easily. But it does not make sense to do so. The game can be played while off-line and not connected to a network.

    Conversely, let’s say you have a manufacturing inventory application that’s changing constantly. It doesn’t necessarily make sense to that the entire application as a native application. It makes more sense as a web-based application, with a potential for an iPhone OS native application front-end.

    It all comes down to your resources and how much time you have to put towards creating an application. If you can dedicate the resources for both an iPhone OS Native application and a web-based application, then why not do both.

    I'm into everything technology related, particularly anything Apple related. I enjoy programming and tend to lean towards server-based technologies over client-based. You can contact me on twitter, via e-mail, or follow me on friendfeed.