As of iOS 5, Apple has deprecated the device unique identifier api and hasn’t provided a friendly Obj-C replacement, instead recommending CFUUIDCreate and NSUserDefaults.

CFUUIDCreate isn’t very complicated and neither is NSUserDefaults, but this solution fails in a few different ways:

• It’s not a quick one-shot call to get the UUID; you have to write your own wrapper to make it friendly
• It doesn’t persist; deleting the app blows away the UUID
• There’s no way to share it between apps

The answer to these issues is to create a class that acts as the wrapper and improves on the persistence and sharing options using Keychain.

Quick Keychain primer:

On iOS each apps gets its own keychain where it can store sensitive data that only that app can access, with some very particular exceptions. This keychain is persisted across installations and, if the user encrypts their backups, across restores. A full restore and setup as a new device or restore from unencrypted backup wipes the keychain.

This gives us a place to store an app (or app suite) specific UUID that will last as long as a given user continues using that device, but that will change if they do a full restore. That’s a nice level of fidelity that suits most legitimate tracking needs, like identifying that a device is already known to a web service tracking active devices. A given device won’t have two UUIDs simultaneously and for most users won’t change until they get a new device.

Another useful feature of Keychain is support for access groups, which allow iOS applications from the same provider to opt in to sharing a common keychain. The UUID can be stored in a keychain that all the apps can access, thus allowing us to know that a given set of installations all represent a single device.

“So this all seems interesting, but where’s the code?” – Nerds Still Reading This

 @interface BPXLUUIDHandler : NSObject
 /*
  * Retrieve UUID from keychain, if one does not exist, generate one and store it in the keychain.
  * UUIDs stored in the keychain will perisist across application installs
  * but not across device restores.
  */
 + (NSString *)UUID;
 /*
  * Remove stored UUID from keychain
  /
 + (void)reset;
 /*
  * Getter/setter for access group used for reading/writing from keychain.
  * Useful for shared keychain access across applications with the
  * same bundle seed (requires properly configured provisioning and entitlements)
  */
 + (NSString *)accessGroup;
 + (void)setAccessGroup:(NSString *)accessGroup;
 @end

BPXLUUIDHandler is a class we created to encapsulate all the handling of getting/storing the new UUID and added support for access groups since some of our clients have application suites.

It supports ARC and non ARC configurations and tucks away all the keychain interaction so that we don’t have to keep writing the same blob of keychain queries again and again.

It’s available for download at our github, use and enjoy and provide feedback.

A few nights ago, I got a little grumpy on Twitter. Xcode 4 has been very popular to snipe at, and some of the things I was seeing in my twitter stream were starting to feel a little tiresome and not particularly constructive.

Make no mistake: a lot of people – including people on my own team – have been seeing legitimate issues, and their productivity is being impacted. But what bothered me was the scarcity of tweets mentioning bug reports. Many people weren’t actually doing anything about it besides voicing their distress, which resulted in me posting this tweet:

This kicked off a heated debate about the efficacy of filing bugs against Apple’s products, so I decided to blog about a topic my friend Matt Drance (@drance on Twitter) had discussed at the last C4 conference.

Get to know your Apple Evangelist

I’d like to introduce you to a man named Michael Jurewitz. Michael works at Apple as the Developer Tools Evangelist. His job is to serve as a liaison between the people that build the tools we use to make our products and the people that use them.

Michael spends a lot of time advocating for developers. He’s accessible via twitter or email to field issues reported by developers and figure out who needs to see them. He’s been a big help to us in the past, but I have also personally been on the receiving end of this more times than I care to recall:

Photo by George Dick, “Radar or GTFO” addition by Steve Streza

File a radar, or GTFO: Mike is going to need you to file a bug before he can even start to help you, because the first question he’s going to get from engineering is “what bug number is it?” He’s going to need some documented description of the issue in order to have a reasonable chance of dealing with it.

What is Radar?

(skip ahead if you already know this)

Radar is Apple’s bug tracking system. It covers a variety of issues, internal and external, and is the primary interface the development community has for reporting issues they’re seeing with Apple’s products and tools out in the wild.

If you’re a developer outside of Apple, you can access radar’s web interface at bugreport.apple.com.

Within Apple, employees have access to a Radar desktop application that they can use to access your issues. It’s pretty neat, and can automatically open hyperlinks (in email, for instance) of the form rdar://yourissuenumber.

What you are probably going to see

Most of the time, you’re probably going to get a response like this one:

12-Jul-2011 12:02 PM Apple Developer Bug Reporting Team : This bug has been closed as Duplicate. We are aware of and tracking this issue under the Bug ID listed above in the bug >State (Duplicate/XXXX). To check the status of the original bug report, please update your report directly and we will provide you with any available information.

