Sketch — Developing an Industry-Standard Design App for the Mac
Table of Contents
About the Author
Alexander Repty is a Mac engineer at Sketch. Sketch is a macOS-native design app featuring excellent tools for vector editing, UI design and collaboration.
When it comes to design apps on the Mac, the simplicity and focus of Sketch made it an industry standard and set an example for countless others. Today, Sketch is a design platform combining the Mac editor, built using native macOS frameworks including its real-time collaboration feature, and a web app.
Our interview with Alexander Repty, Mac engineer at Sketch, goes into the benefits and drawbacks of Apple's frameworks, insights gathered during development, SwiftUI, and more.
New Series: "Developing for the Desktop"
This is part 4 of our new series titled "Developing for the Desktop" — be sure to check out our conversations on Tower, VS Code, Pixelmator and Pitch as well. We speak with the developers of popular desktop applications about their technologies of choice (native or web-based), and the challenges they faced along the way.
Sign up for our newsletter to get notified about the next episode!
About the App
Tell us a little bit about your app: what does it do and when did you start working on it?
Sketch is an industry-leading design platform for the Mac and the web that‘s been around since 2010 and has become the industry standard in fields such as UI design, especially for mobile applications. Personally, I joined the company in March of 2020 to work on the Mac app.
Technologies Being Used
What technologies are you using to develop it?
The Mac application part of Sketch is based on Apple‘s core macOS frameworks: AppKit, Foundation, Core Graphics, Metal and many others. It‘s mainly written in Swift these days, but there are still plenty of Objective-C parts around. Us Mac engineers at Sketch mainly use Xcode for our development work, and we use GitHub for version control and issue management.
Why did you choose those particular technologies?
The world in 2010 was a lot different than it is now: the iPhone SDK was still quite new, there was no sign of SwiftUI on the horizon, and we were still years away from getting a first glimpse of Swift. So the choice in those days was relatively simple — if you wanted to build a Mac app that looked and felt at home on the Mac, you were using Objective-C and AppKit. Of course there were also cross-platform technologies back then, but on the Mac those products never ended up looking and feeling like real Mac apps.
Tell us about the good parts: what’s great about those technologies?
The great thing about AppKit especially is that, for one, it‘s tried and tested. It has a history that spans more than 30 years, starting at NeXT in the late 1980s. And while it has bugs like any other piece of software, it generally really lets you do your job without too much fuss. Most importantly though, using AppKit means you get a ton of behavior for free from the framework, such as accessibility support, keyboard shortcuts and text editing that looks and feels like it does everywhere else on the platform.
Did you encounter any problems or disadvantages connected to those technologies?
The most common downside is probably also related to AppKit‘s age. Because it’s been around for so long, it obviously has some artifacts that you wouldn‘t see in a more modern UI framework, such as the cell paradigm which is completely missing from UIKit. Also, layer-backed views were tacked on at some point during AppKit‘s life and you can see parts of an even older UI framework, Carbon, show through every now and then — when dealing with menus, for example.
In general, Apple is very eager to provide easy-to-use APIs. But sometimes this also means that they’re not quite versatile enough to cover exactly what you need them to do, and using private API is generally not advisable. So occasionally, these APIs can be a limiting factor in what you can and cannot do and you have to get creative to find a solution.
Along the way, was there anything that took you by surprise — any pros / cons, any insights that you hadn’t been aware of when you started?
For me personally, it was interesting to work as part of a team that focused on performance tuning here at Sketch. We set up ways to measure the performance of certain things in Sketch, such as document loading and saving, model changes, rendering etc. and got some interesting insights both about our own code and about the underlying frameworks. While a lot of those were really obvious, some of those discoveries were really unexpected and led me to re-evaluate some of my assumptions about the core frameworks.
How do you see those technologies in a “broader context”, beyond your particular app?
I’ve always held Apple’s frameworks and its general technology stack in high regard, since it’s clear how much thought the team put into everything. Even with a 30-year-old framework such as AppKit, you can see the attention to detail that they continue to put in there, particularly when it comes to things such as accessibility.
Also, Apple isn’t afraid of deprecating things aggressively to keep up a steady pace of improvements. This isn’t universally liked among developers, because it forces us to adapt quickly. But it means that they don’t spend all their time maintaining outdated API just to keep applications alive that haven’t been updated in forever.
Development Tools
What about the development tools that are available? What’s great and what could be better?
I think most Mac developers have a love/hate relationship with Xcode. It’s a constantly evolving product, so things can break easily from one minor version to the next — plus, the need for certificates, code signing and notarisation in general can be infuriating. But all those things considered, Xcode is a tool that tries to get out of your way and let you do your job. It doesn’t always do it right — sometimes it’ll fail to compile for strange reasons or refuse to find the correct certificate for code signing. But all in all, I’m happy that it doesn’t force me to edit countless small configuration files by hand and I can, in most cases, just hit the run button and it’ll do its thing just fine.
One other tool I use a lot is Instruments, and I'm generally impressed by how well it assists me and the scope of support it offers. Especially for a large and complex application such as Sketch, it’s an invaluable tool.
When thinking about the future of those technologies, what do you expect or hope for?
There’s a shift happening right now in the Apple world, and it started in 2019 with the announcement of SwiftUI. I’m writing this before WWDC 2021, so I’m not sure what that edition of the conference will bring, but it's very clear even before that Apple will continue to move in this direction. Which leads me to hope that SwiftUI will continue to mature and integrate really well into the existing macOS ecosystem, so that large applications that are based on older technologies such as Cocoa can make use of these frameworks as well.
Parting Advice
If people want to start developing with those technologies, what should they look at and what advice would you give them?
I think it will still be a while before SwiftUI reaches complete maturity on the same stable basis as AppKit right now, so if someone were to ask me how to start developing Mac apps these days, I would point them to AppKit and Swift. It probably doesn’t make much sense to actually sit down and learn Objective-C anymore, so anyone starting out can just pick up what they do need to know about Objective-C when they come across it somewhere else. I think that this basis would set them up very well for a future with SwiftUI.
As for advice, pay attention to what Apple engineers say at WWDC. When they introduce a new framework, it could foreshadow a major change and you would be wise to adopt it. This happened with Auto Layout — one year after Apple released it, it announced iPhones with vastly different screen sizes. Everyone who was already using Auto Layout had an advantage, while those who were using manual layout had a lot of work to do. Don't fight the frameworks, because that might make your life really hard in the future.
New Series: "Developing for the Desktop"
This is part 4 of our new series titled "Developing for the Desktop" — be sure to check out our conversations on Tower, VS Code, Pixelmator and Pitch as well. We speak with the developers of popular desktop applications about their technologies of choice (native or web-based), and the challenges they faced along the way.
Sign up for our newsletter to get notified about the next episode!