Sample CodeiOS, iPadOS, Mac CatalystReviewed 2026-07-21View on Apple Developer

PDF Widgets

At a glance

Item	Summary
Purpose	Demonstrates adding widgets—interactive form elements—to a PDF document.
App architecture	A Swift sample with the source-visible chain `AppDelegate` → `ViewController` → `PDFKit APIs`.
Main patterns	View-controller organization, Delegate or data-source callbacks
Project style	2 scanned source file(s) across Swift, organized around ranked entry, type, and file boundaries.

Project structure

Source bundle/
├── PDFAnnotationWidgetsAdvanced/
│   ├── AppDelegate.swift
│   ├── ViewController.swift
│   ├── Base.lproj/
│   │   ├── LaunchScreen.storyboard
│   │   └── Main.storyboard
│   └── Info.plist
├── Configuration/
│   └── SampleCode.xcconfig
└── PDFAnnotationWidgetsAdvanced.xcodeproj/
    ├── .xcodesamplecode.plist
    └── project.pbxproj

Structure observations

Architecturally prominent files are ranked from entry points and role-named declarations; resource-only paths are omitted.
Primary languages: Swift.
The verified tree contains 6 project/configuration file(s) and 2 source declaration(s).

Overall architecture

flowchart LR
    N1["AppDelegate"]
    N2["ViewController"]
    N3["PDFKit APIs"]
    N1 --> N2
    N2 --> N3

Reference code

PDFAnnotationWidgetsAdvanced/AppDelegate.swift:10 — architecture anchor

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
    // ...
}

Interpretation

The arrows summarize the source-visible entry, role-named types or folders, and framework direction; when nodes come from structural folders, the sequence is a high-level interpretation rather than proof that every adjacent node calls the next. Ownership is claimed only where the next section cites a stored property or assignment. The diagram is intentionally limited to the dominant path into PDFKit.

Ownership and state

classDiagram
    AppDelegate o-- UIWindow : window
    ViewController o-- PDFView : pdfView

Ownership evidence

PDFAnnotationWidgetsAdvanced/AppDelegate.swift:13 — stored dependency or nearest verified ownership anchor

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
    // ...
    var window: UIWindow?
    // ...
}

Owner	Object or state	Relationship	Mutation authority
`AppDelegate`	`UIWindow` (`window`)	stores or receives	App/module collaborators
`ViewController`	`PDFView` (`pdfView`)	holds a non-owning reference	The referenced object’s lifecycle is owned elsewhere

Composition arrows indicate a source-visible construction expression or locally owned value state; aggregation means the owner stores or receives a dependency without proving exclusive lifetime ownership.

Class and protocol design

PDFAnnotationWidgetsAdvanced/AppDelegate.swift:11 — representative type boundary

class AppDelegate: UIResponder, UIApplicationDelegate {
    // ...
}

Type	Responsibility	Depends on or conforms to
`AppDelegate`	Receives callback-driven events	`UIResponder`, `UIApplicationDelegate`
`ViewController`	View lifecycle, callbacks, and feature coordination	`UIViewController`

No local protocol conformance is claimed as protocol-oriented design; external framework conformances are listed only as dependencies.

Access control

Symbol	Access	Verified effect	Likely rationale
`AppDelegate` (`PDFAnnotationWidgetsAdvanced/AppDelegate.swift:11`)	`implicit internal`	No explicit modifier means the Swift declaration is internal to the module.	Inference: app-target collaboration needs no exported library surface.
`ViewController` (`PDFAnnotationWidgetsAdvanced/ViewController.swift:28`)	`implicit internal`	No explicit modifier means the Swift declaration is internal to the module.	Inference: app-target collaboration needs no exported library surface.

Reference code

PDFAnnotationWidgetsAdvanced/AppDelegate.swift:11 — representative boundary

class AppDelegate: UIResponder, UIApplicationDelegate {
    // ...
}

Swift declarations without a modifier are internal; explicit private, fileprivate, private(set), public, or open entries above are interpreted by language semantics. Objective-C/C samples instead rely on header and implementation boundaries, which are not equivalent to Swift lexical privacy.

Logic ownership and placement

Logic	Owning type or file	Placement rationale
View lifecycle, callbacks, and feature coordination	`ViewController`	The source’s `Controller` suffix makes this role explicit.
Receives callback-driven events	`AppDelegate`	The source’s `Delegate` suffix makes this role explicit.

Design patterns

Pattern	Source evidence	Purpose or tradeoff
View-controller organization	`PDFAnnotationWidgetsAdvanced/ViewController.swift:28`	A controller is the verified coordination boundary; this is MVC-style only where a separate model is present.
Delegate or data-source callbacks	`PDFAnnotationWidgetsAdvanced/AppDelegate.swift:11`	Callback protocols invert event delivery back into the sample’s owner.

Naming conventions

Types: Controller: ViewController; Delegate: AppDelegate.
Protocols: no local protocol declaration in the scanned source.
Methods: application, insertFormFieldsInto, insertRadioButtonsInto, insertCheckBoxesInto, insertMultilineTextBoxInto, insertResetButtonInto, viewDidLoad.
Files: PDFAnnotationWidgetsAdvanced/AppDelegate.swift, PDFAnnotationWidgetsAdvanced/ViewController.swift.

Architecture takeaways

AppDelegate is the main source-visible entry or composition anchor for this sample.
Framework work reaches UIKit, PDFKit through a deliberately small high-level chain; the detailed API graph remains inside the cited implementation files.
Stored-property evidence identifies lifecycle collaboration; it does not by itself prove exclusive object ownership.
Access-control conclusions separate verified language visibility from the likely design rationale.
The source does not justify labeling the design protocol-oriented.

Source map

Source file	Relevant symbols
`PDFAnnotationWidgetsAdvanced/AppDelegate.swift`	`AppDelegate`
`PDFAnnotationWidgetsAdvanced/ViewController.swift`	`ViewController`

Official Apple documentation