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.
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.
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.
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.
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 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.
On the surface, it may seem like a difficult choice between Alexa and Google Home, but once you look at...
Apple has to out-execute itself (and its rivals) every year to coerce millions of users to upgrade and...
CIOs discuss key efforts to shake up their IT departments as they lay the foundation for digital...
The Federal Communications Commission approves new rules that will finally make it harder for...
If implemented properly, blockchain can help secure medical devices and improve patient privacy, but...
Does Silicon Valley’s latest quick-fix for its diversity problem actually work? Or does it just...