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 http://my.pspdfkit.com with your account details. If you don’t yet have an account, request one at firstname.lastname@example.org. You’ll have to add the call to
PSPDFSetLicenseKey() in your app delegate before you call or use any PSPDFKit classes.
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
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
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.
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
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
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
PSPDFAnnotationTypeFromString(). Furthermore, the annotations string name has been simplified from
To create an underline annotation, you can now use
PSPDFUnderlineAnnotation instead of setting a custom
PSPDFHighlightAnnotationType on the
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)
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.
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
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.
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.
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
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.
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
removeAnnotations: and also in the
PSPDFAnnotationManager. Annotations might still use the above soft delete or a real delete; this is decided in the current
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
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.
pdfViewController:willDisplayDocument:delegates were confusing and mostly just a forwarding of
viewWillAppear:. They’ve been replaced by
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
pdfViewController:shouldShowController:embeddedInController:animated:API now offers an additional
pdfViewController:willShowHUD:method was redundant and has been removed. Use
YESto be notified before the HUD shows.