Releases: realm/realm-swift
v10.52.0
Enhancements
- Add
@ObservedSectionedResults.remove(atOffsets:section:)
which adds the ability to
remove a Realm Object when usingonDelete
onForEach
in a SwiftUIList
. - Add support for Xcode 16 beta 1 and fix some of the new warnings. Note that
this does not yet include full support for Swift 6 language mode
(#8618). Realm.asyncWrite()
andRealm.asyncRefresh()
now use the new#isolation
feature to avoid sendability warnings when building with Xcode 16
(#8618).- Include the originating client reset error message in errors reporting that
automatic client reset handling failed. (Core #7761) - Improve the performance of insertion-heavy write transactions, particularly
when setting a large number of properties on each object created
(Core #7734). - App now trims trailing slashes from the base url rather than producing
confusing 404 errors. (Core #7791).
Fixed
- Deleting a Realm Object used in a
@ObservedSectionedResults
collection inSwiftUI
would cause a crash during the diff on theView
. (#8294, since v10.29.0) - Fix some client resets (such as migrating to flexible sync) potentially
failing if a new client reset condition (such as rolling back a flexible sync
migration) occurred before the first one completed.
(Core #7542, since v10.40.0) - The encryption code no longer behaves differently depending on the system
page size, which should entirely eliminate a recurring source of bugs related
to copying encrypted Realm files between platforms with different page sizes.
One known outstanding bug was (RNET-1141),
where opening files on a system with a larger page size than the writing
system would attempt to read sections of the file which had never been
written to (Core #7698). - There were several complicated scenarios which could result in stale reads
from encrypted files in multiprocess scenarios. These were very difficult to
hit and would typically lead to a crash, either due to an assertion failure
or DecryptionFailure being thrown (Core #7698, since v10.38.0). - Encrypted files have some benign data races where we can memcpy a block of
memory while another thread is writing to a limited range of it. It is
logically impossible to ever read from that range when this happens, but
Thread Sanitizer quite reasonably complains about this. We now perform a
slower operations when running with TSan which avoids this benign race
(Core #7698). Realm.asyncOpen()
on a flexible sync Realm would sometimes fail to wait for
pending subscriptions to complete, resulting in it not actually waiting for
all data to be downloaded. (Core #7720,
since flexible sync was introduced).List<AnyRealmValue>.clear()
would hit an assertion failure when used on a
file originally created by a version of Realm older than v10.49.0.
(Core #7771, since 10.49.0)
Compatibility
- Realm Studio: 15.0.0 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.4.0.
- CocoaPods: 1.10 or later.
- Xcode: 15.1.0-16 beta
Internal
- Upgraded realm-core from v14.9.0 to 14.10.1
v10.51.0
Enhancements
-
Added support for storing nested collections (List and Map not ManagedSet) in a
AnyRealmValue
.class MixedObject: Object { @Persisted var anyValue: AnyRealmValue } // You can build a AnyRealmValue from a Swift's Dictionary. let dictionary: Dictionary<String, AnyRealmValue> = ["key1": .string("hello"), "key2": .bool(false)] // You can build a AnyRealmValue from a Swift's Map // and nest a collection within another collection. let list: Array<AnyRealmValue> = [.int(12), .double(14.17), AnyRealmValue.fromDictionary(dictionary)] let realm = realmWithTestPath() try realm.write { let obj = MixedObject() obj.anyValue = AnyRealmValue.fromArray(list) realm.add(obj) }
-
Added new operators to Swift's Query API for supporting querying nested collections.
realm.objects(MixedObject.self).where { $0.anyValue[0][0][1] == .double(76.54) }
The
.any
operator allows looking up in all keys or indexes.realm.objects(MixedObject.self).where { $0.anyValue["key"].any == .bool(false) }
-
Report the originating error that caused a client reset to occur.
(Core #6154)
Fixed
- Accessing
App.currentUser
from within a notification produced byApp.switchToUser()
(which includes notifications for a newly logged in user) would deadlock.
(Core #7670, since v10.50.0). - Inserting the same link to the same key in a dictionary more than once would incorrectly create
multiple backlinks to the object. This did not appear to cause any crashes later, but would
have affecting explicit backlink count queries and possibly notifications.
(Core #7676, since v10.49.2). - A non-streaming progress notifier would not immediately call its callback after registration.
Instead you would have to wait for a download message to be received to get your first
update - if you were already caught up when you registered the notifier you could end up waiting a
long time for the server to deliver a download that would call/expire your notifier
(Core #7627, since v10.50.0). - After compacting, a file upgrade would be triggered. This could cause loss of data
ifdeleteRealmIfMigrationNeeded
is set to true.
(Core #7747, since v10.49.0).
Compatibility
- Realm Studio: 15.0.0 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.4.0.
- CocoaPods: 1.10 or later.
- Xcode: 15.1.0-15.4.0.
Internal
- Upgraded realm-core from v14.6.2 to 14.9.0
v10.50.1
Enhancements
- Update release packaging for Xcode 15.4.
Fixed
@AutoOpen
and@AsyncOpen
failed to use theinitialSubscriptions
set in
the configuration passed to them (PR #8572, since v10.50.0).App.baseURL
was alwaysnil
(PR #8573, since it was introduced in v10.50.0).
Compatibility
- Realm Studio: 15.0.0 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.4.0.
- CocoaPods: 1.10 or later.
- Xcode: 15.1.0-15.4.0.
v10.50.0
Drop support for Xcode 14, as it can no longer be used to submit app to the app
store. Xcode 15.1 is now the minimum supported version.
Known Issues
- Accessing
App.currentUser
within anApp.subscribe
callback would lead to a deadlock.
Enhancements
- Added
SyncConfiguration.initialSubscriptions
which describes the initial
subscription configuration that was passed when constructing the
SyncConfiguration
. (#8548) - When connecting to multiple server apps, a unique encryption key is used for
each of the metadata Realms rather than sharing one between them
(Core #7552). - Improve perfomance of IN queries and chained OR equality queries for
UUID/ObjectId types. (.Net #3566) - Added support for updating Atlas Device Sync's base url, in case the need to roam between
servers (cloud and/or edge server). This API is private and can only be imported using
@_spi(Private)
(#8486).@_spi(RealmSwiftExperimental) import RealmSwift try await app.updateBaseUrl(to: "https://services.cloud.mongodb.com")
- Enable building RealmSwift as a dynamic framework when installing via SPM, which
lets us supply a privacy manifest. When RealmSwift is built as a static
library you must supply your own manifest, as Xcode does not build static
libraries in a way compatible with xcprivacy embedding. Due to some bugs in
Xcode, this may require manual changes to your project:- Targets must now depend on only Realm or RealmSwift. If you use both the
obj-c and swift API, depending on RealmSwift will let you import Realm.
Trying to directly depend on both will give the error "Swift package
target 'Realm' is linked as a static library by 'App' and 'Realm', but
cannot be built dynamically because there is a package product with the
same name." - To actually build RealmSwift as a dynamic framework, change "Do Not Embed"
to "Embed & Sign" in the "Frameworks, Libraries, and Embedded Content"
section on the General tab of your target's settings.
(#8561).
- Targets must now depend on only Realm or RealmSwift. If you use both the
- The
transferredBytes
andtransferrableBytes
fields onProgress
have been deprecated
in favor ofprogressEstimate
which is a value between 0.0 and 1.0 indicating the estimated
progress toward the upload/download transfer. (#8476)
Fixed
-[RLMUser allSessions]
did not include sessions which were currently
waiting for an access token despite including sessions in other non-active
states. (Core #7300, since v10.0.0).[RLMApp allUsers]
included users which were logged out during the current
run of the app, but not users which had previously been logged out. It now
always includes all logged out users. (Core #7300, since v10.0.0).- Deleting the active user (via
User.delete()
) left the active user
unset rather than selecting another logged-in user as the active user like
logging out and removing users does. (Core #7300, since v10.23.0). - Fixed several issues around copying an encrypted Realm between platforms with
different page sizes (such as between x86_64 and arm64 Apple platforms):- Fixed
Assertion failed: new_size % (1ULL << m_page_shift) == 0
when
opening an encrypted Realm less than 64Mb that was generated on a platform
with a different page size than the current platform.
(Core #7322, since v10.42.0) - Fixed a
DecryptionFailed
exception thrown when opening a small (<4k of
data) Realm generated on a device with a page size of 4k if it was bundled
and opened on a device with a larger page size (since the beginning). - Fixed an issue during a subsequent open of an encrypted Realm for some rare
allocation patterns when the top ref was within ~50 bytes of the end of a
page. This could manifest as a DecryptionFailed exception or as an
assertion:encrypted_file_mapping.hpp:183: Assertion failed: local_ndx < m_page_state.size()
. (Core #7319)
- Fixed
- Schema initialization could hit an assertion failure if the sync client
applied a downloaded changeset while the Realm file was in the process of
being opened (#7041, since v10.15.0). - The reported download progress for flexible sync Realms was incorrect. It is now replaced by a
progress estimate, which is derived by the server based on historical data and other heuristics.
(#8476)
Compatibility
- Realm Studio: 15.0.0 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.3.0.
- CocoaPods: 1.10 or later.
- Xcode: 15.1.0-15.3.0.
Internal
- Upgraded realm-core from v14.5.2 to 14.6.2
v10.49.3
Enhancements
- Enable building RealmSwift as a dynamic framework when installing via SPM, which
lets us supply a privacy manifest. When RealmSwift is built as a static
library you must supply your own manifest, as Xcode does not build static
libraries in a way compatible with xcprivacy embedding. Due to some bugs in
Xcode, this may require manual changes to your project:- Targets must now depend on only Realm or RealmSwift. If you use both the
obj-c and swift API, depending on RealmSwift will let you import Realm.
Trying to directly depend on both will give the error "Swift package
target 'Realm' is linked as a static library by 'App' and 'Realm', but
cannot be built dynamically because there is a package product with the
same name." - To actually build RealmSwift as a dynamic framework, change "Do Not Embed"
to "Embed & Sign" in the "Frameworks, Libraries, and Embedded Content"
section on the General tab of your target's settings.
(#8561).
- Targets must now depend on only Realm or RealmSwift. If you use both the
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.3.0.
- CocoaPods: 1.10 or later.
- Xcode: 14.2-15.3.0.
v10.49.2
Enhancements
- The default base url in
AppConfiguration
has been updated to point toservices.cloud.mongodb.com
. See https://www.mongodb.com/docs/atlas/app-services/domain-migration/ for more information. (#8512)
Fixed
- Fixed a crash that would occur when an http error 401 or 403 is returned upon
opening a watch stream for a MongoDB collection. (#8519) - Fix an assertion failure "m_lock_info && m_lock_info->m_file.get_path() == m_filename" that appears to be related to opening a Realm while the file is in the process of being closed on another thread. (#8507)
- Fixed diverging history due to a bug in the replication code when setting default null values (embedded objects included). (Core #7536)
- Null pointer exception may be triggered when logging out and async commits callbacks not executed. (Core #7434)
AppConfiguration.baseUrl
will now return the default value of the url when not set rather thannil
. (#8512)- Added privacy manifest to Core's Swift package (Swift #8535)
- Fixed crash when integrating removal of already removed dictionary key (Core #7488, since v10.0.0)
Compatibility
- Realm Studio: 15.0.0 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.3.0.
- CocoaPods: 1.10 or later.
- Xcode: 14.2-15.3.0.
Internal
- Upgraded realm-core from 14.4.1 to 14.5.2
v10.49.1
Enhancements
- Improve file compaction performance on arm64 platforms for encrypted files
between 16kB and 4MB in size. (PR #7492).
Fixed
- Opening a Realm with a cached user while offline would fail to retry some
steps of the connection process and instead report a fatal error.
(#7349, since v10.46.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.3.0.
- CocoaPods: 1.10 or later.
- Xcode: 14.2-15.3.0.
Internal
- Upgraded realm-core from v14.3.0 to 14.4.1
v10.49.0
This version introduces a new Realm file format version (v24). Opening existing
Realm files will automatically upgrade the files, making them unable to be
opened by older versions. This upgrade process should typically be very fast
unless you have large Sets of AnyRealmValue, String, or Data, which have to be rewritten.
A backup will automatically be created next to the Realm before performing the
upgrade. Downgrading to older versions of Realm will attempt to automatically
restore the backup, or it will be deleted after three months.
Enhancements
- Storage of Decimal128 properties has been optimised similarly to Int
properties so that the individual values will take up 0 bits (if all nulls),
32 bits, 64 bits or 128 bits depending on what is needed.
(Core #6111) - Improve file compaction performance on arm64 platforms for encrypted files
between 16kB and 4MB in size. (PR #7492).
Fixed
- Sorting on binary Data was done by comparing bytes as signed char rather than
unsigned char, resulting in very strange orders (since sorting on Data was
enabled in v6.0.4) - Sorting on AnyRealmValue did not use a valid total ordering, and certain
combinations of values could result in values not being sorted or potentially
even crashes. The resolution for this will result in some previously-valid
combinations of values of different types being sorted in different orders
than previously (since the introduction of AnyRealmValue in 10.8.0). - RLMSet/MutableSet was inconsistent about if it considered a String and a Data
containing the utf-8 encoded bytes of that String to be equivalent. They are
now always considered distinct. (since the introduction of sets in v10.8.0). - Equality queries on a Mixed property with an index could sometimes return
incorrect results if values of different types happened to have the same hash
code. (Core 6407 since v10.8.0). - Creating more than 8388606 links pointing to a single object would crash.
(Core #6577, since v5.0.0) - A Realm generated on a non-apple ARM 64 device and copied to another platform
(and vice-versa) were non-portable due to a sorting order difference. This
impacts strings or binaries that have their first difference at a non-ascii
character. These items may not be found in a set, or in an indexed column if
the strings had a long common prefix (> 200 characters).
(Core #6670, since 2.0.0 for indexes, and since since the introduction of sets in v10.8.0) - Fix a spurious crash related to opening a Realm on background thread while
the process was in the middle of exiting (Core #7420). - Opening a Realm with a cached user while offline would fail to retry some
steps of the connection process and instead report a fatal error.
(#7349, since v10.46.0)
Breaking Changes
- Drop support for opening pre-v5.0.0 Realm files.
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.3.0.
- CocoaPods: 1.10 or later.
- Xcode: 14.2-15.3.0. Note that we will be dropping support for Xcode 14 when
Apple begins requiring Xcode 15 for app store submissions on April 29.
Internal
- Upgraded realm-core from 13.26.0 to 14.3.0
v10.48.1
Fixed
- The Realm.framework privacy manifest was missing
NSPrivacyAccessedAPICategoryDiskSpace, but we check free disk space before
attempting to automatically back up Realm files (since 10.46.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.3.0.
- CocoaPods: 1.10 or later.
- Xcode: 14.2-15.3.0.
v10.48.0
Enhancements
- Lifted a limitation that would prevent declaring a model with only computed properties. (#8414)
- Add Xcode 15.3 to the release package (PR #8502).
Fixed
- Fix multiple arguments support via the
REALM_EXTRA_BUILD_ARGUMENTS
environment variable inbuild.sh
. (PR #8413). Thanks, @hisaac! - Fix some of the new sendability warnings introduced in Xcode 15.3 (PR #8502).
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.3.0.
- CocoaPods: 1.10 or later.
- Xcode: 14.2-15.3.0.