Xcode: Who’s to Blame?

A recent tweet from Dave DeLong reminded me of something that’s been on my mind for a long while.

As software developers, we all screw up. We all check in software with accidental bugs. We’re all constantly coming up to speed with new frameworks, tools, APIs, language features, concepts, and best practices. We’re all trying to accomplish a lot in a limited amount of time.

I think the hashtags Dave used, #BeNice and #DontBeAJerk, convey the sentiment that we should have empathy for each other as developers and as human beings.

Of course, all software has room for improvement and I also think it’s perfectly valid to vent frustrations about the tools you use professionally.1

But I don’t think disparaging the people who work on the software or attributing bad motives to them is helpful at all.

That said, I think it’s fair that the same principle should extend to Xcode itself, especially something that has bothered me for a long time: Blame.

Blame is “responsibility for a fault or wrong” — a word with a very negative connotation.

Screen capture of 'Show Blame for Line' contextual menu item

In Xcode, every line of code is a mea culpa.

Blame is pointing fingers without solving the issue at hand.

In Xcode, the Blame view and the Show Blame For Line menu item imply that the code you or anyone else writes is a reason to be embarrassed and ashamed.

According to the Xcode user interface, every line of code written for Apple platforms is something that should be apologized for—every app in the App Store built from culpable actions and misdeeds.

Blame doesn’t belong in the user interface of Xcode.

Words Matter

A parody of the Swift logo, with a flounder instead of a swift

There’s a reason it’s not called Flounder.

You could certainly make the case that it’s just a word and no big deal. But I believe words matter.

If you clicked on this article based on the title, thinking you would be reading an accusatory, negative piece about Xcode, then you have just experienced the power of the word blame.

And folks at Apple know that words and their connotations matter. There’s a reason it’s called ‘Swift’ and not ‘Sloth’ or ‘Flounder’. There’s a reason we’ll probably never see ‘macOS Death Valley’ even though, like Yosemite, it’s a National Park in California.

That’s How Git Does It

Screen capture of hypothetical Xcode showing an Author menu item instead of Blame

Author! Author!
in an Xcode without Blame.

You could also make the case that blame is the command name in git. But the git command diff corresponds the Comparison view in Xcode. So using exact git terminology in Xcode is not sacrosanct. Even if it was, git has the equivalent and less pejorative annotate.2

Of course, Apple has a long history of forging its own path, regardless of what others in the industry are doing. One could imagine taking the same approach as with the Comparison view and using a name that has nothing to do with an existing git command. The icon in the Version editor pop-up menu already shows the outline of a person. That view could possibly be called the Author view, with a corresponding Show Author For Line menu item.

Just A Joke

You could also say that blame is just a wry bit of humor and if everyone knows it, then it lessens the negative connotation.

But not everyone is necessarily in on the joke. An example is people who are just learning to write code and develop apps. Learners, whether children or adults, can have a fear of failure when trying something new, compounded by a fear of being ridiculed for failing when trying. People new to programming don’t know all of our witty little inside jokes, they just know that Xcode is assigning blame to their efforts.

Apple has been touting the Everyone Can Code program for a few years now, including courses on building apps in Xcode. It think it is great that Apple is making such efforts to teach programming skills to a wide audience. But blame doesn’t belong in a learning environment.3

Sign Your Work

During the development of the original Macintosh, Steve Jobs decided to include each team member’s signature on the inside of the case. The signatures were engraved in the tool that molded the case of every early Mac produced.

This wasn’t so customers would know who to blame. This was because artists sign their work.

Similarly, as software developers, our names are embedded in every commit. They are a record of our work and effort, a record of every success and failure, a record of every hard-won lesson learned.

Whether you are a complete newcomer or an experienced coder, you should be able to take pride in your work as a developer. Your tools should do their best to help you. Your tools should acknowledge and, if possible, even celebrate your authorship, not disparage it.

Please take the blame out of Xcode.

It’s one small change in a .strings file, but may be one giant leap for our coding culture. •

I filed a Radar about this issue in June 2011 while still working at Apple—it was closed as Not To Be Fixed. Today I filed another bug report which you can see on OpenRadar. Feel free to file duplicates.


But don’t expect venting to change anything. The best approach is still to file a bug. That’s no guarantee your issue will be addressed, but you’ve provided the constructive feedback. Of course, the opacity of the Apple bug reporting system has its own frustrations and is its own can of worms.

