ide: Thanks for such a detailed response. Your prioritization makes sense to me.

ide: Thank you very much for your clear and thoughtful response. Here's one in return.

TL;DR: Suggestion: Allow custom Expo modules (eg IAP) that work in all of the Expo managed workflow . That might be much faster/easier solution to create than what you have proposed above, and still provide almost all of the benefit to Expo developers / be available to the Expo community much sooner.

Also, . I would.

See below for a suggestion on different build logic than the one that you propose that I think might allow for almost all of the benefit of having custom modules within Expo managed workflow, but be much simpler and quicker for Expo to implement. Perhaps it’s helpful to modify this feature request or create a new one.

I agree that while IAP and other custom modules within the managed workflow will be a significant amount of work, it will be an important part of Expo's future development. Basically, the biggest limitation at the moment of using Expo for many developers is the ability to include modules that require custom native code and/or auth, permissions, etc. Once this is included, Expo will become useful to a wider range of developers, furthering its core mission. Given its importance, IAP would be an important early use case as you say. That said, it's clearly a lot of work. Thanks for your realistic assessment of timeline. Here are a couple of suggestions on how this could be done more quickly. Perhaps other users can make additional suggestions.

Suggestion for simpler build logic that could (I think) get this important and urgent addition done much more quickly and simply.

Problem: The Expo build system currently can’t provide custom native modules/IAP on iOS, largely because Apple won’t allow custom code within the Expo Client app, and also because there are specific requirements that are different for each user for IAP to work, eg credentials. Similar problems would apply to other custom modules.

Solution: Modify the build process and/or design custom modules to get the majority of the benefit to Expo users, while avoiding / working around the central problem. How? Build process / custom module definition is designed to build the app so that custom native code & user-specific material is left out of apps when they are run within the main Expo iOS client (and potentially Android client too). At least initially, don't rely on ad-hoc Expo clients (which creates a majority of the complexity, and a minority of the value). This approach might accomplish >90% of the solution for Expo users, with <10% of the complexity and Expo team development effort.

This is basically a way to work around the hard problem rather than directly solve it. In my opinion, it would be a far better solution / work around than having to eject the project entirely, as in the current reality. Expo users could still do all of their development in managed-workflow Expo, and almost all of their testing in managed-workflow Expo. For Android, Expo developers could do 100% in the Expo managed workflow. For iOS, Expo developers could do everything except for the very last step. Developers could still build, test, and iterate the app entirely within Expo managed workflow, working on and testing all features except for the iOS version of the custom module native features, which would have a JS fallback. Then, when developers are ready to submit to Apple, Managed Expo could still build them their code, complete and ready for submission to the app store. The only missing piece would be that developers couldn’t run the custom features like IAP within the iOS Expo client app. While this would be a meaningful limitation, it’s only a small part of the total Expo managed workflow benefit to such a developer, relative to expo eject. This is certainly true for me.

Why? This still leaves the great majority of the Expo managed workflow benefits for users that need custom native code modules, like IAP, but it is (I think) much simpler and earsier/quicker to implement than doing all of the steps that you outlined.

Details:

(there may be a better way to accomplish something similar, but here’s a thought starter)

Create a new Expo managed workflow (or modify the existing one) that allows for custom native code modules, and that creates an Expo app that leaves out the custom native code/features when the app is run on iOS within the Expo client. It seems like the main challenges here are living by Apple's rules, and dealing with user-specific information. Workaround: create a new version of managed workflow that allows full functionality on Android, and limits functionality of an app when it runs on iOS, taking away what Apple won't allow or is user-specific. This would mean that many of the steps to build such a system that you discuss above wouldn't be needed. Example of how this might work for a custom module like IAP: On iOS, a JS-only fall-back is used within the managed workflow on the Expo iOS client. The build process can still create a standalone app for submission to testflight/appstore that includes the full custom module and custom, user-based information such as credentials, eg for IAP.

Christopher deCharms: Supporting custom builds — whether for standalone apps or ad hoc Expo clients — is most of the work. If the builders could create custom standalone apps and bill for them accordingly, it’s not as much work to do the same for ad hoc Expo clients.

Practically speaking, we need to make the Expo client more like standalone apps so that the difference between development and production is small, and so people don’t need to test as much code in the standalone app. The way we’ll do this is by shifting more of the development workflow towards ad hoc Expo clients.

Today if you want to write code that runs only in standalone apps, check for and run your code conditionally. Then you could use the Expo client for partial development and build your standalone app with the bare workflow on your own computer and do what you’re proposing.

ide: Thanks! Good luck with your efforts and thanks for your work on Expo.

ide: Thank you for your work! Is there a place to track the progress of this? Will it be released for one platform before the other?

Danny: The Expo blog and the Git commit log are the best places to look.

ide: Thanks for the information was very helpful, I would be interest in paying for this feature is it is needed as a premium account. And just guessing here but I think several of us would love to participate donating some good money to see this done. Count on me if that happens.