A Kid in the June 2019 Candy Store

June 2019 has me feeling like a kid in a candy store.

I’m remarkably excited by the variety of things that are catching my interest and attention this month—so much so that I’m finding it difficult to decide what to do next.

A large part of that is due to all of the announcements at WWDC—but that is not all.

The Monday after WWDC, I wrote about an app I want to create that might be easier to build due to new technologies introduced at WWDC. Foremost among them was SwiftUI which I have really enjoyed digging into.

My week following the developer conference was a flurry of watching session videos and digging into things. But WWDC was not the only thing going on in the world in a few weeks back. On May 31st, Star Wars: Galaxy’s Edge opened at Disneyland.

Star Wars: Galaxy’s Edge

As a big Disneyland and Star Wars fan, had it been any other time of year, I would have tried to be there opening weekend. However, just days before WWDC, with a big LIVE near WWDC show to rehearse and prepare for, there was no way I could make it down to Anaheim.

I didn’t have to wait long though. Last weekend I had the chance to visit Galaxy’s Edge at Disneyland. I feel like they’ve done an amazing job of creating a place that feels very much a part of the Star Wars universe, even though it a brand new location not depicted in any of the movies. My inner nine-year old found it very satisfying to fly the Millennium Falcon, build my own lightsaber, and yes, drink some blue milk.

Combine Framework and Foundation

On Monday I headed home from Disneyland as Beta 2 dropped for Xcode 11, iOS 13, macOS 10.15, and all the rest.

The new beta includes Combine framework support for Foundation classes. So, it just became possible to write code to explore the same sort of data publishing pipelines that were presented in the Combine sessions at WWDC. This includes publishing notifications, properties, and timers.

So, another whole aisle of candy just opened up and I’ve spent most of the week catching up from my trip, rewatching Combine videos from WWDC, and playing around with Combine code.

So far, I am feeling the same sort of enjoyment in writing Combine code as I have had writing SwiftUI code. The main area of frustration I am finding with Combine is that the session videos are the primary place to see Combine sample code. (If I am missing a trove of Combine sample code from Apple – please let me know on Micro.blog or Twitter!) So, I’m finding that anything not covered in those sessions takes bit of trial and error to figure out.

Along the same lines, the code in the sessions often show the path from publisher through operators to subscriber, but don’t necessarily talk about who should be holding onto the publisher or the cancelable item returned from the subscriber, or exactly when it makes sense to set them up. It would be great to see more Combine framework sample code from Apple showing it in integrated into an app project, especially traditional UIKit and AppKit apps.

Toy Story 4, Forky, and WALT

Today I put the Combine framework aside for a few hours to go see Toy Story 4. Every time Pixar announces a sequel I worry that this is the one where they will jump the shark in the franchise. I am very happy to say that I really enjoyed Toy Story 4. I found Forky to be absolutely delightful!

If you know me for any length of time, you will soon discover that I am a big fan of Disney and Pixar animation.

WALT app icon
WALT app

The first iOS app I wrote is WALT: Watched Animation List Tracker. It’s not a commercial success by any means, but it’s an something I wanted to have in the world. It lists over 650 short and full length animated films from Disney Animation Studios and Pixar Animation Studios and lets you check off the ones you’ve watched.

Got to check off Toy Story 4 in WALT today.

I wrote about the creation of WALT shortly after I released it back in 2012. (Was that really about seven years ago? Wow!) A heads-up if you are thinking about paying 99 cents for the app, I do intend to make it a free app and add a tip jar. However there are many other things ahead of that on my to-do list, so I can’t tell you exactly when that will happen.

As mentioned in that original article, one inspiration for WALT was the The Walt Disney Family Museum (WDFM) in San Francisco. I have been a member since it opened ten years ago. The location is beautiful, in the Presidio with a view of the Golden Gate Bridge. And I find the museum and the story that it tells to be inspirational.

Fantasia Talk at The Walt Disney Family Museum

In addition to the exhibits at the museum, one of the things I enjoy most are the programs that they have throughout the year. In the past I have seen many great talks that speak to the creative process. For instance last year, I saw Brad Bird speak about his experiences working with classic Disney animators. I’ve seen animators Andreas Dejas and Floyd Norman talk about their time at Disney. And I’ve had the chance to see original Imagineers like Alice Davis and Marty Sklar.

Tomorrow I’ll heading up to San Francisco to see a talk by composer Fabrizio Mancinelli called The Beauty and Legacy of Fantasia. I’ve always enjoyed and been fascinated with the way animation and music can work together to achieve an effect and look forward to hearing what I believe will be an interesting perspective.

That’s A Lot Of Candy

In feeling like a kid in a candy store, June 2019 is not just some quaint little corner candy store. It’s been a giant store with aisle after aisle of classic candies, exotic candies from faraway places, and brand new candies you had never even heard of before.

With all of this intellectual and experiential candy, I hope I do not get the psychological equivalent of a bellyache. But even if I do, it has been a very memorable and enjoyable month so far. •

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.