CodeMorphic at MinneWebCon 2010

Mobile Apps
Native, Web, or Both?

Bill Heyman
CodeMorphic, Inc.

Tuesday, May 11, 2010

Smartphones 2010
Two major players in Smartphone market
support state-of-the-art web standards:


iPhone
• Arrived 2007
• 3 models (iPhone, iPod touch, iPad)
• Tied to a single US carrier (AT&T)
• Installed base 85M (includes iPod touch)
• Almost 200K apps available
• Tightly controlled

Android
• Arrived 2008
• 25 different phones (plus other devices)
• All major US carriers
• Installed base of 8M and increasing
• Heading toward 50K apps
• Generally open, loosely controlled

Web Commonality
WebKit-based browser
As of Android OS 2.0, both iPhone and Android
support new web standard and HTML5 features,
such as:

<video> local database

geolocation canvas
<audio>
ofﬂine app caching transitions


App Spectrum

Web

Uses web standard technologies:

HTML, CSS, JavaScript


App Spectrum

Web Native

Uses tools & compiled languages that are
targeted for the device.


App Spectrum

Web Hybrid Native

Combines Web and Native technologies.

Generally, the web technologies are
wrapped by a native shell.


Hybrid Apps ~ Native

Hybrid Native

• Packaged in a Native App shell
• Installed like Native Apps
• Distributed like Native Apps
But developed with non-native technologies.

App Spectrum

Web Hybrid Native


Web Web Apps

Two types of mobile web apps:
1. Traditional
2. Ofﬂine


Web Traditional Web

1. Thin-client apps (mobile browser-based)
2. Require a persistent Internet connection
3. Processing and persistence mostly on the
server-side (PHP, Python, Ruby, ...)


Web Ofﬂine Web
1. Thicker-clients (mobile browser-based)
2. No persistent Internet connection
required
3. App web pages are stored on device; user
can quickly reference via a bookmark
4. Makes use of HTML5:
• application cache (manifest)
• local database

Native Native Apps

1. Thick-client apps
2. Developed in standard
development
XCode Eclipse
languages, as deﬁned
by the platform C/C++ Java/JVM
Objective-C


Native Native Apps

3. May include an in-app
web browser.
(Custom formatting)
4. The web browser
doesn’t have to use
the full screen. UIWebView WebView
(Custom control)


Native Native Apps

5. Direct access to the native capabilities
of the device...

accelerometer ﬁle system
camera
audio recording graphics

as limited by the device provider


Native Native Apps

6. May be distributed as an application and
marketed through the App Store or
Market

as limited by the device provider


Hybrid Hybrid Apps

1. Thick Client Apps
2. Use Native wrappers as an app package
3. Provide an in-app web browser to display
Web content to the user (HTML, CSS,
JavaScript)


Hybrid Hybrid Apps

Some Web hybrid wrapper frameworks include:

Appcelerator
PhoneGap
Titanium
Both give access via JavaScript to some device features,
previously reserved for Native apps.

PhoneGap

http://phonegap.com
FOSS framework
minimalist philosophy
easy to use: put ﬁles in the www folder


Hybrid Hybrid Aps

Some Web hybrid wrapper frameworks include:

Appcelerator
PhoneGap
Titanium


Appcelerator
Titanium
http://appcelerator.com
Commercial open source framework
not necessarily “free as in beer”
extensive JavaScript libraries
AIR-like: supports desktop, too...


Hybrid Hybrid Apps

Some Non-Web hybrid wrapper frameworks include:

Adobe AIR Unity rhomobile
Flash

MonoTouch Corona
MonoDroid

Hybrid The Good
1. Quicker learning curve, can re-use your
existing skills
2. Easier to target apps for both iPhone and
Android
3. Use existing HTML/CSS/JavaScript tools
for development and testing


Hybrid The Bad

1. Slower performance (compared to Native)
2. App doesn’t quite feel right, sluggish, non-
responsive
3. Some device features may not be available
or not quite as accessible


Hybrid The Ugly

The Elephant in the Corner of the Room

What’s with the
elephant?
• Apple’s iPhone OS is closed & restrictive
• API, device feature usage is limited
• Restrictive NDAs required to develop on
unreleased software
• App distribution is controlled by Apple
• If Apple doesn’t like your app...
Sorry, Charlie!

Bad Apple
Apple sets the rules...
... and can change the rules at any time!

Like, just last week:

te d
3.3.1 — Applications may only use Documented APIs in the

c
manner prescribed by Apple and must not use or call any

da
private APIs. Applications must be originally written in

e
Objective-C, C, C++, or JavaScript as executed by the

R
iPhone OS WebKit engine, and only code written in C, C++,
and Objective-C may compile and directly link against the
Documented APIs (e.g., Applications that link to
Documented APIs through an intermediary translation or
compatibility layer or tool are prohibited).


Section 3.3.1

Adobe AIR Unity rhomobile
Flash

MonoTouch Corona
MonoDroid


Section 3.3.1

??
PhoneGap
Appcelerator
Titanium


Why?

As a developer, why put up with
Apple’s restrictions?
• Market: 85M devices (10x Android)
• App Store Exposure
• Large Market = Great Potential $$$
Apple’s restrictions do not apply to pure Web
applications (traditional and ofﬂine)

A few words on
• Android provides access to more device
features than iPhone.
• You choose how to distribute your app:
• Via Google Market
• Via your own mechanism (web site)
• Android drawback:
Plethora of devices and device capabilities,
screen sizes, resolutions, etc.

What to do?
1. Style your Web site using mobile-speciﬁc
proportions and style sheets.
2. Consider if there are portions of your Web
site that could be useful ofﬂine for mobile
users.
3. Best bets for Hybrid packaging: PhoneGap
and Appcelerator Titanium
4. Determine if a user may be better served
with a Native app.

Looking toward 2011
• More WebKit technologies:
• WebGL
• SVG
• Android market penetration increasing
quickly.
• Another major player?
7

Thank You!
For mobile app development questions,
please contact me at:

Bill Heyman
@byteCoder
bill@codemorphic.com


CodeMorphic at MinneWebCon 2010

More Related Content

Similar to CodeMorphic at MinneWebCon 2010 (20)

Recently uploaded (20)

CodeMorphic at MinneWebCon 2010