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.
Related
I started to read the Keychain Services Programming Guide and in the Keychain Services Concepts there is a note:
On iPhone, Keychain rights depend on the provisioning profile used to sign your application. Be sure to consistently use the same provisioning profile across different versions of your application.
I don't understand this note... what if for example I need a build for adHoc deployment and I need to later edit the provisioning profile to add more devices? Or if I sometimes build the app for adHoc deployment with its appropriate adHoc provisioning profile, and another times I build it to use TestFlight with its provisioning profile for the App Store?
Thanks
I don't think that's true, I regenerate my provisioning profiles every year and haven't lost keychain access.
What exactly constitutes keychain "identity" is hard to pin down.
QA1726 seems to imply that your keychain access is based on BundleID Prefix/Team ID plus bundle ID. Although bundle IDs are allowed to differ if you use the keychain-access-groups entitlement.
I would also hazard that provisioning profile type now comes into play.
e.g. once upon a time I could read the keychain of the AppStore version of our app from an Ad Hoc version of the app, but not a dev version, but that seemed to stop working around iOS 7.
I hope somebody can contribute some slightly less conjectural information.
it says about the every year the profile expired and updated with new one.this should be same. see here, more here
I'm trying to get my app to work with TestFlight by following this article on their website. At step 5 when it says to select your Development Provisioning Profile and Ad Hoc Provisioning Profile, I'm not sure what to do:
Go to the Build Settings tab and scroll down to the Code Signing
section. For the two default build configurations (Debug and Release),
select your Development Provisioning Profile for Debug and your Ad Hoc
Provisioning Profile for Release. Leave Code Signing Entitlements
blank.
How do I create these? The whole provisioning profile thing is so confusing. For my phone I just clicked "Use for development" or whatever and it basically worked to test my app on. Do I have to create something different?
(Yes I'm a registered developer.)
You have to create provisioning profiles for adhoc and distribution.
See http://developer.apple.com/library/ios/ipad/#documentation/ToolsLanguages/Conceptual/YourFirstAppStoreSubmission/TestYourApponManyDevicesandiOSVersions/TestYourApponManyDevicesandiOSVersions.html
Under 'create an AdHoc provisioning profile'
Yes, you'll have to create a Distribution and Development profiles. This is done on http://developer.apple.com/ ...follow the most updated how-to's appl provides or RECENT online tutorials and go for it.
The process used to be incredibly confusing, but has gotten much simpler over the past few years, don't be scared by all the old things your read. Also, many common tasks like renewing profiles are now autmomated in the XCODE organizer. However, creating these in the first place is done using the dev website and Keychain Access.
You may still struggle a bit to get going the first time, but knowing how to work with provisioning is essential if you want to test/share/distribute/sell your apps.
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.
I want my testers to be able to have App Store and Ad-Hoc versions of my app on the same device. The app requires an explicit App ID, which in turn means that the Bundle ID must be fixed, too. (I.e., if I just append "-test" to it, signing will not work.) Am I right to assume that I must create a separate App ID (say, "com.mycompany.myapp-test") to achieve this? Or is there another way?
When archiving the app, Xcode initially uses the App Store provisioning profile, as that's what the "Distribution" build configuration is set to. When I click "Distribute…" in the organizer and select "Save for Enterprise or Ad-Hoc deployment", I am subsequently asked to select a code signing identity. Will selecting the Ad-Hoc profile's identity here erase the previously applied distribution profile from the archive and re-sign it with the Ad-Hoc profile? Or do I have to select the correct profile when creating the archive already, thus keeping separate archives for App Store and Ad-Hoc distribution?
The Bundle ID of an application identify it uniquely. Only one application with a given BundleID can be installed on the same iPhone, as two applications with the same BundleID are considered to be the same applications (and the one with the most recent version will replace the older one).
So yes, to have both the AppStore and AdHoc version of the same application on the same device, each variation of your application (AppStore and AdHoc) much have its own Bundle ID.
Am I right to assume that I must create a separate App ID (say, "com.mycompany.myapp-test") to achieve this?
Yes
You can use a Wildcard instead "com.mycompany.*" then you can use com.mycompany.whatEverYouWant
Thats nice for debugging various versions but In-App Purchase, Game Center and Push Notification are unavailable for Wildcards.
To answer the second part of my question: If I don't resign the archive during the exporting process, (even if it has already been signed with the Ad-Hoc distribution profile), iOS refuses to install the app (saying something like "Error: The app cannot be installed at the moment."). It does, however, install the embedded Ad-Hoc distribution profile!?
I am making my .ipa for an app I'm about to upload to TestFlight, but I can't seem to figure out how to make it available to all of my teammates.
When I make a provisioning profile at developer.apple.com, I can only register one device per profile. (Right?)
When I create the .ipa in Build -> Archive, I can only use one Provisioning Profile. (Right??)
So this means I can only make an .ipa work for one device. (Right???)
This can't be right. What am I doing wrong?
An ad-hoc distribution profile can support more than one device. Check you are making one of those, rather than a development profile. It's a different tab in the portal. The device UDIDs can all be added in the portal as well.
Alternatively, if you're on the enterprise program, you don't need to gather UDIDs and can install on devices without them. There is some confusion over whether this is technically against Apple's terms but in practice it is being used by many developers for beta testing.