App packaging and signing services

Digital Lab supports testing both packaged and non-packaged native and hybrid apps.

In this topic:

When to use a packaged app

A packaged app is an app that Digital Lab has repackaged with instrumented libraries.

Although both packaged and non-package apps are supported by Digital Lab, packaging is still required in the following cases:

TruClient scripts	To generate transaction response time information. You must also define Object Exists end events in your TruClient script steps (for native apps).
Simulation	For photo, video, and fingerprint authentication simulation. iOS GPS simulation also requires a packaged app.
Hybrid apps	When conducting performance testing of hybrid apps.

Additional considerations

There are also some differences between packaged and non-packaged apps in the following areas:

• Full Device Automation functionality such as cross-app recording and recording of system apps is not supported in packaged apps.
• Support for touch gestures.
• Object recognition.
  For more details, see the known issues section in the Digital Lab Support matrix.
  For UFT One, see also the Object Model Reference (OMR) for mobile in the UFT One Help Center.

Back to top

Considerations when using non-packaged hybrid apps

When using non-packaged hybrid apps, note the following:

Android apps	Remote content debugging must be enabled. For details, see Enable remote content debugging of Android apps.
iOS apps	Apps may need to be signed with a Development certificate of either an Apple Developer or Enterprise Account. For the certificates required, see iOS app signing.

Back to top

Digital Lab packaging and signing services

Digital Lab supports testing both packaged and non-packaged native and hybrid apps. This gives you the option of selecting either a packaged app, or the original version, when running a test.

Whenever the content of an app package is changed, for example when the app is repackaged with instrumented Digital Lab libraries, the app also needs to be re-signed. If the app package is not re-signed, the app cannot be installed on a device.

When you upload an app, by default only the non-packaged version of the app is uploaded. To upload both a packaged and non-packaged version of the app, select the Package the application check box when uploading your app.

Android apps

When the Package and re-sign the application option is selected, Android apps uploaded to the Mobile Lab are automatically packaged with instrumented Digital Lab libraries and signed with a debug certificate. However, if you want to package an Android app that uses services requiring a private key, such as Google Maps or the Authentication service, you need to configure the Android app packaging and signing services. For details, see Automatic signing services. Note: For better performance, the minSDKversion for packaged Android apps should be 21 or later. You can also package and sign apps manually and then upload them to Digital Lab. For details see, Package an Android app manually.

iOS apps

To enable users to sign apps when uploading them to Digital Lab, the administrator needs to set up Automatic signing services. If you have not configured the signing services, you cannot select the Re-sign the application option on upload. You can also package and sign apps manually and then upload them to Digital Lab. For details see, Package an iOS app manually with the packager service, or Package an iOS app manually with the iOS Enabler.

Back to top

Multiple signing services

When working with many devices and workspaces, you may need to use different signing services for your devices. For example, in iOS environments you can only sign up to 100 devices with a single certificate. In addition, you may need to provide a solution for one group without having to rely on the certificate from another group.

Admin users can define other signing services in addition to the primary service, and assign them to different workspaces. After you assign a signing service to a workspace, all apps uploaded to that workspace are signed with the iOS signing service defined for that workspace. As an admin, you can also remove signing services, but not the primary one.

Note that the Agents are always signed with the primary service. For details on how to distribute the signed Agents, see View and manage connectors.

Back to top

iOS app signing

To test an iOS app with Digital Lab, you may need to re-sign your app. This section explains when you need to re-sign an iOS app.

Agent apps

The Agent apps must be re-signed with a Development certificate of an Apple Developer Account, and a development provisioning profile belonging to the same account. For details on signing the Agent apps, see Re-sign the Agent apps

Other iOS apps

The following table details when app signing is required, and what certificates can be used for signing:

Application under Test	Mode	Re-sign required?	Required certificate
iOS native app	Packaged app	Yes	Any type of certificate of either an Apple Developer or Enterprise account
iOS native app	Non- packaged app	No, unless your organization needs to re-sign the app for some specific reason.	Any type of certificate of either an Apple Developer or Enterprise account
iOS hybrid app	Packaged app	Yes	Development certificate of either an Apple Developer or Enterprise account
iOS hybrid app	Non-packed app	Yes Note: Re-sign is not required for the following: Exploratory test recording UFT One 15.0.1 and later only, when Hybrid v2 is enabled. When using App store apps or apps signed with an Enterprise certificate, toggle the Hybrid v2 option in the device control panel to ON.	To identify WebView, development certificate of an Apple Developer account.

Back to top

See also:

• Package an iOS app manually with the packager service
• Package an Android app manually