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

Release Build

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.