Why Is the PDF Format So Well Supported on Apple Platforms?

The PDF format has been well supported on Apple platforms for a long time, and to better understand why, let’s take a trip down memory lane. Apple has a long history with Adobe, and although the journey has been filled with ups and downs (cough Flash cough), the main theme has always been one of collaboration.

The PostScript Era

PostScript is a page description language that was created at Adobe Systems (which went to market in 1984), and is the forerunner of the PDF file format. PostScript is a full-fledged programming language of its own. The way it works is it allows the creation of a program that could be sent to the printer to be interpreted by a PostScript raster image processor (RIP), thereby producing a final document to be printed. The same program can also be sent to a display system instead of a printer, which enables it to be displayed on a screen.

Apple’s LaserWriter was the first printer to ship with a PostScript interpreter, and this initial collaboration between the two companies would lead to several others down the road.

From Printing to Display

One big reason for the popularity of PostScript was the introduction of GUI programs which would allow designers to directly lay out pages for accurate reproduction in printers. However, earlier GUI programs had a lot of problems, mainly stemming from the fact that PostScript was not designed to be used in an interactive display system.

During this time, Steve Jobs left Apple and started NeXT. To address these shortcomings in preparation for their new line of workstations at NeXT, the engineers at Adobe and NeXT collaborated on a 2D graphics engine system called Display PostScript (DPS). NeXT software has used DPS throughout its history, and since Apple purchased NeXT, it has continued to live on in all of Apple’s operating systems.

Introduction of the PDF File Format

With PostScript and DPS, Adobe already had a way to accurately display and print documents, regardless of the device being used. However, these two solutions had the problem that they required powerful desktop machines and PostScript printers, which made them less accessible. To solve these problems, Adobe co-founder J. Warnock wrote something known as “The Camelot Project,” a paper in which he described a new language called Interchange PostScript. This later came to be known as the Portable Document Format (PDF).

The PDF specification is essentially an optimized and more portable version of the PostScript language. During the development of Mac OS X, Apple had to switch to a new graphics language and wanted one with semantics similar to DPS, since that was used in the NeXTSTEP operating system. PDF became the natural choice since it was fast, it was simple, and it had the exact same model (as it was designed to run on PostScript printers).

PDF and Apple Frameworks

Apple’s Core Graphics framework uses the PDF format for its internal vector graphics presentation. When iOS was created, it inherited Core Graphics and the built-in support for PDFs that came with it. The Core Graphics framework also provides an option to create a PDF context, which records your drawing as PDF commands that can be written to a file. The CGPDF* APIs provide a decent set of functionalities that allow developers to view and create simple PDF documents with relative ease. Starting in iOS 11, Apple introduced PDFKit, a framework that encapsulates PDF-related functionality in a more abstract manner than the low-level CGPDF* APIs.

Limitations and Alternatives

The PDF spec is complicated, and while it might seem like Apple supports it well, this is only partially true. PDFKit works relatively well when used for simple tasks like displaying PDF files, but it lacks advanced features when it comes to PDF creation and editing. Bugs with the rendering engine are also problematic, and since Apple’s PDF renderer is closed source, there are often times when all you can do is file a radar and hope that it gets fixed. The timeline of getting radars fixed is slow, and if your business depends on one specific PDF file that always crashes in PDFKit, you are simply out of luck.

Here at PSPDFKit, we have worked extensively with Apple’s Core Graphics renderer since 2011. It has served us well in the past, but we decided to retire it in favor of our own solution based on Google’s open source PDF rendering engine due to several reasons:

• Control over the complete render stack and the ability to add features more quickly.

• Much faster turnaround times on renderer bugs as opposed to filing a radar. With PDFium, we have the ability to fix obscure bugs — which still come up from time to time — ourselves.

• Consistency in cross-platform rendering.

• Using a solution based on an existing engine that’s been in production for years is great for security. Google Chrome is a large target, and both external security researchers and Google’s own Project Zero team put a lot of time into making sure PDFium is secure.

• Unified testing of core code.

Conclusion

Apple has a rich history of supporting the PDF file format, starting from PostScript printers and ultimately leading to a separate framework specifically for PDF files: PDFKit. However, it also has several problems, as outlined earlier in this article. So, if you’re looking for a robust PDF SDK that comes with advanced features for creating and viewing PDFs, look no further than PSPDFKit. Check out some of the newest feature additions to our SDK in our PSPDFKit 9.3 for iOS release post!