v10.54.1
- None.
- The events library would attempt to upload backup files created as part of file format upgrades, causing backup copies of those backups to be made, looping until the maximum file name size was reached (Core #8040, since v10.26.0).
- 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.3.0-16.1 beta.
- Upgraded realm-core from v14.13.0 to 14.13.1
v10.54.0
The minimum supported version of Xcode is now 15.3.
- Build in Swift 6 language mode when using Xcode 16. Libraries build in Swift 6 mode can be consumed by apps built in Swift 5 mode, so this should not have any immediate effects beyond eliminating some warnings and ensuring that all Realm APIs can be used in Swift 6 mode. Some notes about using Realm Swift in Swift 6:
try await Realm(actor: actor)
has been replaced withtry await Realm.open()
to work around isolated parameters not being implemented for initializers (https://github.com/swiftlang/swift/issues/71174). The actor is now automatically inferred and should not be manually passed in.@ThreadSafe
is not usable as a property wrapper on local variables and function arguments in Swift 6 mode. Sendability checking for property wrappers never got implemented due to them being quietly deprecated in favor of macros. It can still be used as a property wrapper for class properties and as a manual wrapper locally, but note that it does not combine well with actor-isolated Realms.- In Swift 6 mode a few mongo client functions have changed from returning
[AnyHashable: Any]
toDocument
. These should have beenDocument
all along, and the old return type no longer compiles due to not being Sendable.
- Some SwiftUI components are now explicitly marked as
@MainActor
. These types were implicitly@MainActor
in Swift 5, but became nonisolated when using Xcode 16 in Swift 5 mode due to the removal of implicit isolation when using property wrappers on member variables. This resulted in some new sendability warnings in Xcode 16 (or errors in Swift 6 mode). - Add Xcode 16 and 16.1 binaries to the release packages.
- Having a query with a number of predicates ORed together may result in a crash on some platforms (strict weak ordering check failing on iphone) (#8028, since v10.50.0)
- 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.3.0-16.1 beta.
- Upgraded realm-core from v14.12.1 to 14.13.0
v20.0.0
The minimum supported version of Xcode is now 15.3.
- Build in Swift 6 language mode when using Xcode 16. Libraries build in Swift 6 mode can be consumed by apps built in Swift 5 mode, so this should not have any immediate effects beyond eliminating some warnings and ensuring that all Realm APIs can be used in Swift 6 mode. Some notes about using Realm Swift in Swift 6:
try await Realm(actor: actor)
has been replaced withtry await Realm.open()
to work around isolated parameters not being implemented for initializers (https://github.com/swiftlang/swift/issues/71174). The actor is now automatically inferred and should not be manually passed in.@ThreadSafe
is not usable as a property wrapper on local variables and function arguments in Swift 6 mode. Sendability checking for property wrappers never got implemented due to them being quietly deprecated in favor of macros. It can still be used as a property wrapper for class properties and as a manual wrapper locally, but note that it does not combine well with actor-isolated Realms.
- Some SwiftUI components are now explicitly marked as
@MainActor
. These types were implicitly@MainActor
in Swift 5, but became nonisolated when using Xcode 16 in Swift 5 mode due to the removal of implicit isolation when using property wrappers on member variables. This resulted in some new sendability warnings in Xcode 16 (or errors in Swift 6 mode). - Add Xcode 16 and 16.1 binaries to the release packages (currently built with beta 6 and beta 1 respectively).
-
All Atlas App Services and Atlas Device Sync functionality has been removed. Users of Atlas Device Sync should pin to v10.
-
Queries on AnyRealmValue properties previously considered strings to be equivalent to Data containing the UTF-8 encoded string. Strings and Data are now considered different types and queries for one of them will not match the other.
-
Realms are no longer autoreleased when initialized. This means that code along the lines of the following will no longer work:
try! Realm().beginWrite() try! Realm().create(MyObject.self, value: ...) try! Realm().commitWrite()
This was a pattern which was somewhat natural with the original version of the objective-c API, but only worked in debug builds and would fail in release builds. We decided to make it consistently work by forcing the Realm to be autoreleased rather than let users write code which appeared to work but was actually broken. In modern Swift this code is very strange, and autoreleasing the Realm made it much more difficult to ensure that the file is actually closed at predictable times.
Realms are now returned retained in both debug and release modes, so this will always break rather than appearing to work. Note that there is still a weak cache of Realms and
Realm()
will still return a reference to the existing Realm if there is one open on the current thread. -
Iterating a Map now produces the tuple
(key: KeyType, value: ValueType)
rather than a very similar struct, and.asKeyValueSequence()
has been removed. This alignsMap
withDictionary
and makes many operations defined bySequence
work onMap
. -
Passing an empty array for notification keypaths to filter on (e.g.
obj.observe(keyPaths: [])
) was treated the same as passingnil
, i.e. no filtering was done. It now instead observes no keypaths. For objects this means it will only report the object being deleted, and for collections it will only report collection-level changes and not changes to the objects inside the collection. -
Decimal128(string:)
was marked asthrows
, but it never actually threw an error and instead returnedNaN
if the string could not be parsed as a decimal128. That behavior was kept and it is no longer marked asthrows
.
- Realm Studio: 15.0.0 or later.
- Carthage release for Swift is built with Xcode 15.4.0.
- CocoaPods: 1.10 or later.
- Xcode: 15.3.0-16.1 beta.
- Upgraded realm-core from v14.12.1 to v20.0.0.
v10.53.1
- Add the file path to the exception thrown by File::rw_lock() when it fails to open the file. (Core #7999)
- Filtering notifications with a LinkingObjects property as the final element could sometimes give wrong results (Core #7530, since v10.11.0)
- Fix a potential crash during process termination when Logger log level is set higher than Info. (Core #7969, since v10.45.0)
- The check for maximum path length was incorrect and lengths between 240 and 250 would fail to use the hashed fallback (Core #8007, since v10.0.0).
- API misuse resulting in an exception being thrown from within a callback would sometimes terminate due to hitting
REALM_UNREACHABLE()
rather than the exception being propagated to the caller (Core #7836).
- 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 5.
- Upgraded realm-core from v14.12.0 to 14.12.1
v10.53.0
- Code sign our published xcframeworks. By Apple's requirements, we should sign our release binaries so Xcode can validate it was signed by the same developer on every new version. (Apple).
- Report sync warnings from the server such as sync being disabled server-side to the sync error handler. (#8020).
- Add support for string comparison queries, which allows building string queries with the following operators (
>
,>=
,<
,<=
). This is a case sensitive lexicographical comparison. (#8008).
-[RLMAsymmetricObject createObject:withValue:]
was marked as having a non-null return value despite always returningnil
(since v10.29.0).- Eliminate several clang static analyzer warnings which did not report actual bugs.
- The async and Future versions of
User.functions
only worked for functions which took exactly one argument, which had to be an array (#8669, since 10.16.0).
- 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 5.
v10.52.3
- Improve performance of bulk object creation when the objects have embedded objects. This is particularly significant for applying sync bootstraps. (Core #7945)
- Client reset cycle detection now checks if the previous recovery attempt was made by the same version of Realm, and if not attempts recovery again (Core #7944).
- App change notifications were being sent too soon when a new user was logged in, resulting in the user's profile being empty if it was read from within the change notification (since v10.51.0).
- A conflict resolution bug related to ArrayErase and Clear instructions could sometimes cause an "Invalid prior_size" exception when synchronizing (Core #7893, since v10.51.0.
- Sync merges which resulted in a changeset's reciprotal transformation being empty were handled incorrectly, possibly resulting in data divergence. No instances of this actually happening have been reported. (Core #7955, since v10.51.0)
Realm.writeCopy()
would sometimes incorrectly throw an exception claiming that there were unuploaded local changes when the source Realm is a synchronized Realm (Core #7966, since v10.7.6).
- 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 5.
- Upgraded realm-core from v14.11.1 to 14.12.0
v10.52.2
- Server-side role and permissions changes no longer require a client reset to update the local Realm. (Core #7440)
- Deleting an object with a
List<AnyRealmValue
proeprty which linked to an object which had been deleted by another sync client would switch to the incorrect cascade mode and perform a cascading delete. This meant that if any subsequent properties in the object linked to another top-level object and that was the only link to that object, the target object would also be recursively deleted as if it was an embedded object. (Core #7828, since v10.51.0). - Fix the assertion failure
array_backlink.cpp:112: Assertion failed: int64_t(value >> 1) == key.value
when removing links to an object (either by reassigning the link or by deleting the object). This could happen if the link came from a collection inside aAnyRealmValue
, anyMap
, or aList<AnyRealmValue>
, and there were more than 256 objects of the type which contained the link. (Core #7594, since v10.8.0) - Fix the assertion failure
array.cpp:319: Array::move() Assertion failed: begin <= end [2, 1]
when deleting objects containing collections nested inside aAnyRealmValue
when this caused bptree leaves to be merged. ()Core #7839, since v10.51.0). SyncSession.wait(for .upload)
was inconsistent in how it handled commits which do no produce any changesets to upload (such as modifying flexible sync subscriptions). Previously if all unuploaded commits had empty changesets and the session had never completed a download it would wait for download completion, and otherwise it would complete immediate. It now always completes immediately. (Core #7796).- The sync client could hit an assertion failure if a session is resumed while the session is being suspended. (Core #7860, since v10.27.0)
- If a sync session was interrupted by a disconnect or restart while downloading a bootstrap (a set of downloads caused by adding or changing a query subscription), stale data from the previous bootstrap could be included when the session reconnected and completed downloading the bootstrap. This could lead to objects stored in the database that do not match the actual state of the server and potentially leading to compensating writes. (Core #7827, since v10.27.0)
- Fixed unnecessary server roundtrips when there was no download to acknowledge (Core #2129, since v10.51.0).
- 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 3.
- Upgraded realm-core from v14.10.2 to 14.11.0
v10.52.1
- Realm compaction (triggered by setting
shouldCompactOnLaunch
) on an encrypted Realm file could produce an invalid file unless the encryption key happened to be a valid nul-terminated string. (Core #7842, since v10.52.0. - Assigning a List or Dictionary to an AnyRealmValue property which already stored that type of collection would only emit a clear instruction if the collection was not already empty. This meant that assigning to the property on two different clients would merge the collections if the property initially stored an empty collection, but would pick one of the two assignments to win if it was initially non-empty. If merging is the desired behavior, appending to the List rather than assigning a new List will still achieve that (Core #7809, since v10.51.0).
- 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.
- Upgraded realm-core from v14.10.1 to 14.10.2
v10.52.0
- 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).
- 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)
- 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
- Upgraded realm-core from v14.9.0 to 14.10.1
v10.51.0
-
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)
- 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 if
deleteRealmIfMigrationNeeded
is set to true. (Core #7747, since v10.49.0).
- 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.
- Upgraded realm-core from v14.6.2 to 14.9.0