AirPods Pro: The First Fifteen Minutes

Just opened the box and set up a pair of AirPods Pro about fifteen minutes ago.

First, I needed to update my iPhone to iOS 13.2 which includes the support for AirPods Pro.

Pairing was as easy as with AirPods, open the case near your iPhone and a screen appears to walk you through the process.

The noise cancelling is impressive. It’s a chilly morning in Northern California and my furnace is on, making a very noticeable amount of noise.

With the AirPods in and noise cancelling turned on, I honestly couldn’t tell you if the furnace is still running or if it reached the target temperature and turned off.

It turns out as I wrote the previous sentence, the furnace had turned off. So I went into the Nest app, adjusted the target temperature upward and the furnace came back on.

I heard absolutely no difference with noise cancelling turned on.

I had to switch off noise cancelling to confirm with my ears that the furnace definitely had come back on.

I have a pair of Bose over-the-ear noise cancelling headphones that I primarily used on flights. They are very bulky and so I’ve fallen out of the habit of bringing them along.

I will definitely be bringing my AirPods Pro on flights.

Figuring out the way to click or long click on the stem is taking a little bit of getting used to, but it’s only been fifteen minutes. The key is finding the flat part of the stem as the surface to press against.

One thing that could use improvement is the discoverability of the settings for AirPods Pro.

You reach the settings in the Bluetooth settings section, by pressing the info button in the AirPods Pro entry in the list of paired devices.

If I had not read about those settings online and their location in the Daring Fireball article about AirPods Pro, I would never have found them or even knew they existed.

Searching for AirPods Pro in the Settings app brings up no entries. I imagine the names of paired devices are not part of the search.

Since you don’t need to visit the Bluetooth settings to set up the AirPods Pro, it never occurred to me that is where you would customize them or run the Ear Tip Fit Test.

(If you were wondering, the default ear tips provided a good fit out of the box.)

So, my first fifteen minutes (okay, now thirty minutes) with AirPods Pro have been good ones. I’m looking forward to my next flight to use noise cancellation without carrying a bulky pair of headphones. •

The Xcode 11 and Swift Package Combo Platter

Since the Swift Package Manager (Swift PM or SPM) was introduced in late 2015 it has seemed like a natural fit for Xcode and SPM packages to work well together at some point in the future. At WWDC 2019, Apple announced that future was arriving in Xcode 11.

Icons for Xcode, a Swift Package Manager package, and an Xcode project

Xcode 11 provides two new ways to work with Swift Package Manager packages:

  • Open an SPM package in Xcode
  • Add SPM package dependencies to an Xcode project

These two new capabilities join a long-standing SPM feature:

  • Generate an Xcode project for an SPM package

Each of the these approaches are different both conceptually and in the nitty gritty details of what files they put where.

Open an SPM Package in Xcode

In Xcode 11, you can open a Swift Package Manager package directly in Xcode without needing a .xcodeproj Xcode project file.

Conceptually, you are working in a Swift Package Manager-centric world with the added ability of using Xcode to edit, build, and test your Swift package.

Note that this does not give you all of the settings and flexibility of an Xcode project. You cannot specify build phases, include resources, do code signing for an app, or any other functionality that is not currently supported by Swift Package Manager.

But being an Xcode project is not the purpose of this particular feature. This feature is all about using Xcode as an IDE for Swift PM packages.

What happens on disk?

Opening a package in Xcode adds a hidden .swiftpm/xcode directory to the package.

As you might guess, the xcode directory contains files Xcode uses such as a package.workspace file containing information about the workspace and xcuserdata and xcshareddata directories.

The .gitignore file generated when creating a new package includes xcuserdata as ignored. You will likely not want to add these files to your git repository. The files in xcshareddata on the other hand include shared schemes generated by Xcode which you may want to check into git to share among team members.


You will probably want to use the same policy of which Xcode-centric files to check in or ignore that you are using for Xcode projects.

The checked-out dependencies and build products are stored in the hidden .build directory, just like building the Swift package using swift build on the command line.

