fix(4226): implement transparent app icons for improved dark/light mode handling

[vinnyhoward]

Description

Issue: Our app icons were stuck in dark mode and ignored light mode settings in TestFlight builds (while working correctly locally). The build process was stripping the light mode icons during compilation.

Solution: Implement transparent background app icons that leverage iOS system defaults:

• Light mode: System automatically applies white background
• Dark mode: System automatically applies gradient black background
  This matches our brand color schemes perfectly and simplifies our icon management.

Additional Changes:

• Removed legacy CFBundleIcons dictionary from Info.plist
• Kept only the modern CFBundleIconName entry
• Simplified asset catalog configuration to use transparent icons

Risk Assessment:

• Primary risk is potential App Store rejection due to transparent app icons
• However, many apps successfully use this approach
• Fallback backgrounds are consistent with our brand guidelines
• Simplifies our icon management and build process

Testing:

• Verified icons display correctly in development
• Confirmed proper light/dark mode behavior locally

Next Steps:

• Monitor App Store review process
• Have backup solution with explicit backgrounds if needed
• Document this approach for future reference

Related issues

Fixes: #4226

Manual testing steps

1. Install a fresh app
2. Hold down on the home screen until the apps jiggle, indicating that the icons can be moved/deleted/edited
3. Click on the "Edit" button at the top right or left depending on the device, and click "Customize"
4. A bottom sheet should appear allowing you to toggle light, dark, and tint
5. Confirm that those still work

Screenshots/Recordings

TestFlight Build

ScreenRecording_02-20-2025.12-04-18_1.MP4

Before

NA

After

NA

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.

[vinnyhoward]

Removing this because it is not needed and was introduced in this recent PR so that we can pass the release build pipeline for TestFlight.

Removing the tint fields in the Contents.json is sufficient to get the builds passing

[github-actions]

Bitrise

🔄🔄🔄 pr_smoke_e2e_pipeline started on Bitrise...🔄🔄🔄

Commit hash: 2d43483
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/3451cfe8-ccb5-48b6-b4ae-7a503c04d014

Note

• This comment will auto-update when build completes
• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

[github-actions]

Bitrise

❌❌❌ pr_smoke_e2e_pipeline failed on Bitrise! ❌❌❌

Commit hash: 5411506
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/65a7100a-78da-4a8c-970a-aeffeb5b70e0

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

Tip

• Check the documentation if you have any doubts on how to understand the failure on bitrise

[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