Skip to content

3.0.0

Latest

Choose a tag to compare

@github-actions github-actions released this 23 Sep 10:47
· 2 commits to master since this release
0d7d50f

Breaking. This release adds an async/await API, isolates VersionVerifier to the main actor, requires Sendable conformance from custom providers, and fixes a Firebase Remote Config default that silently disabled soft updates. Review the Changed and Fixed sections below before upgrading.

Added

  • Async/await API: VersionVerifier.verifyVersion() async and VersionProviderType.verifyAppVersion() async, with a default implementation bridging to the completion handler API so existing custom providers keep compiling. The completion handler API is unchanged.
  • A Swift Testing test suite and code coverage.
  • DocC documentation catalog and doc comments for the public API.
  • Continuous integration (GitHub Actions, macOS) and SwiftLint/SwiftFormat configuration.

Changed

  • Breaking. VersionProviderType now refines Sendable (and NSObjectProtocol instead of NSObject). Custom conformers must be safe to share across concurrency domains.
  • Breaking. VersionVerifier is now @MainActor isolated and final. Call it from the main actor.
  • Breaking. AppStoreVersionProvider and FirebaseConfigVersionProvider are now final. AppStoreVersionProvider.country is now a let (set it at initialization).
  • Breaking. The update action closure typealiases are now @Sendable.

Removed

  • Removed the unused VersionVerifierError.osIsNoLongerSupported case.

Fixed

  • Fixed a data race in verifyVersion where results from multiple providers were collected without synchronization.
  • Fixed the default SoftUpdateScreenType.animateDissapear(completion:) implementation to invoke its completion. Previously a soft update screen relying on the default with animated: true never dismissed, leaving a stuck overlay.

Behavior changes

  • FirebaseConfigVersionProvider now reads the recommendedVersion key by default. Previously the default initializer incorrectly read requiredVersion for both the recommended and required values, so soft (recommended) updates were never detected with the default configuration.
  • When any provider reports a hard update, it is now always selected as the result, independent of whether a hard update presentation mode is configured. Previously an unconfigured hard update could be skipped and a soft update presented instead. Configure a hard update mode to present it.
  • When multiple soft update capable providers are configured, the first soft update result in the provider order is now used (previously the last one was used).