feat: add CocoaPods specs cache to iOS production build

[Qbandev]

Description

The iOS production build in build.yml runs pod install without caching ~/.cocoapods/repos (the CocoaPods specs repository). Every run downloads the full specs catalog from CDN, taking ~1m 36s.

This PR adds an actions/cache@v4 step before pod install that caches ~/.cocoapods/repos keyed on ios/Podfile.lock. On cache hit, pod install resolves specs locally instead of fetching from CDN. Uses continue-on-error: true so cache failures never block the build.

This matches the existing pattern in .github/actions/setup-e2e-env/action.yml (lines 382-391).

Changelog

CHANGELOG entry: null

Related issues

Fixes: MCWP-574

Manual testing steps

Feature: CocoaPods specs caching in iOS production build

  Scenario: First run populates the cache (cache miss)
    Given a production iOS build is triggered via workflow_dispatch
    And no prior CocoaPods specs cache exists for the current Podfile.lock

    When the "Restore CocoaPods specs cache (iOS)" step runs
    Then the step logs show "Cache not found"
    And "Install CocoaPods dependencies (iOS)" completes successfully at baseline timing (~1m 36s)

  Scenario: Subsequent run restores the cache (cache hit)
    Given a production iOS build is triggered via workflow_dispatch
    And a CocoaPods specs cache exists from a previous run

    When the "Restore CocoaPods specs cache (iOS)" step runs
    Then the step logs show "Cache restored"
    And "Install CocoaPods dependencies (iOS)" completes faster (~30s-1m less)
    And the build produces a valid IPA artifact

  Scenario: Cache failure does not block the build
    Given the cache action encounters an error (network issue, quota exceeded)

    When the "Restore CocoaPods specs cache (iOS)" step fails
    Then the step is marked as successful due to continue-on-error: true
    And "Install CocoaPods dependencies (iOS)" proceeds normally with a full CDN fetch

Screenshots/Recordings

N/A - CI workflow change only, no UI impact.

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• 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.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[Copilot]

Pull request overview

This PR speeds up iOS production CI builds by restoring a cached CocoaPods specs repository before running pod install, avoiding repeated full specs downloads from the CDN on every run.

Changes:

• Add an actions/cache@v4 step in the iOS path of .github/workflows/build.yml to cache ~/.cocoapods/repos.
• Key the cache on ios/Podfile.lock (with a restore prefix) and make cache failures non-blocking via continue-on-error: true.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: None (no tests recommended)
• Selected Performance tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 92%

click to see 🤖 AI reasoning details

E2E Test Selection:
The only changed file is .github/workflows/build.yml (CI configuration). There are no changes to application source code, controllers, UI components, navigation, Engine initialization, or test infrastructure within the app itself. Therefore, there is no direct or indirect impact on wallet functionality, user flows, confirmations, network handling, onboarding, browser, swaps, perps, predictions, snaps, or multi-chain features.

While workflow changes can affect the CI pipeline (build, test execution, caching, artifacts), they do not introduce runtime behavior changes in the mobile app. Functional E2E coverage is not required to validate feature behavior. Pipeline validation will occur naturally when CI runs the configured jobs.

Given the absence of app-level changes, no Detox E2E feature tags are required for risk mitigation.

Performance Test Selection:
No application code, rendering logic, state management, controllers, or initialization paths were modified. Therefore, there is no potential performance impact to app launch, onboarding, login, asset loading, swaps, predictions, or perps flows.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud