Framework and module issues release checklist

Inventory dependency surfaces

List Swift packages, binary frameworks, XCFrameworks, CocoaPods, local modules, plugins, SDKs, and generated code. Mark which targets use each dependency: main app, extensions, widgets, App Clips, watchOS, or tests.

A dependency can pass local debug builds and still fail release archive, signing, module stability, or runtime loading.

Run release checks

• Archive with the same configuration used for App Store submission.
• Build on CI or Xcode Cloud, not only one developer machine.
• Test device runtime paths that load the framework.
• Check signing, architectures, module interfaces, and excluded platforms.
• Record SDK versions and update reasons.

Connect dependencies to user risk

A framework issue in login, purchase, analytics, ads, or crash reporting affects more than build hygiene. It can change reviewability, privacy labels, and revenue operations.

AppReviewReady interpretation: dependency governance is part of App Review readiness when dependencies touch sensitive surfaces.

Plan rollback before updating

1. Pin the current known-good version.
2. Read release notes for privacy, entitlement, or API behavior changes.
3. Run archive and runtime tests after update.
4. Verify App Store metadata and privacy disclosures still match.
5. Keep rollback instructions for urgent release fixes.

Dependency provenance ledger

The ledger helps teams distinguish safe dependency maintenance from release-risky changes.

After launch, review crashes and hangs by dependency update. A new SDK can explain quality and conversion changes even when product code barely moved.

Treat binary dependencies as product inputs, not just build inputs. If a framework handles login, purchases, ads, attribution, maps, notifications, or privacy-sensitive processing, an update can require new testing, privacy review, support copy, and App Review explanation.

For urgent fixes, prefer the smallest dependency movement that solves the problem. Jumping multiple major versions during a release incident can change compiler behavior, runtime assumptions, and data collection at the same time, making review and rollback harder.

Record why each dependency is present. Teams often discover unused analytics, social login, payment, or media SDKs only when archive errors, privacy questions, or review issues appear. Removing an unused dependency can be safer than repeatedly patching it.

Check extension and secondary targets separately. A framework that works in the main app can fail inside a widget, notification extension, share extension, App Clip, or watch target because of platform support, size limits, or entitlement differences.

When a dependency fix changes compiler settings or minimum deployment assumptions, verify the oldest supported OS and device class explicitly. App Review can exercise supported configurations that the team no longer uses daily.

Dependency record:
Name/version: [value]
Targets: [list]
Sensitive surface: [none/list]
Archive tested: [yes/no]
CI tested: [yes/no]
Runtime path: [workflow]
Rollback: [version]