What's the difference between iOS 12 and iOS 13 when it comes to including emoji via its code point

user_3943106 0
Viewed 51

Before we start, I'd like to clarify...

  • This question isn't about how to include emoji on labels. I'm aware that has been asked and answered before. I am able to get the emoji on the label just fine.
  • This question isn't about whether we can/should include emoji on labels. I am aware of the issues around that too. We'll discuss as a team whether we want to proceed with emoji, but it doesn't make me any less curious about the issue below.

With the disclaimers out of the way, our situation is as follows: We have an iOS app that deploys back to iOS 12. In it, we'd like to include the warning sign on a UILabel to signal certain situations. The text of the label comes from this bit of code (including picture, because pasting emoji doesn't come through): enter image description here

This line isn't setting someLabel.text directly but it's the relevant bit. I can promise you that surrounding code simply prepends this snippet to other text and slaps it onto a label.

The first character of that literal string at the end of the line is the "warning sign" emoji inserted into the source code via hitting Ctrl+Cmd+Space and choosing it from the resulting picker. Then we have the unicode code point \u26A0.

I get the following when this code runs: enter image description here

At this point I'm really curious about...

  • What changed between iOS 12.4 and 13.7 such that the same source code produces different output? Was the different treatment of unicode code points announced somewhere on some release notes?
  • Is one side somehow "more correct"? Does the "yellow-triangle-with-black-exclamation-in-it" symbol and \u26A0 technically represent different things, iOS 12 mistakenly visualized them as the same, and iOS 13 fixed that issue? Or vice versa; they are actually meant to represent the same thing, iOS 12 did so, and iOS 13 broke something? Or does the concept of correctness not even apply, since they are different representations?
  • Is there any code point I can type into my source file (e.g. \u<something>) that will render as the yellow-triangle-with-black-exclamation-in-it emoji consistently on iOS 12 and later? If so, what is it? If not, is using the actual emoji in my source code the only way to achieve this?
unicode objective-c ios
2 Answers

There are two variants, 26a0fe0f and 26a0fe0e. The former is the emoji variant; the latter is the text variant. In iOS 13 you are using both of them. I don't know why it chooses the second one as a fallback in iOS 13 but the first one as a fallback in iOS 12; the iOS 13 behavior seems more correct to me.

user_3419940

I think I figured it out, but leaving question and answer up in case it helps others.

The crux of the issue is that the "yellow-triangle-with-black-exclamation-in-it" symbol and the "black-bordered-triangle-with-black-exclamation" symbols are not the same entity. We see these in the character viewer built into macOS: enter image description here enter image description here

And sure enough, the representation \u26A0\uFE0F renders as "yellow-triangle-with-black-exclamation-in-it" on both iOS versions: enter image description here

If \u26A0 wasn't supposed to be the "yellow-triangle-with-black-exclamation-in-it" emoji, I still can't explain why it renders as such on iOS 12...

Credit actually belongs to user matt. He had a comment which hinted at these being different, which led me down this path. The comment is no longer there for some reason (got deleted?) so I don't know how to properly attribute.

user_39431060
Related