I’m starting a new Rails project. I want to use Ruby 1.9.3 from the beginning to ease a future upgrade to Rails 4.0, which will require it. This presented a few issues I had to work through for my development and production environments.

Mac OS X ships with Ruby 1.8.7, but I’ve been using RVM to manage different Ruby versions in development and it’s worked fine. Debian is my preferred server distribution and the latest stable release includes Ruby 1.9.2-p0.

I’m not completely comfortable with using RVM in a production environment, and I don’t want to take on the work of installing my own Ruby entirely by hand, so this led me to look at rbenv, a lightweight alternative to RVM. It seems better suited for use in a production environment. I like to match development to production when possible so there are less things to remember, and so I switched to rbenv on my development machine, as well. Paired with ruby-build, it gives me the important features I used from RVM (I never made much use of gem sets).

It did not go well.

$ rbenv install 1.9.3-p0
$ RBENV_VERSION=1.9.3-p0 gem install bundler rails
$ rbenv rehash
$ RBENV_VERSION=1.9.3-p0 rails new app
...
/Volumes/User/Steve/.rbenv/versions/1.9.3-p0/lib/ruby/1.9.1/net/http.rb:799: [BUG] Segmentation fault
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.3.0]

Searching for solutions led me to suspect that this is due to a library version mismatch between the compiled Ruby and a gem. MacPorts can make this more common, because unlike Homebrew, it imposes strict control over dependencies and will install a new version of something (e.g., OpenSSL) even if Mac OS X ships with an older one that would work fine.

Rather than track down the problem library, then figure out how to ask rbenv to link with a different version of it, I decided to try Homebrew.

It worked flawlessly. The error when creating a new Rails project is gone.

What really sealed the deal for me came next. I like PostgreSQL, partly because it supports additional data types that can be very useful. One example is cube, which is used by the earthdistance extension to store locations and do fast proximity searches. On MacPorts, installing those “contrib” extensions is a manual, clunky process. On Homebrew, all the contrib extensions are already compiled and available.

Sold.

Several of the buttons, especially the colored ones along the bottom half of the directional pad, are not rectangular.

It doesn’t matter if we’re developing on the Mac or iOS. Views are rectangular and they either gobble a click/tap or they don’t. Take a look at the green button. The blue outline shows the frame of the view. It overlaps two other buttons: down and rewind. Especially on iOS, where a fingertip is an imprecise input method, a user will find it very frustrating if a tap on down was instead interpreted as green.

The solution is quite straightforward on iOS: create a subclass of UIButton and override -pointInside:withEvent:.

- (BOOL) pointInside:(CGPoint)point withEvent:(UIEvent *)event
{
    /* Surprisingly, this method is called even when point has a negative
     * component and is obviously outside of self.bounds. */
 
    if (CGRectContainsPoint(self.bounds, point))
    {
        /* The point is within our bounds. If a mask exists, check the mask
         * for an allowed tap. If there is no mask, let the superclass
         * (UIButton) do the work. */
 
        if (mask != NULL)
        {
            return mask[(NSUInteger)point.y * maskWidth + (NSUInteger)point.x];
        }
        else
        {
            return [super pointInside:point withEvent:event];
        }
    }
    else
    {
        return NO;
    }
}

pointInside:withEvent: is called by hitTest:withEvent:, once for each subview. If a subview returns NO, then its branch of the hierarchy is ignored. By making pointInside:withEvent: sensitive to only the part of the image that is the button, it’s possible to ignore events for taps on a part that doesn’t.

The key is building a mask. Here, it is a two dimensional BOOL array. If mask is not NULL, the x and y of the point is used to index into the array and return the value there. If mask is NULL for any reason, the code simply falls back to the superclass’s behavior.

One way to build the mask is to look at the alpha channel of the image.

