Skip to main content
Question

Advice needed about using with X API

  • July 18, 2026
  • 2 replies
  • 28 views

Forum|alt.badge.img

Hi,

I’m a RevenueCat newbie 😺

My app, ShareRaven, covers a gap in the market where Apple macOS devices have no ability natively to share to X/Twitter. Neither are there any apps that I could find that allow this.

The key design question is whether the following is the expected RevenueCat pattern for a backendless macOS app: use Apple sign-in plus Purchases.logIn, then treat the entitlement as the client-side feature gate, while accepting that secure per-customer X API metering would require a separate backend.

 

Backendless Mac App Store subscription gating for X API posting

I’m building a native macOS app with a Free/Pro model:

  • Free users can compose locally, copy text, and open X manually.
  • Pro users can connect their X account and post directly through the X API.
  • There is no app backend, no customer credit balance, and no per-user API quota.

RevenueCat is used only for subscription and entitlement management:

  • The app configures RevenueCat anonymously at launch.
  • When a user wants a Pro-only action, they sign in with Apple.
  • The app calls Purchases.logIn(appleUserID) to associate the RevenueCat customer with that Apple identity.
  • The app reads CustomerInfo.entitlements.active["ShareRaven Pro"].
  • An active entitlement—including a trial—unlocks direct X authorization, media upload, and posting.
  • The app uses Purchases.restorePurchases() for restores and CustomerInfo.managementURL for subscription management.
  • On Apple sign-out or credential revocation, the app calls Purchases.logOut() and removes local Apple/X credentials.

Apple handles the actual subscription payment. RevenueCat tracks and exposes access state; it does not pay the X API bill or meter X usage per customer. X API usage is billed to the developer’s X account, protected for V1 by a global X spending cap.

App flow

Everything looks like its right but I’m not sure if I’m using RevenueCat properly. Also do I need to even use RevenueCat ? Would it be easier to just do the subscription directly with Apple or is RevenueCat still simplifying the process ? Any help appreciated ! 🐈 

2 replies

Forum|alt.badge.img+4
  • Active Member
  • July 20, 2026

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.


hafizrahman
RevenueCat Staff
  • RevenueCat Staff
  • July 20, 2026

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,