Publishing with XCode a build release for distribution

Just a little question, when I want to publish with xcode for distribute the app in AppStore should I switch something in build settings?

Because I’m testing and submitting to the store without problems in the past, but I have doubt regarding the fact that with Android I compile with -m release flag, but in XCode I can change something in build settings but I have found that there already both configuration for debug and release.

So the question is, when I submit to the store they choose the release version automatically or I have to build only in release when I decide to distribute?

Thank you for resolving this doubt

That is a good question. I think that this is handled for you, but confirmation would be a good thing. I seem to think that when you build for distribution they take every step to ensure an optimal app, in terms of build settings. I should look into this too.

Perhaps this doc can help us answer.

For distributing an app to the Apple App Store, I prefer to duplicate the release target by clicking on the project name in the project navigator and then click on the project name and in the info tab click the plus sign under configurations and duplicate the release configurations. I then call this the Distribution configuration.

In the future, any changes to the Release configuration should also be made to the Distribution configuration. The only difference between the two configuration should be the code signing. You could also change the bundleID if you wanted to do an Enterprise distribution, since Apple does not allow using the same bundle ID for App Store Distribution and Enterprise Distribution.

Then click Product -> Scheme -> Edit Scheme and select the Distribution build configuration for creating an Archive by clicking on Archive on the left and then selecting the Distribution configuration you just created.

Then setup your App ID and Provisioning Profile in the member center, download the provisioning profile and double click or drag it onto the Xcode icon.

You should have already setup your App Developer Account under Xcode -> Preferences -> Accounts.

Then select your Code signing and provisioning profile for the target you want to publish. Make sure it is under the distribution configuration.

Read the Article Slackmoehrle recommended and verify that you have your build settings, iOS Deployment Target (minimum you want to support), build number increased from previous submitted version, and other settings configured. If you publish and forget to add a requirement that restricts the target audience of your app, it might not be possible to restrict your distribution later by adding a requirement.

After you are confident that you are ready to submit your app, select the target you want to deploy, such as AppName-mobile iOS Device and then select Product -> Archive.

Then choose Window -> Organizer, select the app you want to submit, and then you can validate and submit your app from Organizer. Or you can use the Application loader GUI or command line to upload your app. Scripting the GUI can be very useful if you want to upload several apps that have a similar bug.

After uploading your app, you will need to login to iTunes Connect and attach the build to your app and then submit the app for review from within iTunes Connect.

1 Like

Thank you @slackmoehrle and @Heyalda for answering me.

I find interesting the distribution configuration, for the code signing I always use a code sign for debug and a code sign for release, generally I pick it from the combo box when I’m building.
For iOS target I’m using 5.1.1 as minimum version, and I made the same steps like you for archiving and then validating/submitting.

Anyway they approved my last submit without problem, so I think, like @slackmoehrle said, that they handle it for me (or I hope :stuck_out_tongue:), because this is important also for all CCLOGs, even if now I can try to downloading the .ipa from the store and try to “analyze” it.

Really thank you for now, I’ll keep you updated.

When you say ‘they’ I assume you mean the Cocos2d-x team. And by ‘handle it’ I assume you mean that the Cocos2d-x team setup the HelloWorld in a way that is “optimized”. I think they probably did.

Apple definitely does not do anything to your build that you submit. And you cannot count on Apple’s testing to reject your app if there is something wrong with it. They will sometimes miss major issues and approve the app.

Regarding your concern about debug logging
The Debug build has a Preprocessor Macro defined as COCOS2D_DEBUG=1, which enables debug logging with CCLOG.
The Release configuration does not define COCOS2D_DEBUG, so CCLOG will not log.
The default Archive configuration is Release, so you should be fine if you used CCLOG.

In both Release and Debug configurations, cocos2d::log or printf will log.

My Reasoning for Adding a Distribution Configuration
You could continue to manually change the code signing config of the release when you want to test the Release version. But this is why I make a third Distribution configuration that is the same as Release, except the code signing is different.

Having a Distribution configuration is not required, but I think it streamlines developing, testing and distributing somewhat.

Ok understood, thank you very much, your explanations are really clear.