The very first road to the various app stores from Apple and Google was paved with native code. If you wanted to write for iOS, you learned Objective-C. If you wanted to tackle Android, Java was the only way. Similar issues popped up with all the other smaller players in the smartphone market.
Then some clever developers came to a realization: All the smartphones offered a nice option for displaying HTML in a rectangle on the screen. You have to write a bit of native code that pops up this rectangle in the native language, but everything inside the rectangle is controlled by the same languages that control the browser.
Many developers immediately recognized the beauty of this. They wrote a generic native app with one big rectangle that took over the screen, then they handed off control to the JavaScript team. The result could run on all smartphones with only a few minor changes. Not only that, but the developers could use their JavaScript and HTML chops without learning too many details of the various platforms.
The early years weren't kind to this vision. Apple reacted harshly and banned some HTML apps from the App Store. Developers quickly found they couldn't get too creative with the JavaScript or the HTML before the phone started hiccuping and coughing. The HTML-based apps were often rougher and less polished than their native cousins.
That started changing several years ago. Apple relented and recognized that HTML was not dangerous. Then the hardware got faster, smoothing over many glitches. Today, some of the HTML-based apps I've been writing perform just as well as native apps -- and they're much easier to port.
Now these toolkits are being combined with cloud-based services that add cross-platform builds and app distribution to the mix. The leader of the movement, a once open source project named PhoneGap, is running strong and attracting competition from AppGyver, a startup that wants to make it all even easier. In the meantime, Telerik Icenium is evolving along a parallel path and offering a strong collection of development tools and UI widgets sewn together with JavaScript and HTML. All these tools open up the world of apps to developers who already are skilled in building Web applications.
Adobe PhoneGap
PhoneGap began as an open source project before it was absorbed by Adobe. There's still an open source version called Cordova available from the Apache Foundation and a very similar version called PhoneGap that's available under an open source license (ASF).
The principle difference is that Adobe offers a smooth Web service that turns your HTML into apps. You write the HTML, and Adobe's cloud turns it into something that runs on iOS, Android, Windows Phone, BlackBerry 5/6/7, and webOS. There's a free version that lets you build an unlimited number of open source apps, but only public apps. Professional developers can pay $10 a month for unlimited private apps.
Of course you can do all this yourself. You can fire up Xcode, Android Studio, or the tools for the other smartphones and create each on your own. PhoneGap is really six or more projects for different platforms that all implement more or less the same API. Your code should come close to running the same on all the machines, although issues often arise due to differences in hardware.
After building apps for the iPhone and Android, I can recommend the build process. Just downloading all the tools takes a long time. The job of building code has migrated to the Web, and Adobe is offering one of the first concrete and compelling tools. You put in one chunk of code for your browser and out come six different apps that run on six different platforms. That's amazing.
Though the entire process takes plenty of weight off our shoulders, it is neither as simple nor as perfect as it could be. The platforms have plenty of details that need to be filled out endlessly. The documentation, while good, can't begin to offer enough detail for every possibility.
One of the trickier issues involves creating the digital signature. Apple, Android, and BlackBerry all ask the developer to "sign" the code, essentially acting like the signature an artist applies to a masterpiece or the President creates during a fancy signing ceremony in the Rose Garden. While there's always a big gap between the symbolism and reality, there's no doubt of the legal and emotional power behind the digital signature.
Adobe asks you to upload the private keys and the passwords to its cloud. This may appear as a service, but it gives Adobe the power to create anything it wants and distribute it any way it likes. Would the company act upon this power? I'm sure the public answer approximates the word "never," but who knows about others poking around Adobe's infrastructure? What if Adobe employs someone like Ed Snowden with the ability to read files at will and impersonate others? That person could create extra apps and distribute them easily.
Adobe is not alone here. You court this potential security hole with AppGyver and Icenium as well, and in any case you can work around it. Last week I had to sign a new app, and the safest way was for me to download the complete source code, build it from scratch, then let Apple's built-in signing tool handle it automatically. The mathematics don't require a cloud of servers. Anyone can sign any digital file with the algorithms. But using Apple's tool seems to be the safest path through the system.
Adobe's Build tool also offers one other nice feature: The binary wrapper for your app can also look for new versions of the software on startup, something that Adobe calls "Hydration." This allows you to push new builds to your users without going through the standard update mechanism.
Adobe sells the Build service as part of the Creative Cloud, its latest plan to bundle all of its applications for one monthly fee that tops out at $75. There's also a free plan for testing out the service that offers one "private app" and an unlimited number of open, public apps. Separate paid programs begin at $10 a month and offer many more private apps with controlled access.
AppGyver Steroids
If imitation is the sincerest form of flattery, the folks at AppGyver are clearly infatuated with PhoneGap. They've taken much of the core from the open source project but have added their own build infrastructure and one very useful feature that may prove irresistible to developers.
The interface is a bit different. Whereas the standard way to use PhoneGap is with the customary developer tools like Xcode, AppGyver runs from the command line and piggybacks on many of the tools developed for Node.js. Installing the software requires running the Node package manager and Python. While AppGyver apparently works with Windows and Cygwin, I ran for my Mac within seconds of starting. AppGyver is geared for Linux and Unix, and everything is ready to go on your Mac because it's a Unix box underneath.
When all the command-line typing is done, you're still playing with the code in your browser. Safari does a credible job of emulating and debugging the kind of HTML that runs in PhoneGap/Cordova. I've found a few inconsistencies over the years, but not many. You write your code in your favorite editor, then you deploy it. I started out debugging in Safari, then switched to the built-in simulator. Safari offers the kind of step-by-step debugging that's often necessary, while the Xcode simulator works more for double-checking.
There were some glitches -- or perhaps I should call them overly earnest suggestions. My builds would often fail because some SCSS file was missing. The code ran fine in Cordova with Xcode and in Safari -- neither batted an eye. But AppGyver wouldn't move forward without cleaning up that issue.
My favorite part of the entire AppGyver process is the way you can deploy to your smartphone. When you first deploy, AppGyver creates a QR code with the URL. AppGyver also gives away a set of free apps that can interpret these bar codes and use them to download the latest version of the HTML. All of a sudden, your iPhone will reach out and suck up the latest version of your program and run it in AppGyver's shell.
It's impossible to praise this feature too loudly. I don't know how many times I've lost a day or two of development because apps will only run on iOS devices that have permission from Apple's secret bunker. One guy wrote me saying the software wouldn't work on his phone -- it turned out he'd upgraded a week before. The old UUID in the certificate chain was worthless now, and everything had to be redone. It's not exactly right to say that nothing happens in the iOS world without a developer asking "mother may I" of Apple, but it's a close approximation. AppGyver's solution is a godsend for developers.
The AppGyver system avoids the endless clicking that gets in the way of real debugging and real quality assurance with real users. Apple's tools insist you can't have more than 100 beta testers no matter what. The AppGyver app has already been approved by the App Store, and it can download the latest version of your app when anyone points the camera at the bar code. Others can debug your code, and it's much simpler. This is real innovation.
There are other claims that I found harder to verify or appreciate. The AppGyver team calls its product Steroids in part because it offers some page transitions written in native code. You can optimize your code a bit, and Steroids is supposedly going to replace the poky HTML/JavaScript transition with its own.
I used to see the value in this several years ago. Some of my HTML apps were slow at times, especially when I filled up the RAM with baseball statistics. But this effect has been much less noticeable on the newer smartphones. The bigger memories and faster chips do a better job of swapping out the HTML pages. For that reason, I didn't see or feel much difference when using Steroids. This might be quite different with your app; I've noticed that the smartphones handle code in widely varying ways.
There are other parts to the AppGyver world. Steroids works with AppGyver's Cloud Services that handle the building and distribution of your app. When you're just debugging, the code flows through the cloud to your iPhone or Android. When you're ready to submit it to the stores, it will build the code for you -- if you upload your private key for creating the digital signature.
Prototyper, a neat tool still listed as beta, tries to make app creation as easy as uploading images, then dragging and dropping links between them. It works, but only for the simplest ideas. After a few minutes, I wanted to seize control again and write text with an editor. It may be, however, a good tool to give to the boss for sketching out a prototype. If anything, it will help the boss understand how much work the programmers really do.
AppGyver doesn't charge directly for Steroids or its Cloud Services at this time. The company funds itself through support fees and white-label development. The AppGyver folks are experts at building, and I'm sure that sharing the tools with the world will help add polish. Prototyper has a free plan and a small monthly fee that starts at $9 and goes up to the coy listing that says "ask for price."
Telerik Icenium
In the midst of all this talk about building smartphone apps with HTML, one company started eating the dog food and building the actual development tool out of HTML. Telerik, the creator of Icenium, is nurturing an entire ecosystem for turning ideas into apps for sale in the App Store or Google Play. At the center is an IDE, it's worth noting, that runs in the browser. You write HTML and JavaScript with a tool built in HTML and JavaScript.
Telerik is offering a complete collection of tools to turn your ideas into an app. You can write your code in your browser, host it in Telerik's cloud, then let the cloud build it into a completed app. All of this is centered around Apache Cordova at the core.
The most significant parts of the offering are the IDEs called Mist (browser) and Graphite (Windows), along with a new extension for Visual Studio I didn't try. Mist and Graphite seem functionally equivalent to me, and I wasn't surprised to find that the projects I created in Mist started appearing in Graphite. Both offer a screen split between a file navigator and an editor. The editor can toggle between a text-based HTML editor and a visual tool for dragging and dropping widgets.
There were some glitches. The editor wouldn't work with several views, claiming they weren't proper HTML5. The complaints kept coming even when I deleted all the various DIVs inside. Sometimes it was simpler to work with the HTML instead of the designer.
I also found myself defaulting to the built-in debugger in the browser. Firebug and Safari's debugger are incredible, and it will be some time before anything will be as good as them.
The main difference between the Icenium tools is access to the hardware. The Windows IDE (Graphite) can access the hardware through the USB port, whereas the browser-based IDE (Mist) can't. The tools seem to be evolving. They make it easy to drag widgets into place, but you still need to read the HTML and think about the structure. I found I had to remember what was going on in the HTML layer to understand how to put together all the widgets correctly.
This limitation isn't as important as it might be, because there's a third part of the equation: Ion, a tool that works to deploy and update your app just like AppGyver does. You download Ion for free from the App Store, and it sucks up the HTML/JavaScript/CSS that comprises your app. Debugging and deploying is as simple as it is with AppGyver.
A new part of the equation is Ion's cloud-based back end, known as Everlive. The service, currently called a "preview," mixes in a big collection of data storage services meant to simplify development. Telerik is pairing data storage and "user management" with the distribution of your app. It only takes a few lines of code to let each of your users log into the cloud and store information there. That's a nice set of features.
Telerik has selected two main frameworks to support: Kendo and jQuery Mobile. You don't need to choose these libraries to distribute your code, but extra features -- such as drag-and-drop functionality in Mist -- work with the Kendo framework only.
Pricing starts at $20 per month for a basic account and rises to $120 a month for the "ultimate" tier. There are substantial discounts for a prepaid annual plan, as well as a nice free trial that lasts for 30 days.
Filling the phone gap
These three collections of tools make it simpler to create an app, especially a cross-platform app that runs on iOS, Android, Windows, and BlackBerry. They glue standard HTML, JavaScript, and CSS into the native code in a way that makes it possible to port your app quickly and relatively painlessly. They also open up more of the underlying platform to your JavaScript code by creating a pathway for data and images to flow from the native layer to your JavaScript.
I think these apps can deliver on the promise of simplicity if you're going to build a three- or four-page tabbed app that does little more than display information. You can toss this info into one page of HTML filled with nested DIVs, and the libraries will do the rest.
But once you start creating more complicated apps, you run into the limits of the libraries. One of my applications created a relatively long list of items, and the code slowed to a crawl. After I added another layer of nesting to the lists, it went much faster. You'll discover hundreds of little limitations like this. The HTML stacks and the PhoneGap/Cordova frameworks are growing more polished, but they still require plenty of thinking like a programmer.
This technical promise, however, is far from perfect. While I've been able to quickly move apps from iOS to Android and beyond in a relatively short amount of time, the frameworks are far from being as simple as snapping your fingers when you start using all of the features, especially the more extreme features (like access to the camera) supplied by plug-ins. Sure, it's nice to be working in HTML and CSS to lay out the application, especially if you're familiar with them, but that's only the beginning. Many tiny details still need to be right. When I moved my project from iOS to Android, it took me about a day. That's not much, but it's not as short as measuring it in minutes.
Despite these qualms, I found it incredibly pleasant to be working with tools like AppGyver and Icenium. Not only did they both speed up the debugging cycle (as long as I used well-honed debuggers like Firebug), but the real win came when distributing my app through the internal cloud instead of the standard stores. That speed is invaluable.
