Add Symbol Categories

[narwahle]

Hi,

It would be helpful to add the symbol categories from the symbol.categories.plist file in SF Symbols.app to SFSymbol class to make sorting / filtering images in a view easier.

[fredpi]

@narwahle Thanks for raising this issue!

As I wrote in #75, I feel like we can't make sensible use of the category information. But now, that you raise this issue, that's probably no longer true.

I'm just wondering which specific use case you have in mind: Do you suggest just to add documentation or would you like a method like SFSymbol.moon.is(category: .weather) or an (additional) symbol access like SFSymbol.Weather.moon?

We may also need to take a look on the effect on the complexity, size & scalability of the library when implementing such features, but let's first clearly define what features you suggest to add.

[narwahle]

Hi fredepi,

I was ideally thinking of a method to return an array of all symbols matching a specified category. For my particular use case I'm implementing a feature where users set a custom icon for a folder, having categories included for each SFSymbols would allow a simple way to categories the icons in the picker UI.

Agreed there is a risk this impacts the size of the library due to the ver growing size, but as Apple is now providing the information it would be nice to expose this extra data.

[fredpi]

@narwahle Thanks for the reply! Then I suggest we offer a is(category:) interface for SFSymbol similar to the has(localization: interface.

For the purpose of getting an array of symbols of one category, one could then write SFSymbol.allSymbols.filter { $0.is(category: .weather) }.

Regarding the implementation, we have two options:

• Implement it similar to the way that static localization is implemented (i. e. by protocol conformance). This would have the disadvantage that SFSymbol.moon.is(category: .weather) would return true, while SFSymbol(rawValue: "moon").is(category: .weather) would return false.
• A better way to go would probably be a dictionary approach similar to what @Stevenmagdy suggested for runtime localization here (we decided to change the runtime localization management to the dictionary approach at some point in the future). Maybe we can now combine these two things by creating a dictionary [SFSymbol: (Category, Set<Localization>)].

Unfortunately, I currently don't have the time to implement this myself, but I'll happily discuss the implementation approach and review a PR by someone else. Maybe @Stevenmagdy and @knothed can also comment.

[knothed]

As @fredpi said, the dictionary approach would be very good to have before implementing this feature.

However the global dictionary would be of type [String: SFSymbol] to allow quick raw-value initialisation, wouldn’t it? The category and localization set of a symbol would still be stored inside the symbol.

[fredpi]

@knothed That's also an option – then, the association between symbol raw value and symbol localizations and symbol categories would be made on initialization with SFSymbol(rawValue: "..."). As per @Stevenmagdy's suggestion, this connection would only be made the first time the user uses the has(localization: ...) interface.

Performance-wise, the approach suggested by @Stevenmagdy would probably be better (if it can be realized lazily), because otherwise the (potentially not so fast) dictionary lookup would be performed on every SFSymbol(rawValue: "...") init, even if the user will never lookup localizations / categories.

[stonko1994]

My use case would be to build a picker with search functionality on top of this package. It seems to be the best-maintained one.

And it would be great to group them by categories.

There is https://github.com/alessiorubicini/SFSymbolsPickerForSwiftUI, but it does not have SFSymbols 4.0 support.

[Rspoon3]

Has there been any progress on adding this?