A First Project With PaintCode

& The Story of Look Up’s Arrow

Ben Watanabe

Published in

6 min readMar 10, 2015

- Intro -

This is just an intro, if you want to just jump into things…

Part 1:
Sketching Symbols for PaintCode
Keep Creating Where Comfortable

Part 2:
Animating The Arrow
Creating A Progress Bar

Part 3:
Buttons & Basic Variables
Creating Multi-State Buttons

You’ve likely heard of PaintCode before. The moment you first heard about it was exciting. You might have anxiously downloaded it on the app store or bought it through a MacHeist bundle.

What happened from there..?

If you’re like me, the excitement may have gradually become confusion. Not due to the interface or the functionality, PaintCode is easy to navigate and anything but bloated. PaintCode’s documentation is also complete, filled with great video and images illustrating the functionality. @PixelCutCompany also is also quick to reply to specific questions. At times, they even go above and beyond offering to help with a hands on fix.

What was confusing though was how to integrate PaintCode into a first project. That first project was mid-development on my first attempt, so much of the confusion was likely self-inflicted. Still the team eventually put PaintCode to the side and exporting multiple images and writing code started back up.

To be precise, they went back to writing code, there was no way I could. I went back to sketching with a pencil and mouse.

The point when a design is handed off to developers can be both technically and emotionally exhausting. As the team’s designer I was confused about where PaintCode would come into play in the my process. The team iOS developers were confused where exactly they would pick up from.

A few months later, a new app was beginning development in the morning at Starbucks. PaintCode 2 had also recently released. With the start of a small team of two made up of just one developer (Johnny) and one designer (me/Ben), it was time to give PaintCode a proper chance to prove itself on a fresh canvas.

Sidenote: I’m often asked what the advantage of PaintCode is since now PDF’s can be used for image assets. With the introduction of PaintCode 2 variables, expressions, smart symbols, dynamic shapes, and frames can now be created.

We added PaintCode into our design and development flow transforming the last two steps from:

3. Deciding how to slice assets.

4. Back and forth for changes in design and pushing pixels

to…

3. Designing/importing elements into PaintCode

4. Re-exporting the style kit, when a shadow just had to go.

This was great as a designer because:

Increased my value within the development process. If I were seeking a new job or team to collaborate with my ability to deliver actual code would be attractive.
It gave control, and got rid of the hesitancy to improve on a design for fear of interrupting development. Changing the color scheme or decreasing a shadow was now just a click away.
It opened up new possibilities, like the arrow animation that is covered in part 2. When I first told Johnny about how it would work he got pretty hesitant. After having made it in PaintCode I can completely understand why. Without PaintCode it would have been nearly impossible. Even with PaintCode and the person with the exact vision of how it works executing it still took a long time.

And it was exciting to Johnny because:

It reduced interruptions in attempting to make things pixel perfect.
A greater definition of his role and the ability to focus on it.
Smaller download size being a benefit, especially for iOS apps that want to be downloaded over the cellular network.

The biggest benefit of PaintCode has been the increased understanding between designer and developer.

One way that understanding is developed is the way that the transition from mock-up images to an operating app is broken down. Often that process is like going from a sleek concept car to the production car. Before PaintCode often the developer was forced to be the bad cop, having to pull out flashy features at times. With PaintCode the designer is now in charge of a new check-point between concept designs and production code.

A simple example of this is the 20 Minute Goal label that appears at the end of a rest and how it evolved during the transition from being designed in Sketch to PaintCode.

In Sketch when I’m dreaming it’s not a big deal to convert text to vectors to achieve transparent text. When the same element was created in PaintCode I’m brought back down to earth. I’m forced to realize that a string variable will need access to that text, so it’s localizable. In PaintCode this is realized because I’m the one that is setting parameters for elements. If it remains vectorized text then it’s only localizable through multiple images.

Now I’m the one deciding how to tone it back, and can’t blame “those people” for it. I cut the corner, tying the text’s color to a variable. This way the texts color can be dynamically set to a similar color to the background, giving the illusion of transparency.

Okay, maybe I shouldn’t be shining a light on my design shortsightedness and a less than perfect part of Look Up publicly in this post. With hindsight it’s clear I should have realized the mistake while in Sketch. There are other more subtle examples where PaintCode made clear why a concept might not work at production. To be clear, this wasn’t due to PaintCode lacking capability, but just the reality of what’s possible in a dynamic app. PaintCode increased my (the designers) understanding of what goes into production, while also improving designer-developer relations. No longer did Johnny have to put up with passive aggressive slights when cutting out or toning down a naive concept.

Now it’s time for the Story of Look Up’s Arrow. We’ll cover how the Arrow evolved through PaintCode and it’s many iterations thoughout Look Up. We’ll also cover a few bonus sections where the arrow isn’t, but you will still probably want to be pointed to ☺

Since the above example of the 20 minute goal text and the arrow aren’t directly applicable to most apps, this won’t be a step-by-step tutorial. We’ll discuss the general tips, tricks, and mistakes to avoid that we learned during a first project with PaintCode. These will be broken down into sections like…

Where It’s Used:

Explaining how the arrow was used inside of Look Up and what part(s) of it will be the focus of the section.

The Big Picture:

This is the common points in developing the arrow that would be applicable even if you’re not creating an arrow, since we hope you’re not just copying Look Up.

Implementing Into Xcode:

Johnny will take over at this point, giving code snippets that can be adapted for other projects, and talking about the implementation methods necessary to get the most out of PaintCode.

Detailed Detail Breakdowns:

This will be the in depth part, getting as close to a tutorial as these posts will get. In the more intricate sections breaking down the steps, discussing edge cases, and more.

Covered over a series of posts: