Organising Sketch for iOS
Updated Sketch 3 workflow for iOS development
We have grown up. The app has changed a lot brings us symbols, newly arrived export and even some bitmap editing. The community has expanded dramatically — many tools and companies support Sketch.
I would like to share an update for my previous article covers Sketch 3 new features. You can download preview file and check any topic the same time you read.
- General
- UIKit usage
- Symbols managing
- Export like a boss
General
Use pages in one document
Year ago I used several files plus UIKit to manage long life apps. This technique was helping Sketch to stay fast and responsible. Nowadays I recommend using one document for all screens in view of the fact that Sketch handles a variety of pages more efficiently and the ability to sync symbols across pages is a game-changer.
Frankly speaking, you still can break your app into several documents but just in case you have distinct parts without same symbols.
Flatten images as much as you can
In such a way the size of the document can be reduced up to 80%. It’s better to store uncompressed images in project’s folder because they affect both Sketch’s files size and response speed.
Note, masked container with an image inside it still reduce productivity.
From developers’ perspective there is one more benefit — concise objects hierarchy. Imagine, you want to select an image buried deep inside to measure width and height. If image is not flattened, you hold down the ⌘ key and select image rather than container with sizes you need.
I don’t like locked layers because they can’t be edited fast and still affect the measure guides.
Switch blur layers off
If blur layers don’t seem to be editable later you can hide folder with them and leave a flatten image visible.
Sometimes apps can heavily rely on blur components. You’d better create linked style and switch Background Blur on just before export.
Hierarchy of pages
It should be flexible to adapt for app life circle. If you work in a startup and manage the app for a long period, you should reserve space for future iterations. Pages are the must here.
Freelance app could be handled by a couple of pages.
It should be predictable to navigate through for you and developers. If two screens on a page feel bad and you’re thinking about merging some pages… Envision the way developer will look for screen needed. Most obvious way works best.
For this reason I divide an app into pages based on its structure. If there is a Tab Bar I create at least 5 pages. And some additional for login/registration, onboarding and etc.
Same principle I’d like to follow with Side Menu nevertheless I often merge logically connected pages but reflect this in page’s name.
Design at @1x.
iPhone 6 Plus forced me to start doing it. We want to use the same icons for all iPhones thus points are our choice. Sketch’s performance increased as well.
More about layouts demystified here. But ask your client exact device to start with, support others in case your ideas were approved.
Starting work with UIKit
You can start with default Sketch kit, downloaded kit or create elements from stratch each time you go ahead into wireframing process.
If you want to follow Apple iOS Guidelines you should be aware of reference sizes. Great articles to help you here and here. After a couple of apps you remember proportions of frequently used elements such as Navigation Bar or Tab Bar. Therefore I don’t think UIKit is helpful here.
Predefined kits
But in some cases UIKit can be extremely useful. Finally I assembled some rules for any kit I use:
- contain modals — because a lot of apps require share screens and etc
- contain keyboards — almost every app will ask users to fill in some data (it’s enough to have imaged versions)
- does not contain linked styles or symbols — if you paste groups into from kit they can occasionally replace yours. Or at least it will be outer mess in naming.
- does not contain any artboards — because artboards are shown on iOS device via Sketch Mirror so copy/paste becomes annoying because of display’s switching.
Usually I can’t remember where to find an element and finally create it from scratch. If you have the same problem, I suggest you to merge crucial elements from various kits in one file to speed up your work.
3. Symbol as a brick
Please, note that symbols are changed from Sketch 3.7.
Create your symbol library during wireframing and update symbols to suit your brand later.
I highly recommend not to use linked styles and linked text styles inside symbols. Collaboration will be easier because we know which parts exactly are being changed with pasting.
Symbols to control states
Imagine, you have an input field that has 3 states: normal, filled and disabled. How do I usually create symbols?
- Firstly, I create “input / normal” named symbol and check folder’s name in the Layers List should be “input”.
- Now we copy “input” folder and dublicate symbol. Because of such folder’s name we are suggested to name symbol as “input” too. That can be easily expanded to “input / filled”.
- Repeat for other states.
Having name rather than name with state in Layers List is crucial because it’s quite confusing to have “input / normal” in Layers List and “input / disabled” as a symbol state instead.
Naming in symbols
To save text information after state changing, symbols should have text layers with the same name.
Main text layer of input fields, dropdowns and bars is called “Title”.
For example, in music app I typed names of my favourite songs and artists just ones and was iterating with this content for ages.
Frequently used symbols
Navigation Bar. I create a symbol and assign a name according to its action on the left. Usual states are base, back and close.
Tab Bar. In my implementation Tab Bar is a folder with two symbols and a mask between them. Bottom symbol is “tab bar / base” and it has inactive states, top symbol is “tab bar / active” with selected states. The mask between them enables correct selected state.
4. Export for everyone’s needs
I have some export conventions help me on a daily basis:
- ios app name/artboard name — screens from ios-app-name folder are uploaded into online prototyping tools
- preview/state name — some logic of UI elements have to be in a mockup. Exported to be shared with manager or clients but not for prototyping.
- old/ios app name/artboard name —for unaccepted screens you don’t want to delete now. I also cover such screens with a grey rectangle not to confuse developer.
- backgrounds/name — for some custom backgrounds
- assets/block name/icon name — for icons. Parameter block name is usually nav bar or tab bar and can be omitted.
Containers is a grid system for icons
Tip: stop adding number for dublicated group by chaging Sketch’s Preferences.
Designers should understand which parts of the app are sliced and have an ability to apply changes with no extra developer work.
Firstly, we choose a size of the container to place our icons. The exact values depend on style but if you have chosen 30 X 30 pts container for Navigation Bar, other icons should be fit in it. Then you can choose another container for Tab Bar, suitable for icons in it.
- If developer has to replace an icon he will replace image without code changing.
- Helps to control app visual style — some icons are not symmetric and they seem more organic if moved for a couple of points.
- Container fixes exporting issues, if shape has values with floating points
Slices for icons
I recommend using slices for icons rather than make folders/shapes exportable to reduce connectivity between export and design process.
Normal name of the icon is “name icon”. If it’s ready for export group title is changed for “name : icon”.
- Slices have constant size and do not cut transparent pixels.
- Folder named “share : icon” is easier to read rather than “ios-app-name/assets/nav bar/share”.
- To create @1x…@5x exportable icon and change naming for Android native conventions (@mdpi, @hdpi, @xdpi, @xxdpi, @xxxdp) you have to do a lot of work. But you can create one slice with accessible export options instead and copy it like an ordinary layer. Rename and resize if it’s needed.
If you support iOS 7+ you can export pdf rather than slice pngs. But some apps still support earlier versions of iOS.
Export obviously
Grid layer is not only a container but the way to understand which icons are already exportable. I create a “grid : export” linked style for all containers in my document. While I am doing slicing, grid layers are on this way I see which icons have already been sliced. I switch grid layers off before Artboards export for prototyping tools.
Developers should have an obvious way to understand where to find an icon and its container.
Developer got my file with grid layer switched on. Developer uses the ⌘ key and select a slice layer to measure icon and understand where to find it. Slice on the top prevents developer from choosing shape.
Hide slices to continue design process because ⌘key selects shape again
Export in symbols
You can integrate your export in symbols. Actually I do it on a daily basis. But you should forget about Export button — by pressing it Sketch starts generating previews of all slices you have. And if you have slices in symbols there are many duplicates to be exportable. Some apps had about 300+ slices so Sketch was crashing during the export. But it’s not a limitation because you can export even faster these ways:
- If you have to export all screens to upload or get assets, the best way is to use Sketch Command Line Tool. Just type “sketchtool export slices name-of-file.sketch” and get all slices in the fastest way. Teach your developers this way.
- If you want to export all artboards on the page (uploading new app scenario) you can select them via Sketch Mate plugin and export with button at the botton of the Inspector.
- Some individual slices can be easily exported via button at the botton of the Inspector as well.
Conclusion
This article is not a ultimate truth, it’s just my daily workflow. You can download a preview file to test statements given in the article.
Any workflow changes so find your best, teach developers and work efficiently. Looking forward to getting your feedback. Thanks for all who managed to read to the end☺
