Geek Answers Handbook

Xcode version 4.4 updates do not appear until the next build

Something is probably missing me here. I try to automatically increase the build number in Xcode 4.4 only when archiving my application (in preparation for deploying TestFlight). I have a working shell script that runs on target and successfully updates the info.plist file for each assembly. My build configuration for archiving is the name "Ad-Hoc".

Here is the script:

if [ $CONFIGURATION == Ad-Hoc ]; then echo "Ad-Hoc build. Bumping build#..." plist=${PROJECT_DIR}/${INFOPLIST_FILE} buildnum=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${plist}") if [[ "${buildnum}" == "" ]]; then echo "No build number in $plist" exit 2 fi buildnum=$(expr $buildnum + 1) /usr/libexec/Plistbuddy -c "Set CFBundleVersion $buildnum" "${plist}" echo "Bumped build number to $buildnum" else echo $CONFIGURATION " build - Not bumping build number." fi

This script updates the plist file accordingly and is reflected in Xcode every time it is archived. The problem is that the .ipa file that exits the archive process still shows the previous build number. I tried the following solutions without success:

  • Clean before assembly
  • Empty assembly folder before assembly
  • Move the Run script to phase immediately after the "Dependency Dependencies" step in the build steps
  • Adding a script action as a script run in my schema as a preliminary action

No matter what I do, when I look at the build log, I see that the info.plist file is being processed as one of the first steps. It is always before I run the script and update the build number, which I suppose is why the build number is never current in the .ipa file.

Is there a way to force the Run script phase to run before the info.plist file is processed?

+4
source share
3 answers

in Xcode 4.4.1 I create a new target and add to this phase of the target assembly “Run custom script”, which updates the main target Plist. In addition, you must add this goal depending on the main goal.

+1
source

The reason this happens is because by the time you run your “Run Script”, the Xcode build process has already processed the project plist file to extract the package version number, etc.

You can see this (perhaps in more detail what you want) by going to the log navigator in Xcode (View / Navigators / Show Log Navigator) and selecting the "Archive" assembly.

A detailed list of assembly actions should appear in your main window, and one of the things near the top should be named Process <projectname>-Info.plist . If you expand it using the icon on the right, you will see the actual build command that was running.

The way I got around was to update both the original plist file and the processed one. By doing this, you get an updated version of the assembly in the current assembly, and not in the next.

Here's the script I'm using for this (this is Ruby, so you will need to put "/ usr / bin / ruby" in the interpreter field to use this, but the concept works the same with a shell script or any other scripting language):

 def incrementBundleVersion(file) oldVersion = `/usr/libexec/Plistbuddy -c "print :CFBundleVersion" #{file}`.strip components = oldVersion.split('.') newBuild = components.pop.to_i + 1 version = components.push(newBuild).join('.') print "Updating version: #{oldVersion} -> #{version} : #{file}\n" system("/usr/libexec/PlistBuddy -c \"Set :CFBundleVersion #{version}\" #{file}") end incrementBundleVersion("#{ENV['PROJECT_DIR']}/#{ENV['INFOPLIST_FILE']}") incrementBundleVersion("#{ENV['CODESIGNING_FOLDER_PATH']}/Info.plist")

Please note that the processed file #{ENV['CODESIGNING_FOLDER_PATH']}/Info.plist is a plist binary, so you cannot process it with simple text tools. Using plistbuddy is the easiest way to handle this, and it automatically works with both text and text binary plist files.

+1
source

Mark (et al.), I think I ran into the same problem that you encountered, and I will try to describe it in one sentence, and then explain:

I think that / usr / libexec / PlistBuddy, when launched from inside Xcode, works with cached versions of Info.plist data, and therefore, what is finally written to execute on a device or simulator is not always what you want.

I tried to write the message “Copy Resource Bundle” “Launch Scripts” to change this information so that it does not change in my local git repository, only to detect this, while the information will work correctly when the PlistBuddy commands were executed in the window terminal.app next to Xcode, if not done, cached values ​​will be written.

I finally resigned myself to running the scripts for generating version information before the Copy Bundle Resources stage, and simply made automatic changes to another Run Script, using the same tags for the git message and for git that are automatically created. for the Settings.bundle / Root.plist file, and not for fixing it every time, I chose to just run a script finalization that would execute 'git checkout - $ {PROJECT} /Resources/Settings.bundle/Root.plist' (where there is mine, but it may not be where everyone puts their own system settings resource file).

between checking for changes, running its parts during installation and its parts each time and with the final script at the end, there are 6 scripts for some purposes and 7 for another ...

... but what matters to me is that it is finally automatically automated ... and turns around what PlistBuddy does with my plist files when processed inside Xcode.

0
source

More articles:


All Articles