Pros & Cons of Local Persistence Strategies for React-Native Apps

Some of the benefits of using local storage or “fake backend” in React Native

Dec 2, 2019 · 4 min read

Some of the benefits of using local storage or “fake backend” can include — improving the user experience, quicker loading times, simplifying the messaging-interface and the server-side functionality. Bellow are the Pros & Cons for 3 different data persistence strategies — with considerations for best practices and stage of product development (MVP to large-scale).

  1. AsyncStorage — a built-in React-Native Local and Session Storage

It stores key-value pairs of string-only data, not encrypted, limited to 5MB per app and asynchronous.


  • Alleviates some of the need to rely on Server and External DB
  • Readily-available and simple one-liner implementation
  • Does not delay the loading of the app and can be quicker than data-fetching
  • MVP Considerations — Possibly a simple solution for MVP/POC product — that could serve until switching to production-ready solution.


  • silently reaches 5MB limit… — need to understand if 5MB is plenty for the needs of the app ?
  • the limit of 5MB, as of IOS 8 — can be wiped clean in the case of low memory on device 😞
  • Requires data type conversion as it holds only strings data.
  • for further safety reasons: requires serialisation/deserialisation and content-security-policies in place to maintain safety of data.

Best Practice recommendation

  • Widely used but not highly recommended for storing sensitive data. Not recommended for relying on persistence of data — as for the cons above.

Read more about it — Persisting Data in React Native.

2. REDUX-PERSIST or REDUX-OFFLINE — persist reducers, actions and state

Libraries that work with existing Redux implementation for global state management.


  • Can work well in app which relies on Redux heavily
  • Can hold light-weight data (such as series of IDs) that would be used to fetch data on server.


  • Not the greatest for large size data storage
  • The libraries are undergoing large amounts of changes and deprecated versions…
  • Adds complexity with edge-cases for storing reducers, actions and state.
  • ‘Chokes’ in android…
  • Often strongly advised against — for the lack of pros over simple local storage implementations and the need to learn management (such as redux-loggers interface) for niche/slice of function it provides.

Best practice recommendation:

  • Should be used only in well understood use cases — as simple JS object and local storage is sufficient most times.

Read more about it — Dan Abramov discusses ‘Why use Redux?’ specifically, instead of other simple solutions with an array of tutorials.


offline-first mobile app development — assumes the user is offline, network is slow, server is not reliable, connection is with high latency, public wifi is proxied. Then the architecture consists of three key parts:

  1. Use of simple on-device database ( such as Realm fro React Native)
  2. Communication with server
  3. Server where the synced data will live so that it can be distributed to whoever has permission.


  • seamless app performance on and off-line
  • respect of user’s battery and network resources


Read more about it —

Some Conclusions

  • None of the strategies stand out as the clear winner 😟 — as each have some draw-back — or at least something to watch out for.
  • The AsyncStorage reads as the most straight-forward solution, suiting the apps that are guarantied to use less than 5MB, carefully handling sensitive user data with added encryption and security policies. Though with caution for memory-wipes 🤯
  • Offline-first local database implementation seems to suit a well understood product with huge case for seamless offline performance. And a very keen technical team with plenty of resource — as the promise of performance is great — yet the potential run-ins to problems numerous as well…
  • Libraries for local persistence that are undergoing huge changes and that integrate with Redux — fall into the grey land — with no strong advice to use those without a good use case — “Just store JS object instead!” 😅

Please, if you have come across any other elegant local persistence strategies, please share ! 🙌

JavaScript in Plain English


Written by


Software Engineer @ HeadBox

JavaScript in Plain English

Learn the web's most important programming language.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade