I sign my iOS app in XCode's archive manager for Ad-Hoc distribution for beta testers.
Every time I release a new beta version by pressing the Distribute App / Ad Hoc it asks for a Distribution manifest information with URLs to fill.
It's quite tedious to fill these fields every time, although these values don't change. Is it possible to pre-fill these fields by doing something in xcode project settings?
When you select Ad-Hoc distribution, simply uncheck the "Include manifest for over-the-air installation" option and you won't be prompted.
You can use a previously generated manifest for the new version unless you want to change something; The version number in the manifest is purely informational and doesn't need to match the version number in your app bundle.
I know you decided to just not include the manifest for over-the-air installation. In my case, though, I did want to automate this a bit. So, I used a third party tool, TextExpander, so that I can just type otaqa or otaprod and it will populate these three fields for me. I just included the three strings with tab keys in between them:
Note, I am unaffiliated with this paid app, TextExpander. But, I just found this workaround to be a great time-saver when needing to repeatedly enter the same three values in three separate text fields.
I really wish Xcode handled this process better, saving these values for us.
Related
How to update my app in app-store to a newer version?
Earlier, I successfully offered my app into the app-store. That's the starting point. But it's been a while, I've updated my app, and would like to offer a new release. Since a misstep in preparing the app can take a bit of time, I'd like to have the specific steps required to offer an updated release on the Apple app store.
Summary
The process of releasing a new version of an iPhone app to the Apple app store requires quite a number of steps, but not all the steps will be required, depending on whether certificates are up to date, builds are targeting required versions, if you have screen shots for the required devices, etc. Below is an example of the steps you might need to execute to put a new version into the Apple app store.
Steps
1. Versioning and Signing
Within the XCode application, update the version of your application. Also check to see that there is a valid provisioning profile. In this example, the profile is expired, so additional steps will be required. If you have a valid profile, skip the (lengthy) step 2.
2. Updating Provisioning Profile
Skip this step if you have a valid profile.
This process does not use the Automatically manage signing feature of the XCode application. Automatic signing only works if you have a physical, registered Apple device, which I do not have. So automatic signing might be easier, but is not used here in this example.
2a. Add signing certification
Here we see there are no valid signing certificates, so one is created and associated with the apple ID.
2b. Manage certificates using `developer.apple.com`
By using the Apple developer web site, we see that an old provisioning profile is expired and we also see our new distribution cert is available. We create a new distribution profile for the app store and generate a new provisioning profile, then download it.
2c. Import the new Provisioning Profile into XCode
After the creation of the new Provisioning profile on the Apple developer web site, we import the new profile into XCode. If there is a problem with no signing certificate, you might need to select (project) -- > Build Settings and searh for PROVISIONING_PROFILE and tweak that. Or turn on, then off automatically manage signing.
3. Build and Upload the Application
Here we build the application using a generic device, archive, and upload using the provisioning profile from step 2, or an earlier valid provisioning profile.
We also must wait for the automated processing to complete. An email is generated and sent by Apple.
4. Prepare Application Submission
This is where we assign a `Store Version` number, assign the build file we uploaded in step 3, and reaffirm the application meta data.
The meta data includes screen shots of the application, and Apple requires that certain screen dimensions are represented. This answer will not explore the challenges associated with the case where Apple creates an additional burden on the developer by requiring different screen shot resolutions. Instead, an reference to another post will be included: Submit iOS build update without re-uploading screen-shots and app-previews
. My conclusion for screen shots is that you can often request (through Media Manager), that screen shots you've uploaded be used on various other devices, but when new hardware is released, you'll probably need to generate new screen shots manually.
Once the meta data is complete, the version can be submitted to Apple for approval. This process requires a real person, I think, and has taken at least over night, if not longer. This answer will not address the application-specific review process, but even though the new version didn't change anything significant, you may be asked to alter things in your submission or even within your app.
steps:
in your project in xcode go to Target -> general
there you see version and build,
if your last version in app store was 1.0, now if you have made minor changes in app, new version might be 1.1 0r 1.0.1 etc, and if major app changes, version changes accordingly, i hope you understand what i am saying here
and for build, add 1 to the last build number which you used to upload app in you developer account, not the one in app store.
Now clean app, change your provision profiles and certificates accordingly for app store..
now clean build the app, and then archive the app
after archive completed, a window appear and from there,
either you can export your ipa and browse to your ipa file, use application loader to upload app or
click upload button there in window itself.. and follow steps, this might take some time
depending upon your app size.. and after app upload success, 10-15
minute time takes, to show your this uploaded build in your
developer.apple.com console.
open the developer console, go to itunes connect -> my apps -> select this app uploaded from list of app available in list
since there is already aversion of your app in appstore.. click on add version, give the version number and select the build you uploaded earlier
and then fill in necessary details and submit for review.
i might have missed a few steps, but thats the general idea.. you will figure it out.
First you have to update version of your app choose target ---> Version Like from 1.0 to 1.1.
Choose device it's Generic ios device then clean and build the project.
Make sure you have a valid Production Certificate and provisioning Profile, installed in your mac.
Go to --> Product --> Archive --> it's open archive window --> then click validate button or it's check validation, if any error occur you have to resolve it.
then it ask for Certificate and provisioning Profile - Choose correct one.
if it success then Upload to app store.
If all work done successful then build show on app store after some time.You will get a email.
So for Submit a new build go to itunes connect by login your apple account and open your app then click (+) button version or plateform
give the version name that you provide for app version and create it.
then you can change info for this version like new Updates and screen shot if you want otherwise no need to change anything.
when build your ipa is connect to your account, In Build section of this version it show a (+) button. by clicking Then you can select your build and save changes and submit to app store.
When you build a project in xcode, you specify the provisioning profile/certificate pair in the build settings, and when exporting an archive, you specify an additional provisioning profile to use. What is the reason for asking for this information twice?
Edit for clarification: I've gone through the contents of a bunch of my generated .ipa files, and there seem to be two locations that pertain to signing/provisioning. The document in the _CodeSign folder (which seems to contain encrypted hashes of the file contents, to verify contents/source), and the .mobileprovision file, which seems like it would be added when the build is exported. At this point in time, I don't see anything that would indicate the purpose of the provisioning profile selected in build settings.
You specify a provision profile in the build settings that Xcode uses to sign the app. This makes it possible for you to run your app on a device during development, for example. If I remember correct, in the past the project build settings was the only place where you could specify the profile to use, so you'd typically set the Debug build to use your development profile, and your Release build to use the distribution profile.
At some point (Xcode 4, I think), application archives were introduced to make things easier for developers. You create a single archive and then distribute the app it contains in different ways. You can do an ad hoc distribution to send out to your testers, and then you can use the very same archive to submit to the app store, or create a version for enterprise distribution, depending on the type of program you've joined. But since different distribution methods require different profiles, Xcode asks you for the profile you want to use when you distribute.
Xcode's Archive function is a huge convenience -- it takes a lot of the complexity out of submitting your app, and also takes care of saving the symbols file for each version you distribute so that you can make sense of any crash logs you might receive. It's a recognition of developers' need to use the very same build of an app in different ways. If it seems a little odd that you specify the provision profile to use in two different places, so be it -- that's a rough edge that might get cleaned up in a future Xcode version.
I don't know of any authoritative information on exactly how app signing works, but I think it goes like this:
the provision profile contains your certificate (which includes your public key), and is signed with Apple's private key
you sign your app with the private key that is the counterpart to the public key in your certificate
the device uses Apple's public key to authenticate the profile, and then uses your public key from the profile to authenticate the app signature
if everything matches up, the device will run the app; if not, the app will fail to install
Forget about the "app binary" and "ipa" being signed separately -- I think that's a red herring, and it's unlikely that iOS has to validate two different signatures.
Not sure, but think - First time xCode sign just binary app, and second time whole .ipa archive.
What is the difference between these two screenshots?
and
update: When I uploaded my app on the appstore I got invalid binary. I am trying to find a solution.
Well, in the first one you're telling it that the default behavior is to not code sign, but the behavior on "Any iOS SDK" is to go ahead and code sign after all. In the second you're telling it to always code sign. However, since "Any iOS SDK" covers every compilation you're ever going to do on an iOS project, the former is effectively equivalent to the latter in practice.
You are asking the wrong question.
The Debug and Release Targets are not meant for App store submission. You want to create a Distribution Target, which is usually a clone of your Release Target, except with the Code Signing Identity changed to being your Distribution certificate and Distribution provision file instead of your Developer certificate and provision. You might also want to make sure to Validate your Distribution build before trying to upload it.
For submission to the App Store via iTunes Connect, you need to sign your app with a Distribution Certificate, not a Developer Certificate.
Follow Apple's step by step guide. It walks you through the whole process even with screenshots.
I want to develop both for an employer and for myself. They have their Apple Dev id & password, and I have mine. Two separate accounts.
Can this be done? Two accounts on the same computer with the same copy of Xcode?
Or perhaps do I need to create a second login account on the Mac i.e. with separate home directories?
It works best to have 2 separate Mac User accounts. That way, not only are all the iOS Developer & Distribution Certificates kept in 2 separate Keychains, but you will be less likely to accidentally mix your code (and personal documents, etc.) and your employer's IP. Both User accounts can use the same Xcode/SDK installation, unless you change the directory permissions somehow.
While Xcode might work "best" separated into two accounts, I consider this a deficiency in Xcode.
At work, we avoid automatic code sign identity/profile selection; it seems to have paid off (we have several customers who want us to produce builds signed with their certs and even submitted to the app store on their behalf). Our build scripts automatically pick the provisioning profile by name, install it if necessary, and pass PROVISIONING_PROFILE=... to xcodebuild.
Developement builds can use automatic profile selection provided the code signing identity is specific enough. To avoid hassle, we all sign with the same dev cert/key. Distribution builds can use a specific identity anyway, since there's only one per company.
That said, automatic profile selection might have improved since Xcode 3.0 (or whatever the 2.0 SDK came with).
In practice, dev builds don't really matter, you should check the output of dist builds anyway. The only big problem I've encountered was with a company that had both an App Store and an Enterprise account, both with certificates named "iPhone Distribution: CompanyName Inc.". I think that can be solved by passing --keychain=... in "code signing flags".
iTunes Connect says to use the Application Loader utility in the Mac Developer Utilities folder.
There is also the XCode Submit feature in the Archive area, the same place where you validate an app before submission.
Do these two utilities do the same thing? Which is preferable?
They do the same thing. The only difference is that the Application loader forces you to validate the binary beforehand, whereas in Xcode 4, it's a separate button.
I recommend using the Xcode "Submit" button, especially if you're using Xcode 4. The way Apple redesigned Xcode 4 from Xcode 3, it looks as though they want people to use it. (They made it easier in Xcode 4.) Doing so will eliminate an extra tool from your workflow and might just make your life a little simpler.
Just note the process when using Xcode 4. If you're doing Ad Hoc builds, you'll need a second scheme to Archive those with proper code signing. If you're just doing local builds, you'll be fine with just one scheme.
Be sure to use the notes section in Xcode 4's Archives (area?) to note which builds are Ad Hoc and which are for the App Store. Also, in Xcode (not sure about the Application Loader), when submitting, you'll be prompted to select a code signing certificate. Make sure this selection matches what what you actually signed with.
With these things in mind, they are essentially the same.