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.

NSConference 7: A Look Back

Last fall, I received an email that read, “I would like to invite you to be a speaker at NSConference 7”.

In the invitation email, conference organizer Steve ‘Scotty’ Scott (@macdevnet) described his intent for the conference:

“At NSConference I want the speakers to be with the attendees all the time. I want you to be at the sessions, I want you to be at the meals, I want you to be at the events. I want you to mix, eat, drink and chat with as many attendees as possible.”

“What I require most in an NSConference speaker is enthusiasm and a love of being with the OS X and iOS developer community. Right now I am not looking to pick talk topics, as it’s all about people first.”

I accepted the invitation immediately.

All About People First

In his opening remarks, Scotty expressed the same intent in a different fashion. He said that the speakers and topics were, of course, important, but the real heart of NSConf was creating an environment where members of the developer community could interact.

Leicester Athena

Leicester Athena
Photo by NotFromUtrecht via Wikimedia Commons

The format at NSConf was unlike other conferences I have attended. Each segment began with a 30-minute talk followed by two 10 or 15-minute blitz-talks, followed by a 30-minute break. This approach packed three topics plus plenty of time to talk with fellow attendees into a 90-minute block.

The venue was the Leicester Athena, a gorgeous 1930s art deco theater re-styled to host events. The seating was at round tables, giving folks a chance to talk with one another. There was a massive stage with great lighting and sound (and yes, a full bar on stage too). It is truly a beautiful venue, well-suited to Scotty’s goals for the event.

The days were filled with speakers giving talks, conversations with attendees and lots of coffee and tea. In the evenings, good food and more conversation. The first night was the banquet, each table set with a candelabra, with wine and a meal served at your table. The second night was the party, with a buffet meal and mingling.

It was after folks had a chance to be fed at the party that we launched into our Breakpoint Jam.

Breakpoint Jam: NSConf Edition

The idea behind a Breakpoint Jam is that the band is made up of whoever happens to be in town for a conference. Folks practice up some James Dempsey and the Breakpoints songs on their own before arriving, we do a quick rehearsal the day of the show, and then we perform.

I find the most stress-inducing shows are when all the musicians are new to the Breakpoint Jam — this was one of those performances.

It takes a leap of faith to get on a plane in San Francisco and fly over 5,000 miles to England, knowing you will be performing for a theater full of people with musicians you have never performed with, rehearsed with, or in some cases even met before.

Kevin Cupp on guitar, James Dempsey on vocals, Jonathan Fox on drums and S ‘Scotty’ Scott on bass at the Breakpoint Jam during NSConference 7

Kevin Cupp, James Dempsey, Jonathan Fox and Steve ‘Scotty’ Scott kick off the NSConf 7 Breakpoint Jam
Photo by Cathy Shive

That leap of faith was rewarded by musicians that pulled it all together amazingly well in the rehearsal time allotted.

Guitarist and iOS developer Kevin Cupp (@kevincupp) did perhaps the best walk-on guitar part in Breakpoint Jam history, having learned every nuance from the rehearsal tracks I had sent.

Longtime NeXT and Apple indie developer John Fox (@djembe) added a full drum kit to a Breakpoint Jam for the first time, skillfully playing the varying musical styles from the driving beat of Goto Fail to the Hawaiian breeze-inspired Liki Song.

Rounding out the core trio of Conditional Breakpoints for the evening was NSConf’s own Scotty on bass. (It is no coincidence that Scotty was positioned closest to the on-stage bar.)

For The Liki Song, backup singers arrived in the form of Laura Savino (@savinola) and Ruotger Deecke (@roddi) making their Breakpoint Jam debut, and Uli Kusterer (@uliwitness) whose bass voice is perfect for the ‘object alloc’ chant beneath the choruses.

And, on the ever-important slide-advance keyboard, the incomparable Daniel Steinberg (@dimsumthinking).

Kevin Cupp playing guitar, James Dempsey singing and playing ukulele, Jonathan Fox playing drums, Laura Savino, Ruotger Deecke and Uli Kusterer singing, Steve ‘Scotty’ Scott playing bass.

Left to Right: Kevin Cupp, James Dempsey, Jonathan Fox, Laura Savino, Ruotger Deecke, Uli Kusterer, Steve ‘Scotty’ Scott.
Image by Marius Ciocanel

It was tremendous fun to play on that big stage, in that beautiful theater, complete with lighting effects (and a fog machine, I think). The show was only possible because of all of those who joined in the jam—a big thank you to them for lending their talents to the show. And of course, a giant thank you to everyone the audience, it was a privilege to play for you all.

The Future: A Look Back

Scotty had stated that this year’s NSConference would be the last. When I looked at the schedule, I saw that Scotty had chosen my session The Future: A Look Back to be the last talk of the last day of the last NSConf.

