list.her.sh

The right xcodebuild at the right time

2015-06-13T00:00:00+00:00

What an incredible WWDC! You’ve probably been checking out the new bits and you’ve collected several versions of Xcode on your machine.

Traditionally, you’d switch active xcodebuild versions using the xcode-select --switch command-line utility. But this requires sudo and switches the active developer directory system-wide, both of which can be undesirable particularly for CI builds.

It turns out you can specify a per-build developer directory on the command line without xcode-select! The trick is twofold: assign a value to the DEVELOPER_DIR environment variable and run your build with xcrun.

I standardize my build commands with rake tasks. Here’s a rake test task you might use, perhaps in your xcode-7 branch, to execute a single build using an alternate Xcode:

desc 'Run all application tests.'
task :test do

  dev_dir = ENV['DEVELOPER_DIR'] || ""
  
  # Path to desired Xcode beta
  ENV['DEVELOPER_DIR'] = '/Applications/Xcode-beta.app/Contents/Developer'
  
  sh "set -o pipefail && xcrun -sdk iphonesimulator "+
  "xcodebuild ... etc ... "+
  "clean test | bundle exec xcpretty -ct"

  ENV['DEVELOPER_DIR'] = dev_dir
  
end

iOS Test Coverage with Coveralls

2015-03-11T00:00:00+00:00

Code coverage measures how much of your app or library is executed by at least one of your tests. This manifests as a percentage from 0-100% that can be a good high-level indicator of the quality — or at least the breadth — of your tests.

Today we’ll see how easy it is to automatically measure, report, and visualize code coverage in your iOS app or library. You’ll end up with a report like this one for each file in your project and a great visual representation showing line-by-line where your coverage is strong, where you can improve, and how your coverage trends up (or down!) over time.

You will need:

An iOS app or library to test
Some tests to execute against your app or library
A CI service that executes your tests, like Travis CI or CircleCI, both of which are free for open-source projects
A code coverage tool like Coveralls that can visualize your code coverage results. Coveralls is free for open-source projects!
A utility like slather that sends your test code coverage results from your CI service (#3) to your code coverage tool (#4) every time your CI service runs your tests

SSDataSources, Jazz Hands, FastttCamera, and IFTTTLaunchImage are great examples of open-source iOS projects that report code coverage with Travis CI, Coveralls, and slather. As of this writing, slather does not yet support CircleCI, but work is in progress and SSDataSources is nearly there. Update: slather now supports CircleCI and SSDataSources now builds on CircleCI with slather!

First, you’ll need to get CI to run your project’s tests each time you push a commit. See the Travis CI iOS docs and CircleCI iOS docs, or perhaps you’ll be inspired by these .travis.yml and circle.yml files from the above projects.

Now you’ll need to add the slather rubygem to your project. You don’t necessarily need slather installed locally on your development machine; rather, you could include it in your project’s Gemfile or as a dependency command in your .travis.yml. You’ll also need to instruct your CI service to execute slather after a successful build: for Travis CI, you might add to your .travis.yml a line like after_success: slather.

You’ll need to update some build settings in your project so that when your project’s tests are run, xcodebuild will measure the code paths that are executed by your tests and generate a file that code coverage utilities can parse for coverage results.

There are three ways to set this up. Pick your favorite:

If you have slather installed on your development machine, you can execute slather setup path/to/project.xcodeproj to enable the necessary settings in your Xcode project.
If you don’t have slather locally, head to the “Build Settings” tab of your Xcode project, scroll down to the “Code Generation” section, and set to YES these two settings for the scheme(s) and configuration(s) that your tests will execute: Generate Test Coverage Files and Instrument Program Flow.
You could update the flags passed to xcodebuild in the build command in your .travis.yml or circle.yml to add:

GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=YES 
GCC_GENERATE_TEST_COVERAGE_FILES=YES

You might consider updating your CI script’s build flags (#3 above) even in addition to #1 or #2 to be extra certain that your CI service is generating code coverage files for every build.

Next, head to Coveralls, sign in with your Github user, and add your repo to Coveralls.

Your project will also need a simple .slather.yml file in the root of your repo. This instructs slather how to process your code coverage results and where to send them. Here is one of mine, for use in a Travis CI project:

ci_service: travis_ci
coverage_service: coveralls
xcodeproj: Example/ExampleSSDataSources.xcodeproj
source_directory: SSDataSources

Of particular note for CocoaPods repos is the source_directory parameter. Here you can specify exactly which files should be included in your code coverage results — this is necessary so that you can measure only the files in your pod and exclude source files that might be in a sample or demo project.

That’s it! Package up a commit with your changes, send it via carrier pigeon to Github, and — if your build succeeds — you should see your very first coverage report on Coveralls.

CGFloat in a 64-bit world

2014-10-10T00:00:00+00:00

Apple’s A7 chip famously moved to a 64-bit architecture. This ushered in an era of access to more memory* and a CGFloat type previously aliased to float newly redefined as double. Wait, what?

If you’re writing an iOS app that targets multiple architectures, you’ll want to use the proper CGFloat type for the current device’s architecture. You’ll also want to use the correct float or double versions of math functions like floor (double) or floorf (float).

Thanks to some preprocessor magic and the CGFLOAT_IS_DOUBLE define, we can construct some helpers that call the correct math function and return a number of the correct type for the current architecture. Behold, SPLFloat.h!

Update: One alternative to the below is tgmath.h, though it must be included before math.h. That can be challenging if you’re using CocoaPods.

// SPLFloat.h

@import Foundation;

#pragma once

CG_INLINE CGFLOAT_TYPE SPLFloat_floor(CGFLOAT_TYPE cgfloat)
{
#if CGFLOAT_IS_DOUBLE
	return floor(cgfloat);
#else
	return floorf(cgfloat);
#endif
}

CG_INLINE CGFLOAT_TYPE SPLFloat_ceil(CGFLOAT_TYPE cgfloat)
{
#if CGFLOAT_IS_DOUBLE
	return ceil(cgfloat);
#else
	return ceilf(cgfloat);
#endif
}

CG_INLINE CGFLOAT_TYPE SPLFloat_round(CGFLOAT_TYPE cgfloat)
{
#if CGFLOAT_IS_DOUBLE
	return round(cgfloat);
#else
	return roundf(cgfloat);
#endif
}

CG_INLINE CGFLOAT_TYPE SPLFloat_abs(CGFLOAT_TYPE cgfloat)
{
#if CGFLOAT_IS_DOUBLE
	return fabs(cgfloat);
#else
	return fabsf(cgfloat);
#endif
}

CG_INLINE CGFLOAT_TYPE SPLFloat_pow(CGFLOAT_TYPE cgfloat, 
                                    CGFLOAT_TYPE exp)
{
#if CGFLOAT_IS_DOUBLE
	return pow(cgfloat, exp);
#else
	return powf(cgfloat, exp);
#endif
}

* My kingdom for an iPhone with more than 1GB RAM.

Beta iOS App Icons

2014-09-30T00:00:00+00:00

If you’re constantly switching between Debug, Adhoc/Beta, and Release builds of your app, it can be very helpful to have unique app icons for each configuration. You can easily tell at a glance which version is installed, your beta testers send you better feedback, a lasting world peace takes hold — everyone wins! Best of all, with Xcode 5+’s asset catalogs, there’s no code required.

Here’s how this looks in my app MUDRammer - A Modern MUD Client:

	Debug
	Adhoc/Beta
	Release

Start by adding one or two new App Icon image sets to your asset catalog: click the + in your asset catalog → New App Icon. (Your app doesn’t use an asset catalog? Xcode will create one for you on your project’s General tab. Go ahead, I’ll wait.)

Give your new App Icon image sets some memorable names. Mine are AppIconRelease, AppIconAdhoc, and AppIconDebug.

In your application target’s build settings, scroll down to Asset Catalog Compiler - Options and expand the arrow next to Asset Catalog App Icon Set Name. By default, you’ll see the same App Icon set for all of your app’s configurations. Now it’s just a matter of assigning your App Icon set names to the proper configurations for your app.

Here’s some caution tape. Be careful out there!

For bonus points, start continuously integrating your iOS app. Here’s my build script!

One Star

2014-01-09T00:00:00+00:00

One Star (2014)

Mixed Media (iTunes, Acorn)

On a dark dessert highway

2012-10-15T00:00:00+00:00

On a dark dessert highway, Cool Whip® in my hair
Warm smell of carnitas rising up through the air
Up ahead in the distance, I smell some sizzling fries
My stomach rumbled – it needs glycogen!
I just had to supersize

Hostess stands in the doorway, I heard the taco bell
I was thinking to myself, “This could be heaven or calorie hell!”
Then she holds up a Twinkie® and she throws it my way
Creamy filling hits my uvula
Like a fine soufflé

Welcome to the Hostess® Cafeteria
Sugar-coated plates (syrup on your face)
Salad’s a disgrace
For any olfactory criteria
Fourteen kinds of beer (one by Richard Gere)
Bagels served with smear

She loves her froyo twisted, with sprinkles she recommends
She got a lot of tall, hirsute garçons she calls “Franz!”
See them push the dessert cart – sweet Crêpes Suzette!
Some served from a blender, some avec baguette

So I tackled a garçon,
“CHOCOLATE NOW MINE!”
He screamed, “There’s some kind of lunatic here lying down on my spine!”
Still got some morsels of tasty créme brûlée
Eat ‘em up in the middle of a Skype
With a large latte…

with apologies to D. Felder, D. Henley, and G. Frey

hello world

2012-10-14T00:00:00+00:00

More people should write. I’m trying (again) to be one of them.