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.

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

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

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.

As an overall goal, the get together was intended to be very conversational to allow the four of us to simply get to know each other better. While this low-key style interaction was a constant thread throughout our time together, we wanted to share a few of the more concrete points we discussed; believe it or not the time wasn’t all spent on gambling, drinks and shows. And… we’re excited to share what we go through as we grow. The good and the bad.

We’d like to encourage questions/ideas/comments/dialogue around these points, as well as anything else folks would like to throw out there. We like talking wit’cha!

State of the Design Union

We talked about where Black Pixel has been on the design front and where we think we’re at. Some of the points we want to keep working on are things like processes and efficiencies. We also talked a lot about the role of “design” as it applies to every piece of the project lifecycle and every member of the Black Pixel team.

Direction

Branding. Craftsmanship. Care-invested design.

We want our brand to deliver products with undeniably EXCELLENT user experience.

Our mission is to ensure this standard is reflected in everything from our website and scope documents, to our product interfaces, visual design, development and quality assurance; and of course, what the folks who work with us feel post-project.

Dan started an internal conversation with our design team proposing some ways we can change up current methods with the goal of opening up project-idea-contribution earlier on to create more learning opportunities, introduce more ideas earlier on and push foundational ideas further throughout the design cycle. We are learning from our past, learning from our friends and inspirers, and reworking ourselves to make noticeable, beautiful growth. We want to push ourselves and see what happens.

Creative team – Growth & Development

All of us here at Black Pixel come with a range of experience under our belts, so finding some stride in how we’ll push the boundaries of our creative brains is something we will continually work on. For our team members, we simply want to help people pursue the areas they’re passionate about, and also expose them to roles outside of their normal responsibilities.

As mentioned in the direction paragraph above, we’re going to try some different ways of approaching projects on the creative side. We’re proud of the people who’ve joined forces to become Black Pixel and we want to cultivate taste company-wide.

Evangelism

While we discussed a range of things from promotion, sponsorships, marketing, philanthropy and events, we resolved that the best evangelism method for us right now is putting everything into our people and our work. We have a good number of folks on staff that speak, write, teach and do a lot of traveling just to learn and connect with other folks in addition to the things called “their job.” We find these to be some of the best means to spread the word on who we are and what we’re passionate about. AND of course, we want our work to speak for itself. So for the immediate future, that’s our plan.

That’s the recap!

One good way to do this was using the iPhone Simulator, but you typically get at that by launching Xcode with an appropriate project. I’ve been using Alfred ever since I was introduced to it at SecondConf by Phillip Bowden, and I realized it’d be really convenient if I could kick off the simulator using just a couple of keystrokes.

Here were the steps I used:

1. Find the path the iPhone Simulator. I did this by launching the sim from Xcode, then right clicking on the Dock icon and selecting Options->Show In Finder. Once I had that, I right clicked on the Applications folder showing at the top of the Finder window’s toolbar. This showed me the full path to the current folder.

2. The next thing to do was add the path to Alfred so it knew where to find the sim’s executable. I did this by hitting option-space bar, and then clicking on the gear icon in the upper right hand corner of Alfred’s popup window.

1. You can add the path by selecting the Features tab from the Alfred UI, then hitting the plus button at the bottom of the Search Scope area.

After that, you’re done. Invoke Alfred by hitting option-space bar again, then type ‘io’

Boom:

Strategy — Some of our favorite projects have been ones where the client approached us with the spark of an idea, looking to us for guidance. We sit down with the client’s team, talk through their needs, advocate for their users, and develop that idea into a functional blueprint, often with sample wireframes or even full-color mockups.

Wireframing — Usability is everything from how fast the app launches to the color of a button. We all stress on this, and we all take responsibility if something doesn’t feel right. But happily, we have someone on the team whose job it is to make sure that the blueprints account for all of the possibilities.

Visual Design — This is what people typically think of when they refer to design, and it’s easy to see why. Most of what we process consciously about an app’s presentation is what we see. Making software pretty is one of our favorite things in the world, so naturally it’s very important that we consider every pixel.

Production — When we hand a finished design over to developers, we give them a complete set of assets (including @2x for iPhone projects) and style guide, which includes annotated and documented full-resolution mockups. We don’t like leaving anything to guesswork.

Iconography — To ensure that even the tiniest details in our apps looked great, we hired a guy whose username is “Iconmaster“. Talk about focus. We also have a passion for creating app icons, because they’re often the user’s first experience with an app.

Design Reviews — Because another set of eyes can make all the difference, every project we touch at Black Pixel goes through an internal review process. Even if you have your app designed elsewhere, we’re happy to offer our perspective.

We provide these services à la carte, and we’re excited to work on interesting projects with anyone who is passionate about good design and making their users happy. If that’s you, get in touch.

As some folks will know, in June 2011 I left an amazing role as the Sr. UX + Product manager on the Zappos mobile team with the intent of starting my own UX strategy + design consulting agency. Thusly, soon after began some dialogue with Black Pixel about how we might find ways to collaborate.

You know how it is when you love something a super whole bunch? Like Trekkies and Star Wars fanatics love their respective sagas? Black Pixel ARE those people. And not just for sci-fi. They are those people for apps. They love this stuff. They know this stuff. They can’t get enough. And they LOVE to share what they know. They want their products to be the best possible things they are humanly capable of making. And they ache for projects that hurt their brains while working through possibilities and options and ultimately, solutions.

There’s that on the work side but then there’s this equally amazing human side to them. The individuals that collectively create BLACK PIXEL. Sincere, passionate, ridiculously smart, humble… people you want to be around in hopes that some of their smarts will rub off and also just because they say things that make you happy.

So, while my heart was out to follow my dream of building my own thing, when I learned how aligned the goals of this sweet shop was with everything I believe about design and everything I hoped to build AND they wanted me to join them on the design side of things, I was honored, floored and absolutely thrilled. And I leapt right into the opportunity.

So… passion, passion, love, fanaticism, passion, passion, love = what am I getting at here?

Design! It’s a passion we share. Now when I refer to Black Pixel, I say WE. And WE are in it for the end-to-end experience, folks. I think Black Pixel has been more widely known for their dev chops but did you have any idea they have some AMAZING designers on staff here? Who knew? If you knew, just humor me and go with the excitement. Because that’s what I am. EXCITED. And I get to work with them!

While the mobile space is in constant growth + change, I’m working with a team that is moved by the opportunities we get in collaborating with our clients to define their unique approach, from ideation, strategy and content, through design and development. Holy. Moly!

I’ve joined a team that pours everything they’ve got into the quality of a product. A team that genuinely understands the importance and breadth of DESIGN throughout the entire cycle of a product! Thinking BIG and distilling into refined focus.

We are Black Pixel. WE DESIGN THINGS.

When Sofa was acquired by Facebook a few months ago, the decision was made that the Sofa team would retain ownership of their flagship products in order to sell them separately; Facebook acquired an amazingly talented group of people, but they’re in the business of making Facebook. Having already been through the process of taking over a beloved set of apps with NetNewsWire, we approached Dirk and his team to see if Versions and Kaleidoscope would be a good fit with us. Much like NetNewsWire, we’re all users and admirers of Sofa’s work, and the opportunity to be a part of that legacy was too interesting to pass up.

Recently we talked about our growth and our intentions to continue growing. Our design staff has doubled in the last two months, and Black Pixel as a whole is on track to follow suit. We have worked diligently to build our internal products group in anticipation of this announcement: I (Dave) will be leading the product roadmap and design efforts, and we’ve scaled up our existing product team in order to take on these new applications without having to dilute our efforts on NetNewsWire.

We are, of course, still hiring, so if you think you may be a good match for our team, please contact us.

We’ve had some very interesting conversations with Dirk and company in the course of this acquisition, and are working closely with them through the handoff to ensure that current and future customers continue to see the level of care, quality, and service that they’ve come to expect. Sofa has set a very high bar. We intend to meet it.

Versions and Kaleidoscope join the NetNewsWire suite as the Black Pixel family of products. We will love them and care for them as if they were our own, because they are.