NativeScript RFCs is a request-for-comments process that provides a controlled path for substantial changes to enter the NativeScript framework and related tooling.
The process addresses the need to carefully evaluate changes that affect end users and prevent unnecessary complexity in the framework's API surface. When a change is deemed substantial—such as introducing new API surface area, altering existing API semantics, removing shipped features, or establishing new conventions—it must go through the RFC workflow rather than the standard pull request process. An RFC begins as a pending proposal submitted as a pull request, transitions to active status when merged and undergoing implementation, reaches landed status upon release, or is rejected if closed without merging. This structured approach ensures that significant decisions receive input from both the NativeScript core team and the community before implementation begins.
Developers should follow this process when proposing changes to NativeScript core, the webpack integration, the Android and iOS runtimes, the iOS V8 runtime, or the NativeScript CLI. The process is intentionally limited to these core projects to keep it manageable, though it may expand to other projects in the organization over time. Not all changes require an RFC; improvements that are purely objective quality enhancements, bug fixes, documentation updates, refactoring, or changes invisible to end users can proceed through normal pull request workflows. Understanding which category a proposed change falls into helps contributors avoid having their pull requests closed with a request to submit an RFC first.
The project maintains a pending RFC list accessible through pull requests on the repository. Development activity centers on evaluating and discussing proposed changes to the framework's core components, with decisions documented through the RFC mechanism to create a historical record of how the framework's design evolved.