Submitting to Apple: XCode "submit" or Application Loader? - ios

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.

Related

Prefill Distribution manifest information during iOS app signing

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.

XCode 4.3 code signing errors

Before Xcode 4.3, I used this method to submit applications to the app store:
-- Compile the application with the appropriate signing certificate which was configured inside the application's build settings
-- Distribute the application into the app store or clients using Xcode's built in submission process. When I was asked to select the signing certificate with which to sign the app, I always selected "Don't Resign".
However, the "Don't Resign" option does not exist in Xcode 4.3. Therefore, my application is resigned, and I always end up with an error saying that the code sign verification failed.
Is there any way around this problem?
I have found out that the compilation errors about code signing are due to a bug in Xcode 4.3. As many other have pointed out in Apple's developer forums, and myself, there are many cases where Xcode will complain about code signing your application if your application contains an image bundle! So, I remove the bundle with the images, and re-imported the images as separate files. I was able to compile the application for Ad Hoc this way, whereas it wouldn't compile with the bundle.
Also, as far as "Don't Resign" is concerned, I noticed that even if the application is already code signed in another step, Xcode 4.3 became smart enough to not re-sign the application with the same certificate, even if it appears to not give you the chance to not to! That's what I have verified with Ad Hoc builds. I will soon try that with production builds.
So, Xcode 4.3 became smarter in one way, and dumber into the other. Apple needs to fix this problem with the bundles, SOON!
Yes, there is a way. Before it used to default to whatever code sign it could find and auto-embed it into your apps. Right now its bugged.
To solve it, you would have to go through the steps of obtaining a new certificate and its private/public key. 3 step process:
Make sure you completely delete your old certs and keys by going to Applications > Utilities > Keychain Access. Then Deleting the certificates and private keys associated with your Developer account.
After deleting all that info head Here to generate a new certificate for your app. Download and import to your login keychain
3.In Xcode open your project. Head to your root project folder > targets > build settings and attach the new correct certificates to code sign your app correctly.
If you are unsure about the code-signing process. Either go here or go to the dev provisioning profile under distribution you have some (REALLY OUTDATED) examples to point your way

Code signing issue: Is any difference between this two screenshots?

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.

Best way for uploading binary Application Loader or Xcode organizer

