A phased approach to sandboxing
With the March 1st start date approaching when sandboxing becomes a requirement for submissions to the Mac App Store, I’ve been considering my options. (more…)
Revisiting git tags and building
A couple of years ago I posted my scripts for tagging and building. The build script doesn’t work so well for the App Stores and the Build and Archive-based submission process, so here’s an updated approach that works inside Xcode. (Same as my last article, I’m still using git, the tag.sh script, and Apple Generic Versioning (agv).)
- In your Xcode project, create a Shell Script target called GenGitVersion.
- Insert the following script in GenGitVersion’s Run Script phase, replacing the path to your git executable if need be:
1 2 3 4
git=/usr/local/git/bin/git version=`$git describe` echo "#define GIT_VERSION $version" > InfoPlist.h touch Info.plist
- Make GenGitVersion a dependency of your main target.
- Add “InfoPlist.h” to your .gitignore file.
- In your main target’s build settings:
- Turn on Preprocess Info.plist File
- Set Info.plist Preprocessor Prefix File to InfoPlist.h
- In your app’s Info.plist set the Bundle versions string, short to GIT_VERSION
Now each time you build the main target, the version will be populated in the build’s Info.plist.
Examples
- If you tag a commit, the version returned by
git describeis the tag name. If the current commit isn’t tagged, you’ll get the most recent tag plus the number of additional commits and an abbreviated commit name. Here’s a 1.0b1 tag with 2 additional commits: 1.0b1-2-g3925f3b. This can be a good way to identify a private developer build.
- You can optionally add
--dirtytogit describeand the version will have-dirty appended if there are uncommitted changes to your working tree. git describewill fail if there are no tags in the current working tree.
Why version control is important for solo developers
It’s common practice for any software project with multiple coders to use some version control mechanism. CVS or Subversion used to be popular. These days distributed systems like git and Mercurial are the quickly replacing the old standards. But what about the cases when you’re the only coder? (more…)
Limiting 64-bit to 10.6
Now that we’re all using XCode 3.2 on Snow Leopard (you are, right?) and building 64-bit apps you may find that not everything 64-bit works when your app is run on Leopard. (more…)
The journey to disabling sleep with IOKit
If your app is fullscreen, like a game, has a presentation mode, or plays long running movie files, you’ll want to disable the display from sleeping. DVD Player and Keynote are perhaps the two most obvious examples of this functionality. (more…)
From Hacker to microISV: Tagging, Building and Releasing
It is important to develop a consistent build process for your applications. I have written a couple of bash scripts to help me with this process.
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. (more…)
Launching: If it ain’t broke, don’t fix it
This is the first in a short series on my adventures getting my software out the door. Rather than this first lesson be a lesson in what to do, here’s what not to do. (more…)
Dropping NSLog in release builds
NSLog() is a great tool that helps debugging efforts. Unfortunately it is expensive, especially on the iPhone, and depending on how it’s used or what you’re logging, it could leak sensitive or proprietary information. If you look around the web, you’ll find a few different ways to drop NSLog in your release builds. Here is what I’ve put together based on those. (more…)
Adding iTunes-style search to your Core Data application
iTunes has a very neat way of searching your library, where it takes each word in your search and tries to find that word in multiple fields. For example, you can search for “yesterday beatles” and it will match “yesterday” in the Name field and “beatles” in the Artist field. The basic predicate binding for NSSearchField provided by Interface Builder is not complex enough to archive this kind of search. I need to build the predicate dynamically since I can’t assume what field the user is trying to search and that each additional word should filter the list further – just like iTunes. Here is how to go about adding iTunes-style searching. (more…)