Native or Web? Or Both? Apps are short for “Applications” and are essentially software programs that can be used to perform a specific function on your mobile device. Apps are actually becoming more important than the devices themselves. While the devices will have a limited shelf life, your App and your personal data associated with that App will continue to exist and evolve for much longer and on multiple platforms if you so choose. The Apple App store as part of iTunes was the surprise story of 2008, becoming one of the biggest successes in mobile history. In fact, all of the other major mobile platforms have copied this App store model. The biggest difference between mobile web apps and native apps today from a development perspective is that native apps can require development for multiple platforms whereas mobile web apps can require support for many browsers. The bottom line is that native apps vs. web apps is not really a debate. There is no winner and there is no loser. The choice of what to develop is an engineering and a design decision that should be based on a solid set of requirements. Think about your users and where you want to distribute your content. Mobile is bigger than just apps! Native AppsDefinitionWhat is a “native” App? A native App is an application specifically designed to run on a device’s operating system and machine firmware. It typically needs to be programmed in a unique or proprietary language and development environment for each platform or operating system. The terms platform and operating system are often used interchangeably in the mobile industry. Deloitte estimates the cost of developing for two OSs is 160 percent of the cost of developing for one. (Source). A native App is so much more than just the look and the feel. Many things matter, including the way that data is stored on the mobile. In a native App, most of the Application is stored locally on the device, but the user data may be stored on the device, in the cloud (remotely), or both.
When to Develop
Platforms & Operating SystemsSometimes the term, "platform" has been used rather loosely in the mobile world and this causes some confusion because there are such things as "development platforms". For the sake of consistency, when we refer to platforms we are referring to the operating system. Currently, in the desktop world, we primarily have to deal with different variants of Windows, Mac, and Linux. In the mobile world, we have to target many more if we are looking to develop a native application. Developing for each native platform requires a specialized development approach, often coupled with an integrated development environment (IDE) or software development kit (SDK). This list below is not all inclusive, but provides links to download several IDEs and SDKs used to develop mobile Apps natively for each platform:
In terms of developing for Native Applications, there are so many Software Development Kits (SDKs) to choose from. This list is not all inclusive, but will give you an idea of how complicated it can be to try to develop for multiple platforms using multiple SDKs. While some of these do support limited cross-platform deployment there is no single SDK that supports every Native platform, but there are a few that come close. App StoresEach mobile device today usually provides direct access to a specific platform App store, but not all App stores are accessible on each platform since they are proprietary and unique to each device’s operating system. For example, iOS Apps packaged for iPhone, iPad, and iPod Touch won’t be discoverable in the Android Market (recently renamed Google play). Each App store has a unique process, file formats, and specific requirements for distribution to their App store. The process of distributing your App to these different App stores for each platform can be very time-consuming and should be considered in your overall distribution strategy. While the Apple process is rigid and time-consuming, I’ve found the Android process to be the quickest. Below is a listing of the primary native App stores available to mobile devices in the United States: Native Apps Pros and ConsPros:
Cons:
Mobile Web AppsDefinitionMobile Web Apps are also referred to as Mobile Rich Internet Applications (RIA). The difference between mobile web app and native apps is anticipated to be less obvious by users in the near future. Modern mobile browsers can now gain direct access to the hardware capabilities of mobile devices (including accelerometers and geo-location).
The performance of browser-based mobile web applications continues to improve. Persistent storage and access to user interface functions (such as the address book) may further reduce the demand for platform-specific native apps. As far as today's mobile web apps are concerned, most of the data is stored in the cloud.
When to Develop
Standards
Widgets
The new concept of mobile widgets offers a great multi-device application platform, including local applications that don't require an always-connected Web with URLs and browsers. A widget is a local HTML / CSS / JavaScript web application. A mobile phone user downloads a widget once, and then the web application is stored locally on their mobile phone.
WAC
Mobile Web Pros and ConsPros:
Cons:
FrameworksMobile web app frameworks are easing the development process for those interested in the mobile web app approach. These frameworks allow mobile web apps to look and feel and function like native apps. They are typically available as configurable open source frameworks that you can download and begin working with by using pre-existing templates and themes. They provide anyone the ability to edit the existing files and are developed using web standards (HTML, CSS, JavaScript); the more recent ones support HTML5.
Some of these frameworks include APIs and some offer additional commercial tools or publishing capabilities for packaging the content as a native app. If you only care about targeting the newer smartphone touch devices or mobile devices that support HTML5, then this is a cost-effective alternative to native app development.
Progressive EnhancementPrior to the last few years, web development best practices embraced the concept of graceful degradation of content to support the lowest common denominator. A common theme and best practice these days in mobile web development is progressive enhancement . Graceful degradation dates back to 1994 with respect to the web. The basic idea behind graceful degradation is that so long as less capable browsers can handle documents containing newer technologies and still view basic information and/or functionality, then everything is fine. In recent years, though, this has come to mean producing only one version of the web content without designing in support for less capable browsers. In years past, most thought that the modern desktop browsers would always be what people used, but with the ubiquity of browsers on mobile devices this is no longer true. In a nutshell: when developing any web content, you should start with the basic technology supported and then only provide enhanced features as an option if they user’s browser supports it. This approach is called progressive enhancement. Both graceful degradation and progressive enhancement consider how well a site works in a variety of browsers on a variety of devices. The key is where they place their focus and how this affects workflow. The graceful degradation technique is not useful for mobile browsers because there are serious compatibility issues in the mobile world. If we develop mobile content for the latest device (for example, the iPhone’s safari webkit browser), it may not automatically work on other, less advanced devices. Below is a table showing the key differences between the two approaches and why progressive enhancement is important when developing mobile content.
Device Detection/Content AdaptationProgressive enhancement is a good place to start for mobile content development, but one size doesn’t necessarily fit all. Device detection is used mostly today in situations where the mobile design wasn’t considered first and/or where progressive enhancement isn't possible without a costly rework of the website or web application. For example, a website that was asked to be converted to support mobile might be more quickly accomplished by creating a smaller, stand-alone version. There are several situations where the content will need to be adapted for a specific browser or deliver a specific file time (e.g. video) using device detection. The main problem with this approach is that it can sometimes present a real challenge in terms of life cycle maintenance. Below are some tools that can be leveraged for implementing a content adaptation strategy for your mobile content: WURFL
Terra-WURFL
Device Atlas
DetectMobileBrowsers.mobi
Device Detection/Content Adaptation ExamplesUniversity of Alabama
 |
Development Options |