Xcode: Who’s to Blame?

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

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

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

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

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

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

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

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

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

Blame is pointing fingers without solving the issue at hand.

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

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

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

Words Matter

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

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

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

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

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

That’s How Git Does It

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

Author! Author!
in an Xcode without Blame.

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

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

Just A Joke

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

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

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

Sign Your Work

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

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

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

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

Please take the blame out of Xcode.

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

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


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

Which is admittedly a less catchy name.

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

New Xcode Build System and BuildSettingExtractor

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

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

Project settings sheet with popup menu to select build system

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

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

Icon for the app BuildSettingExtractor

BuildSettingExtractor helps you move to xcconfig files.

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

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

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

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

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

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

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

Logo of new Xcode build system

New build system.
Same build settings.

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

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

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


1And debugging them.

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

iOS Device Summary: September 2016 Updates

I’ve updated my iOS Device Summary with hardware announced at the Apple event on September 7, 2016.

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

A few notes:

Sometimes fall brings new iOS hardware across all product lines. This year, only new iPhone versions were released.

In terms of legacy hardware support, iOS 10 drops support for devices running the A5 and A5X processor. This includes iPhone 4S , which means that there are no devices with a 3.5-inch screen that support iOS 10.

.Don’t feel badly for devices with the A5 chip—they have had a very good run. The iPhone 4S debuted running iOS 5 and iPad 2 debuted with iOS 4.2.1. Both were supported up through iOS 9.

Time will tell if the next version of iOS drops support for A6 and A6X devices. When support for those devices is dropped, iOS devices will be 64-bit only.

In the meantime, of course, it is important to test on older devices running the oldest version of iOS that you support.

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

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

 

tvOS and watchOS Device Summary: April Edition

After updating the popular iOS Device Summary in March, it seemed the beginning of April would be a good time to introduce summaries for devices running the most recently introduced Apple operating systems: tvOS and watchOS.

I hope you find these as useful as I have. •

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

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

iOS Device Summary: March 2016 Updates

I’ve updated my iOS Device Summary with hardware announced at the Apple event on March 21, 2016.

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

A few notes on the newly introduced hardware:

The introduction of the 9.7-inch iPad Pro means even more users will be putting the Apple Pencil and Smart Keyboard through its paces. Even if your app is not a drawing or text-centric, you might consider having at least one size of iPad Pro with these accessories for development and testing.

The iPhone SE brings paris a well-established iOS screen resolution with a faster processor. From a testing perspective, apps that perform well on previous 4-inch devices should perform even better on the new hardware.

Only the display of the 9.7-inch iPad Pro has the new True Tone feature.

The Night Shift feature introduced in iOS 9.3 is available to devices using at least an A7 chip—every device on the 64-bit side of the divide on the summary chart.

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

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

 

iOS Device Summary: Fall 2015 Updates

I’ve updated my iOS Device Summary with hardware announced at the Apple event on September 9, 2015. This edition drops iOS 5 and A4-based devices to make way for iOS 9 and the A9 and A9X.

(This update has taken a little while—I’ve been busy helping to build a new cloud computer at Upthere.  I’m excited to say that we launched yesterday. I encourage you to learn more and join the beta at upthere.com.)

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

The biggest news this fall is the iPad Pro, which introduces the largest iOS screen size ever, but also two new Apple accessories that may be important to test your app with: the Apple Pencil and the Smart Keyboard. On the other new devices, iPhone and iPad screen resolutions remain the same and get faster processors. From a testing perspective, things that perform well on last year’s models should perform even better on the new hardware.

It is also interesting to note that all of the devices that can run iOS 6 are on the 32-bit side of the processor divide.

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

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

Apple Home Page Tabs History—September 2015 Edition

The year 2015 has been a busy one in Apple Home Page Tab history.

It’s been over a decade since there have been this many changes to Apple home page tabs in a single year.

Image of Apple home page tabs

Click for full-sized image

