The issue, however, is that the dSYM file must match the binary exactly^[1]. I have not even had luck with pulling the code out of version control and compiling a second time to get the files to match up. Therefore, we need to store these dSYM files for every build that gets handed off to someone else. For Cocoa Touch development this means every ad hoc build and every release build. This can be a pain.

To solve this problem I wrote a script that is added as the last build phase of all my iPhone projects. The script will move the dSYM bundle into the project directory in a directory cleverly called “dSYM”. In addition the script will check the bundle into git (after confirming the project is maintained in a git repository) and commit just that bundle. Also, since the file is always named the same thing, it renames the file using the current date and time so that no two bundles have the same file name.

Failure checks

The first thing the script does is determine if it should run.

if [ "$BUILD_STYLE" == "Debug" ]; then
  echo "Skipping debug"
  exit 0;
fi

The first part of the script checks to see if the build style is Debug. Since all debug builds run just on the developer’s device and still contain the debug symbols, they can be safely ignored.

if [ "$EFFECTIVE_PLATFORM_NAME" == "-iphonesimulator" ]; then
  echo "Skipping simulator build"
  exit 0;
fi

The second step is to check to see if the build is against the simulator. Again, we have no interest in storing the symbol files for these builds.

Move the file

Since the location of the file is determined at build time and can vary from developer to developer (as well as machine to machine) I use the environmental variables that are part of the build.

SRC_PATH=${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}
RELATIVE_DEST_PATH=dSYM/${EXECUTABLE_NAME}.$(date +%Y%m%d%H%M%S).app.dSYM
DEST_PATH=${PROJECT_DIR}/${RELATIVE_DEST_PATH}
echo "moving ${SRC_PATH} to ${DEST_PATH}"


mv "${SRC_PATH}" "${DEST_PATH}"

The next step is to build up the paths of where the file is currently and where we are going to move it to. I like to store these in variables so that I can print them out to the console in case something goes wrong.

Commit it to version control

Every project is part of version control right? (RIGHT?)

if [ -f ".git/config" ]; then
  git add "${RELATIVE_DEST_PATH}"
  git commit -m "Added dSYM file for ${BUILD_STYLE} build" \
      "${RELATIVE_DEST_PATH}"
fi

The final part only occurs if the project is part of a git repository. If it is then the bundle is added to git and then just that bundle is committed with a simple message.

Conclusion

Although I have recently been having issues getting symbolicatecrash to work properly, eventually either I or someone else will get it working again and at that time these files will be invaluable in tracking down crashes.

The final script is attached. I normally add the file to the project and then have a script phase that just calls this script file.

Move_dSYM_To_Storage.sh.zip

Firstly, if you think that you only work with yourself and you can handle yourself, have a quick look at the I Am A Moron section of this post or this recent tweet by Kevin Hoctor.

Now a few years ago, I started work on a helpdesk ticketing system called tina. In the early days of tina development, I’d didn’t use any version control. I was frequently confused by my own code. I’d look at a piece of code and wonder, “What was I trying to do here?” or “When did I change this? Wait, did I change this?”. Occasionally, I’d tar-up my code for a historical record and I’m not sure now if I ever referred to those tarballs. When I eventually put the tina code into a Subversion repository I was much happier because of it.

With another project, that I wanted to put under version control, I found I had no less that 3 different versions of the code lying around on my hard drive. It look some investigation with diff in order to find out which one was the most current. Fortunately I didn’t have some files more recent in one copy and others more recent in another copy, but that could have easily happened.

With version control, it’s easy to find out what changed in my code, especially if I write useful commit messages. The most unexpected (and incredibly positive) side effect was that once I started using version control, the quality of my code went up dramatically. By tracking exactly what was changing between revisions, unwanted changes and debug code did not slip into the shipping code.

It’s worth noting that this approach goes hand-in-hand with unit testing. Version control lets you know what is changing and unit testing lets you know that your changes don’t result in regressions. As solo developers without QA teams or even a QA person, using these best practices seriously improves our ability to complete with larger organizations.

So, I recommend version control for any coding project bigger than a few lines of code. I used Subversion for a while and have now moved onto git.

My tips for version control success:

• Make small commits – don’t commit a whole day’s work if you wrote 2 features and fixed 8 bugs. That should be at least 10 commits. For sure, commit every-time you complete something – a bugfix, a feature, fixing a typo, a formatting change. It’s makes it much easier to find regressions and other issues later. Oh, and try not to work on many things at once especially if the changes overlap in the code.
• Compile before commit – each commit represents a known state of your code, so make sure the code compiles correctly without warnings or errors before committing.
• Diff before commit – before each commit, look over the diff of your current code compared with the last commit. Then you’ll know for sure what you are committing. If you don’t like part of the proposed commit, change it, diff it again, repeat until you like it and then commit.
• Write useful messages – When you commit a message is required is usually. Make sure it makes sense to you and to others looking at your repository.