- (void) buildMask
{
    if (mask)
    {
        free(mask);
        mask = NULL;
    }
 
    CGImageRef image = [self imageForState:UIControlStateNormal].CGImage;
    if (image == nil)
    {
        return;
    }
 
    NSUInteger width = CGImageGetWidth(image);
    NSUInteger height = CGImageGetHeight(image);
    uint32_t *pixels = malloc(width * height * 4);
 
    if (pixels != NULL)
    {
        /* Provided that memory for the temporary 32-bit pixel array was
         * available, draw the CGImage into that memory. */
 
        CGColorSpaceRef colorSpaceRef = CGColorSpaceCreateDeviceRGB();
        CGContextRef context = CGBitmapContextCreate(pixels, width, height,
                                                     CGImageGetBitsPerComponent(image),
                                                     width * 4, colorSpaceRef,
                                                     kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Host);
 
        CGContextSetBlendMode(context, kCGBlendModeCopy);
        CGContextDrawImage(context, CGRectMake(0, 0, width, height), image);
        CGContextRelease(context);
        CGColorSpaceRelease(colorSpaceRef);
 
        mask = malloc(width * height * sizeof(BOOL));
        maskWidth = width;
        if (mask != NULL)
        {
            for (NSUInteger y = 0; y < height; ++y)
            {
                for (NSUInteger x = 0; x < width; ++x)
                {
                    /* RGBA: high 24 bits are color, low 8 bits are alpha.
                     * Less than 50% alpha is the untapped part of the image. */
                    mask[y * width + x] = (pixels[y * width + x] & 0xFF) > 128;
                }
            }
        }
        else
        {
            NSLog(@"Unable to allocate memory, will fall back to UIButton behavior.");
        }
 
        free(pixels);
    }
    else
    {
        NSLog(@"Unable to allocate memory, will fall back to UIButton behavior.");
    }
}
 
- (void) setImage:(UIImage *)image forState:(UIControlState)state
{
    [super setImage:image forState:state];
    [self buildMask];
}

The subclass overrides setImage:forState: so that when the image is set or changed, the mask is regenerated. To use a non-rectangular button within Interface Builder, we need to also override initWithCoder:.

- (id) initWithCoder:(NSCoder *)coder
{
    self = [super initWithCoder:coder];
    if (self)
    {
        [self buildMask];
    }
 
    return self;
}

If you don’t want to use the alpha channel, another option is to provide an explicit mask image. Masks are monochrome bitmaps, where white indicates the visible area. Building the mask array from a mask image is very similar to using the alpha channel. The only difference is what part of the pixel data is analyzed.

- (void) setMaskImage:(UIImage *)maskImage
{
    if (mask)
    {
        free(mask);
        mask = NULL;
    }
 
    if (maskImage == nil)
    {
        return;
    }
 
    CGImageRef image = maskImage.CGImage;
    NSUInteger width = CGImageGetWidth(image);
    NSUInteger height = CGImageGetHeight(image);
    uint32_t *pixels = malloc(width * height * 4);
 
    if (pixels != NULL)
    {
        /* Provided that memory for the temporary 32-bit pixel array was
         * available, draw the CGImage into that memory. */
 
        CGColorSpaceRef colorSpaceRef = CGColorSpaceCreateDeviceRGB();
        CGContextRef context = CGBitmapContextCreate(pixels, width, height,
                                                     CGImageGetBitsPerComponent(image),
                                                     width * 4, colorSpaceRef,
                                                     kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Host);
 
        CGContextSetBlendMode(context, kCGBlendModeCopy);
        CGContextDrawImage(context, CGRectMake(0, 0, width, height), image);
        CGContextRelease(context);
        CGColorSpaceRelease(colorSpaceRef);
 
        mask = malloc(width * height * sizeof(BOOL));
        maskWidth = width;
        if (mask != NULL)
        {
            for (NSUInteger y = 0; y < height; ++y)
            {
                for (NSUInteger x = 0; x < width; ++x)
                {
                    /* RGBA: high 24 bits are color. Anything other than black
                     * is tappable. */
                    mask[y * width + x] = (pixels[y * width + x] & 0xFFFFFF00) != 0;
                }
            }
        }
        else
        {
            NSLog(@"Unable to allocate memory, will fall back to UIButton behavior.");
        }
 
        free(pixels);
    }
    else
    {
        NSLog(@"Unable to allocate memory, will fall back to UIButton behavior.");
    }
}

It’s not that Objective-C doesn’t have test frameworks. There are several: OCUnit (bundled with Xcode), GHUnit, Cedar and Kiwi. Cedar and Kiwi use blocks to get close to an RSpec-like syntax, but there’s only so far it can go. Objective-C can’t match Ruby when creating a DSL, even with preprocessor abuse.

Fortunately, there is a way to write tests in Ruby and run them against Objective-C code: MacRuby. MacRuby is an implementation of Ruby 1.9 that compiles Ruby to LLVM bytecode and has full access to Objective-C frameworks. You can write full Mac desktop applications with it, but for this post I’ll simply use it to write test specs with RSpec for testing Objective-C classes.

In this post, I’ll walk you through how to install MacRuby, RSpec and how to set up your Cocoa (Mac or iOS) project to unit test with RSpec. These tests are analogous to model specs in Rails. We’ll be testing classes in isolation, not trying to recreate the Cocoa environment in order to test window or view controllers, etc.

A big caveat for iOS developers: MacRuby loads Objective-C code from a framework, but iOS targets don’t support building frameworks. What this means is that you don’t have access to the UI* classes in the code under test. This limits what you can test. Pure model classes (those without any external dependencies) will be fine. Theoretically, it should be possible to find the simulator frameworks and link against those, but I’ve been unsuccessful thus far. Chameleon might help if you want to dig into this further.

With that out of the way, let’s get started. If you haven’t already, download and install MacRuby. This places the macruby binary and other Ruby tools you’re familiar with (irb, gem, rake) in /usr/local/bin, with mac prefixes.

Then, install RSpec 2.5 (at present, there are problems running specs with 2.6).

$ sudo macgem install --bindir /usr/local/bin --format-executable rspec -v '~>2.5.0'

--bindir ensures the rspec script doesn’t overwrite one that might already exist in /usr/bin, and --format-executable adds the mac prefix to it, so it matches the other MacRuby-provided scripts.

In Xcode, open your project and create a new target (File -> New Target). Use the Cocoa Framework template, found under Mac OS X, Framework & Library. Call it whatever you like. I used “Specs”. Do not use Automatic Reference Counting. MacRuby, like MRI Ruby, is garbage collected and will use the Objective-C garbage collector. If your project uses ARC, that’s OK. retain, release and autorelease are no-ops under GC, and nothing changes if the calls to them are missing in the first place. Include Unit Tests should also be unchecked.

You must adjust some build settings for the new target. Under Apple LLVM Compiler – Language, find the settings for Objective-C Automatic Reference Counting and ensure it is set to NO. Just below that, set Objective-C Garbage Collection to Supported.

Go to the target build phases, and add the .m files you wish to test to the compile sources phase. As you add files to your project later, be sure to check the boxes for both your main target and the Specs target if you want to test the new code.

Finally, you need to configure the schemes for the new target. In the build scheme, check the run box. In the run scheme, choose /usr/local/bin/macruby as the executable to test.

Set up the arguments to pass to the executable when it runs as follows:

Choose your framework as the base for expansions. You’ll pass two arguments to the program: the path to the RSpec wrapper and the directory containing the specs.

You might wonder why we’re using MacRuby as the executable to test instead of RSpec directly. If you try to use RSpec, Xcode won’t recognize it as a 64-bit executable and will refuse to run it under the debugger. It will work, but you must also choose “debugger: none” and give up your breakpoints, etc.

With this new target you get a new top-level group in your project. Xcode has also created Specs.h and Specs.m, which we don’t need. You should delete them.

Create a new file in this group called spec_helper.rb and paste this in:

framework 'Specs'
 
# Requires supporting ruby files with custom matchers and macros, etc,
# in spec/support/ and its subdirectories.
Dir["#{ENV['SRCROOT']}/Specs/support/**/*.rb"].each {|f| require f}
 
RSpec.configure do |config|
  # == Mock Framework
  #
  # If you prefer to use mocha, flexmock or RR, uncomment the appropriate line:
  #
  # config.mock_with :mocha
  # config.mock_with :flexmock
  # config.mock_with :rr
  config.mock_with :spec
end

At this point, you should be able to choose your new target from the scheme picker in the toolbar and run. We haven’t created any specs yet, so you should see this:

GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug  8 20:32:45 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys004
[Switching to process 1636 thread 0x0]
No examples were matched. Perhaps {:if=>#<Proc:0x4007553a0 (lambda)>, :unless=>#<Proc:0x400795b60 (lambda)>} is excluding everything?

Finished in 0.0331 seconds
0 examples, 0 failures
Program ended with exit code: 0

You may not see any output. You can use ⌘7 and look at the most recent log or use this tip from Martin Pilkington to create a new window for output. I find this much less intrusive than allowing Xcode to constantly pop up the debugging panes in my editor windows.

Let’s create a simple spec file. Assuming you added a .m file that implements a class called Foo, create a new file in your Specs group called foo_spec.rb:

require "#{ENV['SRCROOT']}/Specs/spec_helper"
 
describe Foo do
  it { should be_an_instance_of(Foo) }
end

Run again and you should see this:

GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug  8 20:32:45 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys004
[Switching to process 1796 thread 0x0]
.

Finished in 0.40422 seconds
1 example, 0 failures
Program ended with exit code: 0

It works! Now try adding breakpoints, mocking and stubbing objects, etc. You have all the features of RSpec available to you.

One common suggestion for improvement from attendees was for demos. These are always tricky with networking topics, because you never know how good the Wi-Fi will be at a conference. When I give this talk in the future, I think I will split it into two, build some demos, and bring a second laptop with a cross-over cable.

With 109 sessions to choose from, newcomers may not know where to start. This guide is intended to help you get started.

The Keynote: the only WWDC session not under NDA, this is where all the public news was announced. If for some reason you haven’t watched it yet, it’s worth watching, although it is a bit long and by now you’ve probably heard about everything.

Since everything else is under NDA, I can’t discuss specifics about the content of sessions.

Start with the Apple Platforms Kickoff. Where the keynote is truly for the press, this session is for developers.

Whether your focus is on Mac OS X or iOS, you’ll be using Xcode, so move on to Session 300: Developer Tools Kickoff. You’ll learn about the new tools and features coming in future versions of Xcode.

The final kickoff session is Session 400: Graphics, Media, and Games Kickoff. I found this session to be less focused on new stuff and more a general overview of the available frameworks and tools, though the demo at the end is impressive. There is a bit about Game Center and AV Foundation if you’re interested in these frameworks.

Trivia: in previous years, these sessions used the “State of the Union” moniker.

Where to next? That depends on what you want to do. Many sessions include pointers to others covering specific topics, so be sure to watch for those to find more information about areas that interest you.

If you’re a Mac OS X developer…

If you have an app in the Mac App Store or plan to ship one in the future, start with Session 203: Introducing App Sandbox and Session 204: App Sandbox and the Mac App Store. There are new submission requirements coming with 10.7 that are more important than anything else.

Follow that up with Session 101: What’s New in Cocoa. This is the high-level session to learn about the new stuff for developers in 10.7. Don’t miss Session 323: Introducing Automatic Reference Counting so you can (mostly) stop thinking about manual memory management.

Session 127: Design Patterns to Simplify Mac Accessibility is James Dempsey’s annual talk that includes a song. Even if you don’t think you care about accessibility (hint: you should), his talk is great and the song is a funny distillation of the topic.

If you’re an iOS developer…

Start with Session 100: What’s New in Cocoa Touch, then Session 323: Introducing Automatic Reference Counting, followed by Session 309: Introducing Interface Builder Storyboarding and Session 102: Implementing UIViewController Containment. Follow the suggestions for related sessions depending on your interests and needs.

App Design

Excellent design will set your app apart from the crowd. There are two sessions covering UI and UX topics: Session 110: Designing User Interfaces for iOS and Mac OS X Apps and Session 105: Polishing Your App, the latter of which includes non-visual polish such as responsiveness and performance, a user experience issue.

Security and Performance

You should care about the security of your app and how well it performs. Session 202: Security Overview discusses attack vectors and options for addressing them. Session 310: What’s New in Instruments will point you in the right direction for performance analysis and tuning, while Session 312: iOS Performance and Power Optimization with Instruments and Session 318: iOS Performance in Depth teaches practical techniques for diagnosing and fixing problems for iOS apps.

Releasing these videos for free is a great service to the Apple developer community. There is value in almost every session, and the huge advantage we have in watching them now is we can check out topics we might not have made time for if attending the conference in person. Skip ahead or stop a video if it isn’t holding your attention.

My recommendations here are a starting point. Apple’s platforms are growing and getting better every year. Explore new things; you never know when you might learn something relevant to an existing project. Watch a session about a topic you think you know well. With such a rich set of frameworks, there are often little tricks to learn that mean you can rewrite some old code to be clearer or perform better.

Is there a particularly good session I haven’t mentioned? Mention it in the comments!

Early registration opened today and you can get a conference pass for 50% off.

dlopen(/Library/Ruby/Gems/1.8/gems/mysql2-0.2.6/lib/mysql2/mysql2.bundle, 9): Library not loaded: libmysqlclient.16.dylib
Referenced from: /Library/Ruby/Gems/1.8/gems/mysql2-0.2.6/lib/mysql2/mysql2.bundle
Reason: image not found - /Library/Ruby/Gems/1.8/gems/mysql2-0.2.6/lib/mysql2/mysql2.bundle

That example is from the mysql2 gem, but the same problem exists with the older mysql gem. The problem is that the libmysqlclient shared library in the MySQL 5.5 package does not specify a full path to the library. When something links with it, such as the MySQL gem, it won’t be able to find the library at runtime.

There are two ways to fix this.

1. The easy way: modify DYLD_LIBRARY_PATH in your .bash_profile (or equivalent if you use another shell). The advantage to this method is that it fixes it once for anything that links with the MySQL client libraries going forward. Add:

   DYLD_LIBRARY_PATH="/usr/local/mysql/lib:$DYLD_LIBRARY_PATH"

2. The hard, do-it-again-someday way: modify the .bundle files within the gem to use an absolute path to the MySQL client library. The fix is lost when reinstalling the gem or updating to a new version and must be reapplied. Change to your gem’s root, somewhere like /Library/Ruby/Gems/1.8/gems/mysql-2.8.1 or .../mysql2-0.2.6, or even both. There are two .bundle files within the gem (under lib and ext) that you must run the following command on.

   $ sudo install_name_tool -change libmysqlclient.16.dylib /usr/local/mysql/lib/libmysqlclient.16.dylib mysql_api.bundle

The second problem with the MySQL 5.5 packages is in the MySQLStartupItem and preference pane. Neither work to start or stop the server.

1. The ownership of the StartupItem files is wrong. OS X complains with

   “/Library/StartupItems/MySQLCOM” has not been started because it does not have the proper security settings.

   To fix that, run:

   $ sudo chown -R root:wheel /Library/StartupItems/MySQLCOM

2. basedir and datadir are not set in /usr/local/mysql/support-files/mysql.server, which breaks the preference pane. Edit that file with superuser privileges (sudo mate or vi, joe, …) and set them:

   basedir=/usr/local/mysql
   datadir=/usr/local/mysql/data

There are problems on both the selling and buying sides of the store. Much more has been said about the problems for sellers, but I’ll run down the list anyway.

No analytics: Small developers don’t have unlimited budgets, so the money we spend on marketing must be spent wisely. This is impossible without feedback. We don’t know how many people are looking at our apps or where they came from. That makes it impossible to measure an ad’s effectiveness. AdMob offers a way to close this loop for ads run on their network, but it requires sending them complete sales data and a marker that they can use to build a detailed picture of the apps users are buying and running.

Little price flexibility: We can’t offer coupons or specials to loyal customers or upgrade pricing. Historically, major version upgrades are a big part of a small developer’s revenue. On the App Stores, new and recurring customers are treated the same.

No trials: Probably the #1 reason apps are so cheap on the iOS App Store is because it’s impossible for customers to try before they buy.

No contact with customers: We don’t know who our customers are and can’t contact them for any reason.

Reviews are a toxic, one-sided conversation: Customers can leave scathing reviews filled with untrue statements, and we’re powerless to respond. It’s allowing customers to picket our storefront.

Reviews and no control over release timing: Developers can (and are) rejected by Apple’s review team for ridiculous reasons. Even when an app is accepted, review can still take two weeks or more. For updates, this means a known and fixed bug remains in the field and causing problems long after it should.

Greatly reduced cash flow: Developers are paid by Apple at the end of each month for the previous month’s sales. At best, that’s a 30 day delay before receiving the cash. At worst, 60 days. For small developers, that makes paying employees and vendors much harder.

The problems don’t end there, though. As successful as the App Store has been, if the buying experience were improved, it could be much more so. Here’s an experiment for you to try.

Imagine you’re unhappy with your current weather app, whatever it may be. Go find the “best” alternative.

I tried doing this and quickly gave up because the buying experience when you don’t already know exactly what you want is awful.

Search is limited: search looks at only app titles and keywords. This is undoubtably because unscrupulous developers try to game the system, but it also means customers must rely on developers choosing meaningful names and keywords. It’s led to borderline spammy app titles. The result is that search queries are short and return either nothing or lots of results.

No way to sort or filter results: literally, no way. You can only browse the results, in the order Apple returns them, page by page. Off the top of my head, some obvious sorting options that would be useful: by rating (both all time and current version) and by price. Useful filters: price tiers, age, and category.

No useful ways to sort when browsing categories: The only choices when browsing a category are by name or release date.

The App Store has over 300,000 apps. Imagine trying to shop at Amazon if you couldn’t sort or filter. For the developer, what this essentially means is that you won’t make any money unless you “win the lottery:” Apple decides to feature your app and/or you make it into the top seller lists. Features are also of limited benefit: the category-specific What’s New and What’s Hot lists aren’t available on the device, which I’m willing to bet is where the vast majority of people shop.

No trials and no upgrade pricing: There is obviously overlap here. As a customer, I’m less willing to buy a more expensive app unless I have confidence it works. Similarly, I’m less willing to spend a bit more than I’d like for an app if I know the next major version will cost me just as much or more (on the desktop, I can justify it since the upgrade is often discounted).

I don’t expect that Apple will fix any of these problems. 10 billion downloads in 2½ years is a remarkable achievement. Apple is a hardware company; while the App Store is certainly profitable, as long as hardware sales stay strong, that’s what they really care about.

All I can do as a small developer is learn from past mistakes and not repeat them in the future. For me, that means no more mass-market, 99¢ apps and likely no more advertising. My future products will focus on niche markets, solving real problems instead of filling a few minutes of a bored customer’s time. These are the people that should be willing to tolerate the App Store’s limitations and eventually find my app, likely even searching Google on their computer and not exclusively shopping from the device.

Update Feb. 4: MacRumors reports that on the iPad, the App Store now offers filtering of search results. I hope something similar comes to the iPhone and iPod touch.

I’ve been moving toward Git for more of my work, for mostly two reasons. The first is that Subversion uses “@” to denote a specific revision of a file, which makes adding images for the Retina Display annoying because they use “@2x” in the file name. The second is that integrating third-party source into a project is more work than it should be because Subversion litters the tree with .svn directories. I can’t simply delete the old third-party source and drop in the new files, because Subversion loses its state. Yes, I could svn rm, then svn add, but that grows the repository unnecessarily and I lose the ability to diff the source and see what actually changed.

Git does not use a numeric repository version, however, and a simple SHA1 hash is unsuitable for use as the third component of a bundle version because it can include the letters a-f. I took the simplest way out and use a file (build-counter) with a number in it, incremented for every Ad Hoc and App Store build, but not for Debug or Release. This file is created if it does not exist and automatically committed.

As with my Subversion script, if any local modifications are detected during an Ad Hoc or App Store build, it will fail.

Since it’s likely that Apple will enforce the same format restrictions on Mac App Store apps, this script can also be used in those projects.

# Xcode auto-versioning script for Git by Steve Madsen.
# Adapted from Subversion script by Axel Andersson.
 
build_counter_file = 'build-counter'
 
raise "#{$0}: Must be run from Xcode" unless ENV['BUILT_PRODUCTS_DIR']
 
def development?
  ENV['BUILD_STYLE'] !~ /Ad Hoc|App Store/
end
 
def local_modifications?
  `git ls-files -m` != ""
end
 
build_counter = File.read(build_counter_file).to_i rescue 0
unless development?
  raise "#{$0}: local modifications present for a production build!" if local_modifications?
 
  build_counter += 1
  File.open(build_counter_file, 'w') { |f| f.printf "%d", build_counter }
  unless system "git commit -m 'increment build counter' #{build_counter_file}"
    raise "#{$0}: Git commit of #{build_counter_file} failed: #{$?.exitstatus}"
  end
end
 
info = "#{ENV['BUILT_PRODUCTS_DIR']}/#{ENV['WRAPPER_NAME']}/Info.plist"
info_xml = `plutil -convert xml1 '#{info}' -o -`
raise "#{$0}: reading Info.plist failed: #{$?.exitstatus}" unless $?.success?
 
info_xml.gsub! %r{([\t ]+CFBundleVersion\n[\t ]+\d+\.\d+).*?()}, "\\1.#{build_counter}\\2"
 
IO.popen("plutil -convert binary1 - -o '#{info}'", 'w') { |plutil| plutil << info_xml }
raise "#{$0}: writing Info.plist failed: #{$?.exitstatus}" unless $?.success?

In Terminal, you can reposition the cursor on a line by option-clicking where you want it to go. Credit where due.

It doesn’t happen every day, but certainly a few times a week: I end up with a monster command, spanning two full 100 character wide lines or more. Inevitably, there’s an error in there in the middle, and I sit waiting, holding down left-arrow to fix it and try again.