…April Fools, that is.

Google’s April Fools’ prank involving a Pokemon scavenger hunt not only caught folks by surprise by launching a day early on March 31st, but also illustrated a great use of two newer mobile techniques: gamification and hybrid app architecture. The gaming aspects of the prank are fun but evident, namely, scavenger hunt around the map to collect all 150 Pokemon characters before time runs out, thus winning entry to an elite group with a chance to become Google’ Pokemon Master. However, the launch of the prank itself provided a powerful demonstration of the potential benefits of hybrid apps.

Hybrid Apps Can Launch New Features Without Submitting an App Update

I stumbled across the prank by accident today while using the Google Maps app to find a local restaurant. Amid the familiar red pins, I saw what looked like an 8-bit flying monster icon flying in downtown Portland. Clicking the icon prompted me to “collect” it, and then a larger picture of the Pokemon character was displayed.

The real magic was that I haven’t updated my Google Maps app in months, yet Google was able to roll out a new feature (the Pokemon scavenger hunt game) without updating their app, deploying an update to Google Play and the Apple App Store, waiting for review and approval (in the case of iOS), and waiting for or prompting users to download an update. The hybrid aspects of the Google Maps app allowed Google to deploy the Pokemon Prank instantly to users. Imagine if you had the ability to roll out updates and feature features to your apps every week, or every day, to all your app users. Web sites do it all the time…why not apps?

Hybrid Apps are a Mix of Client-Driven and Server-Driven Functionality

When I mention “hybrid apps” I mean apps where some features or screens are generated by client code (e.g. the Android or iOS app code) and some features are generated by server code (e.g. XML, JSON, or HTML5 coming from your server). A simple example is an app where some screens are actually HTML5 web pages coming from a server. Since the web pages are generated by the server, not the app, you could make a change to your server code at any time, and the changes would immediately appear inside your app without needing to update the actual app code. Many apps utilize this approach, including several of the built-in iOS apps. Other apps utilize XML or JSON (instead of HTML5) to control information and functionality shown inside the app. In either case, since server code does not require an app store release, any feature or screen controlled by your server code can be adjusted and updated at any time.

Hybrid Apps Demonstrate Why Web-Based Software Eventually Won

In the earlier days of personal computers, most software was installed on your computer from disks, CDs, or website downloads. Updating software involved repeating the process, and managing deployments and support was a serious headache for many development shops.

However, over the past 15+ years, installed desktop software has gradually lost ground to web-based software. While early web tools were slow and clunky, today’s software-as-a-service products are slick, useful, and feel as fast as installed software. Computers and browsers have gotten more powerful, and software development tools have improved allowing rapid development of websites. The comparative ease of delivering a new or updated website to a user versus desktop software is a major reason why HTML rapidly evolved from its roots as a document formatting tool into the software application platform it is today.

Hybrid Apps are Also a Minefield

In 2012, Facebook removed the HTML5 portion of its app due to performance considerations, leading some to conclude that including HTML5 in a hybrid app is forever a Bad Idea. Such a blanket statement is rarely true, especially in a fast-paced industry such as mobile. And HTML5 is already in use by Google, Apple, and other apps to great effect. While discussion where and whether to incorporate hybrid techniques into an app could take up an entire series of blog posts, below are a few helpful thoughts on the matter:

• Too much HTML5 can be a performance drag. Facebook scuttled its app’s HTML5 activity feed in 2012 because phones, operating systems, and web toolkits were far less powerful, and the activity feed was a very large ever-scrolling screen. Keeping the HTML5 lightweight and focused within smaller screen elements allows for a snappier feel.
• Devices get significantly more powerful every year. We’ve been working with hybrid apps for years, and only very recently have the phones been powerful enough to make the apps feel performant.
• Hybrid apps don’t save as much on up-front development costs as you would think. While the idea of building an HTML5 screen once and using it on multiple platforms seems like it would save a lot of effort, it’s important to remember that the effort of building that “magical” screen so that it performs well and lives nicely inside the native app is potentially not much less than if you built the screen using all native client-side code. The cost savings come later when you need to modify that HTML5 — you only do it to one codebase, you avoid app store submission overhead, and you can consolidate some QA effort.
• Hybrid is great for things that need to change frequently. The ability to roll out changes and features in a heartbeat allows you to more effectively adjust your app to your target audience, respond faster to market or business needs, and reach a greater percentage of your user base.

I predict we’ll start seeing more hybrid apps in the next year or two — as the devices and software tools become more powerful, the benefits are hard to ignore. Even Gartner predicts by 2016 over half of the apps deployed will be hybrid apps, particularly in the enterprise space where deployment management and improved ROI are important. In the meantime, we’ll just have to wait and see what pops up on Google Maps next April 1st.