0

SCENARIO

Our team is working on an enterprise application that we have delivered to one of our clients via HockeyApp. This particular client is having issues logging in. The issue does not happen when we use our environment, but it always happens to our client who is on a VPN using their own environment and data. The issue must be debugged by us. The client has deployed the application using Airwatch and

WHAT'S BEEN DONE

I create IPA to deploy over HockeyApp to the client.

The client has resigned the application and deployed it over Airwatch.

I have downloaded the app from their Airwatch catalog to my device.

Built+Run from Xcode to run the app to debug on my device.

WHAT HAPPENS

Before it installs to my device I get the following message:

"This application's application-identifier entitlement does not match that of the installed application. These values must match for an upgrade to be allowed."

enter image description here

QUESTIONS

1) "application-identifier entitlement". What is this?

2) (broader question) How do I debug an application that was installed from Airwatch?

Prakash Pazhanisamy
  • 997
  • 1
  • 15
  • 25
Brandon A
  • 8,153
  • 3
  • 42
  • 77
  • Possible duplicate with this article: http://stackoverflow.com/questions/32677133/app-installation-failed-due-to-application-identifier-entitlement – nynohu Feb 02 '17 at 00:31
  • No, this SO question is not the same as the link you pasted. That link just says, basically, "delete the app". If I delete the app from my device and try to build and run from Xcode it does not "upgrade" the already installed app that contains the VPN and server URL I need to connect to. Instead it installs fresh from Xcode and will not contain my client's VPN or data. – Brandon A Feb 02 '17 at 01:00

2 Answers2

1

Go to Entitlements.plist and verify the application identifier, that should match what is already installed.

I remember using Airwatch which has lot of issues, Ask the client to run your app directly without using Airwatch, If that works fine Airwatch is the culprit.Airwatch modifies your app to make it controllable, that might have caused the issue.

Madhu Avinash
  • 933
  • 2
  • 8
  • 27
0

The client should not have to re-sign the app for it to work in their environment. I suspect that is the issue, as I've run into something similar. If you are using an enterprise iOS account, you can sign the app and send them that. Have them try installing/deploying without re-signing (no need for them to do so using their enteprise iOS acct).

If it works with the signed app from your side, problem solved. AirWatch does not require the client to 'sign' from their iOS developer account at all. It just needs to have the app and matching provisioning profile from 'a' developer account. Using your own signed app should work without any issue. That was the fix to a very similar issue where a vendor repeatedly told our team it was an 'AirWatch' problem and had our devs repeatedly resign unnecessarily. Once they sent us their signed .ipa and provisioning profile everything worked without any further problem.

AirWatch does not 'modify' any app to make it manageable unless your client is using app wrapping which is likely unnecessary. If just providing an app that requires zero modification, the most likely culprit is the re-signed app the client has; and the solution is simply providing the client with the signed app you have already with the provisioning profile already embedded in the .ipa from your own enterprise iOS dev account. Again, no resigning should be necessary and is typically the root cause of the issue for these types of problems.

r3353mach1n3
  • 1