A Generic Swift Blog Post

I began investigating SwiftUI to see if it is indeed the shortest path to a great app. Since then, I committed an update to the MemeMaker project that makes the initial interface a list of examples. I was experimenting with passing a different View into each row as the destination of the row’s NavigationButton, rather than hard-coding the destination.

I found that you can’t just make a property of type View. I believe that is because it uses Self within its declaration of the body property. And so the compiler dutifully complained.

Seeing the type-erasing AnyView type in the documentation, I wrapped everything in AnyViews to get it all working.

I got some feedback from Matt Ricketson on Twitter suggesting I use generics here instead.

Of course it makes complete sense, with better code and less code. You can see the diff here.

With the SwiftUI and Combine frameworks using generics so heavily, I need to develop my intuition about generics beyond arrays and dictionaries. I also really need get better at reading declarations that are chock full of generics.

Fortunately, I think the two go hand in hand.

When Swift first arrived, I found reading optionals in code to be difficult. But AppKit and UIKit development meant using them immediately. I dug in to understand them as best I could. I even wrote a song about it. And now reading and writing code with question marks and exclamation points seems natural, not baffling.

I’m hopeful that as I use SwiftUI and Combine that I’ll refine how I think about generics as well.

I’m also curious. Are there ways that you think about genetics that have made them more understandable for you? (Not so much the syntax, more so the zen of generics) Any articles that you’ve found particularly useful?

I’d love to hear. Please send any of your generic thoughts or thoughts on genetics to @jamesdempsey at Micro.blog or Twitter.

Also, if you are ever writing about generics on an iPhone: BEWARE! Autocorrect really wants to replace ‘generics’ with ‘genetics’! •

SwiftUI: Almost Too Much Fun

In my previous post, I described the JDBP band app I want to build and the technologies introduced at WWDC 2019 that I think might make it much easier to create.

Part of the process is exploring these new technologies and SwiftUI is first on my list.

As I’m playing with SwiftUI, I’m not thinking too much about the app I want to build. For me, and probably many others, my first step beyond watching videos and walking through tutorials is to play with it, use it to build a few small throwaway apps, and try to develop as good a feel for it as I can in a short period of time.

I’m not at a point where I can nitpick over whether I agree or disagree with this or that design choice in the framework. I definitely don’t know it well enough yet.

Currently, I’m in the process of building up my mental model of how all of this works. This also includes mentally diffing that model with my existing mental models of AppKit and UIKit.

That’s a lot of brain cycles. This is going to take a while and is probably also going on as a background process as I sleep.

I found these two sessions really helped me begin to build that mental model of the frameworks beyond tutorials and demos:

I am sure I will watch them multiple times. I also hope we get more documentation, more tutorials, and maybe even more WWDC-like videos from Apple. I feel like what we saw in sessions at WWDC and in the tutorials only scratch the surface of SwiftUI.

How Does It Feel?

I don’t have enough experience with the framework yet to declare that SwiftUI is the shortest path to great apps.

But I’m sure having a blast playing with it!

I haven’t felt a sense of joy and exuberance like this about UI programming for a very long time.

Will that sense of joy fade as I start trying to use SwiftUI for a ‘real app’?

Certainly the excitement of novelty will fade as it becomes more familiar. For other aspects, time will tell, but for now I’m just going to enjoy the ride.

Joy

For me, there’s joy is in how quickly you can compose a complex view—even a live data-driven view—without much code at all. There’s joy in the tooling and preview mechanism, which is flexible and fairly responsive.

And there’s joy in the fact that the views that you compose are well-behaved.

All those things that may have caused you to breathe a tired sigh in the past—things you knew you should or must support, like Dynamic Type, Right-to-Left UIs, Dark Mode and more—now happen automatically and correctly.*

The framework and tools seem to be very thoughtfully designed, in terms of the functionality that is provided, but also in the unified way that things fit together, scaling from structural components like navigation to views and controls, all the way down to shapes, paths, and graphics operations.

MemeMaker

Yesterday, I posted a meme that seems to have gotten a few amused smiles:

Meme of Scarlett O'Hara with words "As God is my Witness, I'll never type translatesAutoresizingMaskIntoConstraints again"
I’ve been playing with SwiftUI and have a declaration to make.

I used SwiftUI to compose the meme and have posted the MemeMaker project on GitHub.

Meme Maker is a not-particularly-functional app created by someone on their couple of days using a new technology:

  • You can’t edit the text except by editing the code
  • You can’t different image unless add other images to the project
  • You can’t export or share the meme