Which is admittedly a less catchy name.

In Xcode 9, ‘Show Blame For Line’ is no longer in the code editor contextual menu in Xcode Playgrounds, but it’s still in the Editor menu. But students also want to build apps, and outside of Xcode Playgrounds, blame is still in full force.

New Xcode Build System and BuildSettingExtractor

Last week at WWDC 2017, Apple announced a new build system for Xcode, with an opt-in preview in Xcode 9. The new system is written in Swift and promises to be a significant advance in a number of areas including performance and dependency management. The new system is built on top of the open source llbuild project and lays the foundation for integrating the Xcode build system with the Swift Package Manager.

You opt in to the new build system per project or workspace. To do so in the Xcode 9 beta, open a project file and then go to File > Project Settings… and in the sheet that appears, choose New Build System (Preview) from the Build System popup menu. Note that the menu item will be File > Workspace Settings… if you are working with a workspace.

Project settings sheet with popup menu to select build system

Opt-in to the new build system for a project in File > Project Settings…
(For a workspace use File > Workspace Settings…)

The big news of a new build system made me curious to see if there were any changes I would need to make to BuildSettingExtractor.

Icon for the app BuildSettingExtractor

BuildSettingExtractor helps you move to xcconfig files.

If you are not familiar with it, BuildSettingExtractor is an open source utility that helps you move to using xcconfig files. It reads the build settings embedded in an Xcode project file and extracts the settings into xcconfig files. It can also extract the Xcode help for each build setting to produce automatically documented configuration files. (Read my prior post Generating Xcode Build Configuration Files with BuildSettingExtractor for more about the benefits of using xcconfig files.)

My investigation led me to look more closely at what was changing and what was staying the same when it came to the new build system and build settings in Xcode 9.

When it comes to build settings, there are two big operations: Defining build settings and using build settings.

As developers, we spend our time on the first part, defining build settings1. In a complex project or workspace, this can be an involved process. Defining build settings includes all of the following:

  • Build settings defined for each target and for the project itself
  • Variable substitution to define derived build settings using ${} or $()
  • Conditional build settings based on build configuration, architecture, and SDK
  • Optionally using xcconfig files to define build settings
  • Understanding the well-defined hierarchy of how build settings are inherited and used

In the end, these intricate and flexible mechanisms for defining build settings resolve into a big dictionary of key-value pairs that is passed to the build system.

The build system is what uses the build settings to help direct how it builds a target. The build system coordinates the various tools required, such as the compiler and linker. It uses a target’s build phases and build settings to generate a build product (e.g. app, extension, framework, library). It understands all of a target’s dependencies and builds them as well. The build system is a complicated beastie with a lot of responsibilities and it is what is being modernized beginning in Xcode 9.

Logo of new Xcode build system

New build system.
Same build settings.

On a number of my projects, I’ve switched from the current build system to the new build system in Xcode 9 to investigate. It appears that everything about defining build settings remains unchanged. Moving between the old and new build systems did not cause any build setting changes or recommended changes. The mechanisms for generating that giant bucket of key-value pairs known as build settings seem to be just the same as before.

This is great news. As developers, we don’t need to learn a new complex system for defining build settings. We get to enjoy the benefits of a new, faster, modern build system with our existing build settings left intact.

As the developer of BuildSettingExtractor, this is also great news—no big changes required. After doing some testing and a tweak here and there, BuildSettingExtractor is now updated to work with the Xcode 9 beta. I invite you to check out BuildSettingExtractor and the new build system in Xcode 9. •


1And debugging them.

iOS Device Summary: A8 iPod Touch Update

I’ve updated my iOS Device Summary with the newly announced iPod touch.

You can check out the iOS Device Summary page for more info about the summary plus PDF downloads—including optimized files for printing.

For developers, the iPod touch has been a useful, relatively inexpensive compact device for testing. The previous model was released almost four years ago and sits at the very low end of devices that support iOS 8 and iOS 9.  The new sixth generation iPod touch is a welcome addition as a more affordable testing device with a recent 64-bit processor.  Like previous generations, the new iPod touch has a 4-inch display, so an iPhone is still needed for on-device testing of larger screen resolutions.

It is interesting to note that every iOS device that Apple currently sells, except the iPhone 5c, has a 64-bit processor.

This also means that if you need to acquire older models for testing iOS 8 and iOS 9, you will need to turn to refurbished or used devices.

