Pixelmator — How A True Mac App Classic Keeps Evolving Using Native Frameworks

About the App

Tell us a little bit about your app: what does it do and when did you start working on it?

The first app we created was Pixelmator, which is a fully Mac-native layer-based image editor released in 2007. That app is still available from the Mac App Store, though it has been superseded by the newer Pixelmator Pro, which was released in 2017. We also have a photo editing app called Pixelmator Photo, which is currently available on iPad, and Pixelmator for iOS, a layer-based image editor for iPad and iPhone. All of our apps are designed to make powerful image and photo editing tools accessible to everyone.

Technologies Being Used

What technologies are you using to develop it?

All our apps are created using native technologies. For Pixelmator Pro on macOS, we use a ton of Apple frameworks, everything from basics like AppKit, to performance-oriented, hardware-accelerated frameworks like Metal, Core ML, Core Image, and Accelerate. Our main programming language is Swift — we were early adopters of Swift back with version 1.0 and, even though we’ve experienced all the growing pains of transitioning through major versions of it, we learned a lot and we got to work with and meet the amazing Swift team at Apple.

Why did you choose those particular technologies?

Being platform-native is key for us at the Pixelmator Team – our identity and products are built on bringing the best native experience and it’s something that we invest a lot in. For developers who focus on being 100 % platform-native, choosing native technologies is pretty much a no-brainer.

Tell us about the good parts: what’s great about those technologies?

The biggest thing is that apps like Pixelmator Pro simply would not be possible without a lot of the foundational technologies provided by Apple frameworks. It’s so much easier to build a consumer product using relevant and accessible UI frameworks on Apple platforms. We depend on Apple frameworks to provide solutions to really tough problems in graphics processing, too. If we need optimized, power-efficient, and precise color management – we can use the Accelerate framework. If we need excellent GPU-based gaussian blur – it’s easy thanks to Core Image. We depend on pretty much every available framework on the macOS platform.

We’re also huge fans of Swift. Pixelmator Classic was created using Objective-C and, comparing that to our Swift-based Pixelmator Pro, we can see that our pace of development is way faster. What’s more, crashes that were common with Objective-C are non-existent in Swift. Optionals are also amazing, making the UI logic of our app much more consistent and avoiding issues that were common in our Objective-C codebase. And by the way, while migrating to Swift, we were forced to migrate to ARC memory management too, which solved a lot of the memory management issues in our legacy non-ARC Objective-C codebase.

Did you encounter any problems or disadvantages connected to those technologies?

The major limitation of choosing native technologies is that we limit ourselves to the Apple ecosystem. This decision limits our market, but it’s a decision that we made early on when founding the company with the purpose of developing native products, and we’re really happy with the current growth of the platform and continued investment by Apple into the graphics ecosystem.

From a development perspective, one challenge is that we have to plan our development schedule around the release cycle of major OS updates. We have to start a very intensive QA cycle with early macOS / iOS betas to spot any regressions that could affect our products. It’s pretty usual for our small team to file tens of bug reports just for regressions. And it’s important for us to report those bugs as soon as we see them, otherwise there’s a possibility that they might slip into the final product. The month or two before major OS releases is probably too late to report issues that affect your product only.

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?

When we started our development of Pixelmator Classic in 2007, we took all Apple frameworks at face value. If it works – great. If it doesn’t or there’s a bug – we need our own solution or a workaround. Over time, we learned the importance of communicating problems and pushing important issues via bug reports, developer technical support, or WWDC labs. Feedback simply needs time to surface and be seen. Most of our issues do not receive any direct feedback, but we see development moving absolutely in the right direction.

How do you see those technologies in a “broader context”, beyond your particular app?

It’s great to see that the macOS development community is really vibrant and keeps redefining and pushing forward the definition of a great Mac app. AppKit is the best it’s ever been since we started in 2007 – there are ever more productivity and creativity apps built with AppKit and that’s always great to see. Recently, with the release of Big Sur and adoption of SwiftUI, we’re also seeing a big wave of experimentation and rapid prototyping for new ideas returning to the platform.

Development Tools

What about the development tools that are available? What’s great and what could be better?

The only tool we use is Xcode and, for the Apple platform, that’s pretty standard. It’s hard to compare with anything else when this is the only tool you’ve ever had, but its biggest strength is that it’s an elegant solution for everything from prototyping and development to testing, profiling, and distribution. There’s no need for additions or alternatives to the current tools that Xcode offers for native development. I also think it’s great that the Apple community cares a lot about the development of Xcode and pushes it in the right direction. As for improvements – there are times when it seems Swift moves very fast and Xcode needs time to catch up with all its additions. But as we have a pretty mature and pretty large Swift codebase, we’re looking for quite boring improvements – faster compile times, better and faster auto completion, and stability improvements. It seems that the Swift and Xcode teams are right on track!

When thinking about the future of those technologies, what do you expect or hope for?

I’m generally super excited about the Swift ecosystem as a whole and where it’s going. Fingers crossed for concurrent programming native to Swift being announced and shipped with the next major Xcode update!

For us, being platform-native means that we’ll gradually be moving from AppKit and adopting SwiftUI for our development. We’ve already shipped a few bits and pieces created with SwiftUI, but I’m really excited to push that forward, changing our current storyboard-oriented approach to programmatic UI development. It’s a major step towards creating the very best native experience because it’s so easy to prototype and develop ideas with SwiftUI.

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 if you’ve decided to start developing for Mac – you’ve made a great decision. With the recent introduction of M1 Macs, native Mac development is in a great place and has a very low barrier to entry. WWDC will hopefully again be remote this year and taking part by watching the keynotes and sessions is a great way to sense where the platform is going. I would recommend waiting for WWDC to get a sense of the direction Apple is heading in and using that to get inspired for your development adventures. There are also many great resources for learning Swift and mastering Apple frameworks. For example, for Swift, you can check out the excellent Hacking with Swift and, for Apple frameworks, the Apple Developer website is an obvious but pretty great place to start.