The app composes some text over an image in a few different ways and then you can take a screenshot of the result to share if you want to.

But it also shows a few things people might find interesting:

  • The main list uses AnyView to pass destination view into row
  • The Overlay example uses the overlay modifier to overlay the text on top of the image. Probably the cleanest solution
  • The ZStack example shows my original example using nested zstacks to pin text to top and bottom of image
  • The Text Gone Wild example shows what happens when the text is allowed to spread out as far as it can
  • All examples show using a named font instead of a semantic font
  • All examples show adding a shadow to text and using a non-named color

So, I put it out there if you want to check it out.

Feel free to download it or fork it and use it as a starting point for your own explorations. If you discover alternate ways to achieve the same result or any other cool things, let me know at @jamesdempsey at Micro.blog or Twitter. •

Feedback

I’m also trying to post a record of feedback I’ve filed. If anything sounds good to you feel free to file similar feedback.

Feedback Filed:

  • FB6145912 Would love an ‘Embed In…’ menu option when writing SwiftUI code
  • FB6145990 Would be great to have option to refactor a View directly into a new SwiftUI file
  • FB6139401 Framework Reference docs should include a Symbol Index Oh how I miss having that big, high info density index of Class / Struct / Protocol / Function symbols!

*And you didn’t breathe that heavy sigh because you didn’t want your app to have that functionality—it was because it takes a chunk of time and work to do and do correctly—time you wish you could spend improving the core functionality of your app or maybe even spending with family and friends.

The Shortest Path To A Great App

The Shortest Path To A Great App” That is the phrase Apple used in a number of the SwiftUI sessions at WWDC last week. But beyond SwiftUI, there were a number of other announcements at WWDC 2019 that also could lead to a shorter path to a great app.

Taken in total, these announcements have left me feeling incredibly energized.

An Oddball WWDC Week

I have an oddball WWDC week compared to most people attending WWDC, AltConf, or Layers.

For the last eight years, I’ve organized and performed in the annual LIVE near WWDC concert on Wednesday night. The last four events have been benefit shows for App Camp For Girls.

I’ve also had the honor the past few years of closing out AltConf on Thursday afternoon with a lighthearted musical Week In Review session. Of course, I have no idea what I’ll be talking about until after Monday’s announcements.

Preparing for these events keeps me pretty busy until late Thursday afternoon—with a large chunk of Monday set aside for the Keynote and Platforms State of the Union—and then viewing sessions or snippets of sessions as I can.

So Friday is the first day of WWDC week I can dig deeper into everything that has been announced.

An Aha! Moment Before Breakfast

It dawned on me early Friday morning that a set of announcements at WWDC 2019 should make an app I have wanted to build much easier and quicker to create.

The annual LIVE near WWDC show is a complicated undertaking. This past year we had 24 performers playing 18 different instruments on 18 different songs.

In addition, for the past few years, Adam Tow has taken some really fantastic photos of the show.

So, for a long time I’ve wanted to build an app for my band, James Dempsey and the Breakpoints (JDBP). The app would be a place to share photos, lyrics and info with fans, and also be a resource for people performing in the show—the Breakpoints.

Fans would be able to download the free app and without an account, see photos, browse photos of past performances, see lyrics, maybe even play JDBP songs from Apple Music if they are subscribed.

Breakpoints would be able to sign in, see info about the upcoming show they are performing in, view the (ever changing) set list, know which songs they are playing on, and be able to swipe through the chord charts for the songs they are playing on, in order on an iPad (or iPhone in a pinch).

But, until last week, just thinking about building that app was exhausting. It would be just me writing it and would need a lot of infrastructure code to get it right.

Then, Friday morning, the thought occurred to me that these three newly announced technologies could make writing this app significantly faster and easier:

  • SwiftUI
  • Sign in with Apple
  • Core Data / CloudKit interoperability

A Journey of Discovery

Will these three newly announced technologies do the trick? What dead ends, limitations, and blind alleys will I discover?

At the moment I have no idea, and that’s exciting.

I still have videos to watch, documentation to read, and lots of code to write and fiddle around with.

The app I’m building won’t be open source, but I’m hoping to make it an ‘open process’ app. My plan is to write little blog posts as I go.

These posts will be me thinking out loud — expressing what I want this app to do before I’ve even fully investigated how I will implement it. And then reporting what I find as I investigate things and see how they work in practice. The intent is for this to be a public journal or technology travelogue as I go through the process of building an app.

I’m also hoping the posts will help spur discussion and feedback and help us all come to understand these technologies better.

Thanks Brent!

This approach was greatly inspired by Brent Simmons. I’ve always admired Brent’s ability to post in the casual and open manner of “Hey, I’m working on a thing. I’m learning it and I’m not an expert. Here’s what I’m discovering and here’s what is confusing to me.” Brent has been a prolific developer for many years, but he never claims to have all the answers. (Plus he plays a mean keyboard.)

A Last Caveat

This app is a side project. As the glow of WWDC 2019 fades and day to day tasks come back to the fore, there may stretches of time between posts about this app. I appreciate your patience in advance.

Let’s see how short that path really is.

I’m so excited to get started! •

Where I’ll be at WWDC 2019

I’ll be doing a few things next week at WWDC 2019 and wanted to pass along my schedule. Hope to see you at one or more of these happenings!

Tuesday: Micro.blog Meetup

Micro.blog Logo

Tuesday at lunch time, I’ll be at the Micro.blog meetup at the Grace Deli, across from The Hilton.

My good friend—and meetup organizer—Jean MacDonald and I co-host The Weekly Review, a ‘microcast’ podcast about personal productivity hosted on Micro.blog.

Stop by and say hello! We’ll also have The Weekly Review stickers to hand out. You can RSVP here.

Micro.blog Meetup, June 4th, 12 – 2 pm

Wednesday: LIVE near WWDC 2019

James Dempsey and the Breakpoints JDBP Logo
Wednesday night, my band, James Dempsey and the Breakpoints, performs our 8th annual LIVE near WWDC show. The party starts at 7 pm—tickets include an open bar. The band goes on at about 8:30 pm, playing a full concert of original, humorous, programming-oriented, and yes, even chart-topping music.

But the night is more than just music and fun—it’s a benefit concert for App Camp For Girls, with ticket proceeds going to support their mission. Come on out on Wednesday night to a great event for a great cause!

Tickets are still available but going fast. Click through to get all the details and buy tickets.

James Dempsey and the Breakpoints, LIVE near WWDC, presented by Capital One
Wednesday, June 5th, Doors open at 7:00 PM, show starts at 8:30 PM. Party until 11:00 PM

Thursday: AltConf WWDC 2019 Week In Review

AltConf Conference Logo
I’ll be closing out the week at AltConf with my sixth annual WWDC Week In Review, a lighthearted look back at the announcements and events of the week.

After a week front-loaded with announcements and technical talks—this easy-going closing session of AltConf combines humor, music, and perspective.

Join me for what usually proves to be an entertaining and occasionally enlightening session.

And, as usual, there will be a bit involving a ukulele.

AltConf 2019, June 3 – June 6, 2019
Closing Session, Thursday, June 6th, 3:00 PM

A Busy WWDC 2019 Week + Stickers!

As usual, it will be a busy WWDC week with plenty of new announcements and technology to wrap our heads around. If you see me out and about during the week, please say hello!

I’ll also have brand new James Dempsey and the Breakpoints and The Weekly Review stickers to hand out. Just ask for a sticker or two when you say hello!

I hope you can make it out to one or more of these events—see you at WWDC! •


Disney California Adventure—A Visual History

Pixar Pier opened at Disney California Adventure this past Saturday, giving Paradise Pier a new theme and a new name.

This inspired me to create this timeline showing the evolution of lands at DCA since its opening.

Timeline of how the lands evolved at Disney California Adventure Park, 2001 - 2018

Click for PDF Version

With the renaming of Paradise Pier, none of the opening day lands of Disney California Adventure remain.

This does not mean that all attractions, buildings, or theming of the original lands have been replaced. It means that every land existing on opening day has at least been renamed, with many rethemed, and some reassigned to other lands.

On opening day, DCA guide maps listed four lands: Entry Plaza1, Hollywood Pictures Backlot, Golden State, and Paradise Pier. These are all now gone.

Golden State was divided into areas, mini-lands within a big land: Grizzly Peak Recreation Area, Condor Flats, The Bay Area, Pacific Wharf, and Golden Vine Winery. These were not full lands when the park opened. Over time, some areas have disappeared as separate areas (The Bay Area, Golden Vine Winery), while others have become lands of their own (Grizzly Peak, Pacific Wharf), and one area even managed to do both (Condor Flats).2

