Last updated: Jun 12, 2019 11:01
Automated and Widget Scenarios and Solutions:
You are installing the app using the widgets on the Mobile Lab interactive page. You do not select any form of instrumentation. This is the error that is thrown during and after the install process.
Your application has a file inside it called the embedded.mobileprovision file. That file contains all the UDID (device ID's) for your iOS devices. Take the UDID's from the cloud and have your application developer sign the embedded.mobileprovision file with them. This will solve the issue with installing the app.
You are installing the app using Automation. You do not select any form of instrumentation. You will receive the same error as shown above in the header, and in Scenario 1.
This is the same solution as Scenario 1. Take the UDID from the iOS devices and have your app developer sign the embedded.mobileprovision file with them. This will solve the issue with installing the app during automation.
XCUI Test Scenarios and Solutions:
Scenario 1 :
You are using resign=false. It means you used in this execution your provisioning profile.
If that is the case probably the devices are not registered in customer provision profile.
There is also option to use the pre-execution resign parameter = true (set by default) and then the app will be resigned with the Perfecto developer signature.
The only issue here is that there are some capabilities that will no longer work.
Please see more about this here: Signing iOS Applications for Gradle Plugin
Application is signed with signature different of the one that is used for installation.
Ideally we would rather have customer's dev teams push the ipa/ipa-runner to Perfecto as per their build process. This is the only sure way we know that the QA team is testing proper app version (and the signature is not wrong just because they use signature for latest app version, but they are pushing old one for install and test).
In both scenarios and in case customer is using DevTunnel, please keep in mind that provision profiles must be installed on devices from customer, not by us.
Usually this is done by developer teams, not by test team.
Reason why we do not perform this actions is that in this case we would need their developer user credentials, which they might not give as per their company policy.
Or we need customer to get developer provisioning signature access, to be able to build their app with the correct signature as per our R&D documentation.