Repository navigation
Conversation
Apps can read each pass's activation state on the iPhone and a paired Watch, then finish verification without leaving the app.
Brunonascdev
approved these changes
Oct 13, 2026
Merged
8 of 10 tasks
Poovarasan-Sandhanam
pushed a commit
to Poovarasan-Sandhanam/metamask-mobile
that referenced
this pull request
Oct 19, 2026
…etaMask#37534) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> <!-- mms-check directive vocabulary — read by .github/scripts/shared/pr-template-checks.ts at module load to build the validation plan. Directives are invisible in rendered markdown and must NOT be removed or edited without updating the validator registry. type=text Section must contain non-placeholder prose. type=changelog Section must have a valid CHANGELOG entry: line. type=issue-link Section must have a Fixes:/Closes:/Refs: line with a value. type=manual-testing Section must have real testing steps or an explicit N/A. type=screenshot Section must have evidence (image/URL) or an explicit N/A. type=checklist Section must have all checkboxes consciously checked. required=true|false Whether a missing/invalid section runs the validator at all. blocking=true|false Whether a failure of this check fails the CI workflow. Default: false — failures are shown as warnings in the sticky comment but do not block the PR. Sections without a directive are checked for structural presence only. --> ## **Description** <!-- mms-check: type=text required=true --> <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> Replace the `@expensify/react-native-wallet@0.1.24` `patch-package` file with a Yarn patch of the MetaMask fork at `0.1.41`. The patch is the local merge of [react-native-wallet#1](MetaMask/react-native-wallet#1) and [react-native-wallet#2](MetaMask/react-native-wallet#2) onto fork `main`. That gives the installed library `primaryAccountIdentifier` and `deviceType` on Apple provisioning, plus `canAddCardToAppleWallet`, `listAppleWalletPasses`, and `activateAppleWalletPass`. Card provisioning still calls the existing add-card API. The new functions are available for a follow-up to use. ## **Changelog** <!-- mms-check: type=changelog required=true blocking=true --> <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: null ## **Related issues** <!-- mms-check: type=issue-link required=true --> Fixes: none — no MetaMask Mobile issue tracks this library patch Refs: MetaMask/react-native-wallet#1 Refs: MetaMask/react-native-wallet#2 ## **Manual testing steps** <!-- mms-check: type=manual-testing required=true --> ```gherkin Feature: Apple Wallet card provisioning Scenario: adding a card still completes after the library bump Given I am logged into MetaMask Mobile on an iPhone that can add cards to Apple Wallet And I have a MetaMask Card that is not yet in Apple Wallet When I add the card to Apple Wallet Then the Apple Wallet flow is presented And the card is added or I can cancel without the app crashing ``` ## **Screenshots/Recordings** <!-- mms-check: type=screenshot required=true --> <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** <!-- mms-check: type=checklist required=true --> <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- Generated with the help of the pr-description AI skill --> <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Large native-module bump and a breaking TypeScript change to the `addCardToAppleWallet` callback; Apple card provisioning paths are sensitive though behavior is intended to stay compatible for existing flows. > > **Overview** > **Bumps `@expensify/react-native-wallet` from `0.1.24` (patch-package) to `0.1.41` via a Yarn patch**, replacing the old `patches/@Expensify+react-native-wallet+0.1.24.patch` with `.yarn/patches/@expensify-react-native-wallet-npm-0.1.41-50938886af.patch` (merged MetaMask fork changes from react-native-wallet PRs MetaMask#1 and MetaMask#2). > > The patched library **extends Apple Wallet / PassKit support**: optional `primaryAccountIdentifier` on add-card data; **`deviceType`** (`phone` / `watch` / `unknown`) on the add-pass response and as a **fourth argument** to the `addCardToAppleWallet` issuer encrypt callback; and new JS APIs **`canAddCardToAppleWallet`**, **`listAppleWalletPasses`**, and **`activateAppleWalletPass`** (full iOS implementation, Android no-ops or throws). iOS native code adds pass listing, activation, multi-device provisioning hints, and clearer errors when a card is already on all devices. > > **No app-layer changes in this PR**—existing provisioning can keep using `addCardToAppleWallet`; integrators must update the encrypt callback signature if TypeScript is strict. New APIs are for follow-up work. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 8b8df8e. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Details
Adds two iOS functions so an app can show a card's verification state and finish activation without sending the user to Wallet:
listAppleWalletPasses()returns every Secure Element pass on the iPhone and on a paired Apple Watch, withactivationState(requireActivation,pending,active, and the otherCardStatusvalues) andisRemote.activateAppleWalletPass({ passTypeIdentifier, serialNumber, activationData, isRemote })activates a pass that is waiting for activation.isRemoteselects the Watch pass when the same card is on both devices.Ported from ShpetimA/react-native-wallet (
d122f802,ca6c4044), adapted to currentmain: the old architecture reads struct fields with the existing per-parameter#ifdef, and Android gets no-op stubs so the shared TurboModule spec still builds.getCardStatusBySuffixandgetCardStatusByIdentifierare unchanged and still report only the iPhone pass.Related Issues
Expensify#84
Expensify#45
Manual Tests
listAppleWalletPasses()and confirm the pass is returned withisRemote: falseand anactivationState.isRemote: true, and that a Watch-only card is no longer reported as not found.requireActivation, callactivateAppleWalletPasswith issuer activation data and the matchingisRemoteflag. Confirm it resolvestrueand a following list showsactive.activateAppleWalletPassrejects when activation data is not base64, the pass is missing, or the pass is not eligible.[], and activation throws.Linked PRs
Expensify#91 also edits the TurboModule spec, the README function table, and
WalletManager.swift/RNWallet.mm. Whichever lands second will need a small rebase. This PR does not depend on Expensify#91.