We tried GraphQL, it added a lot of complexity on the backend that you don’t really need
We like to keep things simple, so we avoided state management libraries and all we needed was https://github.com/async-library/react-async
We also liked onesignal to manage push notifications
I've used Django Rest Framework as well, and although I would agree there's a bit less overhead (though I'd argue not that much: you still should be defining serializers for models like you would be defining types in GraphQL, there are just a lot of nice little helper methods and conventions for DRF that make it a bit faster than setting up GraphQL with Django), one of the main selling points of GraphQL is the ability to use Apollo on the frontend. Because of Apollo's caching system, you don't really need to create any custom state management related to fetching and storing queries from the server. You might need state management for other purposes, and you'll still need to tell it to do things like update lists when deleting items/when a mutation might invalidate other cached query results, but it handles a lot right out of the box.
The biggest headaches related to SPA state management I've run into before Apollo were always about fetching data efficiently and invalidating results from the server, which Apollo does really well. You don't need to worry about "am I fetching X somewhere else an extra time" or "did I remember to update Y in all the right places in the store when I fetched new data"; you can just declare the data you're component needs, and Apollo will either get it from the frontend cache, or if it can't find it there, the server.
If your app was more about user input than ingesting information, I might recommend checking out pouchdb. I just started using it for an app that's almost entirely based on user input that I wanted to work during long stretches of being offline, and it's been working pretty well so far (although I don't feel I've done enough with it to really endorse it fully yet/I have yet to see how the project pans out).
But since it sounds like your app is mostly about displaying information coming from the server to your users, and you want to avoid hitting the wire for data as much as possible, I think a combination of React Native and Apollo is probably a good fit. I'm sure there are other solutions, but it's the one I'm most comfortable with/what I'd probably jump to in your situation.
Since efficient querying is a concern, I highly recommend just biting the bullet. It's extremely easy to underestimate the complexity of caching state on the frontend and to end up accumulating an unmaintainable frontend state management situation. It's totally possible to do what OP suggested without running in to those kinds of issues, but typically that involves more frequent fetching from the server.
It depends how quickly you need to make the prototype/whether you'd be willing to refactor it/how efficient the querying really needs to be/whether you think you can keep state management simple and structured enough to avoid it ballooning/how quickly you think you can grok the basics of GraphQL/etc. Apollo doesn't really care what your schema looks like, unlike relay, so the learning curve isn't as steep. When I picked up GraphQL/Apollo for the first time the terminology felt pretty obtuse, but once the basic idea clicked it felt pretty natural. Most of the devs I've worked with have had similar experiences.
Things like this worry me about getting up and running with GraphQL though, especially "Common GraphQL problems: Server/Client Data Mismatch":
https://www.freecodecamp.org/news/five-common-problems-in-gr...
The recommended solution of using graphql on the server for the server/client data mismatch problem is a good one, but it's not really applicable in your case. That's geared towards people using both javascript and nodejs. If you're using javascript on the frontend and python on the backend, you can't share code/there's inevitably going to be a mismatch. A mismatch isn't always a bad thing, either; often you don't need to expose all of the database models to the client, and want a lighter weight abstraction.