Crafter - Xcode project configuration CLI made easy.
Switch branches/tags
Nothing to show
Clone or download
krzysztofzablocki Merge pull request #24 from sirlantis/patch-1
Convert symbols to strings before passing them to nanaimo
Latest commit 77dc906 Mar 6, 2017
Failed to load latest commit information.
bin initial commit May 2, 2013
lib Convert symbols to strings before passing them to nanaimo Mar 5, 2017 updated podspec and readme Oct 14, 2014
craft.gemspec gemspec warning Nov 6, 2016

How do you setup your Cocoa projects? Do you always set same warnings, clone configurations and do bunch of other stuff? Or maybe you work in a big company and you are missing some standardised setup?

Programmers tend to automatise boring and repetitive tasks, yet I often see people spending time and time again configuring their Xcode Projects, even thought they always set it up same way.

We all know that Xcode templating system is far from perfect, beside we often use different templates, but same level of warnings, scripts etc.

What if you could define your project setup once (even with optional stuff) then just apply that to all your projects?

Enter crafter

That's why I've created crafter, a ruby gem that you can install, setup your configuration once and enjoy hours of time saved.

So how does it work?

Install it by calling:

gem install crafter
crafter reset

this will create your personal configuration file at ~/.crafter.rb

now open that file with your favourite editor and you will see default configuration, along with description of different parts:

load "#{Crafter::ROOT}/config/default_scripts.rb"

# All your configuration should happen inside configure block
Crafter.configure do

  # This are projects wide instructions
  add_platform({:platform => :ios, :deployment => 6.0})
  duplicate_configurations({:adhoc => :debug, :profiling => :debug})

  # set of options, warnings, static analyser and anything else normal xcode treats as build options
  set_options %w(
  # set shared build settings
    :'WARNING_CFLAGS' => %w(
    ).join(" ")
  # and configuration specific ones
    :'BUNDLE_ID_SUFFIX' => '.dev',
  }, configuration: :debug)
    :'BUNDLE_ID_SUFFIX' => '.adhoc',
  }, configuration: :adhoc)
    :'BUNDLE_ID_SUFFIX' => '',
  }, configuration: :release)

  # set non boolean options
  set_build_settings ({
    :'OTHER_CFLAGS' => '-Wall'

  # target specific options, :default is just a name for you, feel free to call it whatever you like
  with :default do

    # each target have set of pods
    pods << %w(NSLogger-CocoaLumberjack-connector TestFlightSDK)

    # each target can have optional blocks, eg. crafter will ask you if you want to include networking with a project
    add_option :networking do
      pods << 'AFNetworking'

    add_option :coredata do
      pods << 'MagicalRecord'

    # each target can have shell scripts added, in this example we are adding my icon versioning script as in
    scripts << {:name => 'icon versioning', :script => Crafter.icon_versioning_script}

    # we can also execute arbitrary ruby code when configuring our projects, here we rename all our standard icon* to icon_base for versioning script
    icon_rename = proc do |file|
      extension = File.extname(file)
      file_name = File.basename(file, extension)
      File.rename(file, "#{File.dirname(file)}/#{file_name}_base#{extension}")


  # more targets setup
  with :tests do
    add_option :kiwi do
      pods << 'Kiwi'
      scripts << {:name => 'command line unit tests', :script => Crafter.command_line_test_script}

As you can see the configuration files is quite easy, yet is pretty flexible. Once you set it up as you see fit, go to your project folder (the one with xcodeproj, workspace etc.) and call:


it will guide you through project setup, with default configuration it would look like this:

1. sample
2. sampleTests
Which target should I use for default?
1. sample
2. sampleTests
Which target should I use for tests?
do you want to add networking? [Yn]
do you want to add coredata? [Yn]
do you want to add testing? [Yn]
duplicating configurations
setting up variety of options
preparing git ignore
preparing pod file
adding scripts

Now your project should have all options applied, generated Podfile (call pod install or set it up in your configuration).

I'm learning Ruby, so I'm looking forward to pull requests on GitHub

Send me your thoughts, I'm merowing_ on twitter


The App Business (the company I worked for) for supporting my idea.

to @alloy, @orta, @romainbriche - for taking some of their valuable time and sharing their thoughts about beta version.

Inspired by liftoff