Frequently, at least one other person will have reported the issue that you did. A lot of people get frustrated by this, because they think that their report has been summarily dismissed as reproduced effort, but really, they just don’t understand that filing duplicate bugs is a very good, important thing. Your duplicate counts, and here’s why.

Filing duplicates is critical to getting things fixed

Engineering organizations always have more work than they can handle, and routinely meet up with their managers to triage their pile of work and figure out what to take on next. The higher the number of reported cases of a particular issue, the easier it is to justify to the person you work for that the issue needs attention.

This is true of any software company. When you release a product, there will likely be one or two edge cases that people report, and you will likely try to figure those out as soon as time permits. But when hundreds of people are reporting the same issue, it becomes clear that the situation is rampant, and requires immediate attention. Apple is no different from any of the rest of us in this respect.

Filing a duplicate bug is your way of up-voting, or bumping, a reported issue. The more duplicates that show up for a specific issue, the higher priority that issue becomes.

On the other hand, there are few things sadder than exchanges like this one between the illustrious Matt Gemmell and Michael:

An issue with only one open ticket is pretty much going to be statistically lost in the noise and is likely to be overlooked unless more people start reporting it.

But even if there are other tickets opened on the same issue, maybe everyone else’s reports on the issue suck. Your post may provide engineering with some crucial information they need to triangulate on the issue and fix it.

Radars don’t have to be expensive to file

To start, getting the issue captured is probably more important than providing sample code that demonstrates the issue, particularly if there are lot of duplicates for the issue you’re reporting.

I have been berated many, many times for not filing a radar on something before asking for help. As a reporter, I feel like it’s my job to provide a test project that clearly shows the problem occurring, and I usually feel like I’m just going to hear “We can’t do anything until you show us how to reproduce it.” Since I don’t have some way of demonstrating the issue (and often can’t easily spare the time to put one together), I end up dragging my feet on actually getting the problem captured in the first place. That doesn’t help anybody.

And, as a matter of fact, I usually do get a response asking me to provide steps to reproduce the issue, or some sample code along with the ticket. But at least once the issue is captured we have a common point of reference we can talk about, and honestly, the folks at Apple can be pretty earnest about wanting to see how serious the issue is. Getting the ticket opened in the first place is a very good way to get a dialog going, find out that its something they need to see to handle, and THEN you can opt to spend your time isolating it a sample app for them.

That said, you get some pretty good extra credit for supplying the sample code up-front, so if you’ve got the time, do it. My friend Danilo Campos and I also like to use sample apps as a way of making sure that the problem is actually a bug in Apple’s code, and not just us shooting ourselves in the foot with a bug of our own. So it doesn’t hurt to be proactive about it if you can.

If you see an issue, get the word out

File your radar, then go to Open Radar and post the same bug there as well (don’t do this for beta products under NDA!). Then tweet the open radar link so that other people are aware of the issue as well. Hopefully that will spur on other people experiencing the same problem to file a report of their own.

If you haven’t heard anything back within a few days, ping @jury, @behrens, or someone like @ctp, and let them know about the issue. MAKE SURE YOU INCLUDE THE rdar:// link, because that’s the first thing they’re going to ask you for if you don’t provide it.

These are good people, and they care about this stuff. Help them help us.

If you have issues with the radar system itself, don’t let that keep you from using it. File radars on radar, and then tell other people about what you’d like to see changed, too.

Finally, here is a list of issues our team captured and sent into Apple today. Please file a duplicate if you are dealing with any of these problems yourself.

-Daniel

Xcode issues

iOS Simulator becomes unusable due to issue with bootstrap server
rdar://10955846 http://openradar.appspot.com/10955846

iOS Simulator Frequently hangs; can’t register with the bootstrap server*
rdar://10955879 http://openradar.appspot.com/10955879

Bootstrap Error*
rdar://10955680 http://openradar.appspot.com/1095568

Xcode syntax highlighting and codesense die randomly
rdar://10955817 http://openradar.appspot.com/10955817

XCode hangs on closing brackets or parentheses
rdar://10490835 http://openradar.appspot.com/10490835

Xcode selects team signing profiles too aggressively
rdar://10914434 http://openradar.appspot.com/10914434r

Please restore “Do not re-sign” when exporting Xcode archives for distribution
rdar://10952383 http://openradar.appspot.com/10952383

Document search in Xcode is glacial
rdar://10956403 http://openradar.appspot.com/10956403

*Duplicates of the first bootstrap issue opened by other members of our team struggling with the same problem.

UIKit Issues

Completion notification for UITableview animations
rdar://10958564 http://openradar.appspot.com/10958564

Radar Issues

Radar should be searchable
rdar://10956083 http://openradar.appspot.com/10956083

