Mobile Web (Hybrid) Apps Versus Native Applications

1. Mobile Web (Hybrid) Apps Versus Native Applications Shatin 沙田

2. Native vs Mobile Web vs Hybrid • Native: • Writing code with for specific platform • Use all features provided by platforms • One Programming Languages • Code ONLY for that platforms • Android – Java • iOS – Objective C • Windows Phone – C++/C# • Mobile Web: • Cross-platform • Limited features • Offline Problems • Hybrid: • Mobile + Native = Some native powers + Web flexibility

3. The Ubiquity Principle • Why mobile web is the only long-term commercially? • Fragmentation • (iOS,Android,WP, BB10, FFOS, TIZEN, Ubuntu OS) • The Web • Control • (HTML Syntax, Javascript) • Consumer expectations • (Widely Used by Users on Desktop Computer)

4. The Ubiquity Principle - Fragmentation • No one vendor able to firmly claim itself king • Getting your application on one platform is a snap • Getting it on two is challenge

5. The Ubiquity Principle – The Web • Web is a highly vetted consumer medium • Web offer many pros and few cons • Only medium for information, applications and services • As more mobile browsers add services to detect location, acceleration or use of the hardware, the need for native applications will be reduced

6. The Ubiquity Principle – Control • Control the mobile application distribution • Mobile application vendors always have to rely on middlemen to get their products to market • The purpose of the product is to service them • Funding of creating mobile applications will always remain a small, high-risk investment

7. The Ubiquity Principle – Consumer Expectations • Consumer expect applications just work and rightfully • Fail to do this is not only a sale lost, but also customer is lost for good • Consumer spends money on device and wants content to support it • Cross-platform support is challenging • Numerous visits occur when a consumer has purchased a brand-new device, but will drop off later

8. The Ubiquity Principle – Ubiquity in the Mobile Web • Mobile Web is the only platform that is available and works across all mobile devices • Sharing the same set of standards and protocols • Mobile web is the easier platform to learn and the cheapest to produce, the most standardized, most available and the easiest to distribute • Level of complexity to adapt to the fragmentation is lower

9. Key features to consider for creating a native application • Charging for it • Creating a Game • Using specific locations • Using Cameras • Using Accelerometers • Accessing the Filesystems • Offline Users • Push Notification • Background Task

10. Charging for it • Charging for things on mobile devices has come down to two obstacles: • Enter a credit card number, need to store the subscribers’ credit card information on a secure website • By the device maker, they will collect the payment and cut and pass on the rest of it to you. This means that you must work within the rules and regulations of their marketplace

11. Creating a Game • Games are resource-intensive • Almost always require the use of a device or platform API • When users launch a game, they have some expectations of what it is going to look and act like • Some game porting house can help to get your game onto multiple platform, but it is costly

12. Using Specific locations • Detect the users’ locations by GPS • Traditionally, the only way to access users’ locations is through native application APIs • Devices that run WebKit, like iPhone or Android devices that runs the Opera or Mozilla browsers can detect user’s location

13. Using Cameras • Traditionally, mobile MMS is used to handle mobile photo interaction • The MMS server somewhere does something with the photo and sends an alert to you, which is complicated, time consuming and fairly unreliable • Native application developers can simplify the task to just taking a photo from within an application • Through HTTP connection to transfer photo • Use for sharing snapshots or videos of friends • Used to process bar codes and to redeem promotions

14. Using Accelerometers • An simple application that measures physical acceleration and gravity and send data back to the device • Detect the device physically rotated, adjusting the display from vertical to horizontal orientation • Use the accelerometer to interact with a device in a more natural way

15. Accessing the Filesystems • Use the data store on the device • Such as address book, photos, and email message, or data from another application • Store information only in limited doses • Never do anything with the users’ data without their express permission

16. Offline Users • Develop the native application when the user is likely to be offline or out of range of a mobile network • Mobile games played on an airplane • Mobile browsers that support HTML5 actually include the capability to create offline apps

17. Notification & Background • Receive Notification like instant message • Continuous update in background – GPS Tracking, Update Stock Market Data

18. Hybrid App to Fill the Gap • Line up Native Power + Web Flexibility • Wrap an WebApp (store offline) as Native App • Content Update by Ajax • Communicate with JavaScript between native code and web code • PhoneGap project, an open source effort that allows you to create native applicaions for iPhone, Android and BlackBerry devices

19. When to make a mobile Application base on Web • Long-term viable platform for mobile content, services and applications • Many device features like location and filesystem access to your web app. • The rate of innovation for creating mobile web apps across every mobile device maker is at its highest level in years • Achieving same standards

20. WebApp is better option when: • We need to update our content frequently • We don’t need any of the Apple/Play Store features • We don’t need especially fast graphic performance • We are not dependent on native functionality • We are not dependent on running our app in the background • We are not dependent on sending(push) notifications

21. Pros of WebApp: • High-level Programming skills are not required • Apple development program subscription is not required • Developing on a Mac running OSX is not required • Web standards skills are reusable in other development areas • Development life cycle is fast • Bug fixing is in real time • An enterprise Web App doesn’t require an enterprise license • A WebApps don’t require Download and Installation • WebApps are accessible to Apple and non-Apple devices • WebApps will run on most device (mobile or desktop) with a browser • WebApps are packable in native app with tools like PhoneGap

22. Cons of WebApp: • In some heavy contexts, WebApps are slower than native apps • Some sophisticated UI effects are difficult to achieve • Data stored in the file systems are not accessible • Some hardware features are not accessible • A personal payment system is required if we want to charge for the app • Push Notification • Background Processing

23. Four different approaches to a WebApp • Level 1: Compatible • Level 2: Optimized • Level 3: Dedicated • Level 4: Native-Like

24. WebApp and Native App: What Makes the difference for the user? • User Interface (UI) • Native – Close to the theme of system • Web – More Flexibility • User Experience (UX) • Native – Usually Faster • Web – Slower • Human Computer Interaction (HCI) • Native – Multitouch, Sensors, NFC • Web – Usually Single Touch, less sensors support