The Gap in the Last PhoneGap Mile

By SuperUser Account on 4/28/2014

So, in short I was able to build install packages for Android, iOS and Windows Phone from one PC using, but…

If you are like me you want to maximize the market for your mobile software.  Well, PhoneGap coupled with the SAAS is the bomb for that.  With PhoneGap you can leverage your web development experience and the power of the W3C standards and HTML5 to, as Adobe advertises, "create mobile apps using the web tools you love - HTML, CSS, and JavaScript - and then easily compile them for multiple platforms in the cloud.”  My app, which I called the DATA-EASY Field Data Collector, does that.  Night and day for months now, I’ve drank gallons of the PhoneGap and Kool-Aid as to master the mobile device's camera, GPS, file system, in-app-browser and other technical nightmares on three of those platforms, iOS, Android and Windows Phone.  In the beginning I made an HTML application, uploaded it to and I got back native platform install packages for iOS, Android, Windows Phone, Blackberry, WebOS, Symbian and Bada.  I thought “Brilliant!”, and it is.  If you have worked with the vendor specific mobile APIs such as the iOS API and Android API you understand just how amazing that truly is.  Was it easy?  Well, yes, if your app is simple it is easy.  However, my App is not simple so a short time later I ran into my first issues.  At the time I was drunk on the Kool-Aid and reluctant to give up on the quest for a true cross-platform Mobile App Utopia.  It is a fact that PhoneGap does a pretty good job of isolating your application from the mobile platform battleground with it’s numerous core plugins, but still there will be collateral damage when you get involved, you just can’t avoid it. There is not a tool in existence that can completely shield you from the turmoil of emerging and rapidly changing Mobile App and Web standards, including PhoneGap.  So if you must go down this road, be prepared to deal with the pain of battle, it is still raging. 

I could go on and on about the individual issues I encountered due to Mobile platform and HTML browser differences ranging from support for Indexed DB storage to handling files and HTML multi-part responses, but I got past those with many late nights and weekends.  So, instead I’ll focus on the latest struggle I am experiencing with what I call “the Gap in PhoneGap’s Last Mile” because that is the one we should all be most concerned about if we want to build a true commercial mobile application. lulls you into believing your hard work is safe and secure, but don’t make that mistake like I did.  Just because you get back install packages from does not mean those packages will run and deploy easily, and perhaps not at all.  First, it takes work and skill to find ways to test those packages on emulators and mobile devices.  The first suggestion I will give you is don’t even bother with emulators.  I’ll just leave it at that.  I wasted a lot of time there. Go out, beg, borrow or buy the mobile devices themselves and deploy the packages and test them on those devices.  In my case I owned an iPad 3 and Android Samsung S4, and I borrowed a Windows 8 Phone from my son.  Next, get good with Open SSL, I posted a couple of other blog entries with some tips there.  You can build and test an Android app on your Android devices without a certificate, but that is not the case for iOS and Windows Phone.  You will need to use OpenSSL or something equivalent to generate the encryption keys and certificate requests required to build and deploy the iOS and Windows Phone apps.  At first I was able to accomplish all of that on my Windows 7 computer, but recently ran into issues there, perhaps due to the Heartbleed bug in OpenSSL.  I worked around that issue by renting a Mac from and using OpenSSL on the Mac to generate a key and certificate request for the iOS deployment.  Be aware you might have to do the same.  Also, you will have to pay money (about $100 each) to Apple and Microsoft if you want to test your install package on your devices.  They require each device you want to run your tests on to be registered with your “developer account”.  Again, Android has no such restriction there.  At first I had no Windows Phone so I just used my Windows 7 PC to get all the way to the deployment of the Android and iOS build packages on my devices.  That actually went pretty smoothly.  I got the iOS certificate and registered my iPad with my Apple Developer Account and used the QR scanner interface of to deploy both the iOS and the Android apps.  Again, it worked brilliantly, this is easy, I thought.  In fact it was so easy and brilliant I refused to give up when I encountered shortcomings such as:

  1. There is no step through debugger to step through much of the javascript code you deploy to the devices.  I fell back to my years of experience developing COBOL on mainframes, before debuggers were common, to survive that.  Not fun.

  2. Though the core plugins, such as the file system plugin, appear at first to work the same on the different devices, they don’t.

  3. PhoneGap plugins help with standardization, but nothing can shield you from the fact you are running in an HTML browser web-view and those browsers are still very different from one platform to the next.  Bootstrap goes a long way there, but not all the way.

  4. There is no one good javascript “framework” you can entirely rely upon.  As you try to come up with a solid design you will feel like you are walking through a carnival with the carnies yelling “come on over here buddy, you’ll win big with THIS javascript framework…”  Just crawling through the carnival of javascript framework hype killed my productivity.    

  5. Javscript itself has issues, big ones.  If you are coming from a compiled, object-oriented environment like I did, be prepared to be astounded by the... let’s call it “flexibility”.  I’m used to it now, but the horror that javascript allows, without a step-through debugger, on different mobile devices, was unimaginable.

 Ok, I know I am being overly dramatic, but the fact is I was overdosing on caffeine and skipping showers for days to get through the development and testing phases of the first two platforms, iOS and Android. 