Make 3rd party issues in radar searchable by outside developers
rdar://10956077 http://openradar.appspot.com/10956077

Docs should get updated with known bugs:
rdar://10956241 http://openradar.appspot.com/10956241

Post discovered workarounds to duplicate bug reports
rdar://10956145 http://openradar.appspot.com/10956145

Not to sound pretentious, but (cue extremely pretentious comment) I was into Photoshop before it was cool. I can remember a time before multiple undos, a time before layer styles. I’ve followed its evolution closely as the years have passed, enthusiastically embracing certain developments, and reluctantly accepting others (only to eventually find them indispensable).

The long-established dominance of Adobe’s product line makes it an equally prominent target for criticism. Any advanced user can rattle off a laundry list of feature requests at a moment’s notice (<cough>duplicate-layer-styles-on-a-single-layer<cough>). Among designers and artists, bitching about obscure, power-user problems is a regular pastime. Ultimately, this is a compliment – what we’re saying is “I really wish your awesome program could do this one additional thing, but it’s not like I’m going to start using something else”.

I guess there might be a point at which such scrutiny becomes unfair, but I personally wouldn’t know where to draw that line. In fact, during a recent conversation with my co-workers, it became obvious that we all shared a very specific disappointment with something that had absolutely no impact on our actual workflow: Adobe’s icon design. For most of the last decade and a half, their major products had attractive little illustrations to represent them. When CS3 was released, however, the feather, flower, and butterfly were swept away to be replaced by boxes with bold lettering.

As a designer, I understand what they were trying to do – it’s a bold, simple, and professional direction to take their branding. But as an illustrator, it made me sad to see icons that don’t reflect the creative potential I associate with the software itself. So, having experience in precisely this kind of work, I thought it might be a fun challenge to create icons that I would have liked to see.

These were mostly a fun side-project, but they’re fully functional icons as well, and we thought we’d post them for anyone who might like them. (Download ICNS files and instructions here)

MoneyWell (by No Thirst Software) wanted a spiffy new icon for its version 2.0, and we were happy to oblige. This is how we went about it.

MoneyWell has consistently been represented by a well bucket full of money, and we didn’t want to stray from that metaphor. The trick was to find a balance between the rustic look you’d expect from a handmade well bucket and a polished design that conveyed the app’s professional quality. Striking this balance would prove to be the biggest part of the challenge throughout the project.

First, it’s always good to start with a detailed sketch.

And before drawing anything semi-realistic I like to collect a few photo references—not in order to copy them slavishly, but because objects in real life often present interesting details we tend to forget when we recall things from memory.

With some idea of the bucket’s form in mind I moved into Cinema 4D to build it there. I tend to prefer Illustrator for small icons, but you can better approximate Apple’s photo-illustrative style in a 3D app. In fact, “de-rendering” the icon in Photoshop becomes an important part of the process—the rendering output is too “3D-looking” on its own.

I can’t explain everything that goes into building something like this in Cinema 4D, but I’ll try to provide the highlights.

While Cinema 4D will indicate the portion of the viewport that will be included in the final render, I like to make this safe area very explicit. I designed a frame graphic at 640×640 with a 512×512 transparent area and loaded this as a texture on a foreground object. I also set the rendering output to 640×640 so everything would line up consistently.

One also needs to be aware of the effects of color correction on the final output. I’ve settled on using “Load from Monitor” in Preferences > View > Display Color Profile as producing color that’s pretty consistent with other apps. Still, I recommend selecting “Use the embedded profile” when opening Cinema 4D’s output images in Photoshop. (You can always convert to sRGB on export.)

I built the bucket by using a cloner to arrange copies of a tapered rectangle in a circle. The taller planks are an extrusion of a curved spline, angled to match the arrangement of the other planks. The handle is a sweep NURBS, while the metal bands and coins are lathes. Really, the modeling is very simple.

Filling the bucket with the coins could have been tricky, but Cinema 4D made this easy. Put the coin in a cloner, assign them some physics, and drop them in. In fact, the shape they fall into and collide with is an invisible funnel—not the bucket itself. By reshaping the funnel, I could adjust how the coins fell until I got the look I wanted for the coin pile.

My first instinct for the bucket was to go all-in on metal to get as far away from a rustic look as possible.

And if it’s all metal, maybe the bucket is not made up of planks but machined from a solid block. (Around this time, Michael Shepard contributed the revised insignia design that would persist through to the final version.)

It’s a bit one-note, and the client asked us to go back to a wooden bucket approach. I was able to get a nice, rough look for the wood using displacement maps, and we moved the “MW” insignia to a medallion rather than lose it entirely.

That’s looking pretty good! But I’d gone too far in the “rustic” direction. The client asked for a darker, more polished look; and suggested the planks bend with the metal bands holding them together—as they would in a real well bucket.

Getting closer. You’ll notice I experimented with (but ultimately decided against) a ridged texture on the coin edges; and at this point we’d decided to eliminate any overflow coins from around the bucket.

The wood’s gotten a bit dull, so we polish it up. Notice the coin edges have yet to be completely smoothed—that’s a side-effect of the displacement used to achieve the engraving on the coins.

We’re close enough that it’s time to start playing with the pieces in Photoshop. I use compositing tags in Cinema 4D to hide certain objects without eliminating their shadows or reflections. Then I render to a “multi-pass” layered image which allows me to adjust those effects individually.

Reflections and specular highlights get toned down or masked out. Edges are softened with inner glow to flatten the overall look and reduce it’s rendered-ness.

This is now very close to the final result, but the wood still wasn’t quite there. The client sent over examples of something that might be more along the right line, and I dug up a similar texture in a high enough resolution to work for the larger icon sizes. Thanks to the multi-pass output, colors can be played with “in post” until they’re just right.

You’d think we were done at this point, but this icon has to work at every size from 1024×1024 (no, I don’t know why that resource exists either) to 16×16. You can’t just scale down and expect good results. As the image gets smaller, it needs to get brighter and sharper in order to be legible. Components may have to be resized or masked out to better conform to the pixel grid. (It helps if you cut your teeth on icons in Classic Mac OS.)

Here are some of the smaller sizes. Note that reflections and highlights have been toned down, contour lines are introduced and certain details (like the “MW” insignia) have been removed. Edges are sharper and the overall look is brighter and more saturated.

By the way, I really like Icon Slate for building and testing Mac app icons. It’ll let you preview an icon against different backgrounds or even right in the dock with a single click. Unfortunately it doesn’t support the 1024×1024 icon resource, so you’ll still need Apple’s Icon Composer to add that resource.

Any software professional with an internet connection probably sees at least a hundred icons a day. They’re small and they’re everywhere – icons, not software professionals – little visual morsels of meaning sewn into the digital terrain like jewels on a robe. As a result, I think most of us tend to take them for granted, but the fact is that a surprising amount of work goes into the good ones. That crisp and shiny final image is, more often than not, the descendant of a dubious lineage of awful, mediocre, or just-not-quite-good-enough ideas, all of which get left on the cutting room floor.

What is, theoretically, a linear transition from idea to execution…

…is usually something a little more convoluted:

What you see above is what goes into making the sausage. A lot of experimenting, a lot of trial-and-error, and ultimately something more akin to survival-of-the-fittest than let-there-be-light.

In this case I was trying to create an icon that looked like a holographic display. I’ve always loved the challenge of rendering “special effects”: glowing things, iridescent things, things bristling with electricity. These are the kinds of images that require obsessive adjustments of color and transparency in order to get from “cheesy” to “wow”.

After the first quick digital concept, I actually went back to my sketchbook:

I won’t be the first or last to emphasize the value of sketching by hand. The obvious advantage is that most basic shapes are just quicker to draw (albeit roughly) than to create in Photoshop or Illustrator. The less obvious advantage, paradoxically, is that sketching out more complicated forms is usually slower – an almost meditative process which allows you to come up with a second idea half-way through drawing the first.

Then I jumped back into Photoshop and got to work creating some rough drafts of different designs. Since I felt pretty confident about the holographs themselves, I started out by focusing on the design of the projection device. Experience has taught me that the ideas I like initially will not necessarily be the strongest candidates, so I try not to get too attached to anything. One of the things I wanted to make sure to get right was the “technology” of the projection screen. My first idea, a grid of glowing bulbs set beneath glass, eventually gave way to a matrix of glowing pixels contained within glass:

But the element that ended up giving me the most trouble was the base of the device. The original concept was to make it very futuristic, like maybe something Apple would be selling in the year 2050. I wanted it to imply a whole aesthetic of product design in whatever future world or alien spaceship it existed in. However, at some point during the course of my experimentation I had created a simple cylindrical disc, and the more I looked at it, the more I realized that all the detail I was putting into the others was going to crowd out the focus – the luminous glow of the projection and the holograph itself.

I shared a couple of the more developed ideas with my coworkers and I wasn’t too surprised when most people favored a shallow, slightly tapering metal base. It needed more personality, but it was clearly the strongest design.

I tweaked the color and shape, added some subtle (but essential) details to the metal and the projection grid, and spent the rest of the time refining the look of the holograph. I was careful at this point to make sure that whatever treatment I came up with was something I could duplicate with multiple shapes. The final product is a set of icons featuring the same device but with different holographic projections depending on the hard drive:

I’m pretty happy with the results. If you want to check them out, the icons are available for download.