If you are building a mobile application with an agile process then you know that dropping a release and getting feedback on it is critical to the success of the project. For those that have not done it before, this can be quite daunting. The goal for this post is to help idenitify how to build for both Android and iOS as well as understand the restrictions in place for the platforms.
For Android, this is a pretty easy task. We assume that you have already created a signed APK. If you would like some guidance on how to do that, please see Pragmatic Titanium with Android and iOS platform tools. Its suggested that you increment the version number on your apk whenever you create a new build. Once you’ve built your APK, publish it to a publicly available location on the web. For example, I tend to use basecamp for managing client projects and will directly post the APK there. The upside for this is that its already locked down with team security but is also easy for users to get to.
Users should have their device enabled for installing non-marketplace android applications. To change this, have users open their settings and enable “Applications” > “Unknown Sources”.
Have the users remove the application completely from their device if they have already installed it – this will eliminate things like stale resources, etc as you QA your application.
Have the users open the url in their browser on their device and have them click the “more” menu button.
Click the “Downloads” menu button.
In the app listing, have them click the apk.
This will prompt the installation, click the “Install” button.
The installation confirmation will appear. Click the “open” button. When you click “open”, the application launcher may require you to restart the application, do not fret, this is normal.
Now that we’ve identified how to distribute the build for Android, lets focus on QA feedback. To that end, screenshots are an essential way for users to provide precise feedback because it removes uncertainty and shows explicitly the rendering of the UI on the device. Unfortunately this is a bit difficult for Android compared to iOS. One way that works great is ddms, but previous experience has shown that not many people testing my applications are equipped to install the android SDK on their laptop. Another alternative if the device is running Android OS 4.0+ is for them to hold down the volume and power at the same time. Outside of that, some hardware vendors implemented their own proprietary key-combos that you can potentially look up.
Shifting gears now, lets focus on the restrictions for distributing an iOS application for QA:
- Corporate Apple account provides 100 seats for a calendar year – this means that if you use a device seat and remove it, you will have to wait 12 calendar months until that seat is again available. 100 may sound like alot, but they can be consumed quite quick actually
- Enterprise Accounts allow for unlimited installations with an enterprise distribution – this is great, unfortunately getting an enterprise account with apple is no small thing
- Development distributions require the development profile to be installed on the device – when developers are running and installing to their local device, then they are usually using development profiles which is great because each developer has their own development certificate
- Ad hoc distributions require all device entities to be in the profile
adding a device to a profile retroactively has no effect (still requires rebuild). Because the ad hoc profile is a distibution profile, it requires the build agent to create the distribution (that or share the distribution certificate)
With these constraints in mind, these are the options available for creating a QA application distribution
- direct USB install via xcode run
- distribute through iTunes (IPA) – this is what Titanium does for installing an application to your device
- distribute via diawi (include profile and IPA)
- distribute via Test Flight (ad hoc only)
Of these options, Test Flight is the only option that we use anymore for serveral really good reasons.
- allow users to register devices (simpler than directing users on how to send the UDID)
- tracks user installs (version, etc)
- controls permissions/access to distributions
- team collaboration (announcement of applications)
- its free
- (advanced) crash reports
- (advanced) feedback along with user tracking
These are the provisioning steps to get you going with TestFlight
- create a testflight project at http://testflightapp.com
- invite team members and have them register their device. The easiest way is to have them open their invitation email on the device
- in the iOS provisioning portal, create a distribution certificate
- create a fully qualified appid (dont use wildcards)
- import all the device tokens from above
- create an ad hoc provisioning profile (under distribution)
- install the ad hoc profile on the build machine
- run the app in the simulator to open the xcode project
Select the app target and under “Build Settings”, set the “Code Signing” values.
Make sure that your device is selected under the active scheme (ex: AZ iPhone 4s). Click “Product” > “Archive”. In the organizer, click “Distribute” and then “Save for Enterprise or Ad-Hoc Deployment” and save your IPA to file.
Click “upload build” and put some notes in. In the confirmation page (permissions), select the team members you want to notify and click “update and notify”. alternatively you can share the short url (http://tflig.ht/SsUqnn)
The users will be sent an email, have them click the install button.
They will then be prompted on the device to install the IPA.
Now that they users have installed the application, they can capture screenshots by holding down the power button and then tapping the hardware menu button. This will store the screenshot in their camera/media library which they can then sync with their laptop or forward the images via email/text.
As you can see screenshots are a bit simpler for iOS, while the packaging and distribution is a bit more involved for iOS. Tools like TestFlight may not be as critical for Android because of the less stringent packaging restrictions, however TestFlight does provide additional value beyond this that is a current gap for android.