Hi Richard, could explain how you are using Swift Data and Firebase together?
I just ported one my apps that used Realm (local only) to Swift Data. It works, but Swift Data’s APIs are really old and unergonomic compared to Realm’s.
I don’t know that Swift Data will hold up at scale, either. This app has only a small model, but I need to migrate some apps with tens of millions of records. From previous experience, Core Data doesn’t play too well when the numbers get large and Swift Data is just a modern abstraction over Core Data.
I don’t think I can use firebase to replace Realm. It seems like offline writes are stored in memory so if the app or phone restarts while offline changes are lost.
https://firebase.google.com/docs/database/ios/offline-capabilities
2 Likes
Thanks, @Jay, very helpful!
@Tam_Nguyen1, see this post above:
1 Like
Yea I saw that but when I was reading the firebase docs there were persist / unlimited cache size options so I thought that meant it was writing to disk and offline writes would be reliably saved … guess not
Has anyone tried https://www.instantdb.com/?
We’ve just begun our investigation, but at first glance, Swift Data appears to be functionally similar to Realm Local at the device level. The big plus? It’s maintained by Apple, whereas Realm is about to be maintained by soon-to-be volunteers, many of whom will probably end up working for competitors anyway. As for Firebase, if you’re planning to use it, be ready to build your own syncing layer between local storage and Firebase’s server component. That means setting up listeners to capture updates and transfer them to local storage, along with an action queue to sync the server with the local copy.
You mean we would need to develop a syncing layer because we’re using SwiftData?
Why not use Firestore instead?
My recollection from six years ago was that Firestone’s local cache size was very limited. That may have changed
We have been down this path numerous times.
Firebase is NOT made for local storage. It is an online first database and relying on any data to actually exist at any future point in time locally will not work.
Firebase local persistence is designed to handle brief interruptions in connectivity. For example: if cellular service is interrupted while you’re using the app because the train you are on goes through a tunnel. Or if you have dropout between cell towers. Brief interruptions is what it’s made for.
So, to answer the above question, yes - a syncing layer would need to be created to keep your local object stored in Swift Data sync’d to Firebase (syncing the properties only as there are no objects in Firebase).
Then in-turn means you need to support two totally different database platforms, coordinate relationships between objects (because Firebase has no relationships) and also handle memory management for scaling, then deal with queries - which is somewhat limiting in NoSQL databases without denormalizing your data. But then - Swift Data doesn’t benefit from denormalizing. Etc etc blah blah.
In the end - it isn’t worth it - it makes a LOT more sense to just use Firebase as Firebase - and give up local storage.
Don’t get me wrong, Firebase is an excellent platform but it has to be approached as an online first solution - totally the opposite of Realm (and others).
Agree. It didn’t make sense to me to translate one database into Swift Data’s SQLite store and try to keep that all in sync.
Curious: has anyone tried using the new datasource protocol for Swift Data to swap in something like Firebase or CouchDB as the persistent store but still use Swift Data’s higher-level APIs to access that data in the app?
The protocol was announced at WWDC24 and it is exceptionally poorly documented. There’s one example session where they show it saving to a JSON file, which is useless for all practical purposes.
I’m working on Realm Sync alternative with Realm SDK. I’ll keep you posted.
3 Likes
We created a pre-seeding local cache that allows us to create a truly offline-first experience, even before the app has connected to Firebase. You store the initial data locally (via IndexedDB or SQLite), then sync it to Firebase when the app goes online for the first time. This solution requires careful planning but offers the best of both worlds—offline capabilities from the start and Firebase’s power for online sync and persistence.
1 Like
MongoDB was waisted years. We will never come back! We canceled all our paid clusters, And moved to Google Firebase!
1 Like
So with this change MongoDB as a company is actually telling its customers to use different database and services around it for mobile development, am I reading this correctly?
Imagine Tim Cook pitching Google Cloud on the WWDC. Did the CEO swap places with his kid or something?
1 Like
Yes. It means that Ditto is expensive, low six figures is minimum $100,000 USD/year for sync service
1 Like
From ObjectBox website:
“Terrific job, ObjectBox is marvelous solution, it almost makes data persistance invisible. I was really astonished to see how the code shrunk, in front of my eyes when I replaced realm. I’m still amazed how simple all of it is.”
and…
"
We price based on the business model
e.g. if you are doing a hobby project or are a small startup, you will not need to pay anything unless you scale"
Worth investigating. Thank you!
So if my small startup starts to grow, I won’t know my costs upfront until I specifically enquire for the pricing, is that correct?
And, If it’s too much for me I have to rewrite my app to another solution. Again.
Because I did not know the future costs I might have. This is the dumbest business model you can ever imagine
2 Likes
We price based on the business model
What a horrible pricing model…
1 Like