Managing Sketch for iOS Dev

Sketch.app workflow for iOS development

Timur Nurutdinov
7 min readMar 24, 2014

Sketch 3 updated article is here:

Let’s begin

Nowadays there are lots of articles about Sketch and its analysis. And I think we should write more about “Tips and tricks” to share not a feature to use but the workflow to discuss and follow.

I have been designing for iOS with Sketch a lot and want to share my working process and the way we cooperate in a team. I’ve been using Sketch from version 2.1.1 and I don’t think it’s perfect. Sketch still has some gaps I want them be fixed here, but anyway it’s the most awesome tool for iOS development I’ve even tried.

Note that we will be using Symbols. It’s a plugin for Sketch that will create a magic workflow for us. Be sure to know how to use it.

How to wireframe

There is a great article to help you with fonts, colours and icons. But the first question you should ask yourself is do we want to use one .sketch file with a lot of Artboards or just go for separate. For wireframing I use a single Sketch template(similar to this) because:

  • Linking styles will help us to highlight components(we do not use Symbols for wireframing because there is no need to play with shape or content on this stage).
  • Usually we don’t need to share wireframes with developers. You know even Sketch files can become large and I usually prefer not to delete old Artboards to remember why I’ve chosen a particular way to implement a feature.
  • We can use a bit of “inline prototyping” with Sketch Mirror that is based on Artboards.

How does inline prototyping works? If you place your Artboards in the right sequence you can test how user will iterate through your app. The process is simular to playing Lego: prepare bricks and then combine them to give a shape to idea.

If you’ve done wireframing you should export all you screens(Export — Create Slices from Artboards — Export all). Then place exported pngs into the new .sketch file where you can manage the flow of the app. I actually use App-name-Wireframe.sketch and App-name-Sequences.sketch files for this technics. Note, Sketch Mirror goes though the Artboards from bottom to top.

Bricks are on the left, user’s flow is on the right
Sequence you will get in Sketch Mirror

You can configure the flow by placing Artboards in the necessary way. For Artboards’ naming I use numbers-description mask. Numbers represent the type of scenario and description gives assistance to operations with states.

Please, do not try to use Sketch everywhere. This “inline prototyping” matters only during the initial period. If you are day-to-day user of online services you can bravely go for them.

Design

File management and UIKit

I would recommend to divide your design for single .sketch files for each logical part of the app. It means every action takes place on the current screen should be placed into the corresponding parent .sketch. For example, I am working with the list of songs for music player, same file should include “empty” screens, popups, on-click/swipe states, subviews(add song to a playlist), etc.

If you are close to Xcode I will suggest you to think you divide your app for ViewControllers. Every state of its life cycle should be placed in one file to ease navigation for developer. So if developer gets a mockup and there is no “empty” state for a screen he will produce it himself. Will you enjoy it?

My example of the app structure

If you use this way of file management you should prepare yourself for using about 20-30 .sketch files per app. How will we able to live without linking styles? How will we slice icons from such bunch of files? My answer is UIKit and Symbols plugin(for my Macbook Air this plugin crashes while processing large .sketch files, but this workflow easily tricks the limitation).

Bug or feature? Begin the name of Artboard with “../” and it won’t be exported. Very useful if you are a fan of “Create Slices from Artboards”, but have no necessity to cover them all.

UIKit is prepared for syncing with other files

UIKit includes every state for each icon, button, swipe, etc. I suggest you to do slicing from UIKit and let other files operate with “Create Slices from Artboards” only.

Don’t store any images in UIKit to hold it lightweight. All components should be prepared for Symbols (“name : class” mask). So if you’ve changed an element you can copy group to another .sketch file and sync Symbols(“cmd+E” by default).

It’s easy to hold your mockups up-to-date with syncing. One time I had to change the view of table cells. This kind of cells were connected to dozen of .sketch files. It took me a minute for reason that developer can get or update all the icons just with two clicks.

In UIKit it is easier to find layer to export

If we look at the icons’ slicing more deeply we shouldn’t forget about grid(simply group of rectangles). If you have one-level-logic icons build a grid for them and locate every icon in its own rectangle. It will be friendly for us to export and helpful for developer to code.

UIKit is the most obvious way to slice from

Cascade Symbol syncing

I call technics this way because it is the approach to sync your groups from bottom(icons and elements) to top(screens). I would like to explain it by the example of Side menu.

Syncing order

The first column of Artboards is used to tune separate icons. Drop here the icon from UIKit or create a new one. Next sync groups of icons with the second column.

The second column is to prepare a group representing whole side menu. Now we can use it to sync with third and forth.

The third column shows our previews for top and bottom parts of side menu. It’s convenient because they can be exported into pngs for online prototyping tools. It also means that you can work with just one large Artboard(the second column) and then just sync that screen to everywhere.

The forth column can stand for screens with popups. Works with 3,5-inch and 4-icnh screens as well. So we are able to stay up-to-date not only on level of buttons or icons(with syncing from UIKit) but on level of screens across the whole logical part of the app.

Finally, we see that first two columns are our assets and the last two are prepared to export. And we don’t want to frustrate our developer with dozens of supporting files, yes? So it’s time to talk about…

Naming

Don’t you use appropriate names for shapes? If you made use of Symbols plugin you do or have to, but let me start with Artboards. You can use paths for their names to construct folder’s structure during the export. Note the meaning not the form or certain words. My conventions for Artboards are:

  • /main/ is a folder I use to export 4-inch previews from Sketch. You can use /4-inch/ as well.
  • /classic/ is the way I operate with 3,5-inch screens. Design Artboard for 3,5-inch iPhone only if you can show something useful there. Developers don’t need the same image with less height because they will try to find differences, don’t waste their time. And your time!
  • /assets/ is a bin for UIKit slicing: icons, buttons, etc. I don’t recommend you to name it /xcassets/ because developers usually prefer their own way of naming, but try to ask yours.
  • ../temp/ or ../delete/ is the name to have screens determined as for design-and-preview purposes only. Although if Artboards have names starting with two dots they won’t be exported but don’t forget to tell the developer that this Artboard is “read only”(chmod 100).

For basic shapes and groups it’s enough then you haven’t got “Rectangle 3219”. If you want a group to sync follow the *name* : *class-state* mask. Furthermore I would advice you to start the name with “[export]” if the layer or group is going to be sliced.

Finishing tips

  • Replace visible blur layers with exported pngs but store original files in the same group. It will improve speed and sensitivity of the app.
  • Sometimes you want to present various states of an element on one Artboard. Switching group on and off is nice to compare but it breaks the flow. In my opinion it’s better to create a new Artboard(even with png as a background) or put another state into UIKit(for switchers or buttons).
  • Use guides carefully! Guides are not responsible for resizing and moving shapes. It is worth rely on “Arrange — Make Grid” function. But guides can be beneficial to developers! Obtain them just before you share the files.

Summary

I really have fallen in love with Sketch. I am looking forward to see my apps in the App Store(approximately late summer). And this workflow helped me a lot but I am really curious to discover others’. Feel free to share your tips!

--

--

Timur Nurutdinov

Saving the world. Shaping the world. Creating the world.