I've been under the impression for some time that for iOS, signing a build with a developer provisioning profile allows the app to run (and get debugged) on an authorized device (listed in the development provisioning profile) through an XCode build, whereas signing with a distribution profile allows the app to be run (but not debugged) on other iOS devices that have been specifically added to the distribution provisioning file for the purposes of QA/beta testing/etc (and installed via iTunes sync or OTA distribution), without the need for those QA/beta-testers to even know what an XCode is.
Seems to match several of Apple's own docs:
"When you’re ready to share your app for user testing [...], you need
to create an archive of the app using a distribution provisioning
profile and send it to app testers" (source)
and
Code Signing with a development profile allows your app to run on
device through Xcode, and signing with a distribution profile allows
you to create distribution builds.
The certificate named "iPhone Developer" allows you to run/debug your
app on iOS devices through Xcode, and the certificate named "iPhone
Distribution" allows testing your submission build with Ad Hoc
distribution (source)
This seems to imply that using a distribution profile is necessary to do app sharing outside of the App Store, and for years I've always assumed this to be true. Recently however, I've been shown a use case from another colleague where they've been able to share builds with many other people using only a development provisioning file. Another user has described a similar discovery here: Why not use development provisioning instead of ad hoc?
I'm worried I might be missing something here, I'm now suspicious that there are cases where as long as another user has access to a relevant developer provisioning profile that includes their device's UUID, and installs it on their device (drag into iTunes, config utility, etc), that they would be able to sync Developer builds through iTunes as well, without the need for making separate Distribution builds.
This has led me to question some of the assumptions I've had about the nature of the differences between developer and distribution builds in general. I'm starting to think that it's more about debug support and general ease of installation, rather than the nature of how it's installed (XCode vs iTunes/OTA explicitly).
In short, if a device has it's UUID included in a developer provisioning profile, do I really need to make separate distribution builds, or can I simply share a Release Development build and assume that will work with an iTunes sync as well? Does the "Use for Development" button in organizer have any real relevance to this?
More broadly: what are the fundamental differences between Developer and AdHoc builds in terms of how they can be shared among other people within an organization in the development/testing phase before being submitted to the App Store?
Check this SO Post for the differences listed out between developer and distribution builds. From a developer perspective, there is not much difference whether you want to distribute your app either by signing it with a developer profile or distribution profile, provided you are not testing push notifications.
Related
We have an enterprise account and need to distribute the App with ad-hoc distribution.
But with the ad-hoc distribution, the testers were still asked to trust enterprise developer and we cannot find the profile & device management in the Setting. Why does iOS ad-hoc distribution still need to trust enterprise developer?
Is there anyone who encountered the similar issue?
Once you installed application,
1: Go to setting -> General
2: Profile and Device Management
3: Click on "Untrusted app"
4: There is option for "trust"
As described here: https://discussions.apple.com/thread/7611217 , the "profile and device management" setting only shows up when a profile has been installed. If it is not showing up it means the tester did not install the profile.
The ad-hoc requires the user to trust it because it has not gone through the apple approval process. This is a security feature to make sure users are not installing random, potentially malicious apps on their phones. Its meant to make them aware that this isn't a verified app yet and they need to be sure they trust the person who sent it to them
I had this issue since 3 weeks. After xcode 9.3 update, I couldn't run ad-hoc build on the device with enterprise account. It was asking to trust developer on settings but you don't need to trust developer on ad-hoc build, you just need to add device uuid to provision profile. Also there is not an option about it on device management section on settings, if ipa file was generated via ad-hoc distribution.
I tried with newly generated ad-hoc provision profile but there was no luck. I tried newly created project with new app id and still no luck.
I think there are some changes about ad-hoc distribution on enterprise account or some bugs.
I used company account to export ad-hoc build to workaround the issue.
I am a bit lost in all the certificates/provisioning profiles.
When I am doing ad-hoc distribution by first doing "archive" and then "distribute" in XCode and chose then my ad-hoc distribution profile, does it matter at all what I have set up in the Project->Target->Build Settings->Code Signing?
On one hand I read in different places that when you archive a build, you can (and really should) use that same archive both for beta testing with ad-hoc and then when ready just sign/distribute the same archive with an appstore profile and upload to app store. That kind of makes sense. It also tells me that I can really leave blank the provisioning profile in the project settings, the one that is chosen during "distribute" action is actually used, and the signing identity is actually the private key associated with the distribution certificate listed in that provisioning profile. Right?
On the other hand, testflight instructions (http://help.testflightapp.com/customer/portal/articles/1333914) clearly state that project settings should be set to use Ad-hoc profile as well, and the same profile must be used in the project settings and in "distribute". That means that I can not use the same archive both for ad-hoc and app-store distribution, can I? Do I need to change project settings every time I want to release for this or that distribution?
Also, if project settings are making any differences in archive/distribute scenario, it is not clear what Code Signing Identity should be used there. Testflight screenshots show iOS Developer is set both for debug and release, yet neither ad-hoc nor app store distribution have the individual iOS developer certificate associated with them, distribution profiles usually are associated with one and one only distribution certificate.
Can someone please shed some light and explain how is it actually supposed to be working?
Thanks
Yes, your build settings matter. Xcode picks up various entitlements from your initial code signing/provisioning profile configuration and it only makes minimal changes to them in the Distribute... phase.
So if Xcode chooses the incorrect profile during the Archive step you can end up with incorrect bundle seed ID, keychain groups, APN environment and iCloud entitlements.
The Distribute... button calls the PackageApplication script, which makes sure that get-task-allow is false (debuggers can't connect), embeds a provisioning profile, then re-signs and zips your app (although I may have the order wrong).
PackageApplication is worth reading. One could fault it for not being very smart, but I think it should be stricter and refuse to package an app whose entitlements differ from the provisioning profile it is using.
You can find it here Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/PackageApplication
I think one stable workflow for distributing Ad Hoc builds is
remove all wildcard provisioning profiles from your system
select your App Store profile in Release Configuration (used in Archive phase)
in Distribute select your Ad Hoc profile
The reason for 1. is that wildcard profiles (profiles that match multiple BundleIDs, created either manually by you or automatically by Xcode) are not worth the trouble. Yes, they get you running code on a device quicker, but you soon have to abandon them if you want to use push notifications or any other interesting service and then they hang around on your system and sooner or later Xcode will silently pick one of them and sabotage your App Store submission.
As for point 2. (selecting the App Store provisioning profile), I'm a little hesitant of specifying profile in the project, but the App Store one only needs to change once a year when your certificate expires (unless you edit the App Identifier in the Certificates, Identifiers & Profiles portal, then you'll need to regenerate your profile & re-select it in your project settings).
Since the Ad Hoc and App Store profiles are based on the same App Identifier, their entitlements will always be in sync.
Point 2. should make point 1. unnecessary, but wildcard profiles will also happily screw up your dev builds too, so why give them the chance to stab you in the back?
Point 3. - you can change your Ad Hoc profile as much as you like - just remember to select the right one in Distribute; the entitlements are taken from the App Store profile which should change rarely. There's nothing stopping you distributing to the App Store from here. That's perfectly natural.
p.s. I don't know why TestFlight recommend selecting Ad Hoc in release instead of App Store.
I work for a company developing their iPad app. None in the company is a technological geek to handle Xcode app deployment themselves. So for now, we do this:
I develop the app.
Create an ad hoc testing version and share the .ipa file with them.
They test and then I make a distribution version for further release.
What I want to establish as a permanent solution is
I develop and share the Xcode archive
They make all different versions for testing and release.
However I have been largely unsuccessful in doing so: for creating the archive, I have to sign/certify with my development profile. They could deploy it further from Xcode archive to an .ipa file, using their distribution certificate. However, they can not install it on their devices. I believe mainly because the development version requires my certificate/profile to be enabled on their devices :(.
Is there a way out? I need to provide them an archive which they could further sign and do whatever they want to do (either test on whatever devices they want to or release).
Thanks,
Nikhil
If you don't want to manage the device identifiers where you are deploying the device, you could use:
1) TestFlightApp.com (although I don't know what the current status of their offerings are -- since they've been acquired by Apple -- but they still have a "Sign Up" link on the top of their home page).
or
2) Apple's Enterprise Developer Program, which allows you to "Distribute In-house Apps".
You can sign application using their distribution certificate.
To do so c'est have to send you a p12 export of the certificate, the p12 contains the private key of the one creating the certificate and the certificate.
To export a certificate :
Go to the keychain access
Right click on the certificate
click export
In years gone by we found that we could only have 1 distribution certificate per logged on user so we created as many accounts as was need, 3 in our case, 1 for each developer program and logged onto the mac using the required account.
So anytime an app was developed and need to be distributed in-house I would log onto the mac using the enterprise account and archive and distribute for in-house and sent the resulting .ipa file and the provisioning profile to the users.
I have now discovered I can have multiple distribution certificates on the mac and am trying to see if I can distribute via in-house logged on to the mac as me and use my own profile or the team profile that link to the enterprise developer program.
The app build ok and generates the ipa file and I can install using iTunes but I get a faded icon on the iphone and when tapped it says installing but never does?
So, my two part question is:
a) is it possible to distribute in-house using my enterprise linked account logged on as me and using my profile or team profile
b) I read you do not need to give the user the profile, but I have always done this as was the requirement when I first learned to do this?
Thanks
a) Yes. I have 10 or so certificates (dev & dist) on my computer for various clients. I keep them in separate keychains for peace of mind. When it comes to time distribute your in-house binary, you archive in Xcode then hit the Distribute… button in the Xcode organizer, choosing the correct Enterprise profile.
b) This is no longer necessary as the Distribute… step mentioned above embeds the profile in the app. Things are much easier than they used to be.
NB: I avoid wildcard provisioning profiles as they can cause heartache, even in simpler situations than yours (e.g. if Xcode chooses a wildcard Ad Hoc profile during Archive, then your entitlements may be wrong once you Distribute), so for this reason I recommend you always use explicit profiles.
This might have been asked lots of times, but still I couldn't find info on why are they needed. I use DEVELOPER prov profiles to test apps on my device, that makes sense.
The Provisioning Portal explains prov profiles like this:
A Provisioning Profile is a collection of digital assets that uniquely ties
developers and devices to an authorized iOS Development Team and enables
a device to be used for testing.
By this logic they are only needed for testing, eg not for distribution. Do we need one to deploy the app on the AppStore?
Absolutely yes. The distribution profile is used for submission to the App Store. It does not have the 100 device limit that the development profiles have.
From the Tools Workflow Guide:
When you’re ready to share your app for user testing or for general distribution through the
App Store, you need to create an archive of the app using a distribution provisioning
profile and send it to app testers or submit it to iTunes Connect. This chapter shows
how to perform these tasks.
The distribution profile prevents the attackers from submitting a modified version of your app to the store - only you, who hold the private key of the distribution certificate, can submit and update your app.
Once your app is submitted, your embedded.mobileprovision and your binary will be checked and compared to make sure that you are the legitimate author. embedded.mobileprovision file is then discard and the app is signed again by Apple using their own certificate (which is by default accepted by all iDevices), so that all iDevices can run it.
When an iDevice downloads the app, the executable binary is then encrypted with an encryption key associated that device. At run time, only that device can decrypt the executable binary and run it.
There are two types of distibution profiles, the first one is to submit your app to the appstore and the other one (Ad-Hoc) is necessary if you can´t connect a device to your mac(developer profile). Then you can share your app wit the Ad-Hoc profile to someone else e.g. via mail.
Distribution Provisioning Profile
Distribution Provisioning Profile is used by Apple to publish an application to App Store. When Apple approve the application it is signed by Apple and became public.
Distribution Provisioning Profile contains:
Application ID - application which are going to run
Distribution certificate - who can debug the app
[Development Provisioning Profile]
[Certificate]