Skip to content

Conversation

@ajanuar
Copy link

@ajanuar ajanuar commented Dec 1, 2025

Description

This PR adds support for using .xcassets asset catalog icons across key navigation UI elements. Developers can now reference native asset names directly for both bottom-tab icons and header bar button items, removing the need to bundle standalone image files. By integrating with iOS/macOS asset catalogs, the update aligns icon handling with platform best practices, simplifies asset management, and enables automatic support for multi-resolution and variant images (such as dark mode).

Addresses discussion.
Closes https://github.com/software-mansion/react-native-screens-labs/issues/576.

Usage

You can add logo to asset catalog via Xcode:

Screenshot 2025-12-03 at 12 11 43

Changes

  • add xcasset icon type for iOS
  • handle xcasset for Tabs
  • handle xcasset for Bar Button Items in Stack
  • update BarButtonItems example screen and add Test3443 that tests xcassets in Bottom Tabs

Before & after - visual documentation

Bottom Tabs Header Bar Button Item
Simulator Screenshot - iPhone 17 Pro - 2025-12-03 at 12 11 45 Simulator Screenshot - iPhone 17 Pro - 2025-12-03 at 12 49 15
Menu Submenu
Simulator Screenshot - iPhone 17 Pro - 2025-12-03 at 12 52 03 Simulator Screenshot - iPhone 17 Pro - 2025-12-03 at 13 06 08

Test code and steps to reproduce

Run BarButtonItems example screen. Use XcassetIconButtonDemo and AdvancedMenuButtonDemo.
Run Test3443.

Checklist

  • Included code example that can be used to test this change.
  • For visual changes, included screenshots / GIFs / recordings documenting the change.
  • For API changes, updated relevant public types.
  • Ensured that CI passes

@kkafar
Copy link
Member

kkafar commented Dec 2, 2025

Hey! Thanks for the PR. We'll look into it after 4.19.0 release

@ajanuar
Copy link
Author

ajanuar commented Dec 2, 2025

Thank you @kkafar ! I'll add more tests

@ajanuar ajanuar marked this pull request as ready for review December 3, 2025 06:12
@ajanuar ajanuar changed the title Add xcassets support chore(ios): Add xcassets support Dec 3, 2025
@kkafar kkafar self-requested a review December 18, 2025 14:00
@kkafar kkafar requested a review from kligarski December 18, 2025 14:02
@ajanuar
Copy link
Author

ajanuar commented Jan 9, 2026

Hi @kkafar @kligarski , any chance to review this PR? Thank you

@kkafar
Copy link
Member

kkafar commented Jan 12, 2026

Hey @ajanuar, it's in our task queue for January. We'll look into it.

@kligarski
Copy link
Contributor

Hi, @ajanuar. Thanks for the PR and sorry for the delay.

I'll push some changes and modify the description a bit. Hopefully, we'll be ready to land this soon.

@kligarski kligarski changed the title chore(ios): Add xcassets support feat(iOS): add xcassets support Jan 15, 2026
Comment on lines 146 to +150
iconImageSource?: ImageSource;
iconSfSymbolName?: string;
iconResourceName?: string;

selectedIconImageSource?: ImageSource;
selectedIconSfSymbolName?: string;
selectedIconResourceName?: string;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about the name of this prop (iconResourceName). It's used for both sfsymbols and xcassets. We also have drawableIconResourceName and imageIconResource on Android which have very similar name.

Maybe those props should be unified (iconImageSource (removing imageIconResource), iconResourceName (removing drawableIconResourceName) for both platforms and selectedIconImageSource, selectedIconResourceName as iOS-only).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like this solution (adding new prop to pass xcasset's name), we could use only one prop for both sfsymbolname and xcassetname however we're currently not passing iconType so we can't differentiate between the two.

At least we're not passing it intentionally - we're using ...icon so it actually is present on the native side but I don't want to rely on that. We need to refactor this logic and add proper typing in JS layer because it's very difficult to add any changes now without being afraid of this whole feature breaking apart.

Decided to go with separate prop for now as refactoring this logic would be way out of scope of this PR.

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.

3 participants