The talk took a look back to the Apple/NeXT merger and the history of some of the technologies that we use today. After the talk, some old-timers told me that they enjoyed the walk down memory lane, while some more recent arrivals to iOS and OS X development commented they appreciated hearing some backstory on the technologies they are using today.

James Dempsey Presenting ‘The Future: A Look Back’ at NSConf 7

The Future: A Look Back at NSConf 7
Photo by Raphael Sebbe

Scotty had also announced that, although this was the final NSConf, he hoped to do another event in the future that took the best of NSConf, but proceeded in a different way — different enough that calling it ‘NSConf’ would be misnomer.

With that in mind, I closed my talk as follows:

“As we wind down to the last session of the last NSConf, I’d remind you that in this developer world of ours, nothing is ever truly gone. Specific implementations come and go, particular instances are created and released, but the underlying themes stick around. That’s true whether we are talking about technologies, or the community of people that use them to create magnificent things.”

Almost Like Being There

Being at NSConf was a fantastic experience — I learned a lot and had the chance to meet and get to know people I would likely not have met otherwise.

I’m very grateful to Scotty for inviting me and to the entire conference team for doing a fantastic job and for treating the attendees and speakers very well. NSConf had an easy-going feel, but everything hit its mark. It takes a great team to make it look that easy.

The next best thing to being there would be watching the amazing talks. And as of last week they are available to everyone on the NSConf 7 channel on Vimeo. I encourage you to check out all the talks, including my talk The Future: A Look Back, which I’ve included below. •

NSConference 7 was held March 16-18, 2015 in Leicester, UK.

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. •

Life Without WWDC

[Update: This post was written in 2014 — but holds true for WWDC 2015. As for me, I didn’t try to get a ticket this year.

I will be in San Francisco during WWDC 2015 week:

  • Prepping for the big James Dempsey and the Breakpoints show — tentatively set for Wednesday night, June 10, 2015. (save the date!)
  • Speaking at AltConf at the end of the week.
  • Watching keynotes and sessions as they are released.
  • Conversations with friends old and new.]

In some ways, the Apple Worldwide Developers Conference (WWDC) has not changed very much since the first one I attended in 1996.  The format is essentially the same. The conference kicks off with a keynote followed by a week of technical sessions, labs and evening events.

But the last few years have brought a major change that has caused me to reshape how I think about WWDC, and unfortunately, how to live without it.

James Dempsey with hands and face pressed up against door to Moscone West, unable to get into WWDC.Since the inception of WWDC, if you were a dedicated developer for Apple platforms, you were at the conference.  And, up until 2011, if you considered attending WWDC to be a must-have part of being an Apple developer, you had at least a week to get a ticket.  If you were reasonably vigilant, you were in.

But in recent years, with the demand for tickets far outstripping supply, you can’t think about WWDC as a must-have part of your life as an Apple developer.  By necessity, you have to think about going to WWDC as a nice-to-have. That is a big change.

Once something changes from being dependably available to rarely available, you begin to form alternate plans and take alternate paths.

Not whining—just reality

First, I want to be clear that this is not a complaint.  I think it’s fantastic that there is so much interest in the platforms that I enjoy using to build apps.  But a new reality has arrived and so I needed to adjust.

Last year, I spent WWDC week in San Francisco without a ticket. I had an enjoyable and productive time last year and so I’ll be up in the city again this time around as well.

So how has a long-time DubDub-er been dealing with being outside the building? Read on…

Beyond WWDC

One key was thinking about what WWDC provides and figure out how to meet those needs in some other way. For me, that boiled down to:

  • Sessions
  • Labs
  • Social Events / Networking

Sessions
I find sessions to be a very valuable part of WWDC.  Especially for a new technology or API, that session often provides not just technical information, but also some insight into the philosophy behind the technology, which does not always make its way into formal documentation.

Last year, Apple did an amazing job of posting session videos the same day of the presentation.  I hope this year to be the same. [WWDC 2015 Update: Apple will be streaming select sessions each day, in addition to releasing session videos]

In fact, watching session videos at home or in a hotel room is arguably a better experience than waiting in long lines and sitting in tightly-packed conference chairs.  Last year, for instance, instead of getting up early Monday morning and standing in a giant line for the keynote, I slept in and watched the keynote from my hotel room.

Plus, I didn’t feel guilty that I was somehow ‘wasting’ my ticket by not being in the building.

So, for sessions, I am completely at peace with not being at WWDC.  Apple has done a great job of making the technical information from the conference rapidly available.

Labs
Labs have always been one of the most valuable aspects of WWDC.  They provide developers with sit-down consultations with Apple employees. There are three types of labs: Technology Labs, the User Interface Design Lab, and the App Store Lab.

In the Technology Labs, you can bring your code and talk one-on-one to Apple engineers (often the very engineers working on the technology you are asking about).

