Swift Data + Firestore

App Development
1

Hi.

I’ve been following the CWC+ courses about the chat app and firestore.

I’m now building my own application that makes use of the new Swift Data available from iOS 17, but I can’t figure out how to solve a problem.

When I create a new Swift Data @Model, I cannot use property wrappers, meaning that I can’t use @DocumentId and @ServerTimestamp.

I’d like to use Firestore and Swift Data in conjunction because I don’t want the user to download a possibly large quantity of data every time they open the app, but rather store the bigger part of it locally, and fetch only updates.

I though of defining two separate models, one with firestore’s wrappers, and the other without them; fetch firestore as a firestore model, and then parse it into the SwiftData model, but this is not that elegant and would require quite a lot of duplicated code, as it would mean having two, almost equal models, for each model that I need.

Does anyone have any suggestion on how could I handle this?

2

Welcome to the community!

Firebase handles this automatically, overall you shouldn’t need a separate local database. See more info here.

And given Swift Data is brand new, using it with something other than Apple frameworks, could have weird results. If using Swift Data, you probably should go with using iCloud as the cloud db

3

Thank you for your reply.

The problem with using iCloud is that I don’t think I would be able to access it from other apps.
I’m planning to build a webapp counterpart, so I need a database that can work with both.

4

Ahhh gotcha, technically you can, there is a JS framework but it is some friction, because it will be connected to Apple accounts

But either way then I’d only go with Firebase. No need to SwiftData

5

Even if the app will need to download possibly thousands of documents on every launch? I’m worried it could become slow

6

How big is each document?

7

Not much, less than 10 fields

8

Fields of text?

Then even 10,000 documents will not slow it down!!

That’s like less than a few megabytes of info

9

Thanks a lot, I will try!

1 Like
10

Remember computers can process millions of things at once! So it seems like overall a lot, but it’s definitely dependent on the type of data

11

Since you’re thinking about caching a big chunk of the data locally, I assume most of it doesn’t change. Which means you shouldn’t have to download thousands of documents on every app init, maybe you should aggregate some of it in just a few docs. Maybe cache it locally and fetch only what’s new. You could maybe save thousands of document reads for each user, which adds up pretty quickly.

You’ll still have to pay for bandwidth, and like Mikaela says you gotta figure out how much data overall this represents. You can get a rough estimation by figuring out number of characters and using a tool like this Convert Character to Byte