Inserting a SF Symbol in a textField or a Label, as text

In UIKit, Swift, I would need to insert a SF Symbol into a textField or a label.

The symbol shows correctly in Xcode (in a string in code or in IB).

But at runtime, the symbol is not found and replaced in the TextField by the unfound symbol:

Is there a way to achieve this and display the symbol as a pure string, like we do with emoji ?

Answered by Etresoft in 902661022

Interesting to know it works on Mac (even when running as iPadOS).

I wouldn't rely on that. I'm sure its all based on Unicode, fonts, and font cascade lists - none of which are API. Sure, these things exist in the API, but there's no guarantee that the OS will have it configured to properly display your Unicode string in all cases.

Using NSAttributedString and NSAttachment is pretty impractical.

It's really not that difficult. And when you build it with attachments, you have full control over how it gets displayed.

That should be handled by the compiler, to generate the required code. I filed a bug report for suggestion FB24474671.

It already does. SF Symbols show up in the text under a private use area Unicode. It looks like the fonts on iOS don't include these symbols, whereas they do on macOS. That one pen example above is an actual Unicode symbol, so it does show up properly.

Apple certainly could add SF Symbols to iOS fonts like they did on macOS.

In my opinion, it's much better to just stick to plain ascii. All of my strings are (x)html snippets. That way, I can control everything about them. Yes, I did have to write the code to add attachments to an attributed string. But I only had to do that once.

I also had to write a parser for xhtml, but that wasn't too difficult either. Earlier I had made the mistake of using the built-in API on macOS. But it was horribly slow and broke one day on a minor OS release. In the process, I learned why it was so slow. It was an out-of-process XPC call.

It's always better to stick to the lowest-level interface that you can practically use. I've been burned so many times it's unreal.

display the symbol how? In what context?

You said "button" and buttons already have image support.

I would never use anything other than plain ASCII in source code. That's begging for trouble. But Xcode encourages it and obviously displays it as rich text, with different colours too. You can display rich text with attachments. Maybe that's how Xcode is doing it.

Something like the following? I wrote it in conjunction with UIViewRepresentable a few days ago.

let sunButton = UIButton(type: .system)
let symbolConfig = UIImage.SymbolConfiguration(pointSize: 24, weight: .medium)
let sunImage = UIImage(systemName: "sun.max.fill", withConfiguration: symbolConfig)
sunButton.setImage(sunImage, for: .normal)
sunButton.tintColor = .yellow

You need to use an NSAttributedString with an NSTextAttachment and pass in a symbol image into the UIImage initializer. Don’t use copied symbols as text from the SF Symbols app, that is intended to be used for design and prototyping purposes only, and relies on an installed font that comes with the SF Symbols app that isn’t normally available on Apple devices.

@etresoft @Tomato The context is to write a text in a textField. Not in a button (sorry if the capture was very confusing, it was a text explaining which button it is).

So in code:

theTextField.text = "a text with a symbol inside as we can do with emoji 🖊️"

Effectively, I would like to do as Xcode does.

Interesting. All of this works fine on the Mac.

But on iOS, some symbols work and some symbols don't. You'll have to do it the old fashioned way as Frameworks Engineer described.

@Etresoft Interesting to know it works on Mac (even when running as iPadOS).

Using NSAttributedString and NSAttachment is pretty impractical. That should be handled by the compiler, to generate the required code.

I filed a bug report for suggestion FB24474671.

Accepted Answer

Interesting to know it works on Mac (even when running as iPadOS).

I wouldn't rely on that. I'm sure its all based on Unicode, fonts, and font cascade lists - none of which are API. Sure, these things exist in the API, but there's no guarantee that the OS will have it configured to properly display your Unicode string in all cases.

Using NSAttributedString and NSAttachment is pretty impractical.

It's really not that difficult. And when you build it with attachments, you have full control over how it gets displayed.

That should be handled by the compiler, to generate the required code. I filed a bug report for suggestion FB24474671.

It already does. SF Symbols show up in the text under a private use area Unicode. It looks like the fonts on iOS don't include these symbols, whereas they do on macOS. That one pen example above is an actual Unicode symbol, so it does show up properly.

Apple certainly could add SF Symbols to iOS fonts like they did on macOS.

In my opinion, it's much better to just stick to plain ascii. All of my strings are (x)html snippets. That way, I can control everything about them. Yes, I did have to write the code to add attachments to an attributed string. But I only had to do that once.

I also had to write a parser for xhtml, but that wasn't too difficult either. Earlier I had made the mistake of using the built-in API on macOS. But it was horribly slow and broke one day on a minor OS release. In the process, I learned why it was so slow. It was an out-of-process XPC call.

It's always better to stick to the lowest-level interface that you can practically use. I've been burned so many times it's unreal.

Inserting a SF Symbol in a textField or a Label, as text
 
 
Q