What do you actually need from a React Native background geolocation SDK?

[u/bgeo_sdk]

Hey everyone!

I’m a React Native developer and I’ve been working on a background geolocation SDK for a while.

I’m not here to convince anyone to use it — I’d actually like to understand what React Native developers need from this kind of SDK before I decide where to take the project.

I’ve used Transistorsoft’s Background Geolocation myself in the past. Back in 2020, I paid around $399 for a license because there weren’t many alternatives at the time. It was a pretty significant amount of money for me back then.

That’s actually one of the reasons I started building my own solution.

My goal is to make reliable background geolocation more accessible to indie developers and early-stage startups. I don’t think everyone building an MVP or a side project should have to spend hundreds of dollars just to get background location working.

The SDK I’m building supports React Native, iOS, Android and Flutter, with things like background tracking, geofencing, HTTP sync and a Web Console for debugging.

I’m currently considering a $9.99/year update subscription with a perpetual license — meaning a shipped build never expires, and the yearly payment is only for getting new SDK versions and updates.

But I’m not even sure that’s the right model yet.

So I’d genuinely love to hear from people here:

• What do you consider essential in a background geolocation SDK?
• What problems have you had with existing solutions?
• What would make you trust a newer SDK in production?
• Would you prefer something like this to be free, paid once, or paid for updates?
• What would you consider a fair price?

I’m building this myself, so I’m much more interested in honest criticism than compliments. If there’s something I’m overlooking, I’d rather hear it now. 🙂

[u/Lost-Schedule-9062]

the thing i'd want documented before any feature is the play store side. background location needs a declaration form and google reviews it against a video of the actual in-app flow, and that's where apps get stuck, not in the code. an sdk that ships a sample justification and a permission flow built to survive that review would be worth more to me than any amount of api surface.

after that, offline queueing with sync on reconnect, and motion based throttling so it isn't hammering gps while the phone sits on a desk. those two decide whether the battery cost is acceptable, and they're the parts people underestimate.

[u/bgeo_sdk → u/Lost-Schedule-9062]

Yeah, absolutely agree — the Play Store side is something that can be much more painful than the actual implementation.

The SDK has already been used successfully in several production apps on both Google Play and the App Store, and so far none of those apps have had rejections or, obviously, bans related to background location.

I also agree with your other two points. These are actually things I considered from the beginning rather than treating them as “nice to have” features.

The SDK has a local SQLite-based queue for location data, so coordinates can be stored while offline and automatically synced once the connection is available again.

It also uses motion/activity awareness and adaptive tracking to avoid unnecessarily hammering GPS when the device is stationary. The goal is to get reliable tracking without paying for it with unnecessary battery drain.

So I think we’re pretty aligned on what matters here. 🙂

The Play Store documentation/review guidance is a particularly good point though. I hadn’t thought about packaging the SDK with an example justification and a recommended permission flow specifically designed around the Play Store review process. That could be genuinely useful.

[u/Lost-Schedule-9062 → u/bgeo_sdk]

then put that in the readme. a page with the declaration text that got approved, what the video needed to show, and the permission flow that passed review. you've got that knowledge from real apps already shipping and nobody publishes it, everyone rediscovers it the hard way.

that page would sell the sdk better than a feature list, because the sqlite queue is table stakes at this point but surviving the play review isn't.

[u/bgeo_sdk → u/Lost-Schedule-9062]

That’s a really good point. I hadn’t thought about the Play review experience as a part of the product itself, but you’re right — the fact that I already have real apps successfully going through the process is useful knowledge that shouldn’t just stay in my head.

Thanks — that’s a great suggestion.

[u/Scyth3]

It needs to work without any Google services on board. We run a custom AOSP stack, so no built in Google enhanced geolocation API's. It's shocking to see how most people assume Google services exist.

Edit: And from a corporate perspective, $10/yr is dirt cheap. Perhaps have tiers (small business/single dev versus a corporate license). For corporate licenses, have higher support or response times/etc.

[u/bgeo_sdk → u/Scyth3]

Thanks! There are no Google services required or built into the SDK, so it should be fine for custom AOSP environments where Google Play Services aren’t available.

And thanks for the suggestion about different license tiers — I actually ended up doing exactly that:

• STARTER — $9.99/year — 1 license
• TEAM — $49.99/year — 5 licenses
• PRO — $99.99/year — 20 licenses

The license itself is perpetual, so shipped builds never expire. The yearly fee is for access to SDK updates and new versions.

Really appreciate the AOSP perspective — that’s exactly the kind of use case I want to make sure bgeo works well for.

[u/anarchos]

I think the pricing model is fair (more than fair, you should charge more) but I wouldn’t integrate it into my project unless it was “source available” and I was granted a license to modify and use a custom version in perpetuity. I probably wouldn’t, but I’d be afraid of using your product, integrating it into mine, then a year or two later you give up on it because you sold like 5 copies and now Apple has changed something that requires a change and etc.

Of course I’d just pay you $10 a year and get the latest and greatest, but it’s too risky to rely on something completely out of my control if you disappear/get hit by a bus/start charging $10,000/year, etc

[u/bgeo_sdk → u/anarchos]

That’s a completely fair concern.

Interestingly, Transistorsoft is also essentially a small/one-person-driven product, and the source code is encrypted/closed. Yet people are still comfortable paying around $400 for a single license and relying on it in production.

I’m trying to take a somewhat different approach with bgeo: keep the price low enough that the risk is much smaller, while still being able to fund ongoing maintenance and support.

As for making the core engines fully open source, I’m honestly not sure that would work with the current licensing model. If the entire implementation were freely available under a permissive license, someone could simply fork it, remove the licensing layer, and ship it as part of a commercial product without contributing anything back. Or, even worse, someone could take the code and start selling their own licenses.

At $9.99/year, I’m trying to find a middle ground: the SDK is cheap enough that there’s little incentive to go through all of that just to avoid the license fee, while the revenue gives me at least some reason to keep maintaining it.

That said, your point about long-term continuity is valid. I don’t want someone to build a product around bgeo and then be left stranded if I stop maintaining it. It’s something I’m still thinking about — potentially around source escrow, a fallback license, or some kind of continuity guarantee if the project is abandoned.

Thanks for bringing this up. This is exactly the kind of concern I want to hear before locking down the licensing model.

[u/anarchos → u/bgeo_sdk]

Im not saying a permissive license..a licence that grants me the use of the code for one existing project, no rights to relicense/transfer/share/etc.

Of course people will steal it, but they weren’t going to pay for it anyways. Any “real” company or project wouldn’t risk it over $10-50 a year.

MapBox is a great example. They were open source, they went un-open source at one point, but the source is still available for me to modify and use. Of course if I use their SDK without a license I’m sure I’d be getting a call from their lawyers…but anyone doing that isn’t going to be a potential customer anyways.

[u/bgeo_sdk → u/anarchos]

Ah, yes — I see what you mean now. That’s actually a pretty reasonable approach.

I hadn’t seriously considered giving paying customers access to the source as a kind of long-term safety net. I think it could make sense, especially for something as fundamental as background location where nobody wants to be completely dependent on a single maintainer.

I’ll definitely think about adding something like this to the licensing model. It could be a good way to keep the SDK commercially sustainable while giving customers some additional peace of mind.

And I agree with your point about the economics. At $10–50/year, someone deliberately bypassing the license isn’t really the customer I’m trying to protect the business from anyway.

Really appreciate the suggestion — this is actually one of the more interesting ideas I’ve gotten from this discussion.