Building an HTML5 Web App

I have an Android App called Concert Tipper but as yet I have not been able to get the same cross platform App approved by Apple for inclusion into the Apple App Store. I am also building an HTML5 Web App version which will run on any HTML5 compliant smartphone. The Web app will be totally under my control and not subject to any review process just to get it to run on your device.

Users don’t really care about any of the problems associated with getting approvals into App Stores. They just want to run the App on their device no matter what smartphone they use. This is the promise that HTML5 holds. We shall see to what extent that promise is delivered.

I’ve been developing software systems of all kinds since 1979. I’ve been building web sites and Internet services from around 1998. I am no stranger to desktop applications, server applications, web applications and embedded systems to name a few. Picking up the basics of HTML5 and Web Apps recently was a challenge but no more so than mastering any new technology. In fact I have to say that I have worked on far more complicated things in the past.

Before I started to convert my Adobe AIR App to HTML5 I looked around at the many Javascript frameworks that are currently available. This was a chore in itself and it took me some time to decide to use the JQuery Mobile framework to provide a user experience similar to what you might find on a mobile App and also similar to the interface that I developed for the AIR app. I also looked at some templating and data management frameworks but decided not to use them as they all looked a little bloated and overkill for my purposes. Instead I opted to code any requirements in Javascript on the client and PHP on the server.

The server side back end database and scripting already existed of course. I had developed this for the AIR apps. This meant that I could concentrate on the HTML5 and user interface which I have to say is coming along nicely as I speak.

Problems? Yes there are some, of course there are. Most of the time consuming ones tend to be caused by incompatibilities between mobile browsers. Some HTML5 compliant browsers are more compliant than others and getting the App to work satisfactorily on all devices is the latest challenge. Safari on the iPhone appears to be one of the better browsers in this respect.

Speed of operation and user responsiveness is also a challenge with a Web App. With the native AIR App I was able to cache a lot of data and provide the user with a fast UI even on the slowest devices. The Web App requires more time downloading data from the server and Javascript tends to be a little slow on older devices. The trick here is to code an acceptable compromise between download/processing time and user responsiveness.

I’m sure that I will come across more challenges before this HTML5 App is completed so I better get back to work.

The Rise Of HTML5 Web Apps And Fall Of The App Store

Apple App Store misery

A lot of things have happened since my last post. My attempts to get my App into the App Store has been a bitter disappointment and a change of direction towards a universal HTML5 Web App.

My Android AIR app has been published in both the Google Play store and the Amazon Android Store for many months now and it has also been extensively tested on iPhones. On the face of it I thought that it would be a simple step to getting it approved in the Apple App Store and available for use on iPhones but I could not have been more wrong.

After jumping through several hoops just to get the App binary uploaded to the App Store I waited for a response from the Apple reviewer. It’s worth bearing in mind that Apple had already taken $99 from me to allow the App to be tested on designated iPhones. Unless you Jailbreak your test phone there is no other way to run an App on an iPhone outside of the Apple Development prison.

I had expected the App to be rejected the first time. There was sure to be something that I would need to tweak I thought. I was surprised and appalled at the responses that I received however. This is what they said:

“We found the user interface of your app is not of sufficient quality to be appropriate for the App Store. Apps that provide a poor user experience are not in compliance with the App Store Review Guidelines.

Specifically, we noticed your app does not take advantage of iOS platform. It would be appropriate to add iOS specific functionality and UI in order to enhance the user experience.

Please evaluate whether you can make the necessary revisions to improve the user experience of your app.”

Ok, what does this mean? What is wrong with the interface? It seems fine to me and has been through many revisions as a result of end user testing and peer review processes. What parts of the iOS platform specifically should I be taking advantage of?

Of course I asked the Apple reviewers to clarify only to receive responses that were just as cryptic. The exchange of communications went on for some time and it was clear that I was going to get nowhere so I asked them a direct question:

 “Is it possible to achieve the changes that you require with an App developed using Adobe AIR bearing in mind that I am only able to add native iOS functionality to the extent allowed by the AIR framework?”

They responded:

“Thank you for your response. After reviewing your reply, it seems your question would be best addressed by Apple Developer Technical Support , who can provide discrete code-level assistance.”

