There is more to mobile web development than just HTML, Javascript and CSS

web apps samsung apple

There are three main technology choices to consider when building apps for smart devices; web, native, and hybrid.

Web apps are built and deployed to a web server running in a data center and viewable through any device’s web browser. Native apps are built specific to a device’s platform and are downloaded and installed onto the device through an app store. Hybrid apps are built using similar web-based technologies as web apps but are bundled up and deployed inside native app wrappers that are distributed to users through app stores just like native apps.

Choosing which of the three different types of mobile apps to build involves prioritizing three potentially conflicting sets of goals. Those goals are time to market, total cost of ownership and the user experience. Time to market can include the total time it takes to develop an app for multiple platforms, or just one platform. Total cost of ownership includes all development and support costs incurred over the lifetime of the app. The user experience is a little more difficult to measure as it deals with aspects of the app, like performance, responsiveness, ease of use, and overall appeal. These experience-based aspects of an app can be a more subjective measure of an app’s quality rather than an objective one.

The problem is that these three very different goals can be influenced by factors that are not directly related to what technically distinguishes the web, native and hybrid technologies themselves. These outside influencers can directly impact how an enterprise prioritizes each goal.

Exposing an enterprise’s infrastructure to everyone’s device

Most enterprise architectures are distributed across multiple tiers. Each tier is typically hosted on a different network that the other tiers have controlled access to, as they are protected behind firewalls to better protect and secure corporate data. For instance, there most likely will be a web tier, a services or business tier and a data tier.

These tiers have evolved over the years to accommodate an almost twenty-year boom in desktop-based web development. While this web tier can directly access the services tier in order to get to the information it needs, the same is not always true for native or hybrid apps running on smart devices disbursed across the internet.

Most enterprises have a roadmap in place outlining which of their services will be accessible over the internet and which ones will not be ready. The services are accessible can become the primary reason that a purely web-based development strategy is adopted over a native or hybrid app.

The existence of these services can certainly affect time to market decision when services do not exist, while on the other hand will drive up the total cost of ownership when they do.

Write once, test everywhere, twice

When it comes to evaluating the total cost of an app, targeting multiple platforms can at first be seen as a cost multiplier. If a change or enhancement needs to be made to the app on one platform, it needs to be made across all platforms. Efforts to eliminate this multiplier have created Mobile Application Development Platforms (or MADPs), like Adobe’s PhoneGap, Apache’s CordovaAppcelerator’s Titanium and Konythat promise to deliver an app to multiple platforms from one code base. While this can have some effect on the total cost of owning a mobile app, it will not eliminate all of the costs associated with supporting multiple platforms.

One challenge that enterprises face when choosing a development strategy that addresses more than one smart device platform is testing. Buying multiple test devices and developing a test strategy that includes an acceptable mix of platform versions, screen sizes and device capabilities is something that must be done regardless of how one decides to get an app onto a device. There are even occasions when testing efforts can benefit from having two identical test devices to compare how two different versions of the app behave, or how the same version of the app behaves on two different versions of the platform’s OS.

There are places you can go that will allow you to test on a variety of different devices without having to actually purchase multiple devices. One such place is OpenDeviceLab. OpenDeviceLab is a grass-roots community movement that is helping create a community pool of test devices that developers can use. Services like TestFlightApp and HockeyApp can make managing the distribution of test builds a much easier task as well. However, the costs associated with managing a battery of test devices is only one part of the total cost equation, albeit a very visible one. There is still the matter of spending time executing the tests.

Currently the smart device market in the U.S. is dominated by two platforms. While the current market share and usage data point to adopting a development strategy targeting at least two mobile platforms, does it make sense to increase one’s total cost of ownership by adding a third?

Repurposing existing desktop web developers

A new discipline among web designers and developers alike is what is known as responsive web. The goal of responsive web is to design websites in such a manner that they adjust themselves to fit appropriately on different size screens. This strategy lends itself well to repurposing existing web developers and designers as responsive web developers and designers. At least that is the theory.

When it comes to repurposing desktop web developers as mobile web developers, it is true that some of the core technologies used in each type of development have similar structures to them, like HTML, JavaScript and CSS. But in practice, the libraries and techniques that are used to implement a touch-friendly web design can come with an unexpected learning curve. Switching from a barebones JavaScript development discipline to more of an AngularJS based JavaScript framework like those used with Ionic or OnsenUI, two popular touch-based JavaScript frameworks, can take some getting use to. Perhaps not quite as steep of a learning curve as transitioning from Javascript to Objective-C, but a learning curve none the less.

For both mobile web and hybrid development using tools such as Apache’s Cordova, the setup and configuration of a mobile developer’s work environment alone can be a daunting task for a traditional desktop web developer. The task of managing and maintaining a workstation equipped with the latest version of Xcode, iOS simulators, Android Studio, SDKs, emulators and device profiles is a skill-set in its own right. One problem realized right away is the slow performance exhibited in Android emulators compared to the iOS Simulator. Fortunately there are technologies like Genymotion that have stepped in and improved performance considerably.

Ensuring that you have the right talent to craft a positive mobile experience can certainly increase costs up front, but expecting a veteran developer that has spent years perfecting your online desktop experience to instantly transition over to becoming your star mobile developer may not be as instantaneous of a process as one would like. You’ll need to give them some time to retool and wrap their brain around what you are asking them to do.

loading

Comments have been disabled for this post