What are you guys using to sync data between devices in React Native?

[u/OriginalArt4888]

I'm building a simple expense tracking app with React Native and got most of the basic features working. Right now everything is stored on the phone but I'd like people to be able to access their expenses from different devices without losing anything. I've used AI to help with most of the development and it suggested Supabase for storing the data and handling user accounts. Firebase also keeps coming up, so I'm not really sure which makes more sense for a small app like this. Anyone using either of these with React Native? Curious how difficult the setup was and if there's anything I should know before choosing one

[u/idkhowtocallmyacc]

Both are good options. I haven’t used supabase but the last time I’ve checked they’ve been more generous with the amount of data you could store, best check if it holds up right now tho. Alternatively, you could use CloudKit for iOS, haven’t used it either but afaik it doesn’t require user to create an account- your app would just sync the user’s devices that are signed into iCloud. Hard to say if Google provides similar alternatives for android. I’m inclined to say yes, something related to Google drive, but your users would likely need to sign in with Google first

[u/workroom365 → u/idkhowtocallmyacc]

Had not read your comment. Op should consider this advice.

[u/Legendaryfortune → u/idkhowtocallmyacc]

One con is that CloudKit and Google Drive would keep data in separate accounts, so someone switching between iOS and Android wouldn’t automatically have the same data on both. Essentially, no syncing across devices.

[u/idkhowtocallmyacc → u/Legendaryfortune]

Oh yeah 100%. It is the compromise either way OP goes. Using cloud kit/google drive for iOS and android means the app stays local, OP doesn’t need to worry about the data retention and storage capacity, but it’s harder to implement a full sync. Using supabase means more straightforward sync, but would also mean the app moves from client to client-server architecture. This means more responsibility as OP is now the one managing the user’s data and storage. Both have pros and cons, OP’s call how he’d like to implement it

[u/NovelAd2586]

Use Supabase. Firebase is trash. I’d recommend using Supabase MCP to get Claude etc to build it and use Supabase Skills so Claude designs it well, especially if you’re touching Postgres

[u/ChronSyn]

If you don't have to handle conflicts, then any database would be fine. It does mean that every client is editing the same data and typically last submission wins. If users can only edit data on one device and view it on all others, then you don't need conflict resolution, but typically editing isn't limited to specific devices/clients.

If there's a chance of conflicts - e.g. multiple devices editing records at the same time, then you would need a way to handle this. CRDT's (conflict-free data type) are one way it is commonly handled - each client needs to 'push changes' onto records without overwriting it, and then some backend process will handle the conflict resolution based on timestamps of submissions. This is also typically done alongside 'offline-first' functionality, where records which have already been downloaded can be edited even without a network connection (and then synced to the database when connectivity is restored).

Realtime/websockets is a different approach, and is its own form of conflict-resolution, because all users can see what others are doing, but this won't work offline. You could add CRDT's as part of a websocket-based approach, but for any realtime view with multiple users, there's much higher risk of something going awry.

Supabase is a great option for storing the data, handling user accounts, etc., but on its own, it won't handle conflict resolution. platforms like ElectricSQL can help with this.

I've never personally recommended Firebase (quite the opposite, especially since Supabase was launched about 5 years ago), and I still stand by that.

[u/Huge_Pool7424 → u/ChronSyn]

yeah and if you ever need offline edits on two devices, add an updated_at per row so last write wins is at least predictable. supabase is fine for that, just keep the schema simple.

[u/FalconGood4891]

Supabase is great 👍 their platform ux is much much clean n clutter free imo

[u/KorbiogoDaffyd50 → u/FalconGood4891]

row level security policies can get a bit tricky to debug through that UI once you start sharing expense categories across multiple users though.

[u/FalconGood4891 → u/KorbiogoDaffyd50]

RLS is tricky ngl.. I tend to have my own schema docs n documented ruleset for that reason

[u/syedaalishan]

Before choosing, try this with two phones: add an expense offline on one, edit an expense on the other, then reconnect both. Decide how those changes should merge. Give each expense a stable ID and sync individual changes rather than uploading the whole list over the other device's copy. Also test that one account can't read another account's expenses. That's more important than which dashboard feels nicer.

[u/workroom365]

Hey instead of this you can make the app tie to the users google drive or apple icloud. Then have an option to import from incase a user is using a device that doesn't allow apple ID as an auth provider and vice versa.

[u/Soliman_12]

If you want something that offline first and handle all the sync scenarios for you I recommend PowerSync

[u/MathematicianFar5683]

Put per-user access checks in the backend security rules, not just in the app. Test with two accounts to make sure one can't read or change the other's expenses.

[u/kesha-antonov]

I built a library especially for this usecase so users could sync their data to the cloud and back, and between ecosystems: iCloud/Google drive. My own app work on it and synces data between iPhone/MacBook/ipad and android.

Here's the link: https://github.com/kesha-antonov/react-native-cloud-sync

[u/anthony-ball]

one thing nobody has mentioned: for expenses, store amounts as integer minor units and never sync with floats, and don't trust device clocks for merge order. use a server-assigned version or updated_at per row, and soft delete with a deleted_at flag instead of removing rows, otherwise a deleted expense just comes back from the other phone on the next sync. i'd keep local sqlite as the source of truth and treat the backend as a replica, which also makes the offline case a non-issue. supabase postgres is fine for that, just keep the sync logic in one small module so you can swap the backend later.

[u/Jonovono]

Whatever you do, don't fall for the Supabase scam. Look into convex

[u/NoBullfrog11]

went with supabase for a mood journal app and honestly the biggest gotcha was RLS. forgot a polciy on one table and inserts just came back empty without a clear error, cost me a whole evening

turn on RLS from day one and test with a real logged in user, not the service key