Unlike session presentations, labs do not scale well.  There are only so many engineers and most of the year they are doing engineering, not manning labs.

As a substitute for Technology Labs, consider using Tech Support Incidents.  You receive two as part of the yearly $99 developer program fee—additional incidents are available for about $50 each.

With a Tech Support Incident, you can ask a code-level question that is answered by a Developer Technical Support (DTS) engineer.  I’ve talked with folks who have used the service and they report good results overall.  One caveat is to not expect an immediate answer, researching and replying to your issue can take a few days.

Using DTS is not an exact substitute for sitting down face-to-face with an Apple engineer, but it is a reasonable and more scalable substitute.  (You also don’t have to wait until WWDC to ask your question.)

As far as I can tell, however, there is currently no substitute for the User Interface Design Lab or the App Store Lab. These resources seem to be exclusive to WWDC.

In my first year as an independent developer, sitting down with someone at the App Store Lab clarified a number of things for me. I found that brief interaction to be very valuable.

It might help developers to have the ability to get these sorts of consultations done outside of the scope of WWDC.  I would be willing to pay for support in a manner similar to DTS to get these additional services during the year.  At present, though, you need to make do without these two labs.

Social Events / Networking
Apple sponsors its own WWDC events such as Stump the Experts, the Apple Design Awards and the Bash—but there have always been a myriad of outside parties and events during the week.  With so many developers converging on San Francisco without a WWDC ticket, it seems that number has grown in the past few years.

Last year, I found that there were plenty of events and parties that did not require a WWDC ticket, and this year seems to be shaping up the same way.

During the day, AltConf is a free conference with speakers all week, right near WWDC itself.  Last year it was a great place to see some live sessions, meet up with folks and hang out in their lab.  In past years, some local developers have also opened their offices up as gathering places during the week.

The evenings are filled with enough events and parties that there is at least one app and one website for tracking them. [Update: These have yet to be updated to show WWDC 2015 events, I would imagine that would happen in the coming weeks or days.]

My personal favorite event during the week is, of course, the James Dempsey and the Breakpoints show.  For the last two years, we’ve had a lot of fun playing a free, full concert of iOS and Mac development tunes to packed houses.

PLUG: This year, on Wednesday night during the conference, James Dempsey and the Breakpoints will be LIVE near WWDC 2015.  Sign up for email updates for forthcoming details about the show, new songs and recordings.

From a social perspective, there is a lot going on WWDC week that does not require a ticket.  Last year, I definitely felt my need to network and talk with others was very fully met.

Wrap up

Being prepared for life without WWDC is the new reality.  Both Apple and the development community have provided resources to make a WWDC week an enjoyable and productive time to be in San Francisco, even without a ticket.

I’m looking forward to being up in the city for the week. If you come to town with or without a ticket, please say hello if you see me and come on out to the show! •

Don’t miss out on the fun!

Join our low-volume email list for James Dempsey and the Breakpoints show details and music releases.

Moving to new Objective-C literals

Last week, I moved one of my projects over to use the new Objective-C literals for NSNumber, NSArray and NSDictionary as well as the new syntax for boxing expressions into NSNumber and NSString objects.  Here are a few comments on how it went.

In a nutshell, the new language features allow code like [NSNumber numberWithInteger:7] to be replaced by a more compact syntax like @7.  The LLVM site has a full description of the new syntax and usage.

Refactoring in Xcode

I ran the ‘Convert To Modern Objective-C Syntax’ refactoring tool in Xcode 4.4 to do the conversion.  There is no option to choose which modern syntax features you wish to adopt before the conversion begins, but in Xcode 4.4, you can choose diff by diff which changes you wish to keep.  Xcode seems to think my Objective-C syntax is already modern enough in other respects, since the only changes the refactoring made was to move to Obj-C literals.

Even if you want to introduce the new literals into your code manually, you might find it interesting to run the refactoring tool just to browse through its proposed changes.  You can cancel the changes rather than apply them, but just by reviewing the proposed diffs, you might see use cases for Obj-C literals that may not have occurred to you.

There were more places than I was expecting where my code creates NSNumber instances from integer expressions and enums.  Also, before running the refactoring tool, it had not occurred to me how often the expression being boxed would just be a single variable holding a scalar value.

So there were numerous places where the updated code did something similar to the following:

NSInteger myValue = 0;
// Do some stuff that changes myValue
[myArray addObject:@(myValue)];

Before doing the conversion on my own code, I definitely underappreciated the power and usefulness of boxed expressions.

Overall, I found the refactoring in Xcode 4.4. to be easy and straightforward.  The Xcode project I converted was a medium-sized Objective-C project using the iOS 5.1 SDK.

A crashing issue to watch out for

There is a potential crashing issue that I ran into that you should be aware of.  In one spot, the code was relying on a nil value terminating the list of arguments to create an array.  So something like:

