Thank you for your interest in contributing to PocketPay Mobile! We welcome pull requests, bug reports, and feature requests from everyone.
- Prerequisites
- Installation
- Running the App
- Project Structure
- Testing
- UI & Design Guidelines
- Accessibility
- Security
- Submitting a Pull Request
- Code of Conduct
Before you begin, make sure you have the following installed on your machine:
| Requirement | Version | Notes |
|---|---|---|
| Node.js | v18 or later | LTS recommended. Use nvm to manage versions. |
| npm | v9 or later | Comes bundled with Node.js. |
| Expo CLI | Latest | Install globally: npm install -g expo-cli |
| Expo Go | Latest | Install on your iOS or Android device from the App Store / Play Store. |
| Git | Any recent version | Required for cloning and branching. |
iOS Simulator / Android Emulator (optional): If you want to run the app without a physical device, install Xcode (macOS only) or Android Studio.
-
Fork the repository on GitHub, then clone your fork locally:
git clone https://github.com/<your-username>/pocketpay-mobile.git cd pocketpay-mobile
-
Install dependencies. This project requires the
--legacy-peer-depsflag due to React Native peer dependency conflicts:npm install --legacy-peer-deps
-
Set up environment variables:
cp .env.example .env
Open
.envand fill in any required values. Do not commit real secret keys or credentials — see the Security Guide for safe practices.
Start the Expo development server:
npm startThis opens the Expo Metro bundler in your browser. From there you can:
- Press
ato open on an Android emulator or connected device. - Press
ito open on an iOS simulator (macOS only). - Scan the QR code with the Expo Go app on your physical device.
Other available scripts:
npm run android # Launch directly on Android
npm run ios # Launch directly on iOS (macOS only)
npm run web # Launch in a browser (limited support)
⚠️ This app runs on the Stellar Testnet only. Testnet XLM has no real monetary value. Never connect a Mainnet wallet during development.
pocketpay-mobile/
├── app/ # Expo Router screens (file-based routing)
│ ├── (auth)/ # Auth flow: welcome, create wallet, import wallet
│ └── (tabs)/ # Main tab navigation: home, history, vault, settings
├── src/
│ ├── components/ # Reusable UI components
│ ├── constants/ # Theme tokens (colours, spacing, typography)
│ ├── services/ # Stellar SDK integration
│ ├── store/ # Zustand state management
│ └── utils/ # Validation helpers and utilities
├── docs/ # Project documentation
├── tests/ # Integration tests and fixtures
└── __tests__/ # Component and unit tests
This project uses Jest with jest-expo and React Native Testing Library.
Run the full test suite once:
npm testRun tests in watch mode during development:
npm run test:watch- Before touching a screen, check its row in the Screen Test Matrix for the test types it's expected to have and its current coverage status. If you add a new screen, add a row for it in the same PR.
- All new screens and interactive components must include tests.
- Use
@testing-library/react-nativeto render components and interact with them via accessible queries (getByRole,getByLabelText, etc.). - Test the key user-facing behaviours: form validation, loading states, error messages, and successful flows.
- Mock external dependencies (Stellar SDK, SecureStore, AsyncStorage) — see the existing mocks in
__mocks__/andsrc/services/__mocks__/for patterns to follow. - Tests should pass before you open a PR. CI will run the suite automatically on every push.
If your change touches src/types/pocketpay-sdk.d.ts or src/sdk-stub/, run:
npm run api:checkThis detects accidental changes to the pocketpay-sdk public contract. If the
change is intentional, run npm run api:update, commit the regenerated
api-reports/pocketpay-sdk.api.md, and note the change in CHANGELOG.md. See
docs/sdk-api-compatibility.md for details.
Before adding new screens or components, read the Design System Guide. Key rules:
- Always import design tokens from
src/constants/theme.ts(COLORS,SIZES,RADIUS,FONTS). Never hardcode hex values or pixel sizes. - The app uses a dark-only palette — there is no light mode.
- Use
COLORS.primary(#00E5FF) for the primary action on a screen andCOLORS.secondary(#7B61FF) for a competing secondary action. - Follow the card, button, and input patterns documented in the design system.
- Review every changed screen and reusable component against the UI State Catalogue, including loading, empty, error, success, disabled, and pending behavior.
We strive to build a wallet that is accessible to everyone. Before submitting a PR for any UI changes, verify your work against the Accessibility Checklist. Highlights:
- Add
accessible={true}and descriptiveaccessibilityLabelprops to interactive elements. - Minimum touch target size of 44×44 dp for all tappable elements.
- Maintain a 4.5:1 contrast ratio for text.
- Announce loading states and errors to screen readers using
accessibilityStateandaccessibilityLiveRegion.
- Never commit secret keys,
.envfiles, or credentials to version control. - All key storage must go through
expo-secure-storeas documented in the Storage Guide. - Read the full Security Guide before touching key management, storage, or any authentication flow.
- Unexpected crashes are handled by the root ErrorBoundary and redacted reporting funnel — see Global Error Handling.
- If you discover a security vulnerability, please report it privately rather than opening a public issue.
-
Create a branch from
mainwith a descriptive name:git checkout -b feat/your-feature-name # or git checkout -b fix/issue-description -
Make your changes, following the code style, design system, accessibility, and testing guidelines above.
-
Run the tests and make sure everything passes:
npm test -
Commit with a clear, descriptive message:
git commit -m "feat: add QR code sharing on Receive screen" -
Push your branch and open a pull request against
main:git push -u origin feat/your-feature-name
-
In the PR description:
- Summarise what changed and why.
- Reference any related issues using
Closes #<issue-number>. - Describe how you tested the change.
- Note any accessibility or security considerations.
- For GrantFox contract issues, review the Evaluation Readiness Checklist before the payment evaluation period. A merged PR does not guarantee payment approval.
-
A maintainer will review your PR. Please respond to feedback and update your branch as needed.
Be respectful and constructive in all interactions. We follow the Contributor Covenant code of conduct. Harassment, discrimination, or hostile behaviour will not be tolerated.
Happy building! If you have questions, open a discussion or leave a comment on the relevant issue.