iOS App Resigning
Real Devices Only, iOS devices only
Apple requires that any app that runs on a real iOS device is "signed" with a certificate that was issued by Apple. Signing is a security measure: it proves the app comes from a trusted source, so iOS devices only allow signed apps to run.
Instrumentation features on iOS require changes to the source code of your app. After these changes, the app must be re-signed to run on a real device.
This has three consequences for running iOS tests on Sauce Labs real devices:
- If you want to use any of our Instrumentation features, resigning must be enabled; otherwise, your app cannot run on the device after we have modified its source code.
- If you want to use our public devices, resigning must be enabled; otherwise, public devices will refuse to run your app.
- If you do not want us to re-sign your app, you may only use private devices and cannot use any Instrumentation features.
How to Enable and Disable Re-Signing
For Appium: Use the 'resigningEnabled' flag in the Sauce Options: disable resigning.
For XCUITest & XCTest: Use the 'resigningEnabled' flag in the saucectl config: disable resigning for XCTest.
For Live Testing: Change the settings for your app in the App Management UI and enable the 'Instrumentation' flag.
Sometimes, the terms "instrumentation" and "re-signing" are used interchangeably in our documentation. This is because re-signing is required for any instrumentation features on iOS, while Android only uses instrumentation without re-signing.
Side Effects of Re-Signing Your App
Sauce Labs applies its own resigning to apps that are installed on our public iOS devices. Our resigner includes the following keychain-access-groups entitlements:
| Key | Value |
|---|---|
application-identifier | <string>XXXXXXXXXX.*</string> |
keychain-access-groups | <array><string>XXXXXXXXXX.*</string> <string>com.apple.token</string></array> |
get-task-allow | <true/> |
com.apple.developer.team-identifier | <string>XXXXXXXXXX</string> |
com.apple.developer.ubiquity-kvstore-identifier | <string>XXXXXXXXXX.*</string> |
com.apple.developer.ubiquity-container-identifiers | <array><string>XXXXXXXXXX.*</string></array> |
inter-app-audio | <true/> |
com.apple.developer.networking.networkextension | <array><string>app-proxy-provider</string><string>content-filter-provider</string><string>packet-tunnel-provider</string><string>dns-proxy</string><string>dns-settings</string></array> |
com.apple.developer.siri | <true/> |
com.apple.developer.pass-type-identifiers | <array><string>XXXXXXXXXX.*</string></array> |
Common Errors
Unable To Verify App
If you are facing the issue where the app crashes with a red screen and an "Unable to Verify App" popup:
This means your proxy might be blocking Apple's signature check for installing custom enterprise apps on iOS. Apple has recently started rolling out a new signature verification and PPQS check for new provisioning profiles and our new accounts. During installation, Apple sends an initial API request to verify the signature of the app.
We recommend that you try the following workarounds:
- Disable the proxy for the device you are using to install the app.
- If the above solution does not work, try using a different network without the proxy.
We do not have control over Apple's signature verification process. It is recommended to work with your network administrator to ensure that Apple's signature check is not blocked by the proxy.
Unable to Access Downloads Folder Using 'fileImporter' SwiftUI API
Apple prevents access to private sandbox data via fileImporter (and likely other APIs) after resigning an app.
The console may contain one of the following error messages:
Could not resolve bookmark
Failed to create a url from bookmarkableString
Tried to call delegate -documentBrowser:didPickDocumentURLs: with an empty array of item