Skip to content

List Apple Wallet passes and activate them in-app - #2

Open
wachunei wants to merge 1 commit into
MetaMask:mainfrom
Brunonascdev:feat/ios-wallet-pass-activation
Open

wachunei wants to merge 1 commit into
MetaMask:mainfrom
Brunonascdev:feat/ios-wallet-pass-activation

Conversation

@wachunei

Copy link
Copy Markdown
Member

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, with activationState (requireActivation, pending, active, and the other CardStatus values) and isRemote.
  • activateAppleWalletPass({ passTypeIdentifier, serialNumber, activationData, isRemote }) activates a pass that is waiting for activation. isRemote selects the Watch pass when the same card is on both devices.

Ported from ShpetimA/react-native-wallet (d122f802, ca6c4044), adapted to current main: 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.

getCardStatusBySuffix and getCardStatusByIdentifier are unchanged and still report only the iPhone pass.

Related Issues

Expensify#84
Expensify#45

Manual Tests

  • On an iPhone with a card in Wallet, call listAppleWalletPasses() and confirm the pass is returned with isRemote: false and an activationState.
  • Pair an Apple Watch that has the same card (or only the Watch has it). Confirm a second entry with isRemote: true, and that a Watch-only card is no longer reported as not found.
  • For a pass in requireActivation, call activateAppleWalletPass with issuer activation data and the matching isRemote flag. Confirm it resolves true and a following list shows active.
  • Confirm activateAppleWalletPass rejects when activation data is not base64, the pass is missing, or the pass is not eligible.
  • Confirm both functions are safe to import on Android: listing resolves [], 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.

Apps can read each pass's activation state on the iPhone and a paired Watch, then finish verification without leaving the app.
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 -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants