Creating a mobile presence of your business —
an evaluation of methods available

So we have a business with a web footprint and all we can think of now is creating a mobile presence to test the waters. How do we go about it? This article is an evaluation of different routes one can take and what is the most suitable method for the given use case.

Method 1: Build a native application from scratch

This is arguably the popular. There are numerous device types, platforms and their SDKs that we would need to cater to, if the application is targeting the full spectrum of users. The most popular ones are iOS, Android, Symbian and Windows Mobile (not necessarily in the same order, dear fanbois!). While this approach gives us maximum freedom and flexibility in the SDK we’re building upon, it also requires a great deal of development and maintenance since we are going to rebuild pretty much everything from scratch.

How do we decide what we are going to build is indeed a good candidate for a native application? A rule of thumb would be to analyze whether there are more online or offline use cases. If we can do most of the stuff offline, a native application is the way to go.

Pros

1. Excellent flexibility. We are free to use the device and SDK capabilities to the full extent since we develop from scratch for each platform separately.
2. Maximum performance. The code is usually compiled to a native form, resulting in smaller memory requirements and often good user experience (provided it is developed in the right way).

Cons

1. Huge development time. Each SDK or device-type combination has to be developed separately. This also require developers who are proficient in each of these platforms.
2. Introduces additional layers. If our application has to communicate to the online counterpart, we might have to create web services and API interfaces of our own, which becomes an additional headache to be maintained.
3. A great deal of maintenance time. We will most likely run into multiple code bases, more bug tickets and each enhancement needs to be ported over to every SDK we use.
4. Additionally, multiple versions of the application existing in the wild could result to maintenance of multiple versions of web services on the online counterpart.
5. Updates have to be delivered via separate versions of the application.

Method 2: Build a native application, using a cross-compiling framework

Since developing for each device type or SDK may sound scary in terms of development and maintenance, this is the next best option available for producing native binaries of our application. The technique is to use a cross-compiling framework and develop using the SDK that it provides. The framework will then do the porting for us, allowing us to maintain a single code base and still target the full spectrum of devices. Titanium Appcelerator and PhoneGap are examples of frameworks that do the cross-compiling for us.

Pros

1. Reduced, but still good flexibility. These frameworks generally provide APIs that allows us to leverage the native features of the devices.
2. Maximum performance. Provided the framework we choose is written well, this method still results in our code being compiled to the native form, resulting in the same performance as the previous method.
3. A great cut on development and maintenance time. We now have to maintain only one code base for our mobile application.

Cons

1. Reduced flexibility, compared to the the first method. We have to rely on the features and the APIs the framework exposes — so a good deal of homework has to be done in choosing the right framework. Since most of the frameworks provide their own SDK, often differing in language and methods of expression, changing our code base from one to another framework might not be an easy option.
2. Since these frameworks try to cater to a wide spectrum of devices, the capabilities and APIs they expose might be limited to the set that works cross-platform. We might also have to wait for framework revisions and platform support to arrive before we can make use of the new features a target device provides.
3. Introduces additional layers. If our application has to communicate to the online counterpart, we might have to create web services and API interfaces of our own, which becomes an additional hurdle to be maintained.
4. Although the cut on development and maintenance time is significant, we still have to build a single mobile application from scratch. It again requires a developer who is proficient with the chosen framework’s SDK and enhancements will have to be ported over to the mobile code base as well.
5. Multiple versions of the application existing in the wild could result to maintenance of multiple versions of web services on the online counterpart.
6. Updates will still have to be delivered via separate versions of the application.

Method 3: Provide a mobile friendly version of your existing website

This one is easy. Provide additional markup and style-sheets to your existing website and pop it goes mobile-friendly. This gets us mobile presence in less than a week, if not in a day, of course for an average sized application. Again, this one is easy, but not without it’s flaws. We do not have a native application produced by this method and users have to access it via a web browser present on their device. While accessing via a browser isn’t that bad, we do not have our presence on the application stores like Android’s Market or Apple’s App Store. This method also gives us the least flexibility because we end up in a very limited browser, without any access of any kind to the native platform capabilities.

This method is suitable if you have only online scenarios; however such applications, this is a very recommended method. There are a good amount of websites today that make use of this technique to create a mobile presence, primarily because of the minimal development time required.

Pros

1. Minimal development time, compared to other methods.
2. No additional maintenance time required.
3. Updates and new features are delivered automatically. All updates are delivered to 100% of users whenever the website is updated.
4. No additional layers introduced in the online counterpart (I should also say there are no offline counterparts).

Cons

1. No offline presence; in fact there is no presence on the device other than bookmarks. This also means no presence in application stores.
2. Zero flexibility in controlling the device’s capabilities. We always run within a limited web browser. This also means mostly no native application look-and-feel and thus an inferior user experience. We miss out big time on page transitions, native UI elements etc. There are numerous JavaScript based client-side frameworks that attempt to provide a near-native experience, but none up to the mark yet.
3. More resource requirements compared to a native application, depending on the bulkiness of our web page. However, this again can be optimized to a certain extent.
4. Requires a data connection to work and the performance and usability mostly relies on the speed of the end user’s data connection. There are several techniques we could employ to reduce the bytes transferred for each page load though.

Method 4: A hybrid approach

This is a combination of the above methods. Native applications are a lot of development and maintenance and the mobile-friendly version of your website means absolutely no control on the device capabilities. The hybrid method tries to resolve some of the shortcomings of both and provides a native application that runs a mobile friendly version of our website. In this approach, we have slightly more development time than the third method but almost no additional maintenance time. However, this method, like the third, works out only if you have more of online use cases.

Essentially, we build a native application using the first or second method, that does primarily one thing — open the mobile friendly version of our website as soon as it is launched. The native application bundles no business logic at all. This gets us rid of the browser-like look (or in other words, conceals the address and status bars) and allows us to style the website to a native look. Since the application that renders the website is pure native code, it has full access to the device capabilities.  This allows us to bring in page-transitions, swipe gestures, etc., natively and even access to device specific controls like Home and Menu.

Pros

1. Better control and flexibility compared to the third method. Since we have a native application, we can leverage some of the platform capabilities. We can as well provide generic methods to access device capabilities, which the website code can consume in a progressively enhancing fashion.
2. Better performance and user experience than third method. Although it still needs to communicate to the web server, we could have some offline storage, processing and and a lot of caching and reduce much more on the bytes transferred back and forth — overall improving the experience. We can also make use of native features like progress indicators and a modal dialog boxes that give the user a native experience.
3. While the native application that does the page load and provide hooks to the device has to be built, it still is much less development time than rebuilding our complete business logic as a native application. Also, once built, the application part requires almost zero maintenance since we don’t pack much logic in it.
4. Updates are still delivered via a website update, without a software revision change. Multiple versions of the the application existing in the wild and being catered for, can be avoided.
5. No additional, maintenance-required layers like web services introduced in the stack.
6. Compared to third method, we do have an offline presence using this method. We can also have a presence in the application stores as a native application.

Cons

1. Compared to first and second method, our device-specific capabilities are still limited, if we were to keep the native application logic minimal. It is more of a trade-off that the vendor has to decide how important is accessing device-specific capabilities.
2. It is most likely to consume more resources compared to a native application. Again, like the third method, it depends on the bulkiness of the web page that is sent to the device. However, this can be optimized to a certain extent.
3. This method, like the third, still requires a live data connection.

Conclusion

As I mentioned during the initial parts of this article, the first choice has to be made whether we need a full fledged native application or not — by analyzing the number of online use cases we have. If we have more offline use cases, it would be right to go by the first or second method, preferably the second to cut down on development and maintenance time. However, if we are on the higher side in online use cases, it would make sense to go by the third or the fourth method. If you were to make web service calls that fetch information to help render your screen, why not as well make an HTTP call to fetch a fully or partially rendered version of the screen?

While I have had only prototyping experiences so far with a few popular cross-compiling frameworks, I do not really find the idea of coding the same business logic all over again in a different SDK to cater for a new device type, to be very exciting. Titanium Appcelerator, which calls itself to be the #1 mobile development framework, claims to have 1.5 million developers but they all together have been able to release only 21,000 applications (both figures mentioned on their homepage). I am not sure if that is a very successful ratio for a framework.

Personally, I find the hybrid approach very exciting to enable mobile presence for an existing website. It allows you to style your pages in a very native look-and-feel that it is hard to tell whether it is a native application or not. The latest web technologies like HTML5 and CSS3 allow us to give the application a native look and feel and caching abilities, without moving a foot away from being on the web. For example the HTML5 local storage could be leveraged to cache frequently fetched key value pairs so that such traffic can be minimized or avoided completely. All in all, this method seems very promising in building a native-like application that leverages the existing website and code base, requires minimum development time, no maintenance and that can be deployed in the platform vendor’s application store.

Tags: Mobile, review

This entry was posted on Tuesday, May 10th, 2011 at 8:35 am and is filed under Mobile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.