I use git for version control and also the services of github. Now in another post on this site Marcus covered how to put git commit checksums in your Info.plist’s CFBundleVersion. I have opted to use Apple Generic Versioning (or agv for short) instead as it has an easy to read incrementing build number and is super easy to script. It’s also great for use with Sparkle since Sparkle uses the CFBundleVersion to see if the appcast has a newer version. Chris Hanson wrote a great piece a few years back about getting agv setup in your XCode project. I followed his instructions for that. I also set the CFBundleShortVersionString in Info.plist to __VERSION__. You’ll see why I do that later.

When it comes time to build my app for shipping, either privately or publicly, I run tag.sh. This bash script increments the agv version and creates a git tag. The script takes one parameter which is the marketing version of your build (1.0, 2.0.4fc1, 2.5b6 etc).

Before running tag.sh, the state of the git repo should be clean- there should be no other staged files or uncommitted edits. It’s also a good idea to close the XCode project since agvtool will modify the XCode project file.

tag.sh also takes care of committing the changed CFBundleVersion for you. Here is it’s code:

1
2
3
4
5
6
7
8
9
10
11

#!/bin/sh
tag=$1
if [ "$tag" == "" ]; then
	echo "No tag specified"
	exit
fi
agvtool next-version -all
git commit -a -m "Increment CFBundleVersion for $tag"
git tag -m "Tag for $tag" -a $tag
git push origin master
git push --tags

So having run tag.sh I have created a git tag for my build so I can always go back and see that version of the code either in github or using git checkout <tag name> at the command line.

After this I use a jumbo script that checks out the tag I just created, builds it, zips it up, uploads it to my web server, outputs an <item> for your Sparkle Appcast (including signing the update) and maybe tweets about it. Phew. It’s a heavily modified version of Gus Mueller’s build script. Here’s the usage:

build.sh -p ProjectName -t tag [-u [-w tweet]]

The two required parameters are a project name and a tag. Optionally you can upload and then tweet about the newly available build. I do all of my public builds in a separate clone of my git repo that never gets edited or otherwise messed with (~/Development/building/). There’s a whole lot going on in this script that could be explained, but for now I’ll just leave you with the code to walk through, and if something needs clarified, post a comment and I’ll do my best.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118

#!/bin/bash
 
upload=0
tweet=""
 
while getopts ":t:up:w:" Option
do
  case $Option in
    w ) tweet=$OPTARG;;
    u ) upload=1;;
    p ) project=$OPTARG;;
    t ) tag=$OPTARG;;
  esac
done
shift $(($OPTIND - 1))
 
if [ "$project" == "" ]; then
	echo "No project specified"
	exit
fi
 
if [ "$tag" == "" ]; then
	echo "No tag specified"
	exit
fi
 
# Configuration
final_builds=~/Development/release_builds
code_folder=~/Development/building/$project
build_folder=$code_folder/build
keys_folder=~/Development/keys
upload_destination=user@yourcompany.com:/usr/local/apache2/htdocs/downloads/
release_notes_webfolder=http://yourcompany.com/releasenotes
downloads_webfolder=http://yourcompany.com/downloads
twitter_uname=someone@somewhere.com
twitter_pword=password
 
if [ ! -d  $final_builds ]; then
	mkdir $final_builds
fi
 
# clean up
if [ -d $build_folder ]; then
	rm -rf $build_folder
fi
 
cd $code_folder
 
git pull origin master
git pull --tags
git checkout $tag
 
sed -i "" 's/__VERSION__/'$tag'/g' Info.plist
 
echo building project
xcodebuild -target $project -configuration Release OBJROOT=$build_folder SYMROOT=$build_folder OTHER_CFLAGS=""
 
if [ $? != 0 ]; then
	echo "Bad build for $project"
	say "bad build!"
