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 teamwork to everything we do. Here’s how we work:

• One big project at a time — Instead of splitting up, 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 mostly communicate asynchronously (using Slack, Jira, GitHub, and Notion) so we can 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 the work 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, 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 new features where we see value. Each year during WWDC, we set aside regular work (except customer support) to spend time learning and trying out new features. We also 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 had module stability in Swift 5.1 in late 2019. Before that, we used Swift in our app, example code, and tests, but now all new code is written in Swift. Right now, our codebase is about 80 percent Objective-C and 20 percent Swift. We prefer Swift, but we’re experts in both.

I wrote about a curious 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 these 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 iOS development is mostly about 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 work 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 — With our small teams, we want to have an impact rather than just staying busy. Engineers make decisions and take ownership.

• Continuous growth — We encourage giving feedback, being curious, and trying new things.

• Diversity and inclusion — We come from a variety of cultures and backgrounds, providing a range of 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 have a company retreat in places like Prague, Budapest, and Lisbon. These gatherings are a chance to talk about our bigger ideas and 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 roadmap are:

• Bringing our AI Assistant to Apple platforms and extending its capabilities. Update: Nutrient iOS SDK 14.6 with AI Assistant is out!

• 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 enjoys 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.