Mobile Development with Cordova (Phonegap): Chapter 7

Chapter 7: Beta Testers

Let's continue on with that default Cordova app, the one that does nothing except say Device Ready, and discuss how you'll work with beta testers. Again, your own programming style and needs will dictate how you program your app, and the real challenge is everything else: distribution, emulators, and so on.


So, beta testers. If someone wants to beta test an app, the techniques for Android and iOS are quite different.

Android

Simply get them the APK file through any convenient means. If the APK is small enough you can email it to them, but you can upload it to any convenient website, send it via Dropbox, etc.

When they open the APK, they will be prompted to install it. Easy.

Tip: Some Android phones have a default setting that they will not install any apps that do not come from the Market / Store. If the application will not install, they should check their Settings to see if this option is used.

Tip: If the digital signature has changed, and they're upgrading an existing app, they may need to uninstall the current one. This is why I always use the --release flag, it omits this accident.

iOS

An iOS device will only run an app, if the app's Provisioning Profile specifically mentions that device. Unless the specific iPhone, iPod, or iPad is already listed in the devices section, the device will refuse to run it. This means that you will need to:

• get the beta tester's device ID (UDID) via iTunes
  This tutorial is helpful:  http://whatsmyudid.com/
• enter it into the Devices list on the Apple portal
• generate a new Provisioning Profile on the Apple portal
• load the new Provisioning Profile into Xcode
  Xcode / Preferences / your identity / the reload button at the bottom
• build the IPA using the Archive tool

Tip: Remember that all beta testers must be mentioned in the Devices and the Provisioning Profile. Remember that FFFF UDIDs are not valid, and as of iOS 7.1 many "find your UDID" apps now give inaccurate answers.

 

You cannot simply email the IPA file to the beta tester. 

iOS has a special technique called Over The Air (OTA) installation. If you have already created an OTA website for this app, you should be able to replace the IPA and have your beta testers hit it. If you're uploading a second copy with a special build/feature for somebody, then create a second manifest file and create a second hyperlink in your index.html file.

But if you've not yet created an OTA setup for your app, here's how:

• Get a website that is hosted via SSL (https URLs).  Important: The URLs used in this process server MUST be via SSL (https) and the certificate must be a paid, signed certificate. Self-signed certificates will not work, and will give certificate errors. An expired certificate will also give errors.
• Upload the IPA file to the webserver. You'll want to stick it into its own subfolder so you can have multiple builds, as well as the supporting files to facilitate the downloading process. Note the URL of the IPA file, and test it in the browser using an https URL to make sure it tries to download, e.g. https://www.example.com/mobileclients/democo/storeapp.ipa
• Use this handy template and create a file named manifest.plist, uploaded into the same folder.
•  Then use this handy template to create a file named index.html, uploaded into the same folder.
• Make some edits to the manifest.plist file:
  - Line 14, the URL to the IPA file which you determined in step 1
  - Line 20, the reverse-domain name of the app, e.g. org.greeninfo.parkinfo
  - Line 22, the version number, e.g. 1.0.0
  - Line 26, the title, e.g. ParkInfo Mobile
• Make some edits to the index.html file:
  - Line 7-8, the hyperlink and optional text; fix the URL to point at the manifest.plist file as per step 3
  - Your project likely won't distinguish Alpha from Beta; you probably only want one hyperlink at the moment
  - Then any other cosmetic, wording, link names, etc. that may inspire confidence in the beta testing technique such as the title

Beta testers should now be able to visit the website you just set up, and click the link to start installing the app on their iPad.

If the app won't install, there's only the one message that it couldn't be installed, which is not helpful. THere are a few things you can do:

• Unzip the IPA file (it's actually a digitally signed ZIP file) and look through the contents.
  The embedded.mobileprovision file will have a list of certificates and devices.
  Check that the UDID really is on the list.
  Tip: It's digitally signed so has some binary crud, but your editor should still be able to open it.
• Check their UDID again, and ask if they used an app or just copied down some number from their settings page. People really do resist plugging in iTunes, and will sometimes send multiple UDIDs trying various other strategies.
• Check that the Provisioning Profile is not expired.
  They are only good for 6 months, and customers do tend to let projects slide for a while.
  If the PP is expired, generate a new one, load it into Xcode, and Archive and upload again.
• Check the Build Settings for architectures.
  iPhones are usually arm7, arm7s, or arm64 and all architectures should be selected.
• If you can get your hands onto the device for a little while, the best debugger is the Console, available via Xcode's Device Organizer when the device is connected via cable. The messages "cannot verify executable" and "MSIVerifySignatureAndCopy" indicate a signature issue.
  Unfortunately, this means that you must have physical possesssion of the phone while at your development Mac.