-useRequiredValue:(id)requiredObj optionalValue:(id)optionalObj {
   NSArray *array = 
         [NSArray arrayWithObjects:requiredObj, optionalObj, nil];
   // Do something useful with array
}

The method +arrayWithObjects: stops processing arguments when it hits the first nil argument.  The code above relies on that fact to create a one-object array when optionalObj is nil, and a two-object array when optionalObj exists.

The conversion changed the array creation to:

NSArray *array = @[requiredObj, optionalObj];

With array literals, relying on a terminating nil does not work.  Behind the scenes, a literal NSArray is created with +arrayWithObjects:count: which requires non-nil values.  So, after converting to Obj-C literals, an exception was thrown whenever the optional argument was nil.

A similar issue arises with dictionaries if you are relying on early nil-termination with +dictionaryWithObjectsAndKeys: and then move to use an NSDictionary literal.

Note that this issue is not flagged by the refactoring tool or the static analyzer, so it is something to watch out for when converting to use Objective-C literals.

To address the issue, the options are either to revert to the previous code or change the code to something else.

I changed the code to something like this:

NSArray *array =
     (optionalObj != nil) ? @[requiredObj, optionalObj] : @[requiredObj];

I decided to stop using the ‘early nil’ approach for a few reasons.  The first is that I know I will be tempted to change that line of code to use a literal array every time I look at it, which will reintroduce the crash.  I could guard against that by adding an emphatic comment explaining the situation, to prevent myself from changing that line of code.  So, everytime I look at the code, I’ll be tempted to convert the line of code, and then have to read about why I can’t convert that line of code.

It seemed more maintainable to move to a different way of doing the same thing.  In addition, the new code is less tricky/clever than the old code and more explicit about what the result will be; no comment is needed.  I am a big fan of well-commented code, but I’m also a fan of code that is obvious enough that the code can clearly speak for itself.

Readability

In most cases, the new literal syntax leads to code that is both more compact and more readable.  In the above example, the new code is not much more compact than the original code, but, the intent is clearer, which I find more readable.  With numbers, ‘@3.6’ is more readable and compact than ‘[NSNumber numberWithFloat:3.6]’.  For arrays and dictionaries, I find that my eyes are not yet parsing literal array and dictionary creation as smoothly as more familiar Objective-C code, but I suspect that will change as I use and see the new constructs more often.

Boxed expressions may cause readability to suffer to some degree.  When you encounter something like ‘@(someVariable)’, it is ambiguous whether you are creating a number or string.  You need to know the type of the expression to know for certain.  In practice, descriptive variable names should make this less of an issue.

I find the code becomes less readable as the boxed expression inside the parenthesis becomes more complex and when Objective-C literals and boxed expressions are combined and nested.  We are moving from code that had giant billboards of [NSString stringWith…  or [NSNumber numberWith… proclaiming just what is being creating, to code which is definitely more compact, but may also be more difficult to read.  For example:

@{ValueAverage : @((self.currentValue - [self.relatedObject
currentValue]) / 2), BoundaryValues : @[@(self.maxValue), @(self.minValue)]}

Even after such a short time using the new syntax, I find that on balance, the literals and boxed expressions make for more readable and compact code, with a few cases where readability seems to suffer a bit.  It is also early in the game, in terms of using the new syntax on a day to day basis.  My opinion will continue to evolve as I use the new constructs more.

Backward binary compatibility and a little BOOL wrinkle

The new Objective-C literal functionality is handled in the compiler, so you must be using a recent version of the LLVM compiler to use this syntax.  Since the compiler generates code that uses existing object creation methods, the code you write and compile can run on previous versions of OS X or iOS.

So, even if you are targeting releases of your app on OS versions earlier than OS X 10.8, or iOS 6, you can use the new literals along with the new version of the tools.

I did encounter one wrinkle with BOOL literals.  To enable the compiler to properly deal with @YES and @NO to represent NSNumber BOOL values, two new language keywords were added to the Objective-C headers.

The iOS 5.1 SDK does not include these new keywords.  So, if you are using Xcode 4.4 and the iOS 5.1 SDK, you need to ‘box’ the BOOL values as expressions to compile: @(YES) and @(NO).

The Mountain Lion 10.8 SDK does have the new keywords as will SDKs moving forward, so this is just a minor transitional oddity.

Conclusion

Overall, I think the new Objective-C literals and boxed expressions are an excellent addition to the language.  I found converting to the new syntax using Xcode 4.4 refactoring to be a smooth process.  The only real bump I hit was in code where I was relying on early nil termination of arguments when creating an array.  The other wrinkle I encountered was the need to box BOOL values using Xcode 4.4. and the iOS 5.1 SDK.   I’m looking forward to using these new language features moving forward.