So, with a fairly small footprint of additional files, you can now use Xcode for Swift PM package development.

Add SPM Package Dependencies to an Xcode project

Also in Xcode 11, you can add Swift Package Manager packages as dependencies of an Xcode project.

Conceptually, you are working in an Xcode project-centric world with the added ability of having Xcode manage dependencies on Swift packages.

You specify the source URL and version of the package you want to use in your project. Xcode will automatically download the correct package version and any dependencies of that package. The dependencies are recorded in your Xcode project file, similar to dependencies on frameworks and libraries.

This is a significant addition. For the first time, Xcode has a native mechanism for managing and updating dependencies.

Developers in the Xcode ecosystem have traditionally turned to third-party solutions such as CocoaPods or Carthage for this functionality, or used git submodules in projects to combine code from different git repositories.

Xcode 11 opens the door to dependency-handling workflows that are actively supported by Apple and its tools.

But I don’t use Swift yet!

Even if your projects are not in Swift yet, you can create SPM packages with targets and products of C-based languages including Objective-C. The only Swift that must be in a package is the declarative Package.swift manifest file.

What happens on disk?

Adding SPM package dependencies to an Xcode project will add a Package.resolved file to the project’s workspace at xcshareddata/swiftpm. This file contains the resolved versions of each dependency. This file is intended to be included in source control so team members and continuous integration systems can use the same dependency versions.

As you might expect, the package dependencies will be referenced in the project’s project.pbxproj file.

There are no additional changes to the Xcode project and no hidden directories added. Everything else, including the downloaded package sources and build artifacts are located in the Xcode derived data directory for that project. The SourcePackages directory in the project’s derived data contains the checkouts and repositories for the Swift packages.

In addition to adding remote package dependencies to the project, Xcode will also recognize local package dependencies. This is useful, for example, if you are developing an app and a supporting package at the same time.

The addition of Swift package dependency management in Xcode gives you a powerful new option in structuring your projects’ dependencies.

Old Original SPM-Generated Xcode Project

Since the early days of the Swift Package Manager, you could generate an Xcode project for a package with the command swift package generate-xcodeproj.

This feature has always had limitations and drawbacks. With the new capability of opening a package directly in Xcode, you should never need to use this feature. But, it is still a temping option when looking at swift package help, so it might be helpful understanding why you don’t want to use this.

The SPM-generated Xcode project is intended as a convenience to use Xcode to view and edit your package. It is not meant to be a long-lasting resource.

If you make changes to the package’s manifest, add or remove dependencies, or make any significant changes, you need to regenerate the Xcode project. It is intended to be a transient resource, justconvenience to allow you to use Xcode to edit and build the package.

