I have developed an app in the in-house, enterprise mode. While testing i was using the iPad provided to me by my company. I tested on it. I had certificates from developer member center. Tested just fine.
Now I have deployed the files on our secure server.I have a link where the ".ipa" files are present. So i used my same testing iPad and downloaded the app from that link via safari on the iPad. It installed and ran successfully. Now i gave that link to another member of my team and he has his own iPad. When he clicks that link it starts installing but it doesn't finish.He gets an error.The error he gets is
"Unable to download Application.XYZ app could not be installed at this time. Done .Retry."
Same thing with another iPad. These iPads are NOT registered under testing on member center. So i have a thought. Since while testing i had certificates and all on my testing iPad, it might have recognized it and installed it.But the other completely new iPads are not identified. So how do i do it?How can i say my app that it is safe to install on so-so iPad that belongs to my co-worker. If i am not clear please ask.Thanks.
bobnoble is correct. You need to have an Enterprise Distribution certificate to use with this. Development certs are similar to ad-hoc certs in that you need to individual identify the device UDID's that will be used.
We do a lot of work with enterprise customers and I never use the development certs, mainly just to cut down on the confusion. It might be a problem if one of our devs goes rouge :), but it is a chance we are willing to take.
In xcode you can select the Project or the Targets when assigning the provided profiles.
Make sure you sign the target.
There is a nice tutorial on the testflight site:
http://help.testflightapp.com/customer/portal/articles/494413-how-to-create-an-ipa-xcode-4-3-
You are getting confused between a Distribution Certificate and an Enterprise Certificate. In your case you should use Enterprise or Adhoc Certificate. Enterprise certificate is not given to a person but organization and it is not created where other certs are created.
Related
I see that this question has been asked many times but I see no solution that works for me so I'm hoping that providing more info might shed some light.
We use appcenter.ms to test iOS apps. Until our iOS certificate expired this method worked fine. We generated a new enterprise certificate and ad hoc provisioning profile for new releases of the iOS app. Which led to the first curiosity.
I see how to upload a certificate on appcenter.ms but not a provisioning profile. I thought there was an option to do this in the past but perhaps I am mistaken. However, the app is signed with a provisioning profile before upload, so perhaps this is not needed now.
Once the app is uploaded, it can't be installed. It remains grey and when you tap it, you get the "this app cannot be installed because its integrity could not be verified" error. Again, that the .ipa is created with an ad hoc certificate and profile in Xamarin (VS for Mac).
Also, I can't install the provisioning profile on a device from appcenter.ms. You basically get stuck in a loop where you seem to successfully install the profile but have to keep doing it because it never actually installs.
I hope this is enough info for some insight and thanks in advance for any feedback.
We were able to solve this by redoing and downloading development certs and via
And also downloading and double clicking the apple development certificate here
After that our keychain showed both as trusted and we could build to the iPhone again.
The issue can be the your device is simply not registered on the developer portal and/or that ad-hoc provisioning profiles have not been regenerated.
You need to register your device, regenerate a provisioning profile with this device in it and rebuild your app using this profile.
This can also happen because of
Developer ID Notary Service - Outage
which can be checked on https://developer.apple.com/system-status/
Notarization is well explained here:
Notarization gives users more confidence that the Developer ID-signed
software you distribute has been checked by Apple for malicious
components. Notarization is not App Review. The Apple notary service
is an automated system that scans your software for malicious content,
checks for code-signing issues, and returns the results to you
quickly. If there are no issues, the notary service generates a ticket
for you to staple to your software.
Work around fix:
Select your app.
Navigate to TextFlight tab
Create External Testing group
Add one tester
Add build which you want to download using TestFlight
Open TestFlight and download an app.
In my case this was caused by trying to include an entitlement for aps-environment "development" when using an Ad-Hoc provisioning profile. The value for this environment in Entitlements.plist must match what is hard coded into the provisioning profile file - if you open an Ad-Hoc profile in a text editor you will see it expects the "production" environment.
The possible solutions depending on your requirements are to either use the Development profile/certificate, or change the aps-environment to "production" to continue using an Ad-Hoc provisioning profile.
It can also happen if you have other incorrect entitlements - worth checking what entitlements are enabled under the Identifier in Apple Developer portal and removing unnecessary ones.
I had this issue because when building the app on xCode for distribution (Product->Archive then Distribute App), I chose automatic signing. After manually signing the app and choosing my own generated certificate and profile, everything worked again fine.
I removed the Entitlements file from the Addition Resources in iOS Bundle Signing and it worked.
I think the MSAL configuration was set to debug in entitlements.plist
I have also face this issue before but for me the reason was little different
First the build was enterprise one and the build was made on the earlier Xcode version on which the iOS version you are using on the device was not supported by the Xcode.
All I did was to update my Xcode and make a new build and shared the build. After that we were able to install that build over device Hope it works for you as well
This is how I solved for myself.
In you iPhone Settings > General > VPN & Device Management you should see your company name (if an app from it is installed), and if you click on it, you will see a button like "Verify" above the list of apps installed provided by the company. Just click on "Verify".
I've been trying to make sense of how to do test automation for an iOS app using AWS DeviceFarm and there seems to be a vacuum of information on how an .ipa is allowed to be installed and run on a random DeviceFarm iOS device. I'm a bit new to Xcode, so maybe I'm missing something.
In Xcode, when you archive a project you have to choose an export method.
I have to rule out the App Store option because my aim here is to test.
Then, the Development and Ad Hoc options require a list of UDDI's, and since the idea here is to test on DeviceFarm with whatever device they assign you on the fly, these two options seem to be ruled out.
Which only leaves the Enterprise option open. BUT... does this mean that in order to use DeviceFarm for iOS testing I must be enrolled in Apple's Enterprise Development Program??? Seems a bit harsh.
So, which of these options are compatible with DeviceFarm, and why? I mean, the only possible answers I can think of are:
A) AWS has jail-broken all of their iOS devices and so the UDID list not relevant.
B) AWS resigns all uploaded .ipa files with their own certificate and uses an Ad Hoc or Enterprise provisioning profile of their own to install and run them.
I'm aiming to use TestNG test scripts btw. Don't know if that's relevant or not.
Mig82,
The iOS devices within AWS Device Farm are not jailbroken. In order to install custom applications on the devices, uploaded IPA files are resigned with a wildcard profile, as noted here in the documentation.
Exporting your app using Development Deployment should work just fine as it will sign it with your Developer Certificate but not require you to define a set of test devices by UDID.
Hope that helps!
Disclaimer: I previously worked on AWS Device Farm.
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."
QUESTIONS
1) "application-identifier entitlement". What is this?
2) (broader question) How do I debug an application that was installed from Airwatch?
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.
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.
I've created an AS3 app with Adobe Flash CC. I'm using AIR 3.9.
It works great on android devices but when I've created an .ipa file and transfer it to my Ipad (with IO7), my app is visible but freeze on "installing" (nothing's happening.)
Do you know what could be the problem ?
Thank you very much for your answers,
EDIT : I'm using the ALPACA Source engine (Infos Here)
This happens when an improper certificate and/or mobile provisioning file was used to compile the app (and is a known bug on iOS 7. It never gives an error message and just tries to keep installing the app).
You need to make sure the following are true:
The app was compiled with either a development or distribution certificate made using Apple's developer portal. It must come from that portal. I have never seen a working way to do it without a certificate generated there and I do not believe it is possible.
The mobile provisioning file used matches the certificate. A developer certificate is used for a development provisioning profile and a distribution certificate is used for an ad hoc or app store provisioning file.
Again, make sure the provisioning profile comes from Apple's developer portal. This one is a little more flexible and I believe it can be faked by other sources, but why bother?
The provisioning profile must include your device's UDID. This is the only way an app can be installed on your device without it coming from the app store
You must use either a development (if your device is set up for development) or ad hoc provisioning profile. An App Store provisioning profile will fail to install.
It only worked for me when i created ad-hoc provisioning profile and used in the intellij project settings
We currently have an Enterprise account with a Distribution Certificate installed with a Distribution Provisioning profile (which contains a wildcard app ID for all of our apps). They are installed on our machines correctly, and each target points to the correct profile. We've been trying to get applications to install correctly, but it only likes devices that have been included in the registered device list in our provisioning portal. These devices happened to be included through Xcode. I understand that with an enterprise license, the requirements of having the device in the portal via UDID is not necessary, and it should allow for distribution to devices within the company. We have about 10 targets with different bundle identifier suffixes, but conform with our distribution wildcard profile. We have included an entitlements.plist file that has the following key/values:
get-task-allow: NO
application-identifier: $(AppIdentifierPrefix)$(CFBundleIdentifier)
keychain-access-groups:
Item 0: $(AppIdentifierPrefix)$(CFBundleIdentifier)
Everything compiles correctly and code-signing works, but trying to distribute the app through the air to other devices returns a 'Unable to Download' error. We run CI and we have a script that compiles and code-signs everything, and then generates a webpage with all the apps so users can test them out. The distribution provisioning profile is set to 'In House' and is signed with the certificate we're using.
Any suggestions?
Figured it out. Seems like everything was set correctly, we just had an old, lingering distribution profile that was used in our script. That profile would embed with the apps and hence wouldn't work.
We have just configured a setup very similar to what you are describing. We wanted to use a wildcard provisioning profile for OTA distribution of several apps with different app ids, without the need to specify device UUID's in the provisioning profile.
While we quickly got it working for an iPad app, I spent to great a part of my life, wondering why I couldn't make it work for an iPhone build. I was faced with the same annoying "Unable to download" error, and no clue of any kind in the device logs as to what might be wrong.
It turned out, that the problem was with my .plist file, which contained a wrong reference to a 512px icon. A 512px icon which isn't even used, but having a non-existing URL in the .plist was enough to break the whole OTA installation process. I simply ended up removing the "full-size-image" section from my .plist, and now it works like a charm!