Apple announced that since 2022 the rules of confidentiality of the platform will change. And more recently, the company submitted a new requirement – “labeling” of applications by type of data collected.
Let’s figure out that the developer needs to be foreseen in his application or game. What rules will begin to act soon, and which – only next year.
Here you need to clarify that now the scheme works the other way around, that is, OPT out. The user by defending gives consent to the use of data until he rejected this directly. Therefore, for example, only 30% of iPhone users in the United States enjoy the right to ban on personal data processing.
Apparently this new rule Apple introduces for itself very much: in Europe, proceedings have already begun related to the compliance of the current IDFA collection process with European privacy rules (GDPR).
As of mid -November, according to Appsflyer, 37% of the market participants did not know that such changes were coming. At the same time, 74% of marketer surveys expect negative financial consequences from changes in the rules of consent to IDFA. They involve losses of identifying information about at least 50% of their consumers.
Apple recently introduced new Markers. With new changes in the application, 14 marks of work with personal data will receive – according to the types of information that is processed. What is included there:
Contact information (Name, Imail, phone number, etc.).
Data from Health, as well as fitness applications.
Delicate information (race, sexual orientation, disability, political views, religion, etc.).
List of contacts.
User data (content of messages, access to photographs, recording gameplay, etc.)
The story of the browser.
ID personalities and devices.
Data on the use of the application (in fact, all work analytics and advertising analytics).
Information about the work of the application (crams, performance, etc.).
Any other data (the most amazing category of data – that is, in fact, Apple reserves the right to interpret the term “user data” as widely as possible).
All points in the list concern not only your direct work, but also the functionality of analytical and advertising services that are built into your application or game.
What is important to include in the notification?
The goal of collecting personal data is analytics, customs of advertising and the like.
What data does your application collect from the list above.
What do you transfer to other companies – advertising networks, analytical tools, third -party SDK or other manufacturers if your application has their code.
Whether the collected data is tied to the personality, account or the device of the user.
Does your application follow the user behavior.
Yes, and now you must update your answers in the App Store Connect if something has changed in your data processing scheme.
In what cases is it not necessary to indicate the work with personal data?
The Apple Rules mention a set of conditions that the application must comply with, so as not to put the marking. You should not collect information for the purpose of the user’s “tracking” or for advertising purposes. Data can be collected irregularly, only at the request of the user, and working with personal information is not the main purpose of the application. Also, the user should be extremely obvious how and what kind of information he shares. Moreover, your application must correspond to all these conditions at the same time.
Accordingly, most likely, only an application that does not work with data can avoid marking. For example, a single -user game without advertising, registration and built -in analytics.
In a word, nothing radically needs to be done. Only attentive to the new rules and indicate all the types of data with which your application or game works. But the confidentiality policy, if you do not have it, should prepare it
Pesa application: how iOS developers automate routine tasks
We accelerate the creation and testing of new UI components, and at the same time we fix the processes.
At the end of summer, we faced the problem-the development of the UI layer of our iOS application has become unbearably long. Especially if it was a complex component that demanded to constantly run the application to check the changes in the code. Indeed, in addition to assembling the project, you also need to get to the screen where this component is used. It takes at least a minute. And so it can happen dozens of times a day. In general, a sad situation. How we left it, says iOS developer
There is a way out – Sandbox! 💡
We decided to create a separate sandwich application in which you can check the current developments and see the ready-made elements.
Our expectations were like that:
For convenience, we decided not to be wise with architecture and stopped on the option when the application has only one screen with a list of cells. And then different UI components can be connected to it. With this approach, we got several main sections: control elements (Controls), Views, cells and screens. Each of them has a set of nested screens leading to ready-made UI elements.
Now, all new and independent UI components are created in a separate lightweight module/library, which can be used both in our sandbox and the main Joom application.
It became easier to live. It would seem that we have achieved our goal – we accelerated the development of UI and we can calmly develop the product further … But the heart suggested that now we are able to solve other problems!
Cype of bugs in nature ♻
The least we want our users to face a bad or crooked interface in the application. And we also do not like to spend time QA commands on the search and run of routine scenarios, where UI gets out of control and behaves incorrectly, for example, in small devices or in foreign languages. We also support Right-to-Left (RTL) Localization, in which the interface should be displayed mirror. With this variety of content, the risk is not to keep track of a special case (for example, the iPhone SE in combination with Arabic local) is quite high.
(And there were many such thickets)
We tried to add check lists so that the developers once again see a reminder of the need to check the interface on various sizes of devices and localizations. But the tangible effect did not take it. Therefore, sometimes communication with the testing team looked something like this: