Design to Development—My process for iOS asset management and handoff
via Sketch & PaintCode
Actively iterating your techniques and processes is paramount as our toolsets continue to evolve. While I continue to tweak, I thought it may be valuable to share my current process for formatting and handing off UI design assets for iOS. I’ve arrived at this process via the 4 apps (1 2 3 4) I’ve worked on over the last 8 months.
Sketch
You know Sketch, you love it or you hate it. Catch me on the right day and I probably agree with you.
Pages are used in Sketch to delineate micro-projects within the app: specific flows or some chunk of functionality. For each Page, we maintain an artboard containing all of our custom drawn graphics (more on this later[1]).
We construct everything at 1x in Sketch with the exception of our App Store screenshots. I’ve experimented a lot with screen densities and I’m confident designing at 1x the best way for us. We design at 1x in Sketch and infinite density in PaintCode.
We store the Sketch files and all other assets (fonts, SVGs, source material, etc.) in an inVision directory sync’d with DropBox.
Sketch Measure
When I designed application interface in Photoshop, I used a few different tools to create specs for development. These tools had various levels of support and cost. Sketch Measure by Jam Mo is the best (and fastest) spec’ing product I’ve used in PS/Sketch and the continued support of the plugin is very impressive... Also it’s free. Cheers to him.
PaintCode
While the documentation feels lacking to me, PaintCode has really become the crucial application for design asset handoff. While it has some pitfalls, it’s a powerful tool that saves us a lot of time and communication.
Not familiar with PaintCode?
PaintCode uses your SVG paths and color data to generate Swift or ObjC classes. With PaintCode you can use expressions, variables, etc. to create passive/active states of your buttons, up/down states, dynamic text, animation from variables, and more. Thanks to the symbol reuse, we reduce the complexity of our design assets dramatically and get the right look every time.
What goes into PaintCode and what doesn’t?
Application Colors—PaintCode’s best feature is probably the organization / naming of colors in your interaction model. This has helped our developers and I quickly create consistent experiences that match our styleguide and UI without wasted time on questions about color, state, etc.
We keep all of our brand colors in PaintCode and dynamically color all of our elements depending on our interaction rules. In the case of FaceParty we use blue very prominently. To change our blue color to red everywhere in the app takes one step when using PaintCode. This is valuable if you’re creating the product from scratch and experimenting with brand/colors/graphics during build. Colors in PaintCode can be used in other parts of the app beyond your graphics allowing you to alter every instance at once.
Assets—We use PaintCode for every graphic we create: no bitmaps are used within our interface. I’ve heard that this can cause performance issues but I’d love to see that better substantiated.
[1] Remember that artboard with all of our custom drawn graphics on it?
- Export the artboard in SVG from Sketch
- Import into a dummy PaintCode file
- Strip out any colors that came over or were replaced by PaintCode
- Copy graphics into your master PaintCode file
- Recolor with proper colors stored in PaintCode
- Begin setting up each graphic on its own canvas—More here:
Hand off
When it comes to handoff, we link the Swift file PaintCode outputs from Dropbox to Xcode. Re-exporting when changes occur is simple.
Layout and multiple devices
PaintCode allows for objects to be instantiated with dynamic sizes, so you can easily scale them to fit all of the screen sizes your apps support. Developers can instantiate PaintCode objects as subclasses of standard iOS objects, and then set their frames just like they would for any UIButton, UILabel, etc., depending on the available screen size. [2]
Swift sample:
class PaintCodeButton: UIButton {
override func drawRect(rect: CGRect) {
PaintCodeStyleKit.drawPaintCodeButton()
}
}let myButton = PaintCodeButton()
myButton.frame = CGRect(x: 0, y: 0, width: 100, height: 50)
It’s great.
While far from perfect, at this moment in time I really love working this way, and our developers do too. We’ve reduced the number of graphics used and overall application size, while dramatically smoothing out the workflow between design and development.
I feel that at this point the real ‘known’ in iOS design handoff is that there’s no ‘right’ way. Please respond to this post with your process/ questions/suggestions and I’ll be happy to discuss and incorporate.
If you found it helpful, please ‘recommend’ to help others discover this article.
[2] Multiple Device Layouts graf & code block contributed by Daniel Tyner-Bryan
You may also like…
