Add support for next-generation SFSymbols

[fredpi]

SFSafeSymbols should include support for the new symbols introduced with iOS 14 and the other Apple operating systems.

Regarding the structuring I suggest the following design:

enum SFSymbol {
    @available(iOS 13...)
    enum v1 {
        case ...
    }

    @available(iOS 14...)
    enum v2 {
        case ...
    }
}

The SFSymbols 2 app required for parsing the symbol catalog isn't available yet, so I will look into this as soon as the app is available.

[fredpi]

Development for next-generation SFSymbols is happening at the xcode12 branch

[fredpi]

The SFSymbols 2 app is now available and looking up its package contents, one sees 3 useful files that weren't there in the previous version:

1. Contents/Resources/name_availability.plist
2. Contents/Resources/legacy_aliases_strings.txt
3. Contents/Resources/name_aliases_strings.txt

The name_availability.plist provides all symbol names + the year of availability (meaning whether it is already available on iOS 13... or only on iOS 14...). It looks like manually parsing the symbols app is no longer needed! 🚀

I will wait until Friday's session about SF Symbols to better understand the meaning of and the difference between the alias text files.

[ohitsdaniel]

Just stumbled upon this repo and wanted to leave some ideas here that would make the enum generation a teeny tiny bit easier:

Check out gyb (part of the Swift Standard library) that allows to generate files based on templates that can include python code. There is a python package that allows you to parse the above mentioned plist files.

I would be willing to help with this as well. :)

[fredpi]

Xcode 12 CI is now up and running, configured for builds targeting the xcode12 branch.

[imthath-m]

@fredpi
this kind of structuring would mean all the existing apps have to update their existing code to use the new symbols.

enum SFSymbol {
    // existing iOS 13 symbol
    case pencil = "pencil"

   @available(iOS 14 ...) 
   case linkBadgePlus = "link.badge.plus"
}

This would be helpful, so that no code changes are required.

Another major factor is, when we are developing and start searching for a symbol in Xcode, we would most like not know whether the symbol we are looking for is available for iOS 13 or 14.

[fredpi]

@imthath-m Thanks for your suggestion! I think it makes more sense so I will take your approach.

I'm just wondering whether I should implement the v1 and v2 subtypes as an additional way of accessing the symbols, so that if someone wants to browse the v2 catalog, that's possible via SFSafeSymbols. What are your thoughts on that?

[imthath-m]

Thanks @fredpi.

I have been thinking about the same problem. I think we can add v1, v2 and whatever the future holds, near the actual symbol in the documentation comment. So that when we look up from Xcode, we get to know the info just before Xcode will let us know (which is just after we complete the line).

enum SFSymbol {
    /// 'symbol' v1
    case pencil = "pencil"

   @available(iOS 14 ...) 
   /// 'symbol' v2
   case linkBadgePlus = "link.badge.plus"
}

Note: 'symbol' refers to the actual symbol you have displayed in code, which I'm not able to copy into the browser.

For the purposes of categorizing and browsing version 2, if we look at the SFSymbol enum, we'll be able to find the ones marked @available.

I have one more idea for categorizing, but you have to let me know whether it is possible to write a script to achieve that.
Can we have computed arrays for the categories in SF Symbols app?

extension SFSymbol {
    var nature: [SFSymbol] {
        [ .flame,
        .drop,
        ...]
    }

    var version2: [SFSymbol] {
        [ .highlighter,
        .scribble.variable,
        ....]
}

For this same purpose, you can go ahead with sub-types also. But either way, if we are to provide better browsing, we have to provide all categories available in the SF Symbols app, not just v1 and v2.

[Robuske]

Just wanted to add my 2 cents.
I don't feel like categorisation (and separating in versions) should be a goal of this library, that's what the SF Symbols app is for, doesn't matter how much work you do it will never be that good for that. Adding the version as documentation helps with quickly knowing if you can use it, but I think that's it. Only other information that I think that might be useful in the documentation is if the symbol supports multicolor or not.

[fredpi]

The release of SFSafeSymbols 2 will be delayed a bit, because I want to wait for the release of macOS Big Sur. It seems like its new APIs aren't available in the Xcode 12.0 release.

[hernangonzalez]

Hi Guys,

Moving files out of /Sources/SFSafeSymbols breaks SPM. Noticed that you moved them right into Sources/.

Cheers,
H.

[fredpi]

Thanks @hernangonzalez! 👍

@hstdt has now fixed this via #57

[fredpi]

The 2.0.0 release is now finally available and adds support for v2 SF Symbols. 🎉