This wasn’t especially difficult, but it was a little tedious to track down.
I’ve relied on a handy little build phase script (I wish I remember where I found it) for automating build numbers from git commits for iOS apps since Apple gave us access to TestFlight via iTunes Connect. This same script didn’t work for my Apple Watch app as I anticipated, so it took a little bit to work out the kinks for AppStore submission.
It boils down to this
- Set the build number = the number of git commits on the branch.
- Change the Info.plist build numbers for the iOS app target, the Watch App target, and the Watch Extension target. This is done in a script build phase before the “Copy Bundle Resources” phase.
- Reset the Info.plist build numbers after all the build phases have run (another script build phase)
See the gist I posted for the complete script. Make sure to check the directory paths for the correct app name.
The new iTunes Connect has only been out a few days. Overall, I think it’s probably better than the old version – there are just a few things to get used to. It seems there’s a noticeable lack of communication within the new web app – enough that I filed a couple of bug reports.
Two surround the situation where you have uploaded a binary to iTunes connect. The first issue – you are not allowed to re-upload a binary with the same version and build number. However, there is no way to remove the old one. The second is a little less obvious: Uploading the new binaries will place them in a “Processing” state with no indication about what is happening. Fearing something had gone wrong, I tried the upload a few more times with different build numbers & formats – all went to “Processing” with no icon – only the version, build number, and upload timestamp. None of them were available to select so I could submit for App Store review. Xcode said everything was OK, Application Loader said everything was fine. An hour later, all four builds were processed. Thanks, I guess.
No matter the technical process, there are a few key points of communication they missed out on:
- There’s no indication what “Processing” actually does, or how long it should take. Minutes, hours, days?
- There’s no explanation about uploading “duplicate” binary version/build numbers until you’ve actually failed
- Sometimes there are errors saving metadata – generic error message – users should be informed about what entry was wrong, and how to correct the problem
- In general, I see no clear links to documentation, which would have been helpful
- Xcode’s messaging is not consistent with Application Loader, which is also inconsistent with the iTunes Connect website.
I believe these issues are easily addressed, however they sure demonstrate how usability/experience is affected when a few pieces of key information is missing.