You may have given test builds to friends and colleagues all the way through the process of developing your app, but even if you haven't, it becomes more important to do so as you get closer to the time when you have to upload the app to the app stores. Beta testers can tell you about technical and nontechnical issues. Are there any typos in the Credits? Does the icon look good? Were there any strange aspects to the installation experience? And of course, does the app do what it's supposed to do on the numerous devices and OSes?
The process of making an app to send it to a tester is different on Android than on iOS. In fact, it's incredibly easy on Android! Let's look at that first.
When click on the Save as Standalone Application… option for Android, you create an APK file. You could e-mail this file to your testers and they could do what is called a "side load" of the file on their device. In Chapter 2, Getting Started with LiveCode Mobile, we saw how tricky it can be to connect an Android device for testing and it could well be beyond the technical abilities of some of your testers.
Fortunately, there is a much simpler approach to do this. Take the APK file and put it online somewhere. It can be on a Dropbox shared location, Google Drive, or perhaps just a server at your office. Whatever it takes for you to get to the point where you have a URL that has a link to the file. Now e-mail that URL to your testers to an e-mail address that they can read on their devices. Then, it only takes a single touch of the link in the e-mail for you to start the download and installation of your app.
There is a Development section in the Android device settings that the testers may need to visit to enable the feature that allows apps to be installed in this way, but it's very easy to make this change.
Things are not quite as straightforward for iOS! First thing you need to do is add the unique device ID (UDID) for each of your beta testers' devices to your iOS developer account. Your testers can get that number by connecting the device to their computer and viewing its Info in iTunes. When you're looking at the Summary section, you will see the serial number for the respective device. Clicking on that number will make it change to a longer number, the UDID that will be needed. Once that number is displayed, you can use a keyboard shortcut to copy the number to the clipboard (command + C on Mac and Ctrl + C on Windows). Have your testers perform these actions and then paste the number in an e-mail to you. You must make sure that you get the number right because it will use up one of your 100 allocated devices of your iOS developer account.
Go to https://developer.apple.com/account/ios/device/deviceList.action in order to add the devices to your account. Click on the + button just below the place where your name appears and you will be able to add the devices to your account:
Next, go to the Provisioning Profiles section and either create a new Development profile or select an existing one and click on the Edit button. After selecting an App ID and a signing certificate, you will then see a list of the devices associated with your account. You can enable any combination of devices you want to work with this provisioning profile. In this screenshot, you'll see that the pool of test devices is very short:
Click on the Generate button and after a few moments, you will be able to click on the Download button to download the file.
Download the new profile and add it to Xcode (just double click on the downloaded file). Open your app's Mainstack in LiveCode, go to Standalone Application Settings…/iOS, and make sure that the provisioning profile is selected from the Profile menu. Click on the Save as Standalone Application… option again to make sure that the new devices are known by the app.
By now, you will have an "APP" file, which is the iOS equivalent of the "APK" file for Android. As with Android, you could e-mail this file to your testers along with the provisioning file and have the testers "side load" it onto their devices. In this instance, that's not such a difficult task because the tester can use iTunes to do the same. If you do go down that route, have your testers drag the "APP" and provisioning files onto the Library in iTunes, connect the device, view the Apps tab, make sure that the new app is selected, and perform a Sync. However, it is possible to make things a lot easier for your users, as easy as they were for Android users.
Since iOS 4.0, it has been possible for us to install an app from a link in a web page. Creating the file structure for this to work is a bit tricky though, but fortunately, there are at least a couple of tools you can buy to make things easy for you.
HyperActive Software has made a LiveCode plugin that can take your "APP" file and make the file structure needed for the "over the air" installation to work. There is just a single dialog box that you need to fill the required information in:
After selecting the "APP" file, you only need to enter the URL where the folder will be when it's online and then click on the Create Files button. The URL link to your online app will be confirmed at the bottom of the window. Click on the URL to copy it and then e-mail it to your testers. When they visit the web page on their device, there will be a single link to touch and iOS will prompt you for approval to install the app. If you look at the next available position on your home page, you will see that it is being installed or is already installed if you are not quick enough.
Note that Apple requires a secure server for this to work and the URL must start with HTTPS. The easiest source is to use a Dropbox public folder, though you need to make it secure if you've signed up for Dropbox after October 4, 2012. Refer to the AirLaunch FAQs for further information at:
http://hyperactivesw.com/airlaunch/airlaunchtips.html
Tip
AirLaunch workflow in development
AirLaunch can be installed as a LiveCode plugin and can be run right after you create a standalone version of your app. You can save the installation web page on your iOS device and click on it to launch the installer. This method is a lot easier to test your app during development than connecting a cable to your device and dragging the app into Xcode.
BetaBuilder can be found in the Mac App Store at:
http://itunes.apple.com/us/app/betabuilder-for-ios-apps/id415348946?mt=12
It wasn't made with LiveCode in mind and works with "IPA" files and not "APP" files. An easy way to convert the LiveCode APP file into an IPA file is to drag the APP file into iTunes and to select Show in Finder by right-clicking on the app in the Library. This will reveal the IPA file that you can drag into the BetaBuilder window.
The process is much the same as AirLaunch's process, where you select the file to use, enter the URL of the online folder, and the program generates the files for you. Again, this all happens in a single dialog window:
Both products create similar files as illustrated in the following Dropbox public folder:
Both products make life easy for your testers. AirLaunch has the advantages of being a plugin that works within LiveCode, which you're likely to have open anyway, and working directly with the APP files that LiveCode creates. BetaBuilder is a Mac app that is run separately and requires you to transfer the files to your server using some other Mac application. AirTouch has FTP built-in to streamline your workflow.
BetaBuilder's main advantage is that it's incredibly cheap! It also generates a web page that is more informative than AirLaunch, which shows just a simple link with the name of the app. However, AirLaunch allows you to export the template and edit or integrate it into your website.
A service named TestFlight was in place during the time I was writing the first edition of this book that worked similar to AirLaunch and Beta Builder. In 2014, Apple purchased TestFlight and merged it with iTunes Connect (iTC) that is used to submit apps to the Apple App Store. TestFlight is a lot more than what you need to just send out personal apps to a few testers, but it is required while dealing with apps that go out to as many as 1000 testers. One big change is that you will also need a Distribution Profile and Certificate to start the submittal process as described further in this chapter.
TestFlight has two levels of testing: Internal and External. Internal testing is for members of your development team. You can add up to 25 internal testers using the Users and Roles section of iTC and assign them a Technical role. They will get an e-mail invitation and need to activate an iTC account. When you start testing your app, they receive another e-mail announcement and need to download the TestFlight app to their device that must run iOS 8 or its later versions. The TestFlight app then installs your app for testing. The test only lasts for 30 days unless you update it and submit a new version. The TestFlight app can also be used for error reporting and feedback.
External testing is similar, but requires a Beta App Review and must comply with the full App Store Review Guidelines before the testing begins. A review is required for new versions of your app that contain significant changes. Up to 10 apps can be tested at a time, internally or externally. You can add up to 1000 external testers just by supplying a list of their e-mail addresses and checking whether you have their approval. After releasing, the testing proceeds in the same manner as it did with internal testers. At the time of writing this book, a tester could not be on both the internal and external lists. Refer to https://developer.apple.com/testflight/ for further information.
Note
Missing push notification entitlement
In early 2015, you would get this e-mail warning message while submitting an app to iTC: "Your app appears to include API used to register with the Apple Push Notification service, but the app signature's entitlements do not include the "aps-environment" entitlement." This is an issue in LC and does not affect anything. Apple's Push Notification Service is built in the LC engine and LC doesn't bother to strip it out if you don't use it. It is documented in bug 10979 in the RunRev Quality system at http://quality.runrev.com/process_bug.cgi.
While testing with the Android Emulator or direct connection should be sufficient to learn LiveCode development, the real world is much more complex. In the last several years, testing alternatives have emerged to help test your apps on other Android devices. With numerous Android devices, this is really needed. There were 8614 listed in the Google Play store at the last count and many more must've been listed even now, when you read this. There are also variations in the Android OS available at Amazon, Samsung, and others. Hopefully, testing through Google testing resources will be adequate for your needs.
Google also has a testing capability built in their Google Play store. As with Apple's iTC and TestFlight; for Google, you have to prepare your store list and upload your APK just as you would when publishing it. To distribute to testers, you need to create and select a Google Group or Google+ Community that the testers join. Google has alpha and beta tests, which are similar to Apple's internal and external testing. Notification e-mails are sent to testers with a link to the testing section of Google Play. Because your testers can't leave public reviews for alpha/beta apps on Google Play, it's a good idea to let them know where they can provide you feedback (an e-mail address, website, and so on). Further details can be found at:
https://support.google.com/googleplay/android-developer/answer/3131213?hl=en
Amazon has a tool called Live App Testing to allow developers to beta test apps through the Amazon appstore. Developers can invite up to 500 specific users to test the app through an e-mail invite. In addition to this, the A/B Testing Service allows to conduct in-app experiments to try different UI interactions with different groups of users. It supposedly also supports iOS, but requires specific APIs that would need development of LiveCode externals.
For more information refer to:
To facilitate testing of apps, Samsung has developed Remote Testing Lab (RTL) facilities. These labs contain real devices that allow developers to upload and test their apps. To use these devices, you need to download and run a Java applet that connects your APK to a live device in the Samsung lab and provides an interface to interact with this device. This may have some potential in the future, but is included here for possible investigation. For more information on Samsung testing, refer to http://developer.samsung.com/remotetestlab/rtlAboutRTL.action.
Tip
The previous testing alternatives are the primary alternatives associated with the iOS and Android device manufacturers. Since Apple bought TestFlight, several other cross-platform testing solutions have picked up the slack. A quick search on the Internet shows HockeyApp, Crashlytics, Ubertesters, TestFairy, and others that may have potential as well.