Sample CodemacOSReviewed 2026-07-21View on Apple Developer

Encrypting and Decrypting a Single File

At a glance

Item	Summary
Purpose	Encrypt a single file and save the result to the file system, then decrypt and recreate the original file from the archive file using Apple Encrypted Archive.
App architecture	A Swift sample centered on `AppleEncryptedArchiveDemo`, with direct use of AppleArchive, Cocoa, CryptoKit, System.
Main patterns	No named application pattern supported by the extracted structure
Project style	1 scanned source file(s) across Swift, organized around ranked entry, type, and file boundaries.

Project structure

Source bundle/
├── FileEncryptionDecryption/
│   └── main.swift
├── Configuration/
│   └── SampleCode.xcconfig
└── FileEncryptionDecryption.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 3 project/configuration file(s) and 2 source declaration(s).

Overall architecture

flowchart LR
    N1["AppleEncryptedArchiveDemo"]
    N2["AppleArchive APIs"]
    N1 --> N2

Reference code

FileEncryptionDecryption/main.swift:15 — architecture anchor

struct AppleEncryptedArchiveDemo {
    // ...
}

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 Apple Archive.

Ownership and state

classDiagram
    AppleEncryptedArchiveDemo --> AppleArchiveAPIs : uses

Ownership evidence

FileEncryptionDecryption/main.swift:15 — stored dependency or nearest verified ownership anchor

struct AppleEncryptedArchiveDemo {
    // ...
}

Owner	Object or state	Relationship	Mutation authority
`AppleEncryptedArchiveDemo`	Apple Archive APIs	Uses framework types; no stored lifecycle relationship was detected in the architecture anchor.	The declaring implementation controls calls.

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

FileEncryptionDecryption/main.swift:15 — representative type boundary

struct AppleEncryptedArchiveDemo {
    // ...
}

Type	Responsibility	Depends on or conforms to
`AppleEncryptedArchiveDemo`	Represents a feature value or composable behavior	Concrete collaborators/imported frameworks
`Error`	Represents feature failure conditions	`Swift.Error`

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
`AppleEncryptedArchiveDemo` (`FileEncryptionDecryption/main.swift:15`)	`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

FileEncryptionDecryption/main.swift:15 — representative boundary

struct AppleEncryptedArchiveDemo {
    // ...
}

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
Feature and framework orchestration	`AppleEncryptedArchiveDemo`	The sample keeps the demonstrated path in its primary concrete type.

Design patterns

Pattern	Source evidence	Purpose or tradeoff
No named application pattern	`FileEncryptionDecryption/main.swift:15`	The verified source directly composes concrete framework types; this document avoids forcing a pattern name.

Naming conventions

Types: feature-specific names rather than reusable layer suffixes.
Protocols: no local protocol declaration in the scanned source.
Methods: fileDemo, encryptFile, decryptFile.
Files: feature/project roles rather than a strict one-type-per-file rule.

Architecture takeaways

AppleEncryptedArchiveDemo is the main source-visible entry or composition anchor for this sample.
Framework work reaches AppleArchive, Cocoa, CryptoKit, System 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
`FileEncryptionDecryption/main.swift`	`AppleEncryptedArchiveDemo`, `Error`

Official Apple documentation