The only other time Apple home page tabs changed three times in a calendar year was back in 2003.

All three of the home page tab changes that year revolved around the introduction of the iTunes Music Store. The Switch tab for the Mac Switcher ad campaign changed to Music with the introduction of iTMS in April 2003. This lasted five months when iTunes replaced Music. This lasted only a month when the tab became iPod + iTunes.

There were no visual style changes to the tabs in 2003, just repeated content changes to that single tab as Apple adjusted how it presented its new foray into digital music to the world.

The changes of 2003 came full circle this past June, when the iTunes and iPod tabs combined to become a Music tab with the introduction of the new Apple Music service—but even bigger changes were right around the corner.

August 2015: Store to Shopping Bag

In August 2015, a redesigned apple.com combined the shopping experience of store.apple.com with the product information found on the main Apple site.

With the online store no longer a standalone site, the venerable Store tab—a fixture in the Apple home page tab lineup since the very beginning—had outlived its usefulness.

The Apple home page Bag icon containing a blue dot to show it has contents

Shopping Bag is the first tab to show state.

For its entire tenure, the Store tab was the constant companion of the Apple tab, its steady commerce-oriented neighbor to the right.

The new Shopping Bag tab is the logical successor to the Store tab, but it is not its replacement in either location or behavior. 1

The Apple and Shopping Bag tabs are now the first and last items serving as bookends for the rest of the home page tabs.

In terms of behavior, clicking the Shopping Bag tab displays a menu of shopping-related choices, similar to the ‘shopping cart’ on most e-commerce sites.  It is the first Apple home page tab to indicate state, showing a blue dot if the user has items in their bag. 2

A New, Responsive Design

The updated apple.com also included visual and functional changes site-wide and to the tab bar in particular.

The tab bar became translucent black with underlying page content visible beneath, a refinement to the visual style introduced in September 2014. 3

The updated website design is also responsive, with the tab bar changing appearance based on page width. For a width 768 and above, the tab bar shows all of its tabs.

The Apple home page tab bar adjusted for narrow width shows a menu button to access other tabs, a centered Apple item, and the Bag item on the right.

The responsive design hides most tabs and adds a menu tab when viewed at narrow widths.

For narrower widths, only three items are visible. The Apple tab appears in the center. The Shopping Bag tab is on the right edge.  A new menu tab is on the left edge. All other tabs are presented as menu items displayed by clicking or tapping this new tab.

In the narrow layout there are other minor changes—the tab bar becomes slightly taller and the Apple and Shopping Bag icons slightly larger.

September 2015: TV no longer a hobby

In September 2015, Apple announced the fourth generation Apple TV with Siri Remote and a tvOS SDK for developers to create apps for the new device. Along with that announcement, a new TV tab was added.

This tab was a long time coming. Apple TV was first announced under its code name iTV nine years prior, in the fall of 2006. For many years, Apple referred to Apple TV as a ‘hobby’, indicating that it was not a core product such as Mac or iPhone. History indicates that hobbies do not warrant a tab on the Apple home page.

So, with the announcement of the new Apple TV and the addition of the TV tab, it seems TV is no longer a hobby for Apple. •

Since the last update, I’ve been cited as the ‘unofficial Apple home page tabs historian’ in articles at The Loop and Six Colors.  Here are a few past articles on this topic that you might enjoy:


The name Bag was the label Apple originally used in the tab’s web accessibility ‘aria-label’ tag. As of September 29, 2015, this appears to have changed to Shopping Bag

Some earlier tab bar designs would indicate selection state, darkening to indicate which section of the site you were visiting. The shopping bag is the first tab that carries state or status independent of selection.

The images used in the A Brief History of Apple Home Page Tabs graphic are screen captures of the tab bar over a white background

 

iOS Device Summary: A8 iPod Touch Update

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

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

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

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

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

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

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

iOS Device Summary: iOS 9 Update

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

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

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

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

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

Finally, devices for testing:

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

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

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