else
 
	#ok, let's index the documentation if we've got it.
	#/Developer/Applications/Utilities/Help\ Indexer.app/Contents/MacOS/Help\ Indexer "/tmp/buildapp/build/Release/BuildApp.app/Contents/Resources/English.lproj/BuildAppHelp"
 
	mv $build_folder/Release/$project.app $final_builds
 
	# make the zip file
	cd $final_builds
	zip -r $project-$tag.zip $project.app
 
	rm -rf $project.app
 
	if [ $upload == 1 ]; then
 
		echo uploading to server...
		# upload
		scp $project-$tag.zip $upload_destination
 
		# get values for appcast
		dsasignature=`$keys_folder/sign_update.rb $final_builds/$project-$tag.zip $keys_folder/$project\_dsa_priv.pem`
		filesize=`stat -f %z $final_builds/$project-$tag.zip`
		pubdate=`date "+%a, %d %h %Y %T %z"`
 
		cd $code_folder
 
		cfbundleversion=`agvtool what-version -terse`
 
		#output appcast item
		echo
		echo Put the following text in your appcast
		echo "<item>"
		echo "<title>Version $tag</title>"
		echo "<sparkle:releaseNotesLink>"
		echo "$release_notes_webfolder/$project.html"
		echo "</sparkle:releaseNotesLink>"
		echo "<pubDate>$pubdate</pubDate>"
		echo "<enclosure url=\"$downloads_webfolder/$project-$tag.zip\""
		echo "sparkle:version=\"$cfbundleversion\""
		echo "sparkle:shortVersionString=\"$tag\""
		echo "sparkle:dsaSignature=\"$dsasignature\""
		echo "length=\"$filesize\""
		echo "type=\"application/octet-stream\" />"
		echo "</item>"
		if [ "$tweet" != "" ]; then
			echo "Calling twitter: $tweet"
			curl -u $twitter_uname:$twitter_pword -d status="$project $tag is up. $tweet" http://twitter.com/statuses/update.xml
		fi
	fi
 
	open $final_builds
	say "done building"
 
fi
 
cd $code_folder
git checkout Info.plist
rm -rf $build_folder

Other References

Push tags to github Sparkle Basic Setup

As memory serves the only time I’ve used version control in a meaningful way the system I was using was Visual SourceSafe from Microsoft. I know. Blech! It’s awful! I’ve pulled code from many a CVS or Subversion repository, but I’ve never really used them in the way they are intended to be used. Now, thanks to Marcus, I realize that version control isn’t just about versioning any more. It’s a whole methodology/ideology that makes better programmers. Here is what I mean.

Branching Inspires Wild Experimentation

Have you ever been so far down a path in your code that you just think, though you probably should, there is no way you would take a chance to re-factor due to looming deadlines or even just a simple fear that you might mess up so badly you couldn’t recover? Well, fear no more! Git provides such a simple way to create a branch of your code in which you can experiment, you won’t even give it a second thought. I won’t go into the whole setup and how to get going with Git as this is done very well elsewhere including a previous post from Marcus. I just want to point out how easy it is to branch with a single command. In Terminal.app, cd to the directory of a project you have under Git source control and enter the following command.

bash$ git branch experimental

bash$ git checkout experimental

bash$ git checkout master

bash$ git checkout master
bash$ git merge experimental

If you found, conversely, that your ideas were purely delusional–a characteristic of your over-achieving sense of hubris–you can blow them away by simply typing:

bash$ git branch -d experimental

Now the idea is just a bad memory and not something you ever need worry about (or mention to your programming peers) again. Your code on the master branch is still as it was when you first started the branch. Hallelujah!

Note: The word ‘experimental’ I’ve used in these command line examples is simply a tag. You can call your branch whatever you like. Call it ‘hubris’ if you like. Depending on your personality, this may be more appropriate.

The chance to experiment so easily and without fear will make you a better programmer. You will venture into areas that you would have never tried before and will likely become more bold in what you’re willing to attempt. This can only be a good thing in the long run.

Collaboration

The Tutorial introduction to git provides a good example of how to collaborate when multiple people are working on the same computer, but where Git’s real power comes in is in its ability to enable collaboration. If you’re familiar with extreme programming or pair programming then you are already aware of how collaboration will make you a better programmer. The learning curve for developing applications for the Macintosh for me has been significantly leveled as Marcus has shown me how to do things in the context of real code. You can learn things in many different ways, but sharing code has got to be one of the strongest means of gaining deeper understanding. This can only make you a better programmer.

While not a direct feature of Git itself, you can share your repository over the many file sharing web applications out there. Marcus and I use Dropbox for our projects that we collaborate on. Here are the steps you take to collaborate remotely using Git and Dropbox.

1. Sign up and install Dropbox from http://www.getdropbox.com.
   
   This will create a folder in your home directory under ~/Dropbox.