This is the point at which I decided to stop banging my head against a brick wall. I realized that Apple has recently tightened up their acceptance criteria and that there was very little chance that my cross platform Adobe AIR App was ever going to get approved. On top of that it is clear that any App in the Apple store is under constant threat of being removed at Apple’s sole discretion. So even if I managed to get the App approved there is no guarantee that it would remain available to iPhone and iOS users .

HTML5 Web Apps are the way forward

If I can’t get a native App into the Apple Store then I will build a Web App using HTML5 technologies instead. Done properly a Web App will work on any HTML5 compatible smartphones including the iPhone and it can be made to look similar to a native App. This approach requires no approval from any smartphone manufacturer and can be run directly from my servers. This is a huge advantage. In my next post I will give you some brief details of how I am approaching the HTML5 version of the App.

Waiting For Review In The Apple App Store

I can’t tell you how relieved I felt last week when I finally managed to get the App uploaded to the Apple App Store and saw the status change from “Waiting for upload” to “Waiting for review” instead of “Invalid binary”. The process had been painful and there was precious little help from Apple in diagnosing the problems.

Provisioning for distribution

The first step in the App Store submission process is to prepare the binary package in a format acceptable to Apple. This involves obtaining two new files from the development portal. You need a distribution signing certificate and a distribution mobile provisioning file. These files are used to create the distribution binary package in the same way as the development packages are created for testing the App on suitably provisioned test devices.

This is a fairly straightforward task but I have a big problem with it because it means that I had to create an upload package using files and tools in a way that I can not test before uploading to the Apple Store. This might not sound much of a big deal but I’ve been creating software solutions for more than 35 years and experience tells me that that if something has not been tested then there is likely to be a problem with it. This time I had to trust myself to get it right and hope for the best.

You can not do this without an Apple Mac

The next problem was uploading the package to the App Store but before I could do that I had to take the “.api” file, un archive it and re-zip it up on an Apple Mac computer. The archive can only be produced on a Mac as it adds some codes that are not used by other archivers. As I had created this App as an Adobe Air project on a Windows machine I had to find a Mac to perform this step. I also knew that the package can only be uploaded to the App Store from a Mac and I don’t actually own a Mac. I had to find a friend with a Mac who was prepared to do this for me.

Luckily my friend Huw has a Mac and he was interested to see how this process works so we were set to go. After he had unzipped and rezipped the package he downloaded the Application Uploader software and attempted to upload the App for me. When this App finally gets approved I will need to acquire a Mac to maintain Apps in the store.

Restrictions on members

We noticed that we were only allowed to upload Apps using the member account designated “Agent”. It was set to the originator of the main account who was not involved with the development process. We tried to reassign the Agent role to one of the developers using the portal. Unfortunately all attempts to do this failed so we ended up logging in with the main account that we knew had the Agent role assigned. Not ideal but that seemed to work.

Invalid binary!

All appeared to be well during the upload and I saw the status change from “Waiting for upload” to “Upload received” and I thought we were winning. Then the status changed to “Invalid binary” and our hearts sank.

What was wrong? Well the App Store is supposed to send you an email when this happens containing a description of the problem but we didn’t get anything. We tried again from different accounts and attempted other minor changes but nothing worked. Invalid binary every time. It took us two days to find the problem and in the end it was so simple yet so not obvious. I shall leave the explanation of this to a later post.

So now it is uploaded and it has a status of “Waiting for review”. Review is when a human tester will give the App a test drive and I have every reason to believe that they will find something wrong with it that I will have to fix before they approve it. Until then I can relax.

If you have an Android phone you can try it out right now by installing it from Google Play Concert Tipper. If you have an iPhone then it should be available in the Apple App store soon.

Submitting An App To The Apple App Store

Why does it take so much time and effort to get a mobile App submitted to the Apple App Store?

Apple has a submit and review process that rivals getting accepted to do quantum mechanics at university. They force developers to produce good Apps whether they like it or not. If it isn’t good enough then it will get rejected. This might be good news for users but it isn’t so good for developers.

Submitting an Android App is child’s play in comparison

I developed a mobile app and submitted it to the Android Play site about three months ago. It’s an Adobe AIR based app written entirely in ActionScript 3 which makes it a cross platform app that can easily be ported to the Apple iOS system for use on iPhones and iPads. I thought that this would enable me to submit the same app to the Apple App Store very soon after it was established in the Android Market but I was completely unprepared for the additional work I would have to do before I could submit to Apple.

