PSPDFKit 3 Migration Guide

PSPDFKit 3.0.0 for iOS is the forthcoming major release of PSPDFKit, an extensive PDF displaying and editing framework for iOS. As a major release, 3.0 introduces several API-breaking changes and new architecture.

This guide is a starting point to ease the transition to PSPDFKit 3.0 for iOS.


PSPDFKit 3 for iOS requires iOS 6 and Xcode 5.x.

Starting with PSPDFKit 3.3, we require Xcode 5, and we no longer support compilation with legacy mode.

New Licensing Model

PSPDFKit 3 now requires a serial number to unlock its features. Log in at with your account details. If you don’t yet have an account, request one at You’ll have to add the call to PSPDFSetLicenseKey() in your app delegate before you call or use any PSPDFKit classes.

Project Settings

PSPDFKit 3 requires several new frameworks. If you use PSPDFKit.xcconfig, you’re all set, unless you manually changed the Other Linker Flags setting in your project. Either merge the settings, remove yours, or manually add the required frameworks (you’ll find all the details if you open the PSPDFKit.xcconfig file).

API Changes

Several API methods, enums, and constants have been renamed to improve clarity in the API. Most constants are now named like PSPDFObjectsGlyphs; previously, in PSPDFKit 2 for iOS, they were named inconsistently and mostly had a style like kPSPDFObjectsGlyphs. In general, a look at the header should help you find the new matching API quickly. Several methods also have additional parameters and no simple counterpart to keep the API clean. For example, the dismissAnimated: method in PSPDFBarButtonItem has been extended to dismissAnimated:completion:.


Several classes have been renamed. All PSPDFAction*** classes now are named PSPDF***Action to better reflect their types.


All deprecated methods in PSPDFKit 2 for iOS have been removed. PSPDFKit 3 for iOS doesn’t feature deprecated methods, so for deeper integrations, you’ll need to invest some time up front to upgrade your codebase.

Class Overriding

Direct access to overrideClassNames has been removed. Use overrideClass:withClass: to register your subclasses. Remember that all view/controller-related classes need to be registered in PSPDFConfiguration, while model classes are in PSPDFDocument.

New Annotation Toolbar

The annotation bar has been completely redesigned. Several subclassing hooks have been changed as well to reflect this. PSPDFKit 3 for iOS also has several new annotation tools that you might want to enable if you manually set the contents of the editableAnnotationTypes dictionary in PSPDFDocument. Notable additions are the PSPDFAnnotationStringEraser and PSPDFAnnotationStringSelectionTool instruments.

The Annotation Data Model

In PSPDFKit 2 for iOS, several annotation types were groups for multiple annotations. This has been simplified. Starting with PSPDFKit 3 for iOS, each annotation type string corresponds to exactly one annotation type. You can convert between these two representations via PSPDFStringFromAnnotationType() and PSPDFAnnotationTypeFromString(). Furthermore, the annotations string name has been simplified from PSPDFAnnotationTypeString*** to PSPDFAnnotationString***. To create an underline annotation, you can now use PSPDFUnderlineAnnotation instead of setting a custom PSPDFHighlightAnnotationType on the PSPDFHighlightAnnotation.


Previously, saveChangedAnnotationsWithError: was only allowed to be called on the main thread, took a lot of time, and afterward destroyed the current documentProviders. Then annotations were parsed again. This process has been greatly optimized and streamlined. PSPDFKit 3 for iOS can now deal with saving in the background and can correctly update the current annotation set without the need to reparse. There’s a new asynchronous API for saving — saveAnnotationsWithCompletionBlock: — and the synchronous API has been renamed to saveAnnotationsWithError:, since depending on the set of annotationProviders, save might save all annotations and not just the changed ones.

The External Annotation Data Model (NSCoder)

The NSCoder data model for saving annotations has been radically changed. To support archives that have been saved with v2, you need to call PSPDFAnnotationSupportLegacyFormat() with the NSKeyedUnarchiver as an argument and afterward process the unarchived annotations with PSPDFPostprocessAnnotationInLegacyFormat() to convert them to the v3 format.

JSON Serialization

There’s no direct support to parse the v2 JSON format in v3 — you need to write your own converter if this is required. In v3, you can create JSON using the PSPDFJSONAdapter class and by calling JSONDictionaryFromModel:. PSPDFAnnotation now also has a factory method that converts the JSON to the correct types via the static + annotationFromJSONDictionary:document:error: method. The document parameter is only required if you have subclasses defined that should be used in place of the default annotation types.

XFDF Support

PSPDFKit now supports the Adobe XFDF 3.0 spec, which can be read in Adobe Acrobat and other frameworks that support XFDF. This is your new preferred way to send data to a server, since it’s standardized XML. This is compared to the proprietary way of encoding annotation data that’s used in NSCoder and JSON serialization. There’s also a PSPDFXFDFAnnotationProvider for your convenience, which takes a fileURL to load/save but can be used as a template to build your web-based version for sending/receiving XFDF.

Value Transformers

JSON serialization uses various value transformers to convert things — for example, enums — into more a useful representation (strings). The NSValueTransformer subclasses have been directly exposed in v2. In PSPDFKit 3 for iOS, we use the more appropriate way of only exposing the name (like PSPDFLinesTransformerName). You can fetch the subclasses from the global registry of the NSValueTransformer class with valueTransformerForName:.

Change Notifications

In PSPDFKit 2 for iOS, it was necessary to call copyAndDeleteOriginalIfNeeded for changing annotations and to send a PSPDFAnnotationChangeNotificationOriginalAnnotationKey. This was the reason for lots of subtle bugs and unnecessary complexity, and it’s been removed in v3. You still need to send change notifications (PSPDFAnnotationChangedNotification), but it’s no longer necessary to create a copy of the annotation.

Deleting Annotations

In v2, the only way to delete annotations was setting deleted = YES on the annotation object. Starting with v3, there’s an API for this, both in PSPDFDocument removeAnnotations: and also in the PSPDFAnnotationManager. Annotations might still use the above soft delete or a real delete; this is decided in the current PSPDFAnnotationProvider implementation.


Annotation providers now have to deal with annotation deletion, and the API has been changed in several other ways. Study the new protocol header for details.


PSPDFAnnotationParser has been renamed to PSPDFAnnotationManager to better reflect what it actually does (collecting annotations and managing annotation providers). Accessor methods have been changed from annotationParser and annotationParserForPage: to annotationManagerForPage:.

Document Sharing

The methods to send a document via email or use the Open In… feature have been unified. Both have lost their custom configuration methods and were replaced with the new PSPDFDocumentSharingController, which features a simpler and more flexible way of selecting flattening/annotations and the page range.


  • The pdfViewController:willDisplayDocument: delegates were confusing and mostly just a forwarding of viewWillAppear:. They’ve been replaced by pdfViewController:shouldChangeDocument: and pdfViewController:didChangeDocument:.

  • APIs that had one annotation as an argument have been replaced with NSArray*, since v3 now supports selecting multiple annotations at once. For example, pdfViewController:didSelectAnnotation:onPageView: is now called pdfViewController:didSelectAnnotations:onPageView: and sends an NSArray* instead of a single PSPDFAnnotation*.

  • The pdfViewController:shouldShowController:embeddedInController:animated: API now offers an additional options: argument.

  • The pdfViewController:willShowHUD: method was redundant and has been removed. Use pdfViewController:shouldShowHUD and return YES to be notified before the HUD shows.