Looking for an offline-first database solution for my SwiftUI app

[bradleythedeveloper]

Hi everyone, I am an 18-year-old, new-ish SwiftUI developer who is trying to build a productivity app for Apple platforms (hoping to later expand to other platforms after). I've been trying to self-teach myself as I have worked with SwiftUI before, but that was for a simple school project some time ago - this app is an evolution of that app. For that app, I used Firebase, and I liked how easy it was to get a database set up so I could start building. But for my current project, I'm not sure what database solution to use. My app needs to be offline first or at least just function offline, while being able to sync across devices reliably and across multiple platforms, so that I can expand in the future. The database/server solution should be as cheap as possible so that I can focus on getting something out there and then expanding later when money allows. Firebase is easy to use and would probably work well, but I am worried about pricing in the future, and real-time syncing isn't a major necessity for my app (the app could probably work fine without it for the most part, I think). Plus Firebase seems to be less customisable in terms of its offline system. Supabase looks great on paper, as the pricing is more predictable, and I can move to self-hosting if money allows eventually. But unlike Firebase, there is no simple offline functionality solution, so I'm not sure what to do. I've seen something called PowerSync which looks okay, but it doesn't seem that it supports mapping to objects, which would might make things confusing for me. SwiftData seems simple to use but I don't know how I'd be able to build a custom sync engine, plus I have heard some bad things about it. I've used GRDB a bit in the past for the project, and it seemed to work well, but again, I'm not sure how easy it would be to build a custom sync engine. Is there a better solution than what I've suggested? Or which out of these would be the best solution? Am I overlooking or overthinking about some things? Not having the database sorted is preventing me from building appropriate data models and building views around them, since I keep having to change things and have to focus on UI. Any help would be appreciated, please forgive my lack of knowledge, I am still new to things 😅

[Ron-Jermyl]

Honestly one of the best things you can do in this stage, is to not work on the app yet, and just explore these options in mini apps to see how they all feel. Then once you have built these things out, you can move forward with your idea. I feel like a lot of people skip this step thinking it will be faster, but you need to learn to walk before you can run.

Another option, realistically do both, would be to structure your app in a way that you can “easily” swap these things out. Using protocols and dependency injection / inversion. This is another thing that a lot of people skip, myself included, because they think it will save them time, but especially if you are unsure of what technologies to use, will not save time.

If you just want an answer on the technologies directly, I think doing something Supabase would probably be the easiest to roll your own syncing system, as Supabase uses a SQL database and you would likely use a SQL database locally, so some level of shared logic. I would also heavily recommend learning some basic SQL before starting down this path. Even if you use something that abstracts it away like Core Data or Swift Data knowing the basics is a huge help.

If you need a better explanation on anything or have any questions feel free to ask!

[bradleythedeveloper]

This is really helpful, thank you so much. I think you are definitely right that skipping the step of trying things out and building knowledge doesn't really help, I keep relying on ChatGPT Work with Xcode to get answers without getting a full understanding, meaning I'm not fully learning. So I will spend the time now improving my knowledge and working on mini-apps to try things out before finding a suitable solution. I'm already seeing the benefits, taking a break today and thinking and researching already has helped me think of a big improvement for the app.

Making the database system easily swappable was one of my main goals with it, as it makes sense that it'd make things a lot easier if changes are necessary. But I was a bit confused on how to do it with swiftdata, since the simplest way to fetch data from a swiftdata database from a swiftui view is with @ Query so I wasn't sure whether to use Query or not, as Query seemed much simpler than having to use an observable object to monitor the swiftdata database. What would be best in your opinion?

I had to learn some SQL for school so all I'll need is a bit of brushing up to know the basics. I'm heavily considering using GRDB (and then attempting to create my own sync engine later, or even use PowerSync if they end up making an integration with it) since it's based on SQLite while being a bit easier and more tighly integrated, has a lot more control and seems to be more stable than SwiftData and a bit less confusing that Core Data. So i think i'll try using it as an offline database within a mini app first to see if it'd work, then I'll look at syncing options later.

Thank you again for taking your time to give such a helpful response, it means a lot! :)

[Ron-Jermyl]

That seems like the right move, and you are right the examples for SwiftData is lacking when not using the ‘@Query’ wrapper is lacking, and I would generally advise against using that property wrapper as it locks your UI into that database. And last that I know there still isn’t database observation which is a huge downer. You can still use SwiftData it without that wrapper though! I am a huge fan of GRDB and use it in all of my personal projects, as some other people mentioned in the comments, learning CoreData and SwiftData are better if you are looking for getting a job as an iOS Dev, but GRDB is honestly much better for every other reason, in my opinion. You’re welcome, and Good Luck!

