Emoji in the interface of iOS applications and Apple requirements
I was not surprised to find in the search output on Habr publications on the problem of using emoji in the interface of applications published in the App Store blessed Apple. So I apologize in advance if you repeat.
The essence of the problem is that Apple prohibits the use of emoji in the application interface. Apparently it started around autumn 2018 (at least in the spring of 2018 ). But, perhaps, before, I did not go deep into the chronology of the problem. The Internet is filled with messages from developers whose applications are denied due to emoji in the application interface. Moreover, even the updates of previously published applications are wrapped! Some report a publication failure due to the presence of emoji in the application screenshots! Typically, Apple’s failure looks like:
Agree, quite an interesting position from a company that was one of (if not the only) founders of the popularization of emoji ... Under the cut, I will put forward a couple of assumptions about the causes and a couple of ways to solve the problem. In particular, how I ended up published in the App Store with an app in which emoji was originally the main idea.
I think that the main reason for the ban is not copyright, as it may seem from Apple’s response. Although using third-party emoji helps to get around the problem, I do not think that this is the root of the problem. In the end, the application is published on the company's site. She gets interest from sales. At the same time, it also develops and provides a development environment, programming languages and frameworks to simplify and speed up the creation of software. Having issued all this, but prohibiting the use of pictures from the font seems like a strange push on copyright. It is not logical for a perfectionist company to require developers to use left-handed emoji for input and relatives for output. If the output also uses third-party emodzhi, then it will look not much less strange in the ecosystem of Apple.
I tend to think that the point is that emoji is not an icon ... Ie there are icons in the system and they can be used (when I removed emoji from the interface, but left the icons - it worked, and after all the icons are also quite copyrighted), but you can’t use your own emoji as icons! As far as I understand, developers of keyboards and input tools have no problems with emoji.
You display emoji on the button, the user presses it and it appears in the input field - it seems that this is the only scenario that Apple approves when checking the application. In all other cases, you should use full-fledged icons or other people's emoji fonts (which, apparently, are regarded by the company as icon fonts).
In fact, all this is my personal speculation, but for now they seem quite logical, because Much converges (at least in my head) ...
Based on the above, the following are the tips / tips:
Technically, in my application, emoji was used specifically for user input. But it was not obvious because the application was rejected even for public testing, not to mention the publication in the store. I'll explain now.
The meaning of the application is that the user can quickly (literally with one touch) add tags. Target audience - streamers, maybe podcasters or people leading live broadcasts. Like many application ideas, this one came about when I myself began to need something (and, like many such applications, no one needs anymore). The problem is that after the end of the stream you often want to cut the best moments. But then it is difficult to remember and find everything that was interesting. Shovel clock streams are not the most fun and needed a way to conveniently and quickly create notes in the process.
This is how the idea of “Stream Note” - an application with a set of buttons with emoji that you press as needed in the broadcast process. When pressed, the timestamp from the beginning of the broadcast and, in fact, emoji as the title / icon in the list of tags would be saved. The default application had a set of buttons with emoji for more obviousness to the user.
I suspect that the problem is that the process did not provide for the appearance of emoji in the input field and the subsequent manual dispatch. Because the point was to maximally simplify and speed up the process of creating a note, so when you press the button with emoji, a new label with this emoji just appeared in the list of tags to the stream. At the same time, emoji was displayed large (so that you could immediately see which event was noted during the subsequent analysis of materials) and did not look like the text entered by the user.
As a result, the application was rejected for public testing (I wanted to throw a link to my brother for testing, so as not to take the trouble of putting him on the team of testers on the Apple website). And if the versions for internal testing in a team become available almost instantly, then versions for public testing are tested almost as if they were published in a store. As a result, I was "shaved." What was useful, because As a result, I checked the publication in the store the first time.
I redid the manual configuration of the buttons. If earlier it was sharpened under emoji and the string of them was broken into buttons, now the user can create buttons with inscriptions. Also, buttons with emoji were excluded from the default set.
Naturally, no one forbids the use of the inscription of one character, which will be emoji. But if the name of the moment consists of one emoji, it will still be displayed on a large scale.
With such a twist, the functionality has not changed (it has even become more universal), but in the default version there is no emoji, and the user chooses what to use. What Apple can't forbid him to do.
The essence of the problem is that Apple prohibits the use of emoji in the application interface. Apparently it started around autumn 2018 (at least in the spring of 2018 ). But, perhaps, before, I did not go deep into the chronology of the problem. The Internet is filled with messages from developers whose applications are denied due to emoji in the application interface. Moreover, even the updates of previously published applications are wrapped! Some report a publication failure due to the presence of emoji in the application screenshots! Typically, Apple’s failure looks like:
From appleGuideline 5.2.5 - Legal - Intellectual Property
Your Trademarks and Copyrights. Specifically, your app includes:
')
- Apple trademark, emojis, imagery - or likeness
Agree, quite an interesting position from a company that was one of (if not the only) founders of the popularization of emoji ... Under the cut, I will put forward a couple of assumptions about the causes and a couple of ways to solve the problem. In particular, how I ended up published in the App Store with an app in which emoji was originally the main idea.
Why not?
I think that the main reason for the ban is not copyright, as it may seem from Apple’s response. Although using third-party emoji helps to get around the problem, I do not think that this is the root of the problem. In the end, the application is published on the company's site. She gets interest from sales. At the same time, it also develops and provides a development environment, programming languages and frameworks to simplify and speed up the creation of software. Having issued all this, but prohibiting the use of pictures from the font seems like a strange push on copyright. It is not logical for a perfectionist company to require developers to use left-handed emoji for input and relatives for output. If the output also uses third-party emodzhi, then it will look not much less strange in the ecosystem of Apple.
I tend to think that the point is that emoji is not an icon ... Ie there are icons in the system and they can be used (when I removed emoji from the interface, but left the icons - it worked, and after all the icons are also quite copyrighted), but you can’t use your own emoji as icons! As far as I understand, developers of keyboards and input tools have no problems with emoji.
You display emoji on the button, the user presses it and it appears in the input field - it seems that this is the only scenario that Apple approves when checking the application. In all other cases, you should use full-fledged icons or other people's emoji fonts (which, apparently, are regarded by the company as icon fonts).
In fact, all this is my personal speculation, but for now they seem quite logical, because Much converges (at least in my head) ...
What to do?
Based on the above, the following are the tips / tips:
- In the role of icons, use icons or third-party emoji fonts.
- Try not to use emoji in the app store screenshots
- Use emoji only for user input (there is also a nuance here, see the description of my situation)
- Hide emoji from the default state and allow the user to configure them.
- Create a version for public testing, in the process of checking you will be shown various problems of publication, if any
My story (with digressions)
Technically, in my application, emoji was used specifically for user input. But it was not obvious because the application was rejected even for public testing, not to mention the publication in the store. I'll explain now.
The meaning of the application is that the user can quickly (literally with one touch) add tags. Target audience - streamers, maybe podcasters or people leading live broadcasts. Like many application ideas, this one came about when I myself began to need something (and, like many such applications, no one needs anymore). The problem is that after the end of the stream you often want to cut the best moments. But then it is difficult to remember and find everything that was interesting. Shovel clock streams are not the most fun and needed a way to conveniently and quickly create notes in the process.
This is how the idea of “Stream Note” - an application with a set of buttons with emoji that you press as needed in the broadcast process. When pressed, the timestamp from the beginning of the broadcast and, in fact, emoji as the title / icon in the list of tags would be saved. The default application had a set of buttons with emoji for more obviousness to the user.
This interface was rejected:
I suspect that the problem is that the process did not provide for the appearance of emoji in the input field and the subsequent manual dispatch. Because the point was to maximally simplify and speed up the process of creating a note, so when you press the button with emoji, a new label with this emoji just appeared in the list of tags to the stream. At the same time, emoji was displayed large (so that you could immediately see which event was noted during the subsequent analysis of materials) and did not look like the text entered by the user.
As a result, the application was rejected for public testing (I wanted to throw a link to my brother for testing, so as not to take the trouble of putting him on the team of testers on the Apple website). And if the versions for internal testing in a team become available almost instantly, then versions for public testing are tested almost as if they were published in a store. As a result, I was "shaved." What was useful, because As a result, I checked the publication in the store the first time.
I redid the manual configuration of the buttons. If earlier it was sharpened under emoji and the string of them was broken into buttons, now the user can create buttons with inscriptions. Also, buttons with emoji were excluded from the default set.
App Store Version:
Naturally, no one forbids the use of the inscription of one character, which will be emoji. But if the name of the moment consists of one emoji, it will still be displayed on a large scale.
How it looks in the case:
With such a twist, the functionality has not changed (it has even become more universal), but in the default version there is no emoji, and the user chooses what to use. What Apple can't forbid him to do.
Source: https://habr.com/ru/post/456542/
All Articles