I believe DCA is the only Disney park that has replaced or renamed all of its opening day lands.3

Research for the timeline was done using my collection of guide maps from the park as well as online announcements or news articles of land and attraction openings and closings. Please feel free to send me any feedback or corrections at http://jamesdempsey.net/contact.

Also feel free to contact me at http://jamesdempsey.net/contact if you have guide maps from the early years of DCA that you are willing to sell – or send photos of. I am particularly trying to find DCA maps between late February and late May 2001 to pinpoint the change from Entry Plaza to Sunshine Plaza.

I’ve enjoyed witnessing the transformation of Disney California Adventure over its seventeen year history and hope you enjoy this visual history of its lands. •

About me: I’m a Disney, Pixar, and Apple history hobbyist. I worked at Apple for fifteen years then set out on my own as a software developer, technical trainer, speaker, and musician. I write humorous songs about technical things. My album debuted at #5 on the Billboard comedy album charts and was the #1 comedy album on iTunes in the US, UK, and Canada. If you or someone you know (or someone in Disney Imagineering) needs an original song with clever lyrics contact me!


Yes, Entry Plaza. The opening day DCA guide maps use this name. Within months, the name on the maps changed to Sunshine Plaza

Golden Vine Winery is a good example an area which is still very similar to opening day, but has technically ‘disappeared’. This was originally an area, or sub-land, of Golden State. When the Seasons of the Vine attraction closed and became reopened as Walt Disney Imagineering Blue Sky Cellar, the reopened attraction was now listed as part of Pacific Wharf, where it remains as of 2018. 

Pacific Wharf is the only remaining original land or area that has not been renamed. But it was not a land on opening day, it began as an area of Golden State and was not promoted to a full land until 2012. Grizzly Peak Recreation Area was renamed to the much simpler Grizzly Peak when it also became a full land in 2012.

Where I’ll be at WWDC 2018

I’ll be doing a few things next week at WWDC and wanted to pass along my schedule. Hope to see you at one or more of these happenings!

Tuesday: Speaking at the NextDoor Conference

Logo for the Next Door Conference

Tuesday morning, I’m speaking at the Next Door conference, located, remarkably enough, next door to WWDC.

I’ll be talking about two of the more glamorous aspects of app development: build settings and xcconfig files. In the session, we’ll cover the why and how of giving your build settings an out-of-project file experience to make build settings easier to manage.

Registration is open until Monday and a there’s a great lineup of speakers. I encourage you to check the conference out.

NextDoor Conference, June 4th – June 7th
My session about xcconfig files: Tuesday, June 5th, 10:00 AM

Wednesday: LIVE near WWDC 2018

James Dempsey and the Breakpoints JDBP Logo
Wednesday night, my band, James Dempsey and the Breakpoints, performs our 7th annual LIVE near WWDC show. The party starts at 7 pm—tickets include an open bar. The band goes on at about 8:30 pm, playing a full concert of original, humorous, programming-oriented, and yes, even chart-topping music.

But the night is more than just music and fun—it’s a benefit concert for App Camp For Girls, with ticket proceeds going to support their programs. Come on out on Wednesday night to a great event for a great cause!

Tickets are still available but going fast. Click through to get all the details and buy tickets.

James Dempsey and the Breakpoints, LIVE near WWDC, presented by Capital One
Wednesday, June 6th, Doors open at 7:00 PM, show starts at 8:30 PM. Party until 11:00 PM

Thursday: AltConf WWDC 2018 Week In Review

AltConf Conference Logo
I’ll be closing out the week at AltConf with my fifth annual WWDC Week In Review, a lighthearted look back at the announcements and events of the week.

After a week front-loaded with announcements and technical talks—this easy-going closing session of AltConf combines humor, music, and a bit of perspective. I hope you join me to be entertained and maybe occasionally enlightened.

And, as usual, there will be a bit involving a ukulele.

AltConf 2018, June 4 – June 7, 2018
Closing Session, Thursday, June 7th, 3:00 PM, Room 1

A Busy WWDC 2018 Week

As usual, it will be a busy WWDC week with plenty of new announcements and technology to wrap our heads around. If you see me out and about during the week, please say hello!

I hope you can make it out to one or more of these events—see you at WWDC! •


My father, Wilbur Dempsey, passed away

I have a sad update. Wilbur Dempsey, my father, passed away yesterday afternoon.

He died peacefully without pain in the hospital. He was surrounded in his final hours by his children and a few other loved ones.

