Deploying Mobile Apps to Test Devices

Testing…testing… is this app on? One of the most critical stages of the mobile development process is deploying to test devices. This process is crucial because it allows developers to identify and fix any issues before releasing the app to the public. While Appflow’s Live Update feature can reduce deployment risk with instant rollbacks, testing is still a must.

When it comes to test devices, you have two options — virtual devices, such as emulators for Android or simulators for iOS, and real devices. However, the stage at which you use a type of device, as well as how you access and use these devices, can vary. Appflow, the mobile CI/CD solution from Ionic, can make the deployment process easier for any stage and device type.

Virtual Devices

Virtual devices include emulators for Android and simulators for iOS. Both serve similar functions, but are technically a little different. Emulators have increased fidelity to real devices because they consist of both hardware and software implementations written in a low-level language. Simulators are a software-driven implementation that mimics a hardware environment. Both are easier to provision than real devices and despite their differences are typically used for the same purposes.

Because of their low cost and ease of provision, virtual devices tend to be used in earlier stages of app development. You may open a virtual device right from Android Studio, XCode, or the Capacitor CLI or VS Code plugin during your development process to quickly validate a code change or new feature.

Virtual devices are also useful in automated testing. Automated tests for mobile apps typically provide an initial review for any issues before proceeding to more thorough manual testing. Virtual devices can be used for local automated testing or in a dedicated test environment or CI pipeline.

iOS Simulator Builds in Appflow

Appflow is excited to now offer iOS Simulator builds in the cloud! This build type is unique because it does not require a signing certificate or provisioning profile. iOS Simulator builds generate a .app file that can be opened on a simulator. Because the builds happen in Appflow, any member of the team can download the .app file for testing.

To create an iOS Simulator build in Appflow, select iOS as the target platform on the build configuration screen. Then, click build! No signing certificates are needed, and unless you have custom environments or native configurations you’d like to use, it’s as simple as that.

Once the build is complete, download the bundle from the build log to open on your own simulator or share with testers. Unzip the downloaded zip, then drag the .app file onto an open simulator and the app will install so you can open and test. Simulators for multiple devices come installed with XCode.

iOS Simulator builds in Appflow are a great way to quickly get started with native iOS builds. You can go from connecting your project repository to running an app on a simulator in minutes.

Real Devices

Real devices can be used for both manual and automated testing. While real devices can be more costly to provision and manage, they are more reliable for testing because they best represent the actual conditions your users will experience. They also allow for testing specific hardware configurations.

For automated testing, some organizations use in-house real devices to run tests. There are also real device cloud services that can be used. For example, when using a real device service provider like Browserstack, a binary built in Appflow can be uploaded directly to Browserstack using their API.

Real devices are more commonly associated with manual testing. Testers can deploy build binaries to a real device for installation, usually by connecting the device to their machine and uploading the file.

Real Device Previews in Appflow

Appflow makes it easy to install the latest build of your app to a test device with App Previews. With just a scan of a QR code, open a web or Android build of your app right on your device.

Access the QR code for an Android build on the Builds list in Appflow or from the build details page. Scanning the QR code with an Android device will open the .apk file to be installed.

For web builds, make sure you first enable web previews in your settings, and then select “Web preview” on the build configuration screen. This will generate a shareable URL of your build as well as a QR code to open the build on a real device. Read more about Web Previews here.

Pre-release User Testing

The options outlined so far are all useful for developer and QA testing, but what about when you want to share your app with a wider audience before release? There are some options that make it easier to deploy test builds to the real devices of beta testers or other limited audiences.

Google Play Console Quick Sharing

Google Play Console provides a service to quickly upload an .apk or .aab file to generate a download link to share with testers. You must have a Google Play Console account and have permission to release apps to testing tracks. 

Apps uploaded to this service don’t need to be signed with a production or upload key. This makes it useful for sharing debug type builds. The download link can optionally be restricted to specific emails as well. For more details, check out the Google Play Console documentation here.

Google Play Testing Tracks

Google Play offers three types of testing tracks to deploy your app to test devices. All apps deployed to a testing track must be a signed release type build.

The internal testing track is used for quick deployments to up to 100 users. You can deploy devices that are not fully configured to internal testing tracks.

The alpha testing track is also called the closed testing track. This allows for deployments to a wider list of authorized testers.

The beta testing track is also called the closed testing track. With beta or open testing, anyone can join the testing program, and your app and store listing should be ready for Google Play Store visibility.

Here is more documentation on Google Play testing tracks.

Apple Ad Hoc Releases and TestFlight

Apple Ad Hoc releases can be used to deploy apps to up to 100 test devices per year. Each test device must be manually added to the provisioning profile used when creating the credentials for the Ad Hoc build. Ad hoc releases are useful for distributing your app to internal testers and stakeholders.

If you need to deploy to more test devices or are ready to share your app wider pre-release, Apple TestFlight may be a better option. With TestFlight, you can invite up to 10,000 testers using email addresses or a public link. TestFlight also provides tooling for testers to provide feedback directly from the app.

Deploying to TestFlight requires an App Store build type, so your app should be configured and ready for production signing. For more information on setting up TestFlight, view the documentation here.

Deploying to Beta Test Devices in Appflow

With Appflow, you can easily deploy to iOS and Android testers from a cloud build of your mobile app.

Google Play

For Google Play Testing Tracks, once your track is set up in Google Play Console, add the destination in Appflow. From the Destinations screen, select “New destination” and choose the Google Play type. Then, select the corresponding testing track type (internal, alpha, or beta) and complete the package name, publishing format, and JSON key file requirements.

Once a release build of your app is completed in Appflow, deploy to your Google Play testing track destination.

Apple App Store

Add your Apple Developer Account credentials as a destination in Appflow under the App Store destination type.

For Ad Hoc releases, register the test device IDs before the process of generating your provisioning profile for code signing in your Apple Developer Account. Once this has been uploaded to Appflow along with your signing certificate, select the Ad Hoc build type during the build process in Appflow. Make sure you select the production signing certificate and distribution provisioning profile uploaded for the build.

Once the build is complete, you can download the app binary from the build details screen to distribute to testers. Only registered devices will be able to install the app.

For Apple TestFlight, you will also need to generate a production signing certificate and distribution provisioning profile, however you do not need to specify devices in the provisioning profile. Once these are uploaded, select the App Store build type in Appflow. 

You can select the App Store destination from the build screen to automatically deploy your app once the build is complete.

Automations

You can also deploy automatically to pre-configured tracks with Appflow Automations. From the Automate screen, create a new automation and specify which branch should trigger the build and deploy. For example, you may have a “testing” branch for apps not ready for release.

Then, select the appropriate build type, signing certificate, and deploy destination. Now, whenever a commit is pushed to that branch, your app will automatically build and be delivered to your test destination.

Next Steps

When testing on either virtual or real devices, it’s important to consider what specific devices will be used to test your app. When designing your test device matrix, factors to take into account include the popularity of devices, or any specific devices that may be more likely to cause issues with your application. Browserstack provides usage statistics on devices that can be helpful for your own strategy.

Regardless of what stage of testing and what type of device you use, Appflow has solutions available to build a test version of your app and deploy to devices. To learn more about Appflow, get started with a free trial here.