Now that brings me to Windows Phone.  I’m tempted to say don’t even go there.  I don’t think Microsoft wants you to go there.  First, I faced the challenge of getting the .xap from onto my son’s Windows 8 Phone.  Well I may not have found the only way to do it, but here’s how I did it.  There’s a Windows 8 SDK with a command line deployment tool that does it.  The problem is it only runs on Windows 8.  So, off to Best Buy I went.  Actually I needed a new PC badly and I could find no way to accomplish Windows 8 Phone deployment without Windows 8.  First I installed the latest Visual Studio Express 2013 release 2.  After a few days of monkeying around with the emulator and Hyper-V (I really wanted Hyper-V to work but couldn’t get there with my Acer. Uninstalled McGaffe, etc. etc.  That’s another blog entry in itself.)  I finally resorted to plugging in the phone and running the command line tool from the SDK.  The problem was the SKD was for Windows Phone 8.1 not 8.0 and it did not work.  I figured, well I’ll upgrade my son’s phone to 8.1.  It turns out Windows Phone 8.1 is not released yet and I no longer have an MSDN subscription so I couldn’t get there from here.   Finally I gave up and installed Visual Studio 2012 and the 8.0 Windows Phone SDK, registered the phone with my new Windows Phone Developer account and got it running, sorta... Remember, no step through debugger, different browser (IE 10) the horror, the horror.. At least I could still use Weinre to get to the bottom of some of the issues, wrong! As of today the Windows Phone connects to the Weinre server for about thirty seconds and then disconnects.  It is a known issue I could not work around.  In the end, see below for the list of issues I opened up on the Apache Cordova Project (the source of the core plugins for PhoneGap).   

I actually found work-arounds for most of the issues, most of them related to the way files and directories are handled differently and the way URIs and navigation works.  I’ll just say at this point stay away from using hrefs to navigate the app.  Several of the navigation / URI problems I found were more to do with AngularJS than with PhoneGap, so if you use something other than AngularJS you might not have as much trouble.  In hind-site, I suggest you stick with jQuery Mobile and avoid AngularJS, Bootstrap and Dojo if you want to deploy to all three platforms.  They are all very good in their own right, but I lost a HUUUUGE amount of time working around issues with those.  In the end, my App is running on Windows, except for one of the key components.  I implemented the Google Drive API and it is a keystone to the app.  Not surprisingly the App bails silently whenever the Google Drive API loads on the Windows 8 Phone.  Without a debugger I still have no idea why.  So I put in another twenty hour day yesterday trying to port all that code to the Windows SkyDrive API.  So far no joy there.  Both APIs rely on OAuth which relies on the in-app-browser plugin which I think is not working properly on Windows at this time.  Again, it is very hard to pinpoint with no debugger. 

Oh yeah, back to the topic of this blog, “the Gap in PhoneGap’s Last Mile”.  So what I am referring to is I was lulled by the brilliance of into thinking deployment to the three mobile platforms was going to be easier that it is.  In fact, the last phase, deployment to the App Stores, was nearly the thing that shot down months of hard work.  I know it is not PhoneGap's fault these App Stores do business the way they do, but it should be more clear that having a "built", "deployable" file is a long ways from getting the App tested and distributed.  Also, the development process is deceptive because you have "built", "deploy-able" files from right out of the starting gate.  However, over time as the App becomes more sophisticated you realize you have to invest a huge amount of additional effort to account for the differences in the browsers, file systems and other platform specific things that the plugins don't handle that well.  I started by developing each feature and testing it on Android.  After it worked well there I would install it on iOS.  Usually that's where the real work began.  I ran into several issues reading and writing files and converting to and from binary and base64 on iOS.  I ran into other issues going from iOS to Android with the database behavior since iOS supported IndexedDB, but Android did not.  Those discrepancies caused me to re-factor code I had working on one platform because it would not run on the other.  Compounded by the lack of a step-through-debugger, the development process gets harder and harder, and that is not even considering the Windows Phone, it gets even more difficult when that one is thrown into the mix.    At this point the open-source-ness is good, but I would be willing to pay more for more help / support / documentation and features.  For example, I would certainly have paid something if offered to broker the App Store submissions for me.  So in conclusion, you can get a PhoneGap App running on iOS and Android quickly, but you will learn you are on your own getting the App that last mile from there up to the App Stores, and it is a very loooooooooong mile..