Thanks for the code!
There is quite a bit of discussion (and confusion) about how to initially interact with Realm, and there are significant differences in that operation between a local only and a sync.
There are no current plans to alter the database format so that’s not something to be concerned about. The only significant change was when Realm became MongoDB Realm and the database needed to be changed to support Atlas NoSQL storage.
As far as blocking the background thread Realm is running on, it’s not really a problem - it’s by design, and if the pattern presented in the guide Sync Changes Between Devices - iOS SDK is followed, it’s not an issue. The following code prepares and executes the connection and sync’s the data. It’s all done on a background thread so the UI is not tied up and in the .success block, you know it’s ready to go.
let app = App(id: YOUR_REALM_APP_ID)
// Log in...
let user = app.currentUser
let partitionValue = "some partition value"
var configuration = user!.configuration(partitionValue: partitionValue)
Realm.asyncOpen(configuration: configuration) { result in
switch result {
case .failure(let error):
print("Failed to open realm: \(error.localizedDescription)")
// handle error
case .success(let realm):
print("Successfully opened realm: \(realm)")
// Use realm
}
}
If you are using a local only realm, none of that is needed as there is no synchronization - the data is always present.
I believe this is (finally) in the works (right, Realmers?). FYI and you may know this - Sync’d realms have no migrations. Additive changes are simple and fully supported, just update your object in code and you’re set. Destructive changes require a deletion of local data and re-sync with the server (per the above code). Local only Realms fully support migrations which is laid out in the guide Schema Versions & Migrations
Oh and this…
Realm.asyncInitialise(completion: {result, message in
// Show for a minimum of 1 second or things look messy
let elapsedTime = Date().timeIntervalSince(startTime)
let delay = max(0, 1.0 - elapsedTime)
DispatchQueue.main.asyncAfter(deadline: .now() + delay) {
Generally speaking, attempts to ‘work around’ an asynchronous call usually ends up in weird and intermittent operation. I would advise against that; work with async functions - let them drive the boat and then take action when they are done with their task within their closure. Trying to ‘guess’ at when an async function will complete is like trying to catch a bullet in the dark with a pair of pliers.
A little off topic but I thought I would include this:
During development, where you’re constantly changing object properties, stick with local only realm. It will save you a ton of time and avoids having to stop and restart the Realm server etc. Once you get the objects to a happy place, then implement sync’ing.