Life on the iOS team at Nutrient: Building for the long term

Working on the iOS team at Nutrient is pretty different to many other iOS development jobs. I’m our iOS team lead, and in this post I’ll share how we work, the challenges we face, and what’s important to us.

Our products

Our iOS team is responsible for all things native on Apple platforms. We’re much more than mobile — we see more usage on iPad than iPhone, and our products are also available on macOS (using Mac Catalyst) and visionOS. Our iOS team makes two products:

• Nutrient iOS SDK — Originally released by Peter Steinberger in 2011 as PSPDFKit, developers use our SDK to integrate advanced PDF viewing and editing features into their apps. The SDK powers hundreds of popular iOS apps from companies like Dropbox, Box, and Autodesk, and it’s a cornerstone of document handling on iOS and beyond.

• PDF Viewer for iPad, iPhone, Mac, and Apple Vision Pro — Our app was launched in 2016 to showcase our SDK’s capabilities. This product is essentially Nutrient iOS SDK, plus the system document browser (UIDocumentBrowserViewController), so we don’t have a lot of app-specific code. Our app is compiled natively with the Mac Catalyst and visionOS SDKs.

How we work

We’re an experienced team of three iOS developers working fully remotely from India, the United Kingdom, and Austria. With 6, 9, and 10 years of tenure at the company, respectively, we have a great deal of trust in each other and bring deep domain expertise and a collaborative spirit to everything we do. Some of our core ways of working are outlined below.

• One big project at a time — Instead of assigning different people to different projects, we tackle large projects together as a team. This aligns our individual priorities and gives us collective ownership of the outcome.

• Async-first — As a remote team, we prioritise asynchronous communication (using Slack, Jira, GitHub, and Notion) so we each have the flexibility to set our own schedules. For example, if someone wants to take a four-hour lunch break to run some errands or whatever, that’s fine as long as work still gets done. Regular meetings (using Zoom) are kept to a minimum (around two per week on average for engineers), giving us ample focused time for coding and problem-solving. However, we sometimes set up ad hoc calls if that’s the most efficient way to solve a problem.

• Ship regularly — We work in four-week iterations ending in a release. As a result, our releases usually go smoothly, and customers aren’t waiting long for fixes.

We love to share what we’re learning. You can find numerous stories under the iOS tag on our blog.

Building for the long term

Our product and codebase are in their 14th year, with proven demand throughout that time. We want to keep going for a long time to come, so we build for the long term. We continuously maintain and incrementally modernise our codebase. However, as a small team, we need to be pragmatic, so we don’t overhaul code that’s working fine.

We’re quick to update to build using the latest Xcode version so we can use the newest features and adopt the latest APIs and language features where we see value. Each year during the week WWDC takes place, we set aside regular work (except for customer support) to spend time learning and trying out new features from Apple. We use the latest version of Xcode each September, so that we’re ready for Apple’s major operating system updates.

A couple of noteworthy blog posts about using interesting technologies are:

• Generating API documentation for multiple targets with DocC

• Adopting UITextInteraction

We couldn’t use Swift in our SDK until the language achieved module stability in Swift 5.1 in late 2019. Naturally, we were using Swift before that in our app, example code, and tests — but since then, we’ve used Swift for all new code. Right now, our codebase is about 80 percent Objective-C and 20 percent Swift. We certainly prefer Swift, but we’re experts with both languages.

I wrote about a notable problem arising from this mix of old and new:

• NSCopying in a Swift world

We use SwiftUI for most newer UI components, but right now, our greater interest is in refining our framework’s APIs to work seamlessly in our customers’ SwiftUI apps. We’ve found designing the APIs for SwiftUI components to be an exciting challenge. On that topic, as an SDK used in hundreds of apps, we take API design and longevity seriously. Our customers value an SDK that’s easy to use and keep updated.

You can read more in the following posts:

• Creating a customizable toolbar API for SwiftUI

• Customizable UI components on iOS using UIKit

We usually support the three most recent versions of Apple’s operating systems. We find this gives a good balance between satisfying customers who want to support many versions and letting us adopt new APIs relatively quickly while keeping our testing overhead manageable.

Automated tests are essential for maintaining our high-quality standards. Bug fixes are paired with regression tests, and releases are automated using custom tooling for our SDK and fastlane for our app. Meanwhile, our CI pipelines are orchestrated with Buildkite and run on MacStadium machines. If you’re interested in learning more, we have a series of posts on continuous integration for small iOS teams.

Debugging deep dives

There’s a joke that much of iOS development boils down to loading JSON from the network and displaying it in a list. Our work is rarely like this. We regularly tackle technically challenging problems that push the boundaries of Apple’s platforms and lead to some pretty interesting debugging sessions. Here are a few fun debugging adventures we’ve written about:

• Reverse engineering UIKit to fix our top crash — Tracking down an extremely hard-to-reproduce assertion failure inside UIPageViewController with the help of the Hopper disassembler.

• Understanding fast-math — Investigating why some PDF elements were missing when compiling in release configuration due to the rabbit hole that is IEEE floating-point calculations.

• Resolving UITextView flickering issues — Sharing how most successful debugging sessions are backed by similar principles.

• Optimizing annotation drawing performance — PDFs can contain thousands of annotations, and naturally, having a large number can have an impact on performance.

• Investigating a dynamic linking crash with Xcode 16 — We learned some handy environment variable tricks from Apple during a WWDC lab to help hunt down this crash.

Customer-centric development

As iOS developers creating tools for other iOS developers, we can relate to our customers’ needs and pain points. This perspective gives us significant influence over product direction and design. Examples of this include:

• Customer support — To stay connected with real-world use cases, all our developers help our customers directly, using Zendesk, to diagnose and resolve technical issues customers encounter when integrating our SDK.

• Design excellence — We collaborate closely with our Design team, bringing our expertise in Apple platform design expectations to our discussions with them. We believe in using standard system UI components and patterns so that our SDK fits in with as many apps as possible. This also lets us spend engineering effort in more impactful ways. Two iOS design best-practice posts are Open links in Safari, not Safari view controller and Choosing the best way to send emails in an iOS app.

Culture and values

At Nutrient, we’re curious, creative, and collaborative. We emphasise:

• Impact over activity — Our work is optimised for outcomes rather than busywork. Engineers here are empowered to make decisions and take ownership.

• Continuous growth — Feedback and learning are integral to our culture. We encourage open-mindedness and experimentation.

• Diversity and inclusion — Our company represents a variety of cultures and backgrounds, fostering fresh perspectives. We believe in equal opportunity and are especially interested in receiving job applications from people who feel in any way underrepresented in the tech industry.

Every year, we host a company-wide retreat in locations like Prague, Budapest, and Lisbon. These gatherings give us a chance to align on our shared goals — not to mention, they’re just a lot of fun!

What’s next

Over the next year or so, some major items on our product development roadmap are:

• Bringing our AI Assistant to Apple platforms and extending its capabilities.

• Overhauling our UI in stages so users can work more efficiently. We look forward to building better user interfaces with less code by using modern APIs.

• Designing APIs for SwiftUI apps so our UI can be customised more easily.

• Improving performance, especially memory use, for exceedingly complex documents that draw millions of paths. It‘s fact of life that as our devices become more powerful, people will make ever-more complex PDFs to use this power.

Join us

If you’re an iOS developer who thrives on solving complex technical challenges, values collaboration, and wants to build tools that empower other developers, Nutrient could be the perfect place for you. Join us as we shape the future of document technology.