Advice needed about using with X API

Hi ​@michael-freeman-a3ce43 ,

Your approach makes sense, and I’d definitely recommend using RevenueCat here.

Think of it as two separate pieces:

• RevenueCat answers “Does this customer currently have access to Pro?”
• The X API handles authentication, posting, and anything related to X itself.

So before enabling the X features, you can simply check whether the customer has an active ShareRaven Pro entitlement. That includes free trials as well, since the entitlement is active during the trial period.

A couple of notes:

• Sign in with Apple is completely optional from RevenueCat’s perspective. If you want customers to keep the same identity across devices or reinstalls, then calling logIn() with their Apple ID is a good approach. Otherwise, anonymous customers work perfectly fine too.
• I’d also avoid calling logOut() unless the customer is intentionally signing out. logOut() creates a new anonymous RevenueCat customer, so it’s generally something you only want to do during a real account sign-out.
• Definitely include a Restore Purchases button and use CustomerInfo.managementURL if you want to let customers jump directly to Apple’s subscription management page.

As for whether you should use StoreKit directly or RevenueCat, I’d stick with RevenueCat. It still uses StoreKit under the hood, but it saves you from having to build and maintain all of the subscription state management yourself. You get a much simpler entitlement model, a dashboard to troubleshoot customers, restore handling, analytics, webhooks, and the flexibility to expand to other platforms later if you ever decide to.

Hi ​@michael-freeman-a3ce43, welcome to RevenueCat! And thanks ​@Crudyg123 for the great breakdown above.

Just one addition on your core question:

Client-side entitlement checks via CustomerInfo are the expected pattern and enough for most apps. For an extra layer of protection, have a look at Trusted Entitlements: our SDKs verify response integrity by checking a cryptographic signature on the entitlement data, so you can detect (and choose to block) tampering. It's on by default on recent SDKs in informational mode. You'll want to read entitlements.verificationResult and decide how to handle access when it comes back failed.

If abuse ever becomes a real concern, validate the entitlement server-side via our REST API or webhooks before posting. That will require a backend, though, so it's a judgement call. Either way, it sounds like you've thought this through well. Happy to help if more questions come up as you build ShareRaven.

Best,

Thanks 

Thanks for both of your replies ! 😃

I’ve been trying to simplify by not having a backend at all.

I’d like to simply store my X API credentials in the app end, but AI agents keep telling me this is a bad idea. But as always their accuracy is suspect. I could swear that I could store the credentials securely.

But then there’s the issue of actually using a portion of the users subscriptions to buy the appropriate number of X API credits. X API seems to have no way of doing this programatically. 

Could RevenueCat deal wit buying the X API credits ?

Hi ​@michael-freeman-a3ce43 ,

For your first question, you might want to look at OAuth 2.0 Authorization Code Flow with PKCE. At a high level, the user signs in to their own X account through the system browser, and your app receives tokens scoped to that user. X verifies the exchange with a one-time cryptographic proof instead of a client secret, so there's no secret to ship. The only credential that goes in the app is your client ID, which is safe to embed when your app is registered as a Native App (a public client) in the X Developer Console. With this system you will also want to request the offline.access scope so the sign-in persists via refresh tokens.

You should never embed your client secret, bearer token, or paid API key. Anything shipped in the binary can be extracted, and the Keychain can't protect a developer secret you distribute to every install. 

For your second question, RevenueCat can't do this. Apple collects the payment and pays the proceeds straight to your developer bank account. RevenueCat validates the purchases and tracks entitlements, but no money flows through us.

As far as I can check, X also has no API for buying credits, just as you said. You can enable auto-recharge to top up automatically from a saved card, which combined with your spending limit might cover the "keep it funded, but capped" use case without a backend.

Best,