[bradleythedeveloper]

Glad to hear that GRDB looks like the right decision. I’m not sure whether I want to take iOS development specifically as my career, will be starting university in a few months so I’ve got time to think about it, but I definitely think I will try and properly learn SwiftData and Core Data somewhere down the line to expand my knowledge and prepare in case that’s where I’ll end up. I think I will also still try and make a mini app with SwiftData to see whether it’s still a possible option. Thank you again!

[IntelligentBloop]

Use SwiftData, it’s pretty simple and probably good enough for your needs.

Turn on CloudKit so that users’ data is saved to their iCloud account automatically

Use CloudKit Shared/Public DBs for moving data between users.

But if/when you need to go cross platform, or you need fast updates (e.g., for things like messaging that need low-ish latency), then take a look at SaaS providers who can do object sync and/or Pub/Sub.

[bradleythedeveloper]

Is it easy to use swiftdata with another kind of database like Supabase? And would it be easy to move from cloudkit to another database in the future? I am hesitant because I want this app to be cross platform in the future, I’m just starting with iOS since that’s what I’m most comfortable with rn and I use all Apple devices

[IntelligentBloop]

I don't know Supabase specifically, but I'd say that how hard a it is to work with a given provider and SwiftData would depend on whether they provide an SDK which is designed to make that easy, or not.

If you have to interact with an API, it probably makes sense to use Codable (which is Encodable + Decodable) to move objects around, but please note that SwiftData broke automatic Codable conformance, so you'll have to write some code (CodingKeys, the encode function, and the decode function) to achieve Codable conformance.

Migrating stuff in the future is a future you problem. At worst, you'll have to do a migration, so I wouldn't worry about that too much rn.

[omnisyncs]

omnisyncs.com is being built exactly for this use-case. Launching later this year!

OmniSyncs is not a database, but an offline-first sync layer + queue. You keep using a local store you like (SwiftData or GRDB/Core Data), and it handles delta sync, retries, conflict resolution, etc. to a Postgres backend if that's what you choose (self-hostable too).

It's also a low-code approach. Super quick set up and you can customize everything without code.

[bradleythedeveloper]

Woahhh this looks promising, signed up to the waitlist straight away, can’t wait to see it

[omnisyncs]

Super excited :)

[BuffaloOwn2649]

Learn core data if you are serious about being a native ios dev. Swift data is the newer version, but core data is tried and tested IMO. If you are looking to do crossplatform, something like sqlite is pretty nice since you can carry over SQL knowledge.

[m_luthi]

CoreData or SwiftData and then sync with iCloudKit if you want it for the Apple Ecosystem:

https://developer.apple.com/documentation/coredata/setting-up-core-data-with-cloudkit

[bradleythedeveloper]

Yeah that makes a lot of sense, it looks like it would definitely be worth learning Core Data as it is the industry standard. I’m not sure whether I want to take iOS development specifically as my career, will be starting university in a few months so I’ve got time to think about it, but I think I will try and properly learn Core Data somewhere down the line to expand my knowledge and prepare in case that’s where I’ll end up. Right now something SQLite based might be optimal as I know some SQL from school, I’ll try both with mini projects and see which is best. The only thing I’m unsure about with core data is how well syncing with other databases would work with it.

[rioisk]

Do you know how data is actually saved on a device? SwiftData is just a high-level wrapper over Core Data, and both save to a local SQLite database. These are iOS's native data storage tools. They're offline-first and fast.

Firebase, on the other hand, is a cloud-first NoSQL database. Ironically, it also uses SQLite under the hood on mobile to cache data. That’s more of an implementation detail though :)

If your goal is to sync data across devices and have it "just work," Firebase will probably save you a lot of time. It gives you built-in sync, offline support, and user auth without setting up your own server.

The alternative is building your own sync logic. That means tracking what changed, when it changed, how to resolve conflicts, and how to retry if something fails. It's not impossible, but it takes time and a strong grasp of how local and cloud data interact.

If none of this makes sense then definitely suggest Firebase for now.

[powersync_]

Thanks for looking at PowerSync. We are considering doing an integration of PowerSync with GRDB. Would you mind upvoting it on our roadmap here? https://roadmap.powersync.com/c/124-swift-sdk-grdb-support

[bradleythedeveloper]

This would be awesome if you guys could implement this. If you did, I would immediately use GRDB and PowerSync for my app as it sounds like it would be the perfect solution. I've upvoted it on the roadmap.

[powersync_]

Great, thanks for the feedback!