When Written: June 2014
The work on my mobile App progresses, final testing has been completed and tweaks to the graphics have been done, everyone involved in the project seems to be happy with it, so now is the time to submit it to the stores for it to be available to users. However as this is going to be a chargeable App, the first stage is to set up the details for the bank account that the App purchases will be paid into. This is a fairly painless task with both the Google Play and the Apple iTunes store, I shall not be covering the Windows Store in this article as this particular App will not run on Windows phone devices currently.
For iOS Apps you need to visit iTunesConnect ( https://itunesconnect.apple.com ) and go to the ‘Contracts, Tax, and Banking’ section, there will probably already be one contract set up because of your testing using ‘ad-hoc’ builds, this contract is for free applications and if that is all you need you can leave it there. However as we are charging for this App then we need to tell Apple which back account we want our Apps earnings transferred into. There are several stages to this including US tax requirements that need to be confirmed, but it is not too onerous. You will also need to set up a third contract if you want to take revenue from placing adverts in your App. The Apple system seems to ‘know’ about all the banks and relevant accounts whereas the slightly simpler to fill in Google Play store does not activate the accounts until it has sent a small deposit to the account you have specified and you have confirmed this by entering this amount on the web page.
This is perfectly acceptable way of confirming that the account exists and does at least make sure that any future payment will go to the correct bank account but it does mean that there is a delay of a few days before your Google Play account is available to take payments so obviously bear this in mind when planning your App’s launch. The Google Play store uses ‘Google Wallet’ for accepting transactions and it is this that you have to set up if you have not already done so for a previous use.
Once you are happy that these accounts are set up, you are ready for the, hopefully, torrents of money that will be coming your way then you can start to consider moving your App from beta to a full publish. This is a very good time to check that all the description text, keywords and screen shots are correct and up to date, it really doesn’t look very good if your App launches with a description of “My mega App” or with embarrassing details on the screen shots of the App working! With your iOS build you will have to rebuild it as an ‘iOS Production’ rather than your previous ‘AdHoc’ build used for testing. With your Android App it is simply a case or promoting your beta App to production. Your iOS App will need to be approved before it will go live so again there will be some delay before you can start promoting it, so make sure you warn your marketing department of these delays before they start their promotions.
Once published and hopefully users have downloaded it from the stores you can use both the stores to monitor downloads, comments, ratings and even crashes of your App. It is extremely important that you keep a close eye on these, as a simple bug in your program, if not fixed quickly will result in poor ratings and a drop in the ranking of your App. With so many Apps available hoping to get to the top ranking without promotion would require a lot of luck or an amazing App, the sort that solves world poverty or perhaps better, one that makes you irresistible to a particular sex! Lynx are probably working on this as I write! To increase your chances of being seen in the crowded App stores, I suggest that you follow Kevin Partner’s suggestions in his articles in this magazine about promoting your product online.
During the writing of this series of articles about developing mobile Apps using HTML5 technology I have had several enquires as to whether it was possible to write Apps for Blackberry in the same way. Now whilst Intel’s XDK development tool does not currently offer a build option for Blackberry, the build for web App option works fine on these devices, but you cannot submit this to the Blackberry World store. This would minimise the chance of your App being seen and of course make charging for it tricky. So I was pleased to see that the Blackberry developer site now has an HTML5 development tool itself. This is called WebWorks (https://developer.blackberry.com/html5/download/
) which uses the Apache Cordova framework. If you use this you can then submit your App to their store for distribution.
WebWorks, nice start but needs more work BlackBerry.
The reason was that my machine has a relatively small drive C: as it is a 250G SSD drive, I try to install and create my work files on the 2T RAID drive D: that is also in this machine. WebWorks by default looks at C: for these certificates, you can tell it otherwise, but it seems to ignore you if you do, I gave up and in the end created the locations and files it was looking for on drive C: the build then progressed a little further but it reported that it needs a debug token or a release token and to generate one of these you need to ‘execute the run command’ no help as to where this is or what this involves. You can’t seem to do this from the WebWorks UI.
After trawling through the on-line documentation I found out that this required the running of some command line scripts and the debug tokens time out after 30 days, even if you only want to test on the free BlackBerry simulator, talk about making things difficult! Come on BlackBerry this really is not good enough, I totally understand the need for signing for security, but please make the process obvious and easy. No wonder developers look towards other more switched on platforms to write for. One nice point here is the free simulator for BlackBerry is however rather good as it is a proper virtual machine and not just a browser based version of the device.
I have written before of the limitations of using browser based mobile emulators and their limitations for emulating the more involved device properties, but using a virtual machine the BlackBerry should do a better job of emulating some of the more involved device issues when testing. I will be having a further play with this, but for now I have a few deadlines to meet!
Article by: Mark Newton
Published in: Mark Newton