Because of this, the generated Xcode project was not intended to be shared or checked-in to source control. This is confirmed by looking in the .gitignore file automatically generated by SPM where /*.xcodeproj is on the list of files to be ignored.

The generated Xcode project stores some items within the xcodeproj directory including an Info.plist file per target in the package.

If your package has any C-based library targets, (for instance if you are exposing an existing C library to Swift), then the generated Xcode project contains a directory GeneratedModuleMap which contains a module map for each C-based target. The module map file contains a hard-coded path which includes the current user’s home directory. This makes the generated Xcode project decidedly un-shareable.

I am unable to think of a good use case for a generate Xcode project file now that Xcode 11 has the ability to open Swift packages directly. This functionality now seems obsolete.

Summary

With the introduction of Xcode 11, there are now three main ways to work with Swift Package Manager packages in Xcode:

Swift Package Manager-centric
Use Xcode as an IDE for Swift PM packages. No Xcode project required.

Xcode project-centric
Add Swift PM packages to an Xcode project. Xcode manages the dependencies.

Swift Package Manager generated Xcode project
Don’t use any more. Just open the package directly in Xcode 11.

The WWDC 2019 session Adopting Swift Packages in Xcode contains a number of demos showing how to use Xcode with Swift PM packages and is a good resource for getting started.

Xcode 11 makes great strides in working with Swift PM packages in two complimentary ways. •

Drive Time with the Swift Standard Library

The last week and a half or so, I’ve been driving up and down the East Coast. (Hello I-95, my old friend. I’m paying tolls on you again.)

My trip included attending the 90th birthday of a family member in Virginia, visiting my sister in NJ, visiting a friend in Delaware, and then celebrating the birthday of my friend Larry Noto in Maryland. I also did an open mic night at Larry’s music store Music Land and saw Larry’s stand-up act , opening for Jon Lovitz.

While driving, I was thinking about a little piece of an app I’m working on. I write an integer out into a URL as a string and then read the integer back in when I interpret the URL—nothing earth-shattering.

My thoughts turned to ways to make that URL shorter and a bit less ugly, with the premise that longer URLs are uglier URLs.

As I made my way down the road, it occurred to me, a hexadecimal string would certainly be more compact. But then, if base 16 is good, base 32 would be even better. Two characters in base 32 could represent 1024 values instead of 100 in base 10. Three characters could represent over 32K values instead of 1000.

So, in the end I was looking for:

  • Small encoding. A way to encode an integer as a string that uses as few characters as possible.
  • A ‘URL-ready’ string. The resulting string should need no further URL encoding for things like spaces.
  • Easy to implement. The minor improvement is not worth a lot of engineering effort to implement or maintain.

Enter the Swift Standard Library

One drawback of a road trip is the inability to write code or even peruse documentation while driving. After arriving at my destination, I did some poking around and found these in the standard library:

An initializer for Int: init?(_:, radix:)

And one for String: init(_:, radix:, capitalized:)

In both initializers, the radix has a default value of 10 but can handle everything from base 2 to base 36.

Base 36?

In this base 36 encoding, the digits 0-9 and the letters a-z are used in the string representation. The decimal number 35 is z, the decimal number 940 is q4.*

Using a radix of 36 gooses the values representable by a two character string up to 1296, and by three characters up to over 46K.

And, as it turns out, I was already using those initializers with the default parameters to encode and decode the integer.

I ended up factoring out those calls into a few extensions on URL and URLComponents, but, conceptually the answer was simply to move from:

let stringValue = String(integerValue)
let int = Int(stringValue) ?? "0"

to

let stringValue = String(integerValue, radix: 36)
let int = Int(stringValue, radix: 36) ?? "0"

So, the solution met all of my criteria. I updated the code in my hotel room.

The Old Coldness

Checking on swiftdoc.org, it looks like this functionality has been in Swift since at least Swift 1.2.

This made me realize the even with all of the new things introduced with each release, Swift and the standard library had a lot of nice functionality from the beginning.

Some of my drive time thinking was about solving a programming problem. But then afterwards, my thoughts progressed to how we are understandably drawn to the brand new features, but that sometimes a piece of API that has been around for years can be brand new to you, and that’s just as exciting and delightful a discovery. •


* The encoding strategy in these standard library methods extend the encoding pattern used by hexadecimal numbers. Note that there are many different ways to encode digits or byte values, including Base32 described by RFC 4648.

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

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


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


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.

LIVE near WWDC 2017 Info

Click For Full Show Details and Tickets

Wed, June 7th, 7:00 PM – 11:00 PM
City National Civic Theater
135 W San Carlos St, San Jose CA

Join us for the 6th Annual LIVE near WWDC show by James Dempsey and the Breakpoints! It is shaping up to be our biggest show ever!

This year’s show will be about as near to WWDC as you can get. We’re playing at the historic City National Civic Theater — directly across the street from WWDC.

  • For this year’s big event, we’ve teamed up with women@wwdc (formerly WWDCGirls) for a combined cocktail hour and concert—all to benefit App Camp For Girls.
  • Ticket proceeds benefit App Camp For Girls.
  • Amazing new venue — right across the street from WWDC.
  • No WWDC ticket required!
  • All ages welcome!
  • Bar with top-shelf liquors, beer and wine. Your ticket includes a certain number of drinks:
    • ​VIP Ticket: Unlimited drinks
    • General Admission: Three drinks
    • Student / New Grad: One drink

Click For Full Show Details and Tickets