Mendix native mobile package for React Native applications.
Before you begin, ensure you have the following installed:
- Node.js: Version 18 (specified in
.nvmrc) - Yarn: Package manager (Yarn workspaces are required)
- React Native development environment (optional, only needed if running the example app): Follow the React Native environment setup guide
- For iOS: Xcode and CocoaPods
- For Android: Android Studio and Android SDK
This project is a monorepo managed using Yarn workspaces with:
- The library package in the root directory
- An example app in the
example/directory
git clone https://github.com/YogendraShelke/mendix-native.git
cd mendix-nativecorepack enable
yarn installThis will enable Yarn via Corepack and install dependencies for both the library and the example app.
yarn prepareThis compiles the TypeScript code and generates the lib folder.
The example app demonstrates library usage and reflects your local changes in real-time.
yarn example startyarn example iosOr open in Xcode:
yarn dev:iosyarn example android- JavaScript/TypeScript changes: Automatically reflected without rebuild
- Native code changes: Require rebuilding the example app
iOS (Objective-C/Swift):
- Open
example/ios/MendixNativeExample.xcworkspacein Xcode - Find source files at:
Pods > Development Pods > mendix-native
Android (Java/Kotlin):
- Open
example/androidin Android Studio - Find source files under:
mendix-nativein the Android view
Run type checking:
yarn typecheckRun linter:
yarn lintFix linting issues:
yarn lint --fixRun tests:
yarn testIf you encounter build issues:
yarn cleanyarn install- Install dependenciesyarn prepare- Build the libraryyarn typecheck- Type-check with TypeScriptyarn lint- Lint code with ESLintyarn test- Run unit testsyarn clean- Remove build artifactsyarn example start- Start Metro bundleryarn example ios- Run example app on iOSyarn example android- Run example app on Androidyarn dev:ios- Build, install pods, and open iOS project
See CONTRIBUTING.md for detailed contribution guidelines.
This repository supports automated releases using a GitHub Actions workflow. A manual fallback process is also documented below for situations where the workflow cannot be used.
The automated workflow handles:
- Bumping the package version
- Building and generating the lib folder
- Creating the tarball (.tgz)
- Creating a GitHub Release with attached artifact
- Moving the Unreleased notes from CHANGELOG.md into a new version section
- Creating a pull request against master with updated files
- Go to GitHub → Actions → Manual Release.
- Select Run workflow.
- Choose the version bump type:
- patch
- minor
- major
- Run the workflow.
The workflow will:
- Update package.json version
- Run
yarn install && yarn prepareto generate the build - Run
yarn packto generate the .tgz file - Create a new GitHub Release with:
- tag = new version
- release notes from the Unreleased section in CHANGELOG.md
- the generated .tgz file attached
- Commit updated CHANGELOG.md and package.json
- Create a pull request:
- branch:
release/<version> - base:
master
- branch:
After the PR is merged, the release is complete.
If the automated workflow fails, the release can be performed manually with the same steps.
Choose one:
npm version patch
npm version minor
npm version majorThis updates package.json locally (you'll commit this later).
yarn install
yarn prepareThe prepare script should generate the lib folder.
yarn packThis creates a file like:
package-name-vX.Y.Z.tgz
Keep this file for the release.
Move the content under Unreleased into a new version heading.
Example:
## [Unreleased]
## [1.2.0] - 2025-01-15
<previous unreleased notes>git add CHANGELOG.md package.json
git commit -m "chore: release <version>"
git push- Go to Releases → Draft a new release.
- Use the version number as the tag and title.
- Paste the notes you moved from the Unreleased section.
- Upload the .tgz file from the yarn pack step.
- Publish the release.
If your project requires PR-based updates, create a PR against master with the same changes you committed.
Use the automated workflow whenever possible because it handles every repetitive step. When needed, the fallback manual process mirrors the workflow exactly so releases remain consistent and predictable.