2. Have the person you want to collaborate with do the same and then create a shared folder that both of you can access through the Dropbox web interface.
   
   
3. From the project directory of the project you want to share, type:

   bash$ git clone --bare . ~/Dropbox/Shared/MySharedProject.git
   

   Note: Keep in mind that I’m assuming you already have this project under Git version control. If not you first need to run init like so in the root of your project directory.

   bash$ git init
   

   The –bare keyword we used in the clone command means that we simply want to create a directory that contains the contents of the .git directory in your project directory and not the actual workspace. The .git directory contains all of your code and changes to everything you need is there–it’s just not the actual workspace where xcode works from.
4. Create a remote (alias) for the newly cloned project by typing:

   bash$ git remote add sharedproject ~/Dropbox/Shared/MySharedProject.git
   



5. Now you can push any code changes from your working directory to the cloned directory, which, since it is in your Dropbox will automatically be uploaded to the drop box and downloaded by any other computers you have that can access Dropbox. First you need to commit any changes in your working directory with the following command.

   bash$ git commit -a -m "Commit message"
   

   Then you need to push the changes to the remote with the following.

   bash$ git push sharedproject master
   

   This pushes your changes to the cloned repository which is in your Dropbox directory. As soon as you do this, you should see the Dropbox icon in your menu bar change to the ‘synchronizing’ icon. If your change is small, it will only change for a split second so you’ll have to watch it closely to see that happen.

Once your files are committed and have been pushed to your cloned repository, you can now pull the project from another computer. I’m assuming you have Git and Dropbox set up on the second computer. Here are the steps you take to get the code into Git.

1. In Terminal.app on your other computer, create a new directory where you want your project to be stored with a working directory. Now run the following command.

   bash$ git clone ~/Dropbox/Shared/MySharedProject.git
   

   Notice that we didn’t use the –bare keyword this time. This is because we want our cloned copy to also setup a working directory since we’ll be accessing it from xcode on the second computer as well.
2. Now create a remote (alias) to reference the project like you did on the other computer using the following.

   bash$ git remote add sharedproject ~/Dropbox/Shared/MySharedProject.git
   

   Note: This step is optional as your clone will do this automatically. The difference, however, is that the clone will create a remote called ‘origin’ by default where you can name it whatever you want (sharedproject in the example) if you do run it.

3. Now you can pull the code at any time with the following command.

   bash$ git pull sharedproject master
   

   You won’t need to do that at this point as your code is fresh from the clone, however, should you make any changes on the originating computer that have been pushed, you could now pull those changes from this secondary computer.

If you now make changes to the code on the second computer, you can use the exact same command you used on the first computer to push the changes. First commit the changes with:

bash$ git commit -a -m "Commit message"

bash$ git push sharedproject master

And now you’re up to date. The changes are ready to be downloaded from the first computer.

The Urge To Merge

Nothing like sexual inuendo (urge to merge, hint hint, wink wink) on a site called ‘Cocoa is my Girlfriend’ to get a geek going, but that’s not what I mean. Settle down. Take it easy…

In the end, Git’s greatest feature is its ability to merge code changes.

There are times when you have fairly complex code merges that are necessary and systems such as CVS or SVN (Subversion) will simply choke and give up leaving the messy merging process to your weak manual merging skills. This is a shame and not necessary any more as it is rare for Git to be unable to successfully merge code. Again, this probably its biggest strength. When you don’t have to worry about merging your code, you can do whatever you like in your branch with little fear that merging in your changes are going to conflict with someone else’s. This merging power comes from Git’s unique philosophy of source code management which sees changes as individual code additions and deletions rather than complete file changes.

Conclusion

There will remain naysayers who have “always done it this way” and will remain in the realm of central repositories for version control. However, if you can think outside of tradition and see the power that comes from a good source control system, you will become a better programmer. I will submit that simply starting to use any version control when you haven’t before will make you a better programmer, however, using Git for your version control system, will make it infinitely easier to become so.

There are a few scripts floating around that perform this trick for subversion, but git handles build numbers a bit differently and it appears that no one has bothered to publish one. As is known, subversion uses an incrementing integer for build numbers. This makes it very easy to determine which build number came first and makes it very useful for a non-public version number. Git, however, uses a hash for each build number which is not incrementing and therefore not very useful for determining version numbers. However, it is still very useful for pulling up a specific build when a crash report is received, etc.

Therefore, with the help of Matt Long’s perl-fu, I have updated Daniel Jalkut’s subversion perl script to work with git. Since the build numbers are not sequential, I would not recommend using them for Sparkle. Therefore, in my own build process for iWeb Buddy, I hand select the version number (for example 1.0.4) and then use the short hash from git as the CFBundleVersion number. Normally this number is displayed in parens after the primary build number but, at least in iWeb Buddy, I have removed it from the display entirely. Since it is no longer a sequential number it would only potentially confuse users and it displays in the crash reports anyway.

The updated script is as follows:

# Xcode auto-versioning script for Subversion by Axel Andersson
# Updated for git by Marcus S. Zarra and Matt Long
 
use strict;
 
# Get the current git commit hash and use it to set the CFBundleVersion value
my $REV = `/opt/local/bin/git show --abbrev-commit | grep "^commit"`;
my $INFO = "$ENV{BUILT_PRODUCTS_DIR}/$ENV{WRAPPER_NAME}/Contents/Info.plist";
 
my $version = $REV;
if( $version =~ /^commit\s+([^.]+)\.\.\.$/ )
{ 
	$version = $1;
}
else
{
	$version = undef;
}
die "$0: No Git revision found" unless $version;
 
open(FH, "$INFO") or die "$0: $INFO: $!";
my $info = join("", <FH>);
close(FH);
 
$info =~ s/([\t ]+<key>CFBundleVersion<\/key>\n[\t ]+<string>).*?(<\/string>)/$1$version$2/;
 
open(FH, ">$INFO") or die "$0: $INFO: $!";
print FH $info;
close(FH);

Since git is distributed, there is no need to be online to produce a build. The script will grab the current abbrev-commit hash and will inject it into the current build’s Info.plist file.

I am also a user of .mac. I like the service and the iDisk is probably my favorite feature. Therefore, I wondered, like chocolate and peanut butter, could I put these two together and come up with something better than the individual parts?

The answer is yes. They work amazingly well together and make it very easy for me to push my code changes off-site even when I am not actually connected to the net. The basic configuration is fairly simple. I created a private directory on .mac, set up a bare repository in that directory and defined that directory as a remote location for my Git workspace. Below are the details on how to accomplish this.

Install Git on OS X

First, you need to have Git. The easiest way that I have found to get it is to use the MacPorts and do a ‘sudo port install git-core +svn’. I add svn because once you get used to Git you will want to put it in front of all your svn repositories that all those stone age developers still use.

Note: After installing MacPorts, you may need to add /opt/local/bin to your PATH in order for the port command to be found from the command line. Edit your .bash_profile file in your home directory (assuming you use bash) in Terminal and add the following line to the bottom of the file: export PATH=/opt/local/bin:$PATH .

Create your working repository

Once you have Git installed, you will want to create a repository. That is accomplished with a single call:

mkdir TempProject
cd TempProject
git init

What that does is create a single directory called .git in the TempProject directory. All of the version information for that workspace is stored in that single .git directory (hello Subversion guys, your .svn directories suck).

Set up the bare clone

Now that your repository is created, you want to create a remote copy of it in case your harddrive eats itself or gets stolen (BTW Wil, sorry to hear about your MBA, that thief should burn). To do that, you want to have iDisk local syncing turned on. When it is, you will have a directory under /Volumes with your .mac username. For instance, mine is at /Volumes/mzarra. In this directory you want to create a new directory (I called mine git). Make sure that directory can only be accessed by you.

Now that it is created, you want to build the bare clone of your workspace. To accomplish this, execute the following:

cd TempProject
git clone --bare . /Volumes/${USERNAME}/git/TempProject.git

After a few moments your new bare clone is ready.

Linking the remote clone

The final step is to tell your local repository where that remote repository is:

cd TempProject
git remote add origin /Volumes/${USERNAME}/git/TempProject.git

Note that I used origin as this is the default repository name for push and pull. If you want your origin to be somewhere else then change this name.

Performing a push

Now that everything is set up all you need to do to sync your repositories is:

git push

And Git will update the bare clone.

Sync multiple working copies

But wait — there is more. If you have more than one Mac, you can use this bare clone to keep your two workspaces in sync! On the other Mac, once Git is installed, you can grab a working copy as follows:

git clone /Volumes/${USERNAME}/git/TempProject.git

And you will now have another working copy! If you need to update your second Mac at a later point just:

git pull

And Git will do all the work for you.

Conclusion

There are a couple things to note.

• The initial sync back to .mac can be slow if your workspace is large. However, as long as you ‘push’ often enough, your subsequent syncs should be very quick. Therefore, get in the habit of pushing often.


• Only one Mac can sync with .mac at a time. Therefore it is possible to get a sync failure if the n Macs try to sync at the same time. Therefore if you are going to do a pull and you just pushed to .mac, make sure that both syncs succeeded.