I hope you find this version of the chart helpful. •

Chart depicting iOS devices by screen size, processor and supported OS version

iOS Device Summary: iOS 9 Update

I’ve updated my iOS Device Summary with the iOS 9 info Apple has publicly posted.

Check out the iOS Device Summary page for the rationale behind the summary plus PDF downloads—including optimized files for printing.

Some things to note from WWDC announcements and Apple product lineup changes:

All devices that support iOS 8 will also support iOS 9.

Apps are currently required to support both 32-bit and 64-bit processors. With iOS 9, the App Store will also accept apps that are 64-bit only. This allows developers to limit deployment of an app to more recent devices with faster CPUs and GPUs. The device summary now has a line showing where 32-bit ends and 64-bit begins.

Finally, devices for testing:

  • At $199, the 16 GB, 5th generation iPod touch is still the most affordable compact iOS 9 device
  • At $299, the 16 GB, WiFi iPad mini 2 is now the most affordable iOS 9 iPad
  • As of 6/19/15, the original iPad mini is discontinued—try used and refurbished devices for low-end iPad testing.

I hope you find this version of the chart helpful. •

Chart depicting iOS devices by screen size, processor and supported OS version

Learning More About Xcode Build Settings with BuildSettingExtractor

Last week I posted about BuildSettingExtractor, a utility that makes it easy to pull the build settings out of an Xcode project file and into xcconfig build configuration files. (The post also mentions some xcconfig file benefits with links to ‘how to’ information. Read the earlier post here.)

I also wanted BuildSettingExtractor to be useful for anyone who wants to learn more about the build settings in their projects. To that end, the latest version, available on github, generates build setting descriptions gleaned from the installed version of Xcode.

For example:

// Framework Search Paths
// 
// This is a list of paths to folders containing frameworks to be
// searched by the compiler for both included or imported header
// files when compiling C, Objective-C, C++, or Objective-C++, and by
// the linker for frameworks used by the product. Paths are delimited
// by whitespace, so any paths with spaces in them need to be
// properly quoted. [-F]

FRAMEWORK_SEARCH_PATHS = $(DEVELOPER_FRAMEWORKS_DIR) $(inherited)
	

// Info.plist File
// 
// This is the project-relative path to the plist file that contains
// the Info.plist information used by bundles.

INFOPLIST_FILE = BuildSettingExtractorTests/BuildSettingExtractorTests-Info.plist

Inline Build Setting Info

To learn more about build settings, Apple provides the Build Setting Reference (Apple developer documentation links are notoriously fragile, just search for the document) as well as Quick Help in Xcode when a build setting is selected. (In Xcode choose View > Utilities > Show Quick Help Inspector (Cmd-Opt-2))

In addition to these ways of learning more, BuildSettingExtractor gleans the build setting info from Xcode and puts it inline in the generated xcconfig files. This has a few benefits:

  • Read about each build setting without selecting setting one by one in Xcode
  • Read about only the build settings currently set in your project and targets
  • Information about build settings is available wherever you are looking at the xcconfig file: github, text editors, diff tools, etc.

What if I don’t want this lovely but verbose feature?

If you want BuildSettingExtractor to generate pithy xcconfig files without the build setting info, Choose BuildSettingExtractor > Preferences… (Command-,) for the new preferences sheet and turn it off.

BuildSettingExtractor Preferences Sheet

Happy Building! (and a call for help)

I hope you find BuildSettingExtractor useful, either as a learning tool, or to get rolling with xcconfig files. If you do find it useful, please spread the word about it: https://github.com/dempseyatgithub/BuildSettingExtractor.

As for the call for help, if you would like to help out with a basic app icon for BuildSettingExtractor, the utility can emerge from the primordial world of the generic app icon. Contact me if you are interested. •

Generating Xcode Build Configuration Files with BuildSettingExtractor (xcodeproj → xcconfig)

