Editor’s Note: Welcome to our weekly Reader Forum section. In an attempt to broaden our interaction with our readers we have created this forum for those with something meaningful to say to the wireless industry. We want to keep this as open as possible, but we maintain some editorial control to keep it free of commercials or attacks. Please send along submissions for this section to our editors at: dmeyer@rcrwireless.com.
When it comes to deciding on the right platform for mobile apps it’s so easy to get caught up in incorporating all of the latest bells and whistles. Very often, it seems, brands are eager to use the latest technology because they want to “check the boxes” in an effort to create award-winning or buzz-worthy offerings. But, it’s really critical to stop and think about what you are doing and to define a clear mobile strategy before taking the leap – for potentially all of the wrong reasons.
A few weeks ago I went to an International Marketing event in Sao Paulo and found myself a little bit uncomfortable hearing some excessive debate on the triumph – or failure – of HTML5. I heard much conversation about mobile platforms and very little about who the mobile app is trying to reach. It made me wonder if some people have a mobile strategy in place at all? If you don’t know where to go, you could be going anywhere – even the wrong direction. I daresay the people that start talking about mobile technology as the very first step of a mobile strategy are also unstructured in their thinking about the business case, constraints and target audience (and perhaps making some incorrect assumptions).
All this conversation reminded me of an interesting press release from Gartner released earlier this year about business-to-enterprise mobile apps moving towards hybrid platforms. This is happening in part because their target audiences (i.e. employees or “internal” people) may share similar behaviors, needs and expectations (even if it’s at a higher level). The companies also have business objectives and strategies that justify the use of a hybrid solution, mainly for example, when dealing with the uncertainty and speed of today’s consumer-driven mobile landscape – not to mention the “bring-your-own-device” phenomenon.
Additionally, some may think that the native or hybrid decision is mainly related to the expected level of usability of the app and its visual design. My team has delivered native apps for iOS and Android, Web-based “pure” HTML5 (running on the device’s browser, i.e. Safari and Chrome), as well as HTML5-hybrid (using PhoneGap) and native-hybrid (using Titanium/Appcelerator). Today, based on the real cases we have developed, I believe it’s possible for an app to provide both great visual design and high levels of usability on top of hybrid and Web platforms.
For example, one project we worked on with a multinational beverage corporation required a business-to-consumer mobile solution as an additional interactive channel, part of a wider marketing campaign. Moving forward with a HTML5-hybrid approach we were able to provide the exact same rich user experience – including functionalities, content, visual design and usability – for both iOS and Android. A couple of specific features for recording audio and video needed to be developed natively for each platform and incorporated in the form of plugins. However, the remaining big chunk of functionalities, all the content and the fluid “look and feel” with visual effects (directly connected to usability) were all developed on top of the hybrid piece of the solution (multi-platform coding) thus being shared among the two operating systems “as is.” In the end, users on either operating system couldn’t tell that the app was built on top of a hybrid platform.
The same thing happened when we developed another project for a Fortune 500 company in the food services industry. This time we followed a native-hybrid approach for creating a B2C app intended for online ordering. In this case, the audio and video recording was replaced by the ability to use the camera in reading barcodes. Again, the iOS and Android users probably still don’t know that their apps share the same intermediate code behind-the-scenes.
The decision to choose native or hybrid development is often closely linked to how the app interacts with low-level operating system tasks and the hardware of the device. Some examples that may require native coding to work most efficiently include, low-level memory management, more control over 3D graphics and installed authentication certificates. Every hybrid app consists of a fraction of native code plus a complementary part of multi-platform code, which is the reusable part. Depending on the business case, the complementary percentages of native and multi-platform code will vary. In short, if there is a very high percentage need for native code, it may be better to go directly to 100% native development on each platform.
The same reasoning is valid in the opposite case: low need for native code can justify hybrid development as well. Each case is unique. Web-based apps (i.e. pure HTML5) could be chosen in situations where the need for an offline sync is not so critical for example and when it’s possible to guarantee that the user experience will remain consistent among the different types and versions of browsers running on different OS and devices. This is especially true for Android when also considering the different flavors launched by each device type and respective screen features.
I personally believe there is a chance for mobile development to move towards Web-based solutions, similar to what happened when “to-be-installed” software in the 90’s was replaced by sites and Web apps. Either way, it’s important to avoid the shiny temptations to develop a mobile product or service on top of a specific platform solely because it’s “cool.” Instead, as I’ll discuss in part two of this series, it is important to focus on understanding the business case, constraints, and especially your target audience.
