Accessibility Matters

At the Iconfactory, we look at accessibility as a way to give back to a community that’s given us so much. We were thrilled to be inducted into the AppleVis Hall of Fame.

Adding VoiceOver and other accessibility features to your own app is extra work. But as soon as you realize that you’re making someone else’s life better, it’s all worth it.

This is also a good time to remind you that we have an accessibilty project of our own: xScope’s vision defect simulation is open source.

Adulterated Swift

There has been some discussion lately about Swift not having the dynamic features of the Objective-C runtime. Brent Simmons has been doing a great job of pointing out why this is a problem.

It’s very easy to overlook the importance of the dynamic runtime environment. Many of the things it enables happen behind the scenes. There’s no better example of this misunderstanding than a developer who says their app is “Pure Swift”.

That’s because you can’t currently write an app that only uses Swift. The purity of your code is lost as soon as you #import UIKit.

A picture’s worth a thousand words, so here’s a project that demonstrates why it’s impossible. The app itself is ridiculously simple: there’s a button, a few labels, and a single action method. It’s as “Pure Swift” as you can get.

Download Pure.zip

This project also contains an Objective-C category named NSObject+Adulterated. This category overrides two methods that lie at the heart of the dynamic runtime: -respondsToSelector: and -methodForSelector:. The normal operation of these methods is not affected; the only additional functionality is some logging to the console when they’re used. Other than being in the bridging header, the code is not used directly by the app.

When you run the app, you’ll immediately see all the places where Swift is not being used. Pretty much everything you take for granted in your app is using the dynamic runtime. Layout, drawing, animation, and event handling are all dependent on something that Swift doesn’t have yet.

Of course, you’ll immediately say, “This isn’t Swift’s problem! Just rewrite the frameworks!”

And that is exactly the point I’m trying to make.

The community around Swift’s evolution is amazing. The language is improving quickly and dramatically thanks to talented developers inside and outside of Apple. It’s a remarkable open source project.

My concern is that there isn’t a corresponding discussion about the things we’re going to build with this new language. As you’ve just seen, frameworks are important, yet there is no uikit-evolution mailing list. There is an imbalance between the tool and the craft.

I’m guessing that part of this problem lies within Apple itself. There are plenty of developers in Cupertino who have built large applications and the frameworks that they use. I’m absolutely certain that this subject has been discussed in detail by some very smart folks. And they, of course, can’t talk about internal projects.

My suggestion for the folks on the Swift project is to be a little more forthcoming about future plans with frameworks and other infrastructure besides the language itself. It’s a big piece of a puzzle that long-time app developers want and need.

A lot of hand-wringing could be ameliorated with a simple “Yep, we’re working on it.”

Pretending You’re Not Busy As Hell

You know those last few weeks of a project where it seems like every ball you own is up in the air? Your desktop looks like bomb went off: stuff like “website comp (with hero)-20160414-final-2.1 copy.psd” and “DO NOT DELETE YET” scattered all over the place. You’re busy as hell.

And then you realize that you need to take product screenshots. Or do a screencast.

While doing screenshots for my upcoming book, I solved this problem by writing a simple shell script. It updates an undocumented Finder preference that controls whether the desktop is created or not. Without the desktop, all of your icons disappear (don’t worry, the files are still there!)

Simply typing finder_icons off in your Terminal lets you pretend that you’re working in complete zen and take the shots you need. Doing finder_icons on quickly brings you back to reality and lets you create an even bigger mess.

Enjoy!

Updated April 29th, 2016: Dr. Drang points out that this technique also works well for screen sharing. I try to avoid the use of killall when dealing with the Finder because you never know when it’s in the middle of a file operation (such as copying a file or deleting a folder.) Using the AppleScript quit command lets the Finder determine when it’s safe to shut down.

Updated October 16th, 2018: For those of you who prefer not to use a script, download the FreeMyDesktop app. This simple app modifies the preferences and kills the Finder from a button in the menubar. Handy!

Going Deep

If you haven’t already, check out my in-depth analysis of the new iPad Pro display. I think it tells us a lot about the future of what we’ll all see on Apple’s devices.

This is clearly a time where our tools and APIs need to evolve. Here are some things that you’ll need to watch out for as you start using color management on iOS:

  • rdar://25836820 – Color management support is not consistent across devices
  • rdar://25836842 – Color profile conversion by Xcode is not documented
  • rdar://25836912 – Current color profile for display is not available
  • rdar://25836961 – Quartz 2D Documentation about iOS color spaces is incorrect
  • rdar://25837000 – Color Management Best Practices for iOS is incorrect
  • rdar://25837030 – There is no way to turn off True Tone
  • rdar://25837065 – The CGColorSpace documentation needs to be more explicit about new color spaces
  • rdar://25837117 – PNG assets can’t have an embedded color profile

Of course, I’ll be covering these issues and a lot more in my new book. Sign up for the A Book Apart newsletter (at the bottom of the page) and you’ll be notified when it’s ready.

The Forensic Shit Show

It turns out someone at the FBI advised another law enforcement officer in San Bernardino to reset the iPhone that the government wants Apple to unlock.

This is just another episode in a complete forensic shit show.

Remember, this is the same case where the media was allowed to roam freely through a crime scene. One of the photos in that gallery shows a computer without an Ethernet connection on the wall (the age of the apartment also suggests that there would be no wired Internet.)

What are the chances that there was a wireless network in that apartment? What are the chances that there are IP logs on that router? Or maybe some kind of data backed up to a disk on the router? Here’s another wild guess: maybe that router was used to connect to an online backup service.

Yep, someone did the equivalent of a “restore factory defaults” on a device under active investigation.

What we’re seeing here is law enforcement’s complete lack of understanding of how digital devices store and transmit data. This new evidence is much more intricate than smoking guns or blood splatters. The important stuff is what you don’t see: it’s a hard problem where the people dealing with it are untrained. Shit, I work in this business and trying to decipher what’s going on makes my head spin.

Yet law enforcement is asking Apple to not only provide data, but also to create a forensic instrument that allows them to extract information from any device. And by its very nature, this tool would be made widely available throughout the forensic and law enforcement community.

Basically, the government is asking Apple to hand over a golden key that can defeat the security of any device to folks that can’t even secure a wireless network. Worse, this whole process is being overseen by politicians that think the problem is predators getting access to their grandkid’s Playstation.

This is why the entire tech community is saying “No fucking way.”

Updated February 21st, 2016: Several people have commented about my use of “restore factory defaults” in the post above. My intention was figurative, not literal.

The folks involved with the investigation were pressing buttons without understanding the consequences of their actions. To me, it feels like a “reboot to fix” approach. The password reset did not damage any data, it just made automatic backups stop working because iCloud information on the device needed to be updated, and that can’t be done without a passcode.

Others have reminded me that the FBI had cleared the crime scene. That’s true, but since the Wi-Fi equipment was not collected as evidence, it still shows that the investigators were out of their league. In an electronic investigation, a router is a key piece of the puzzle.

Both of these things are details in a bigger picture: the FBI wants to hold the private keys to a public key encryption system that affects the privacy of hundreds of millions people. If they can’t get the details of an online backup service right, how the hell do we expect them to guard a back door?

There’s also a possibility that the iCloud password reset was intentional. If this is the case, we have a government that is extorting Apple by essentially planting evidence. Imagine what they could do with a private key.