Ten days before he died, Dad at 92 years old was still mentally sharp, still living on his own, and still driving. He drove down to my sister Ann’s for their usual Sunday dinner. He would always stay overnight and drive home to Milltown in the morning.

The next morning he was not feeling well, so he stayed with my sister. His decline happened quickly over the next week. He found it increasingly difficult to walk, becoming more tired and losing energy and his appetite.

Tuesday morning he was unresponsive and taken to the hospital. I arrived late in the evening that same day and we spent the night with Dad in the hospital.

Dad never regained consciousness, but during that time we had our chance to tell him how much we loved him, to share our favorite memories with him, and tell him through tears how much we would miss him.

The photo below is of Dad ten days ago on March 18th.

The world has lost a truly kind, selfless person who brought so much joy, laughter, and sunshine to everyone around him.

Rest in peace in God’s love Dad. •

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.

UPDATE: In the Xcode 9.3 betas, blame has been removed from Xcode. From the release notes: 

Renamed user interface elements to clarify the information presented. In the Version editor “Blame View” is now “Authors View” and in the Source editor “Show Blame For Line” is now “Show Last Change For Line.” (35031446) 


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.

WWDC in San Jose: Full Circle

Next week’s James Dempsey and the Breakpoints concert is especially meaningful to me. It circles back to the literal spot where it all began.

I’ve now been writing and performing these funny, nerdy songs about software development for sixteen years.

LIVE near WWDC 2017 Poster

It started in 2001. WWDC was held in San Jose and I was working at Apple. AirPods, iPhones, iPads, Apple TV, and Apple Watch did not exist. Event the first iPod would not be released until later that year. It was a different world.

The previous year, I had given my first WWDC presentation ever. The presentation went well, but speaking to a cavernous convention center room, it also felt a little dry.

While leaving the parking garage that night, a thought occurred to me: Wouldn’t it be funny if someone pulled out a guitar at the end of a session and played a little song to sum things up?

The thought stuck with me and over the next year I wrote a song1. The track manager thought it would be a fun way to close the session I was giving, so performing the song was a go.

I was expecting I’d be performing this song in a convention center room.

I could not have been more wrong.

That year, there were so many WWDC sessions that some were held across the street at the City National Civic theater. The CNC can seat thousands of people. Legends like Bob Dylan, The Rolling Stones, The Who and countless others have performed there.

As for me, I had never performed an original song for an audience before.

I had never even played guitar in public before.

Some people might have some friends come out to a coffee shop for an acoustic open mic night to make their performance debut. Somehow, I ended up making my debut in a 3,700 seat auditorium in front of a few hundred colleagues and developers.

I was a nervous wreck.

As I was wrapping up the session, I pulled out a guitar2 and told the audience, “I’ve never played guitar in front of an audience before, so it might just suck to be you.”

Fortunately the crowd kindly overlooked my musical errors and the song met with an enthusiastic response. From there, a song at WWDC became a yearly tradition until I left Apple in 2011. Since then, we’ve gotten to play more than one song in a row at the yearly LIVE near WWDC show. And it all started on the stage of that big hall in San Jose.

It is hard to convey how much it means to me to be performing at the City National Civic again.

Sixteen years ago, I faced my fears and stepped onto the stage alone to play a song as a humorous closing of a technical talk.

Next week, I’ll be returning to the exact same spot, backed by a full band, to perform a full concert of songs to raise money for a great cause.

If you are in town for WWDC week or if you live in the area, I invite you to come out for the show next Wednesday night, June 7th. No WWDC ticket is required, and it’s an all-ages show, so folks under 21 are welcome. The show is located directly across the street from the San Jose convention center.

The show is shaping up to be a lot of fun. I hope you can make it out to benefit App Camp For Girls and also to help celebrate this full-circle homecoming concert—for me it is very special and I’d love to see you there. •


James Dempsey and The Breakpoints, LIVE near WWDC
A Women@WWDC benefit for App Camp For Girls
presented by Capital One
Wednesday, June 7th, 7:00 – 11:00.
Event information and tickets

Can’t make the show but still want to support App Camp For Girls?
Click the Make A Donation button in the Buy Tickets section of the event page.


It was The Fetch Spec Song, about technologies now faded into to the mists of history: WebObjects and its object persistence framework, the Enterprise Objects Framework (aka EOF).

It wasn’t even my guitar, it was an indefinitely borrowed guitar