v10.46.0

Enhancements

• Add a privacy manifest to both frameworks.
• Internal C++ symbols are no longer exported from Realm.framework when installing via CocoaPods, which reduces the size of the binary by ~5%, improves app startup time a little, and eliminates some warnings when linking the framework. This was already the case when using Carthage or a prebuilt framework (PR #8464).
• The baseURL field of AppConfiguration can now be updated, rather than the value being persisted between runs of the application in the metadata storage. (Core #7201)
• Allow in-memory synced Realms. This will allow setting an in-memory identifier on a flexible sync realm.

Fixed

• @Persisted's Encodable implementation did not allow the encoder to customize the encoding of values, which broke things like JSONEncoder's dateEncodingStrategy (#8425).
• Fix running Package.swift on Linux to support tools like Dependabot which need to build the package description but not the package itself (#8458, since v10.40.1).

Breaking Changes

• The schemaVersion field of Realm.Configuration must now always be zero for synchronized Realms. Schema versions are currently not applicable to synchronized Realms and the field was previously not read.

Compatibility

• Realm Studio: 14.0.1 or later.
• APIs are backwards compatible with all previous releases in the 10.x.y series.
• Carthage release for Swift is built with Xcode 15.2.0.
• CocoaPods: 1.10 or later.
• Xcode: 14.2-15.2.0.

Internal

• Upgraded realm-core from 13.25.1 to 13.26.0

v10.45.3

Enhancements

• Update release packaging for Xcode 15.2. Prebuilt binaries for 14.1 and 15.0
  have now been dropped from the release package.

Compatibility

• Realm Studio: 14.0.1 or later.
• APIs are backwards compatible with all previous releases in the 10.x.y series.
• Carthage release for Swift is built with Xcode 15.2.0.
• CocoaPods: 1.10 or later.
• Xcode: 14.2-15.2.0.

v10.45.2

Enhancements

• Greatly improve the performance of creating objects with a very large number
  of pre-existing incoming links. This is primarily relevant to initial sync
  bootstrapping when linking objects happen to be synchronized before the
  target objects they link to (Core #7217, since v10.0.0).

Fixed

• Registering new notifications inside write transactions before actually
  making any changes is now actually allowed. This was supposed to be allowed
  in 10.39.1, but it did not actually work due to some redundant validation.
• SyncSession.ProgressDirection and SyncSession.ProgressMode were missing
  Sendable annotations (PR #8435).
• Realm.Error.subscriptionFailed was reported with the incorrect error
  domain, making it impossible to catch (since v10.42.2, PR #8435).

Compatibility

• Realm Studio: 14.0.1 or later.
• APIs are backwards compatible with all previous releases in the 10.x.y series.
• Carthage release for Swift is built with Xcode 15.1.0.
• CocoaPods: 1.10 or later.
• Xcode: 14.1-15.1.0.

Internal

• Upgraded realm-core from 13.25.0 to 13.25.1

v10.46.0-beta1

Fixed

• Registering new notifications inside write transactions before actually
  making any changes is now actually allowed. This was supposed to be allowed
  in 10.39.1, but it did not actually work due to some redundant validation.
• SyncSession.ProgressDirection and SyncSession.ProgressMode were missing
  Sendable annotations (PR #8435).
• Realm.Error.subscriptionFailed was reported with the incorrect error
  domain, making it impossible to catch (since v10.42.2, PR #8435).

Compatibility

• Realm Studio: 14.0.1 or later.
• APIs are backwards compatible with all previous releases in the 10.x.y series.
• Carthage release for Swift is built with Xcode 15.1.0.
• CocoaPods: 1.10 or later.
• Xcode: 14.1-15.1.0.

v10.45.1

Fixed

• Exceptions thrown while applying the initial download for a sync subscription change terminated the program rather than being reported to the sync error handler (Core #7196 and Core #7197).
• Calling SyncSession.reconnect() while a reconnect after a non-fatal error was pending would result in an assertion failure mentioning "!m_try_again_activation_timer" if another non-fatal error was received (Core #6961).

Compatibility

• Realm Studio: 14.0.1 or later.
• APIs are backwards compatible with all previous releases in the 10.x.y series.
• Carthage release for Swift is built with Xcode 15.1.0.
• CocoaPods: 1.10 or later.
• Xcode: 14.1-15.1.0.

Internal

• Upgraded realm-core from 13.24.1 to 13.25.0

v10.45.0

Enhancements

• Update release packaging for Xcode 15.1.
• Expose waiting for upload/download on SyncSession, which will suspend the current method (or call an asynchronous block) until an upload or download completes for a given sync session, e.g.,:

  try realm.write {
    realm.add(Person())
  }
  try await realm.syncSession?.wait(for: .upload)

  Note that this should not generally be used– sync is eventually consistent and should be used as such. However, there are special cases (notably in testing) where this may be used.
• Sync subscription change notifications are now cancelled if the sync session becomes inactive as is done for upload and download progress handlers. If a fatal sync error occurs it will be reported to the completion handler, and if the user is logged out an "operation cancelled" error will be reported. Non-fatal errors are unchanged (i.e. the sync client internally retries without reporting errors). Previously fatal errors would result in the completion handler never being called. (Core #7073)
• Automatic client reset recovery now preserves the original division of changesets, rather than combining all unsynchronized changes into a single changeset. This will typically improve server-side performance when there are a large number of recovered changes (Core #7161).
• Automatic client reset recovery now does a better job of recovering changes when changesets were downloaded from the server after the unuploaded local changes were committed. If the local Realm happened to be fully up to date with the server prior to the client reset, automatic recovery should now always produce exactly the same state as if no client reset was involved (Core #7161).

Fixed

• Flexible sync subscriptions would sometimes not be sent to the server if they were created while the client was downloading the bootstrap state for a previous subscription change and the bootstrap did not complete successfully. (Core #7077, since v10.21.1)
• Flexible sync subscriptions would sometimes not be sent to the server if an UPLOAD message was sent immediately after the subscription was created. (Core #7076, since v10.43.1)
• Creating or removing flexible sync subscriptions while a client reset with automatic recovery enabled was being processed in the background would occasionally crash with a KeyNotFound exception. (Core #7090, since v10.28.2)
• Automatic client reset recovery would sometimes fail with the error "Invalid schema change (UPLOAD): cannot process AddColumn instruction for non-existent table" when recovering schema changes while made offline. This would only occur if the server is using the recently introduced option to allow breaking schema changes in developer mode. (Core #7042).
• MutableSet<String>.formIntersection() would sometimes cause a use-after-free if asked to intersect a set with itself (since v10.0.0).
• Errors encountered while reapplying local changes for client reset recovery on partition-based sync Realms would result in the client reset attempt not being recorded, possibly resulting in an endless loop of attempting and failing to automatically recover the client reset. Flexible sync and errors from the server after completing the local recovery were handled correctly (Core #7149, since v10.0.0).
• During a client reset with recovery when recovering a move or set operation on a List<Object> or List<AnyRealmValue> that operated on indices that were not also added in the recovery, links to an object which had been deleted by another client while offline would be recreated by the recovering client, but the objects of these links would only have the primary key populated and all other fields would be default values. Now, instead of creating these zombie objects, the lists being recovered skip such deleted links. (Core #7112, since client reset recovery was implemented in v10.25.0).
• During a client reset recovery a Set of links could be missing items, or an exception could be thrown that prevents recovery (e.g. "Requested index 1 calling get() on set 'source.collection' when max is 0") (Core #7112, since client reset recovery was implemented in v10.25.0).
• Calling sort() or distinct() on a MutableSet<Object> that had unresolved links in it (i.e. objects which had been deleted by a different sync client) would produce a Results with duplicate entries.
• Automatic client reset recovery would duplicate insertions in a list when recovering a write which made an unrecoverable change to a list (i.e. modifying or deleting a pre-existing entry), followed by a subscription change, followed by a write which added an entry to the list (Core #7155, since the introduction of automatic client reset recovery for flexible sync).
• Fixed several causes of "decryption failed" exceptions that could happen when opening multiple encrypted Realm files in the same process while using Realms stored on an exFAT file system. (Core #7156, since v1.0.0)
• Fixed deadlock which occurred when accessing the current user from the App from within a callback from the User listener (Core #7183, since v10.42.0)
• Having a class name of length 57 would make client reset crash as a limit of 56 was wrongly enforced (57 is the correct limit) (Core #7176, since v10.0.0)
• Automatic client reset recovery on flexible sync Realms would apply recovered changes in multiple write transactions, releasing the write lock in between. This had several observable negative effects:
  • Other threads reading from the Realm while a client reset was in progress could observe invalid mid-reset state.
  • Other threads could potentially write in the middle of a client reset, resulting in history diverging from the server.
  • The change notifications produced by client resets were not minimal and would report that some things changed which actually didn't.
  • All pending subscriptions were marked as Superseded and then recreating, resulting in anything waiting for subscriptions to complete firing early.
    (Core #7161, since v10.29.0).
• If the very first open of a flexible sync Realm triggered a client reset, the configuration had an initial subscriptions callback, both before and after reset callbacks, and the initial subscription callback began a read transaction without ending it (which is normally going to be the case), opening the frozen Realm for the after reset callback would trigger a BadVersion exception (Core #7161, since v10.29.0).

Compatibility

• Realm Studio: 14.0.1 or later.
• APIs are backwards compatible with all previous releases in the 10.x.y series.
• Carthage release for Swift is built with Xcode 15.1.0.
• CocoaPods: 1.10 or later.
• Xcode: 14.1-15.1.0.

Internal

• Migrated our current CI Pipelines to Xcode Cloud.
• Upgraded realm-core from 13.23.1 to 13.24.1

v10.44.0

Enhancements

• Expose SyncSession.reconnect(), which requests an immediate reconnection if the session is currently disconnected rather than waiting for the normal reconnect delay.
• Update release packaging for Xcode 15.1 beta. visionOS slices are now only included for 15.1 rather than splicing them into the non-beta 15.0 release.

Compatibility

• Realm Studio: 14.0.1 or later.
• APIs are backwards compatible with all previous releases in the 10.x.y series.
• Carthage release for Swift is built with Xcode 15.0.0.
• CocoaPods: 1.10 or later.
• Xcode: 14.1-15.0.0.

v10.43.1

Enhancements

• Empty commits no longer trigger an extra invocation of the sync progress
  handler reporting the exact same information as the previous invocation
  (Core #7031).

Fixed

• Updating subscriptions did not trigger Realm autorefreshes, sometimes
  resulting in Realm.asyncRefresh() hanging until another write was performed by
  something else (Core #7031).

Compatibility

• Realm Studio: 14.0.1 or later.
• APIs are backwards compatible with all previous releases in the 10.x.y series.
• Carthage release for Swift is built with Xcode 15.0.0.
• CocoaPods: 1.10 or later.
• Xcode: 14.1-15.0.0.

Internal

• Upgraded realm-core from 13.22.0 to 13.23.1

v10.43.0

Enhancements

• Added Results.subscribe API for flexible sync. Now you can subscribe and unsubscribe to a flexible sync subscription through an object Result.

  // Named subscription query
  let results = try await realm.objects(Dog.self).where { $0.age > 18 }.subscribe(name: "adults")
  results.unsubscribe()
  
  // Unnamed subscription query
  let results = try await realm.objects(Dog.self).subscribe()
  results.unsubscribe()

  After committing the subscription to the realm's local subscription set, the method will wait for downloads according to the WaitForSyncMode.

  let results = try await realm.objects(Dog.self).where { $0.age > 1 }.subscribe(waitForSync: .always)

  Where .always will always download the latest data for the subscription, .onCreation will do it only the first time the subscription is created, and .never will never wait for the data to be downloaded.

  This API is currently in preview and may be subject to changes in the future.

• Added a new API which allows to remove all the unnamed subscriptions from the subscription set.

  realm.subscriptions.removeAll(unnamedOnly: true)

Fixed

• Build the prebuilt libraries with the classic linker to work around the new linker being broken on iOS <15. When using CocoaPods or SPM, you will need to manually add -Wl,-classic_ld to OTHER_LDFLAGS for your application until Apple fixes the bug.
• Remove the visionOS slice from the Carthage build as it makes Carthage reject the xcframework (#8370).
• Permission errors when creating asymmetric objects were not handled correctly, leading to a crash (Core #6978, since 10.35.0)

Compatibility

• Realm Studio: 14.0.1 or later.
• APIs are backwards compatible with all previous releases in the 10.x.y series.
• Carthage release for Swift is built with Xcode 15.0.0.
• CocoaPods: 1.10 or later.
• Xcode: 14.1-15.0.0.

Internal

• Upgraded realm-core from 13.21.0 to 13.22.0

v10.42.4

Enhancements

• Asymmetric objects are now allowed to link to non-embedded, non-asymmetric objects. (Core #6981)

Fixed

• The Swift package failed to link some required system libraries when building for Catalyst, potentially resulting in linker errors if the application did not pull them in (since v10.40.1)
• Logging into a single user using multiple auth providers created a separate SyncUser per auth provider. This mostly worked, but had some quirks:
  • Sync sessions would not necessarily be associated with the specific SyncUser used to create them. As a result, querying a user for its sessions could give incorrect results, and logging one user out could close the wrong sessions.
  • Removing one of the SyncUsers would delete all local Realm files for all SyncUsers for that user.
  • Deleting the server-side user via one of the SyncUsers left the other SyncUsers in an invalid state.
  • A SyncUser which was originally created via anonymous login and then linked to an identity would still be treated as an anonymous users and removed entirely on logout. (Core #6837, since v10.0.0)
• Reading existing logged-in users on app startup from the sync metadata Realm performed three no-op writes per user on the metadata Realm (Core #6837, since v10.0.0).
• If a user was logged out while an access token refresh was in progress, the refresh completing would mark the user as logged in again and the user would be in an inconsistent state (Core #6837, since v10.0.0).

Compatibility

• Realm Studio: 14.0.1 or later.
• APIs are backwards compatible with all previous releases in the 10.x.y series.
• Carthage release for Swift is built with Xcode 15.0.0.
• CocoaPods: 1.10 or later.
• Xcode: 14.1-15.0.0.

Internal

• Upgraded realm-core from 13.20.1 to 13.21.0
• The schema version of the metadata Realm used to cache logged in users has been bumped. Upgrading is handled automatically, but downgrading from this version to older versions will result in cached logins being discarded.