Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expo In App Purchases #4416

merged 141 commits into from Jun 25, 2019


Copy link

commented Jun 4, 2019


This PR adds the highly requested In-App Purchases module to allow Expo apps to be monetized.


Using the Google Play Billing library on Android and Storekit API on iOS.

I had to make some changes in order to get started including adding expo-in-app-purchases as a dependency to Sandbox, adding the EXInAppPurchases pod as a dependency in the podfile, and changing the Bundle Identifier of the Expo Client from host.exp.Exponent to dev.expo.Paymentson iOS and the Application ID from host.exp.exponent to com.expo.payments on Android. This was necessary to match the entries in the Google Play Console and App Store Connect respectively so that I can safely add purchases to test against without putting the Expo client at risk of being removed.

This is because in order to test In App Purchases on both platforms you have to create an entry for the app and add the purchases yourself along with the necessary details (title, price, description, etc). On Android, you also have to upload an apk and publish the app as an alpha or beta release.

Obviously, we do not want the changes to be permanent so those commits HAVE TO BE REVERTED before merging this PR into master. This was just the fastest and easiest way to start prototyping.

Test Plan

Currently, I am building the Expo client from source (after making the aforementioned changes) and testing using the sandbox app under the apps/ directory as I'm developing.

In the future, we will need a more reliable way to test this feature and we can do one of the following:

  1. Change the Application ID/Bundle Identifier of Standalone NCL to match the above, reupload them to Google Play Console/App Store Connect, and add a screen that uses the API.
  2. Add a new standalone app in the apps/ directory with the above App/Bundle IDs.
  3. Keep using sandbox or another simple Expo app and add instructions in the README for how to get started testing such as changing the Expo clients App IDs (obviously this is less ideal).

As of now, you should be able to just pull down this branch, build the client, and test the API in sandbox.

Please note that in order to test the Google Play Billing and Storekit libraries you have to be using a real device so this will not work on simulators.

sergeichestakov added some commits May 10, 2019

Separate connecting to app store and querying purchases methods
Also returns values to the JS side. Connecting to app store will return
the history of purchases a user has made in the app. Querying for purchasables
returns all possible purchasable items available from the Google Play
Console. Both return a response code and array of results.
Combine consuming and acknowledging a purchase in one function
Now a user can pass in a boolean which effectively dictates whether an
item is consumable or not (can be bought more than once) rather than
worry about calling two different functions

@sergeichestakov sergeichestakov merged commit 35f8047 into master Jun 25, 2019

2 of 3 checks passed

client Workflow: client
docs Workflow: docs
sdk Workflow: sdk

This comment has been minimized.

Copy link

commented Jul 1, 2019

Fantastic that you're building this much-requested functionality.
Please, please, PLEASE make sure to handle subscriptions and the ability to have a back-end mechanism to track subscriptions. This is increasingly the go-to business model for many apps.
Apple & Google do not provide adequate (or even accurate) tools for tracking even the most critical information about what users are doing. For example, if a user cancels their paid subscription, and does not open the app on their phone (a common behavior)... there is no way to know that you have lost this person as a paying user. This means that having even the most basic knowledge of how much revenue you are collecting is not possible. The numbers that Google / Apple give on their portals are demonstrably wrong.
Looks from the commits like you are including subscriptions, and not just purchases, so that's a great start.
Please integrate with and/or similar functionality. They are attempting to solve this "no back-end for managing app $$" problem, and they can make clear what the issues are and how to address them. Happy to provide further details myself if that's useful.
I don't have any affiliation with their company, except as a user who badly needs this functionality and has spent large amounts of time trying to create solutions given the tools from Apple & Google.
I suggest that you reach out the the founder, Jacob Eiting,, who is extremely knowledgeable about inapppurchase, helpful, and would love to integrate their already-built-and-real-world-tested back-end functionality with Expo.
Again, the app stores make it nearly impossible to track user behavior necessary for absolutely key business metrics. For example, if you're running a subscription-based business, you must know how many active, paying subscribers you have, how many cancelled, when they cancelled, etc. The app stores don't provide any back-end functionality to (reliably) do this. The metrics that they give are often demonstrably wrong. It's crucial to be able to track this information.
Thank you.
And thank you again for handling in app purchase from within Expo.



This comment has been minimized.

Copy link

commented Jul 2, 2019

I have reviewed all comments on this PR, and I can see work is nearing completion for this much needed feature. I have a pure Expo project currently under development with Expo 33 SDK and would need to eject only for IAP, which I would love to avoid. Realistically, what would be the ETA for this feature to be ready for production? Weeks? Months?
Would it require waiting for the 34 SDK?
Thanks for your hard work!


This comment has been minimized.

Copy link

commented Jul 2, 2019

Hi all -- the initial release of this module will be very soon, at which point it will be ready to try out in bare workflow apps. It's tricky to include in the Expo client for a number of reasons, including the fact that it makes App Store review more complicated and also that IAPs are tied to your bundle identifier/package name (and therefore it would be virtually useless in the Expo client anyway). This means that for the foreseeable future it will be available in the bare workflow only.

Thanks everyone for all your enthusiasm and excitement about this module! 🙂 As it's now been merged and this PR is closed, I'm going to go ahead and lock this thread -- please redirect any questions or comments to our forums.

@expo expo locked and limited conversation to collaborators Jul 2, 2019


This comment has been minimized.

Copy link
Member Author

commented Jul 3, 2019

Thanks everyone for your feedback. I'm super excited to announce that the initial release of the Expo In-App Purchases module is finally here! You can now run npm install expo-in-app-purchases and head over to the docs to learn more about how to use it:

As @esamelson mentioned, this module is currently only available in the bare workflow for a number of reasons. As for tracking subscriptions, I left a note in the docs that you can use the Google Play Developer API on Android and the Status Update Notifications service on iOS. This seems to be the best option for now as those APIs are recommended by Google and Apple themselves. We currently have no plans to integrate with RevenueCat or other third party services.

I'm excited to get feedback from you guys as you try out the module and hope to see some awesome Expo and React Native apps getting monetized soon!


Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.