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!?
Related
We have a series of iOS Enterprise applications that were built with Telerik Cordova (discontinued in May 2018). Those apps are in the process of being converted to a new platform, but in the mean time they must continue to service client needs.
The distribution certificate the apps were built with is valid for another 14 months or so, but the provisioning profiles expire in a few days. Since these are Enterprise apps they will expire with the profiles.
Unfortunately, Telerik can no longer rebuild the apps using an updated profile for us. We have re-signed the apps using new provisioning profiles (using both iReSign and Terminal). When we try to side-load the resulting IPAs through the XCode Devices panel, we get an error stating that the entitlements do not match and the apps are not installed.
The question was raised as to whether or not we not need to re-sign the apps since the certificates are still valid. Perhaps it would be possible to just replace the .mobileprovision file on the device somehow? I gave it a try using iTunes Sync but I cannot confirm whether the file actually went to the device or not.
Question: Is it possible to just update the *.mobileprovision on the device without re-signing the app? If so, could someone please give me the steps or direct me to a link to perform the steps?
Alternate Question: Otherwise, any thoughts on how to resolve my Entitlements issue? The app only needs Push Notifications, but Game Center and In-App Purchases are also enabled. These are reflected in the App ID and provisioning profile, and the distribution certificate is of type Apple Push Services.
I should point out that I am not an admin on the Apple Developer portal for the project as I am an outside consultant, so my portal access is strictly read-only.
Thanks in advance for any direction provided!
If the applications were distributed to the devices by an MDM, then you can push a new provisioning profile to them using the MDM.
If the applications were installed over the air from a web server or directly using iTunes or Apple Configurator, then you need to replace the entire application package on the device. This requires the app to be re-signed, since the changed .mobileprovision file will change the package signature.
If you don't have the original, app ID with matching entitlements in the developer portal, then you will need to delete the existing application from the device before installing the new, re-signed application. You won't be able to do an in-place upgrade.
I have an app (adhoc dist.) and uploaded it to Diawi.
Now, I should add new UDIDs. After add them, do I need to recreate or rebuild the IPA and re-upload to Diawi?
Thanks in advance
An Ad-hoc IPA will only install on the devices listed in the embedded provisioning profile. If you want the app to be able to be installed on additional devices then yes, you need to provide an updated IPA with the updated profile.
Better yet, use TestFlight and avoid all of this hassle.
The answer to your query may be in two types of accounts
1) If you have an Enterprise Apple Account: No need to add tester UUDI to the account as the app can be released using Universal distribution binary which any device can install using OTA installation method.
2) If you have the developer account: your existing app will have no impact but yes for the new devices to install you have to regenerate the profile as the existing as on store account portal will get Invalid and needs to be updated for New IPA compilation. The old one will not work.
I would always recommend having an Enterprise account for a testing/building app company as Appstore Developer account is better for Distribution on Appstore or small scale company who rarely adds device ID for debugging and testing unless its standalone developer like scenario.
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'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'm so confused -
after an entire day's struggle, i finally figured out how to submit my app to Apple via archiving & distributing from xcode.
... that was my free version
now i made my code changes, and on my pList file, i changed the Bundle Identifier to com.blah.mygame.pro instead of com.blah.mygame.lite
i also changed the Bundle name to be My Game Pro instead of My Game Lite
but now i'm confused - when i click on the project in Xcode, and i hit "Target" instead of "Project", i can't find my release/distribution profile! (my develop/debug profile) is still there.
if i were to click Project instead of Targets then i actually do see my previous distribution profile.
however, in my develloper portal, i had actually set my distribution profile to be linked up with the "com.blah.mygame.lite" identifier. was i not supposed to do this???
weirdly enough, when i made my distrubution profile earlier today, i say something like "mygame * -" or something that i coulda linked it to. but i just chose com.blah.mygame.lite without thinking
are you supposed to have multiple distribution profiles? one for every app? what i just want a lite and pro version?
** edit:
bonus points for this:
if i only needed 1 provisioning profile, (and since i messed up naming my previous provisioning profiles)... how do i rename all my distribution profiles without it interfering/messing up with my apps?? it's already submitted and awaiting approval
* EDIT # 2:
okay, i got both apps submitted with 2 separate distribution profiles.
however, is there any way that i can rename a distribution profiles while the app being submitted is still using it??
i had mistakenly named it "My Company Distribution Profile" when i should have named it "Distribution Profile for My Game Pro Version"
You have two options for fixing it:
Use a AppId like. com.blah.mygame.* . You can replace the * with any number of strings and use it for creating different application.
I won't recommend this approach, because the issue with this is you won’t be able to use push services or in-app purchases. You might not plan to use these services now, but if you change your mind, you won’t be able to change your app ID without creating a new app.
Create different AppId for different Apps. It'll be a good approach
Sounds like you're using a single AppID for both of your apps. You can only use one provisioning profile for multiple apps only if the AppID bound to that profile has a wildcard (e.g. "com.sample.*").
quoted from the iOS Provisioning Portal:
The Bundle Identifier portion of an App ID can be substituted with a
wild-card character (asterisk '*') so that a single App ID may be used
to build and install multiple applications. If the wild-card character
is not used, the Bundle Identifier portion of your App ID must be
input as your CF Bundle ID in Xcode to allow the application to
install on your device. The Bundle Seed ID portion of your App ID does
not need to be input into Xcode. Wild-card App IDs cannot be used with
the Push Notifications or for In-App Purchase.
I hope you have created an AppId with this bundle identifier com.blah.mygame.lite and created a distribution profile linked with this AppId. By doing like that, you can run or archive your apps only if it is having the same AppId like this com.blah.mygame.lite. If you want to create an AppId to run all apps, then you need a Wildcard AppId like this com.* . And If you think you need to run the app with AppId com.blah.mygame.pro then you need to create another appId like that and associate that appId with another distribution profile or modify the old one and download and install it and use.
There is no need of distribution profile for every app....one is enough for every time but
your bundle identifier is same as you given in your distribution provisioning profile when
you create it first time....