1.
Background
There are lots of mobile app development technologies in the
market, which uses deferent approaches. It’s very hard to decide which approach
we should use in a particular project. What are the areas we should focus? How
we gather others experience and adapt it to our company.
2.
Introduction
This post describes out come of a detail research done by
evaluating current mobile development approaches and related technologies used
by the international companies as well as the experiences gathered from the
local companies mobile engineers. In this post I describe how to choose the
best mobile app development approach and related technology platform and what
are the reasons for each and every selection.
There are lots of mobile app development technologies in the
market. When deciding the correct technology for the mobile app you need to have
a clear idea about the use of each technology. When deciding the right
technology you need to concern about the following goals,
1.
User experience
a.
High UI richness
b.
High Performance
2.
Development Cost
a.
License
b.
Training
3.
Development Time
a.
Available resource capabilities
b.
Leaning curve
At the moment most of the time you will not be able to
archive all the goals, most probably you will be able to archive one of the
above mentioned goals.
If you don’t have a clear idea about the approach and the technology,
you will have to pay the price in the long run. For example your goal was to
reduce the cost but you decide the wrong technology, then you will be end up
with expending two or more times than the estimated budget.
3.
Development
Methodologies
There are three major mobile development approaches
1.
Pure HTML5 web sites (write once, run
everywhere)
2.
Hybrid (Cross platform)
3.
Native
Each and every approach has its own advantages and the
disadvantages. Lets look at the each and every approach in derail by evaluating
the related major development technologies available in the market.
3.1
Pure
HTML5 web sites
If you want a mobile solution very quick within a small
budget this is the correct approach for you. But in this approach you will not
able to access any mobile features except the HTML controls, which can access
camera, geo location and local storage for offline work.
In this approach you can archive the concept “write once run
everywhere”. But if you want different design than a desktop, web pages should
be replicate the look and feel of a mobile app. For that you can user
JavaScript frameworks such as jQuery Mobile or Sencha Touch. These frameworks
consist with layouts, navigation patterns and transition animation and etc.
Some times you may need to customize the look and feel of the
web site according to the native UI of each platform. For example iOS style
controls on iOS and android style controls in android.
If you go for platform specific changes your code reuse
percentage will drop to 70%-80%. But keep in mind these are not real apps the
functionality is very limited. For example you can’t access the contacts,
connect to third party hardware, run in background, receive push notifications
and etc.
Most importantly you can’t send the web sites to the app
store or google play store. Though this approach is very easy and cost
effective this have significant limitations.
If the company have web development and the app is really
simple such as web site being ported to mobile this is the best approach and
cost saving will be 70-100% for the second platform.
3.2
Hybrid approach
If your main goal is to reduce the cost this is the best
approach for you.
There are two types of hybrid apps, there are
1.
Web to Native Wrapper Hybrid app
2.
Runtime Hybrid app
3.2.1 Web to Native Wrapper - Hybrid
If you want to run your WEB app in a mobile web browser and
access to more device features you can use wrapper tools to pack you app into a
native container. The wrapper tools usually offer a set of extensions to some
native platform APIs from your web code, enabling you to do what websites can’t
do. This is like a web site without a browser frame but with extra
functionality. These apps can be distributed through app stores.
The most popular wrappers are PhoneGap and Apache Cordova. At
the moment if your teams have HTML/JS skills this is the quickest way to get
the app into the app store.
The standard web-view used by the cordova to display your
web-app on the mobile device considerably different form the native browser.
Most of the time they are slower than the native web browser. It lacks
JIT-compilation, making your app packed JS much slower than the browser
versions or the native code. Slow down is noticeable in most aspect of UI, from
the response time to touch gesture to smoothness of screen transitions and
animations.
For iOS the Cordova uses UIWebView this is slower than the
new safari web kit. Apple has come up with a new web view call WKWebView but at
the moment Cordova has not officially updated the standard web view to new web
view due to some reasons they have faced with iOS 8.
The other problem you will face is related to JavaScript and
memory use. It needs a lot of memory when JS-Heavy frameworks like Sencha Touch
render your UI. So the longer the user stays in the app and uses it, the more
memory it’s going to take, up to the point when the OS kills your app. This
will not happen to a light weight app this will happen for large applications
such as social networking or business applications with lots of controls, data
and transitions.
These type hybrid apps are slow. They are slow to load data,
slow to process it, and even slower to respond to touch gestures. Hybrids also
don’t feel like proper native apps, which often irritates users.
If you’re considering going HTML5/JS for your project, the
best approach is to delivering the app through the browser or developing a
simple by using the maximum amount of static HTML5 and adding JS only where
necessary. Your code will run faster and users will likely be less critical and
more forgiving.
“The biggest mistake we made as a company was betting too
much on HTML5 as opposed to native. It just wasn’t ready.”
Mark Zuckerberg,
Founder and CEO of Facebook
When we taking about the most of the companies experience in
developing this king of hybrid approach its best for simple, single-screen
apps, with minimum transitions and logic, where low performance is difficult to
notice. And their recordation is not try doing something more complex or
optimizing app performance because it will simply eliminate the cross-platform
benefits and the budget will be nearly same as pure native app.
3.2.2
Runtime Hybrid
app
These types of app are not warped with a container; they are
compiled into native runtimes. The performances of these types of apps are nearly
similar to native apps. You get the native UI, most of the native API’s and the
native performance.
At the moment there are two major competitors in the market.
1.
Appcelerator
Titanium
With Titanium app you can build fully native UI with java
script. A carefully written Titanium app may offer UI performance comparable to
that of native app, but its still driven by the JavaScript and its fundamental
technical limitations. Its make the app’s business logic slower than it can be.
In complex apps the user may see this effect as delays in screens transitions,
while your JS code is loading or parsing data.
The development teams has a learning curve though the app is
written by JS because it much closer to native app, the team need to have some
knowledge of the native platforms as well. The team will have to use
platform-targeted code.
This is decent platform, which provide native UI, but since
it is built on JS there is performance issue. This performance is greater than
the wrapper technologies and the less than the native apps.
If we develop an app with several screens and minimum
business logic this the best approach but if we add more and more it will make
performance issues. So if you optimize the app to increase the performance the
cost will be nearly same as building a native app because you have to optimize
it for each platform.
2.
Xamarin
As we discussed there is a performance issue due to use of
JS. But Xamarin has go one-step further using C# and .NET instead of JS. With
Xamarin you can modularized your code. You can separate platform specific UI
code from the high level parts like business logic, data model and server
integrations.
The shared code is then written just once with full reuse for
all supported platforms, while all the native features are implemented via
calls to native UI and the APIs independently. Xamarin provides a set of C#
bindings covering 100 percent of the native APIs. The apps build using this
technology is full capable of what a native app can does. For example work in
background, connect to external hardware and etc.
The .NET code is compiled in to the native binaries for iOS
and Android. And the code is easily ported to windows mobile.
The problem with the Xamarin the binaries slightly larger
than the pure native ones, because of that the lunchtime get increased, but
after fully loaded it runs much faster that JS bases app. The performance of
Xamarin apps is indistinguishable from native.
The other problem is you have face is you need to do
non-trivial memory management. Because the garbage collector works a bit
differently from the typical .NET environment. But Xamarin offers a good set of
best practices for memory and performance. Follow them from the start and
you’ll be safe.
If your have mobile development resources familiar with in
.NET this is the right technology for you.
When you need maximum flexibility, performance, access to
hardware, platform capabilities, or if your app is simply huge and complex, the
best technology is Xamarin. It’s perfect for business applications with large
amounts of logic, server-interaction and data-oriented code, and should give
you around 40-60 percent of code reuse.
3.3
Native approach
If your goal is higher user experiences, which are optimum
performance, high UI richness and smoothness; this is the correct approach for
you. Because the native development technologies are optimizes for each
specific platform. (Xcode for iOS, Eclipse for Android, VS for Windows Mobile).
There for you can get the maximum possible capabilities of the mobile OS.
If you are after the best possible reliability, quality, and
performance, or simply want to start with just one platform this is the right
technology for you. It may cost you a bit more, but you’ll know what to expect
and exactly what you’re paying for.
4.
Why mobile
web apps are slow?
Actually JavaScript will not make the app slow, it’s slow in
mobile devices because of the mobile processor architecture. Mobile processor uses
ARM architecture where as computers use x86 architecture.
ARM processor is special designed processor for mobile
devices and other kind of low power devices. It’s specially design for low
power consumption. It has low number of registers than the x86 processor. And
also mobile devices have limited memory when compared to computers. There for
x86 is ten times faster than ARM. This is the reason the heavily used Java
Script mobiles application are slow in mobile devices.
Summery
Technology
|
Tech Complexity – General
|
User Experiences
|
Works Best for
|
Code Reuse
|
Main Problems
|
HTML 5
|
Simple
|
Slow
|
Existing websites
|
70-100%
|
Very limited access to native features
Less native look and feel
Cant be submitted to app store
|
Cordova + JS framework
|
Simple
|
Very Slow
|
Web sits need app store,
One-Screen apps
|
60-90%
|
Poor performance
Less native look and feel
Heavy JS will make memory problems
Business logic is written in JS
Slower than the native web browser
|
Titanium
|
Medium
|
Acceptable
|
Simple apps
|
50%-70%
|
Poor performance
Limited native feel
Business logic is written in JS
|
Xamarin
|
Very Complex
|
Fast
|
Business apps
|
40%-60%
|
Initial load time high compared to native
Have to follow best practices to avoid memory issue
|
Native
|
Complex
|
Best Possible
|
Business apps, Demanding apps
|
0%
|
Cant be reusable
|
5.
References
