Category: Development

Making Sense of Color Management

Making Sense of Color Management Book Cover

After over two years of work, my book on color management is now available for purchase. People I know and respect are saying some really nice things about my writing. It makes me happy when doing hard things pays off.

Previously, I’ve written about how displays are changing and how color affects the things we build for these devices. Whether you build on the web, or with native apps, your work in the coming years will be affected. You can learn more about the book at the Iconfactory.

But don’t just take my word for it. Here’s what Mike Krieger, Cofounder and CTO at Instagram, has to say about the book:

For years, engineers and designers have mostly stumbled through color management, understanding it ‘just enough’ to ship an asset to the web or an app. As devices move to wide color, a deeper and more practical understanding is vital, and Craig’s book provides exactly that. In fact, I’ve put his advice to use for Instagram.

As a developer, you might be interested in taking a look behind the curtains at the book’s mini-site. You’ll find additional articles, new markup for the web, and sample code for both iOS and macOS. The book provides essential background for these examples, but it will give you a taste of what you’ll be learning.

I also have some more advanced code examples for iOS in the works. If you work with raw pixels in bitmaps, process photos with Core Image, or do analysis with vImage, this will be right up your alley, so stay tuned!

Written on December 9th, 2016 for Design, Development

Leaving Last Betas

I just updated to macOS Sierra on one of my Macs and immediately encountered a problem: I was enrolled for beta downloads even though I had never enabled them on that machine. I’m guessing that there was an old download on that machine that somehow caused the App Store to enable the beta.

There’s a good reason why I don’t want the betas installed on that Mac: it’s the one that runs the version of macOS that most of my customers will be using. It’s also the machine that submits products to the App Store, and we all know how picky they can be about tool and OS versions.

There’s button in the App Store settings of System Preferences that lets you opt out of updates. The problem is that button doesn’t do anything if you’ve already checked for updates. This is very likely to happen since the first thing most people do after installing the new OS is open the App Store.

To turn off beta updates I first quit the App Store app and checked that there was a beta seed URL for Software Update using the Terminal:

$ sudo defaults read \
    /Library/Preferences/com.apple.SoftwareUpdate CatalogURL
https://swscan.apple.com/content/catalogs/others/index-10.12seed-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz

I then nuked it:

$ sudo defaults delete \
    /Library/Preferences/com.apple.SoftwareUpdate CatalogURL

(Thanks Cliff!)

After getting off the beta, I then cleared the Software Update catalog with:

$ sudo softwareupdate --clear-catalog
Changed catalog to Apple production

(Thanks franz!)

As I did that the App Store settings in System Preferences immediately showed “No check for software updates has been done yet”. Launching the App Store refreshed the catalog and did not show the beta update.

Yay. Time for a drink!

Written on September 30th, 2016 for Development

Sticker Accessibility

The popularity of Stickers was no surprise to us. What did surprise us was that these graphical elements are a hit with customers who have vision difficulties.

In retrospect, it makes sense. You want to let friends know that poo is hitting the fan even if you can’t see well. As always, Apple has thought about making their products accessible from day one, and the new features in Messages are no exception.

But it doesn’t work like you’d expect for the default apps created by Xcode. Take Parakeet’s excellent Snacks collection as an example. What would you expect to hear VoiceOver say with this configuration?

Bacon

Congratulations if you said “Bacon P-N-G Accessibility Label”. Technically, that’s the “same” as the Bacon.png file that was dragged into the Asset catalog, but it’s not what you or your customer expects. When you add “Bacon” in the Accessibility field as well, it’s read correctly and everyone wins. As you know, you can’t have too much bacon.

As for our own Sticker packs, we implemented custom view controllers and don’t suffer from this particular problem. We have identified some other small accessibility issues throughout our work and will be issuing updates soon. Parakeet will also be updating their release with improved labels.

If you’ve released Stickers for iMessage without Accessibility labels, we suggest that you do the same.

Written on September 21st, 2016 for Advice, Design, Development

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

Written on May 20th, 2016 for Development, Observation, Opinion
Newer
Older