I want to know best way for uploading binary to itunestore. Is it through Application loader or using Xcode organizer archive build, validate and submit.
There are significant differences which I've tried to list below (as of Xcode 6.3.2 - Jun 2015):
Xcode Organiser
The application to submit must be selected from the list of your locally archived apps (you cannot browse to a specfic file)
Gives option to 'Validate' your app before submitting
At validate/submission time will download/sync all the provisioning profiles associated with the selected Apple developer account and re-sign/re-embed the application with the appropriate one (it does indicate which one's get selected but you cannot override this)
Gives option to automatically upload the debugging symbols that are included in the archived application
NO upload progress
(Gives the option to Export to an *.ipa which could be used with Application Loader)
Application Loader
Requires you browse to an *.ipa file for its input
No option to Validate before submitting
Uses the provisioning profile that is already embedded in the *.ipa file
NO way to upload debugging symbols
Gives upload progress
You don't use Application Loader in Xcode 4 anymore. You can only upload through the Xcode Organiser...
As zekel mentions below, you can still use Application Loader to submit your IPA files. The Xcode Organiser method is useful if you are building the app yourself and want to validate and submit from one place. Application Loader method is useful if you have the IPA signed to the correct certificates installed on your system.
After using both methods, Application Loader gives you more indication of progress status which is useful if you are on a slow connection.
A sole developer or small team might just submit directly from Xcode, especially for a smaller project. But for a larger team, more complex project, or an automated build system, submitting from the Application Loader is easier.
It's a matter of workflow more than anything else.
I mostly use Application Loader it is best because:
It just requires you browse to an .ipa file.
We need not to worry about the provisioning profile that is already embedded in the .ipa file.
NO way to upload debugging symbols
We need not to Validate before submitting.
We can see the progress bar where and what is the status of app uploading.

Steps to upload an iPhone application to the AppStore

I want to know the basic steps for uploading my iPhone application to AppStore.
How do I make a provisioning profile using a certificate and what other settings do I need to do to upload an application?
I have just made an application on my iMac using Xcode and the iPhone SDK V2.2.1. What do I need to do for uploading it on the Apple iTunes store?
I am member of that and I have also a distribution certificate.
This arstechnica article describes the basic steps:
Start by visiting the program portal
and make sure that your developer
certificate is up to date. It expires
every six months and, if you haven't
requested that a new one be issued,
you cannot submit software to App
Store. For most people experiencing
the "pink upload of doom," though,
their certificates are already valid.
What next?
Open your Xcode project and check that
you've set the active SDK to one of
the device choices, like Device - 2.2.
Accidentally leaving the build
settings to Simulator can be a big
reason for the pink rejection. And
that happens more often than many
developers would care to admit.
Next, make sure that you've chosen a
build configuration that uses your
distribution (not your developer)
certificate. Check this by
double-clicking on your target in the
Groups & Files column on the left of
the project window. The Target Info
window will open. Click the Build tab
and review your Code Signing Identity.
It should be iPhone Distribution:
followed by your name or company name.
You may also want to confirm your
application identifier in the
Properties tab. Most likely, you'll
have set the identifier properly when
debugging with your developer
certificate, but it never hurts to
check.
The top-left of your project window
also confirms your settings and
configuration. It should read
something like "Device - 2.2 |
Distribution". This shows you the
active SDK and configuration.
If your settings are correct but you
still aren't getting that upload
finished properly, clean your builds.
Choose Build > Clean (Command-Shift-K)
and click Clean. Alternatively, you
can manually trash the build folder in
your Project from Finder. Once you've
cleaned, build again fresh.
If this does not produce an app that
when zipped properly loads to iTunes
Connect, quit and relaunch Xcode. I'm
not kidding. This one simple trick
solves more signing problems and "pink
rejections of doom" than any other
solution already mentioned.
Apple provides detailed, illustrated instructions covering every step of the process. Log in to the iPhone developer site and click the "program portal" link. In the program portal you'll find a link to the program portal user's guide, which is a really good reference and guide on this topic.
Check that your singing identity IN YOUR TARGET properties is correct. This one over-rides what you have in your project properties.
Also: I dunno if this is true - but I wasn't getting emails detailing my binary rejections when I did the "ready for binary upload" from a PC - but I DID get an email when I did this on the MAC
Xcode 9
If this is your first time to submit an app, I recommend going ahead and reading through the full Apple iTunes Connect documentation or reading one of the following tutorials:
How to Submit an iOS App to the App Store
How to Submit An App to Apple: From No Account to App Store
However, those materials are cumbersome when you just want a quick reminder of the steps. My answer to that is below:
Step 1: Create a new app in iTunes Connect
Sign in to iTunes Connect and go to My Apps. Then click the "+" button and choose New App.
Then fill out the basic information for a new app. The app bundle id needs to be the same as the one you are using in your Xcode project. There is probably a better was to name the SKU, but I've never needed it and I just use the bundle id.
Click Create and then go on to Step 2.
Step 2: Archive your app in Xcode
Choose the Generic iOS Device from the active scheme menu.
Then go to Product > Archive.
You may have to wait a little while for Xcode to finish archiving your project. After that you will be shown a dialog with your archived project. You can select Upload to the App Store... and follow the prompts.
I sometimes have to repeat this step a few times because I forgot to include something. Besides the upload wait, it isn't a big deal. Just keep doing it until you don't get any more errors.
Step 3: Finish filling out the iTunes Connect info
Back in iTunes Connect you will need to complete all the required information and resources.
Just go through all the menu options and make sure that you have everything entered that needs to be.
Step 4: Submit
In iTunes Connect, under your app's Prepare for Submission section, click Submit for Review. That's it. Give it about a week to be accepted (or rejected), but it might be faster.

Resources