Three months after submitting to the Android Play site I am only now at the point where I feel confident in submitting to the App Store. So why has it taken so long to get the Apple version ready? Well that’s the purpose of this post. Read on to find out where all my time has gone.

First steps in preparing an App for the App Store

The first thing to do was to get a test version of my app running on an iPhone. Packaging the Air app for iOS is fairly straightforward using the Adobe Air sdk tools but I did have a problem trying to use the latest versions. I could not get it to build successfully and I finally reverted to version 1.6 because it works and I didn’t have the time to work out why later versions do not. I shall revisit this problem once the App is in the App Store.

Now you might think that once you have built and packaged your app for iPhone you should be able to transfer it to your iPhone and start testing it. This is indeed exactly what you would do with an Android App but not when it’s an Apple device I am afraid to say.

99 dollars just to run your own App on the iPhone that you own 

Before you can run your App on the iPhone that you paid good money for you have to get yourself an account at the Apple Development Portal which will cost you $99 for a one year subscription. Why do you need this? Well there are a few requirements that your App has to fulfill before it will run un an iPhone and you can only fulfill these requirements through the development Portal.

The first thing you need to get from the developer portal is a Developer certificate. This can only be obtained through the portal and you use it to build your App binary package. The purpose of the certificate is to authenticate your App and without it it will not work when you put it on your device.

The next thing you need from the portal is a provisioning file which is tied to the device that you run it on. Yes this means that you have to build as many binary packages as there are devices you want to test it on. This can be a real problem if you have many testers because every time you make an update you have to build a new binary package for each tester one at a time. The appropriate provisioning file also needs to be loaded onto the test device before the App can be loaded and run.

Yippee it runs on my iPhone! A long way from submitting to the App Store

So you have your developer certificate and a mobile provisioning file for your App. You have loaded your provisioning file onto your test device and built a binary package that you have loaded and installed onto your iPhone or iPad via iTunes. You start the App on the device and it works. Great you want to upload it to the App Store immediately so that everyone can use it. Well no, not yet. You still have a lot to do before you can do that.

When I got to this point I set about testing it to make sure it worked the same as the Android version. It’s an Air App so it should work exactly the same right. Well it should and it mostly does but there are some differences that need to be identified and corrected for all platforms you are targeting. I found that some events do not behave in exactly the same way, especially around start up. There are also some important differences with events from Web View windows so it’s important to check it out thoroughly.

I was testing the App on an iPhone 3gs because it’s the only Apple device that I personally own. This is ok but you really do need to test it on more than one device and with more than one tester. I have a developer friend with an iPhone4 so I asked him to do some testing for me. His name is Huw Nichols

Always get someone else to test your software

Huw found some bugs for me very quickly. It’s funny how you can test your own code until you are blue in the face and still miss bugs. Luckily I am used to this and make a point of writing maintainable code that is easy to fix. This enables me to correct bugs quickly so the only real problem is discovering them in the first place. I’m always happy when someone finds a bug for me because I know that once I’ve fixed it then it’s one less bug in the App.

Conforming to Apple guidlines

Then a more pressing set of issues started to emerge. I had begun to study the Apple developers guidelines and I realized that my App didn’t conform to several of the requirements. While it was perfectly acceptable in the Android world there were some points that I felt might get it rejected by the Apple review team. There is no review process for Android Apps so there is no risk of it being rejected for non conformance to any guidelines.

Now it can take several weeks to get an App reviewed by Apple so I didn’t want it to get rejected if I can help it. It took me a lot more time to mould my App into Apple form than it ever did to fix the bugs we found. If you are developing an App for iOS then I would strongly suggest that you read the guidelines before you start to avoid lengthy delays at the end.

Well I am nearly ready to submit to the App Store. I have collected together most of the things that I will need. Icons, keywords and descriptions are just a few of the things required. I am now writing a set of review notes for the review team. They need enough description to enable them to test everything including any test accounts and other things that they will need.

Don’t leave unfinished features in your App

It was during writing the review notes that I discovered another issue that could get the App rejected. I had built in a messaging system which I had planned to activate from the server post launch. I realized that Apple might see this as an unfinished feature which is something that they will reject Apps for. After much soul searching I decided to implement the bare minimum which was to send the App a welcome message on installation. This took a couple of days to put in but I think it was worth it.

I’m hoping to submit the App to the App Store very soon so watch out for my next update.