The most recent NSScreencast covered using build configuration files to specify build settings in Xcode. (Episode #154)

Using build configuration files—or xcconfig files as they are known—has some definite benefits.  However, as seen in the screencast, the initial process of copying the current build settings out of an Xcode project into xcconfig files is tedious and potentially error-prone.

Screenshot of Build Setting Extractor 1.0

Nuthin’ fancy. Drop an xcodeproj file on it—it spits out xcconfig files.

To aid in that initial extraction process, I wrote a utility app called BuildSettingExtractor.  It is available on github at https://github.com/dempseyatgithub/BuildSettingExtractor.

The app is a simple droplet utility: drop an xcodeproj file on it, choose a destination folder, BuildSettingExtractor will extract the build settings from the project and generate xcconfig files.

A set of files is generated for each target in the project and for the project itself.  Each set of files includes one xcconfig file per build configuration and one xcconfig file of shared settings. For example, a typical Xcode project will generate nine xcconfig files: three sets of files for the app target, test target, and project with three files for Debug, Release and Shared in each set.

I hope you find BuildSettingExtractor useful. Even if you are just curious about project build settings, this is an easy way to inspect a project’s build settings without fear of accidentally changing them.

A little more about xcconfig files

By default, Xcode stores all build configuration settings in the project file itself. However, you can tell Xcode to base a build configuration’s settings on a build configuration file instead.

A build configuration file is a text file of key-value pairs. An xcconfig file can also contain comments and include other xcconfig files.

//
// Project-Debug.xcconfig
//

#include "Project-Shared.xcconfig” // Include other xcconfig files

// An xcconfig file is a text file of key-value pairs.
// Use comments to record why you are using certain build values.
// The /*comment*/ and #comment styles are not valid in an xcconfig file.

COPY_PHASE_STRIP = NO
GCC_DYNAMIC_NO_PIC = NO
GCC_OPTIMIZATION_LEVEL = 0
GCC_PREPROCESSOR_DEFINITIONS = DEBUG=1 $(inherited)
GCC_SYMBOLS_PRIVATE_EXTERN = NO
MTL_ENABLE_DEBUG_INFO = YES
ONLY_ACTIVE_ARCH = YES

There are some benefits to using xcconfig files:

  • Build settings are not in project file—this removes one source of project file merge conflicts
  • Build settings can be documented using comments
  • An xcconfig file of shared settings can be included in each build configuration

There are also potential drawbacks to using xcconfig files.  One potential pitfall is that the build settings for a configuration are based on the xcconfig file—but settings set in Xcode override the xcconfig file settings. This can leave you with unexpected build behavior because an errant build setting set in Xcode is overriding the xcconfig file setting.

This issue is compounded by the fact that when new Xcode versions update project settings, the settings are added to the project, not to an xcconfig file.  So when using xcconfig files, some vigilance is required to keep an eye out for build settings being added to the project.  These stray build settings should be moved from the project to the appropriate xcconfig file.

What Next?

BuildSettingExtractor generates xcconfig files from a project—it does not set your project up to use them.  Here are few resources that walk through that process:

I was inspired to release BuildSettingExtractor by Episode #154 of NSScreencast. The episode is a step by step demo walking through the process.

By the way, if you aren’t familiar with NSScreencast, I recommend taking a look. Ben Scheirman (@subdigital) presents weekly bite-sized screencasts covering a wide range of development topics. Some screencasts are free and some, like Episode #154, require a subscription. (Ben also plays guitar with James Dempsey and the Breakpoints, but that has yet to be the subject of a screencast.)

The blog post Using xcconfig Files For Your Xcode Project by Jont Olof Lyttkens (@jontolof) explains how to set up a project to use xcconfig files in Xcode 6.

Finally, Building the Build System by Rob Napier (@cocoaphony) is an older post, written for an older version of Xcode, but the overall concepts and explanation of the benefits are still relevant.

In each of these walkthroughs, instead making a bunch of xcconfig files by hand and then copying and pasting from the project into the correct file, you would use BuildSettingExtractor instead. •

iOS Device Summary: iPad Air 2 and iPad mini 3 Update

It’s been a busy few weeks with Apple announcements and Backtrace, our new album of iOS and Mac development songs, hitting the Billboard charts. I’ve updated my iOS Device Summary to include the recently announced iPads.

Check out the iOS Device Summary page for the rationale behind the summary as well as PDF downloads—including optimized files for printing.

The new iOS devices introduced this fall presented some challenges for the summary chart:

The iPad mini 2 and iPad mini 3 have identical processors and screens. The devices appear on the chart as a single entry, split to reflect the different supported OS versions.

We have not seen a revised iPod touch in two years. With the traditional Apple fall events behind us, it is unlikely we will see a significant update until next fall at the earliest. Since the iPod touch line ends at the A5 chip and the multiple-model iPhones start at the A6 chip, these have been combined into a single row.

Finally, the new A8X chip pushes the number of columns to the limit, so I’ve dropped the ARM chip and the iPhone 3GS and 3rd Generation iPod touch from the chart.

Since the chart is starting to have trouble cleanly representing devices on a single page, I am looking at more dynamic ways of presenting this information in the future.

Until then, I hope you find this version of the summary chart helpful. •

Chart depicting iOS devices by screen size, processor and supported OS version
Check out the iOS Device Summary page to learn more and download printable PDFs of the summary.
And check out Backtrace, the only album of iOS and Mac development tunes ever on the Billboard charts.

Breakpoints in Vegas — Album Preview Jam

Last Friday night, just a stone’s throw away from where Frank Sinatra and The Rat Pack performed their legendary shows, James Dempsey and the Breakpoints made their Las Vegas debut. The jam featured songs from the upcoming album Backtrace.

Album Art for James Dempsey and the Breakpoints Album 'Backtrace'Taking the stage for the first time as Conditional Breakpoints were Jean MacDonald (@macgenie) founder at App Camp for Girls, on guitar for Goto Fail; and Matt Smollinger (@mattsmollinger) of Skaffl on backing vocals for The Liki Song.  Josh Smith (@kognate) of AllTrails made a switch from blues xylophone last month to guitar.  Adding to the excitement, Jonathan Penn (@jonathanpenn), recent hire at everyone’s favorite fruit factory, flew in just in time to don his trademark sunglasses, tune up and jam. Finally, Daniel Steinberg (@dimsumthinking) of Dim Sum Thinking delivered his excellent keynote before jumping in on slide-advance keyboard.


Coming this fall

This fall will see the first album release of James Dempsey and the Breakpoints and Breakpoint Jams from coast to coast. Sign up for updates to keep up with the fun!

Get Email Updates

iOS Device Summary: iPhone 6 Update

I’ve updated my iOS Device Summary to include the new iPhone 6 models.

Check out the iOS Device Summary page for the rationale behind the summary as well as PDF downloads—including optimized files for printing.

At $199, the 16 GB 5th generation iPod touch is still the most affordable compact iOS 8 device.  It allows you to test on the slowest processor supported by iOS 8, with a screen resolution shared by the iPhone 5, iPhone 5c, and iPhone 5s. There is, however, no iPod touch that provides a less expensive way of testing the new screen resolutions on a device.

Of the two new iPhone 6 models, the iPhone 6 Plus seems to be the more important device to have on hand for testing, with both a new scale factor and a greater likelihood of providing a modified user interface to take advantage of all that lovely screen real estate. •

Chart depicting iOS devices by screen size, processor and supported OS version

Check out the iOS Device Summary page to learn more and download printable PDFs of the summary.

An Eclectic Breakpoint Jam in Columbus

The 2014 Fall Tour kicked off at CocoaConf Columbus with the most eclectic collection of instruments ever assembled for a Breakpoint Jam.

It was a night for newcomers to the Breakpoint Jam.

Every breakpoint in the house was conditional except for veteran Breakpoint Daniel Steinberg (@dimsumthinking) of Dim Sum Thinking. Daniel, fresh from the latest revision of his new book, A Swift Kickstart, delivered a fantastic keynote before working his slide-advance magic.

Eric Knapp (@ejknapp) of Madison College introduced the crowd to the Chapman Stick playing a solo song before giving familiar James Dempsey and the Breakpoints songs a new twist.

A jar of Breakpoint Jam

Have you tried the Breakpoint Jam?

CocoaConf mainstay Will LaFrance (@wjlafrance) made his debut as a Conditional Breakpoint on classical guitar.

Reprising his initial performance in Washington DC last March, Mark Dalrymple (@borkware) of Big Nerd Ranch showcased his talents on trombone on Modelin’ Man and vocals on The Liki Song.

Josh Smith (@kognate), co-author of the recently-released Build iOS Games with SpriteKit, arrived at the conference in the midst of transporting a xylophone across state lines, giving Josh a chance to join in the jam as well.

Thanks to everyone in Columbus, we had a great time and hope you did as well!

The Fall Tour continues in at CocoaConf Las Vegas in September, where James Dempsey and the Breakpoints will make their Vegas debut! •

Don’t miss any of the fun, sign up to get email updates!

Get Email Updates