(This is not a tutorial)
DeviceCheck was introduced with iOS 11, it allows developers to check whether or not a user is in one of four custom states. All states are decided by the developer. DeviceCheck was introduced to allow developers to properly identify and classify their users across all of the developer’s apps and regardless of whether or not the user deleted any of their apps. There are a number of uses, but they commonly relate to monetization and social. Should you offer a new user deal in-app and want to ensure users cannot delete, re-download, and access that deal again, DeviceCheck is your solution. If you offer a social app and want to ensure users who violate your terms are unable to access your service for as long as possible (until they get a new phone) DeviceCheck is your solution.
Prior to DeviceCheck and even today, developers would implement so-so or highly-reprimandable-in-Apple’s-view methods of identifying users, the biggest example of which involved Uber up until 2017 or so. Among the so-so solutions were to use the unique, but non-permanent and sometimes non-existent Advertising Identifier for each user. Alternatively, some developers would store information in keychain, but that information would be deleted once the app was deleted. The highly reprimandable actually involved accessing the unique IMEI/serial of each phone. DeviceCheck has been the perfect answer for all parties. It offers permanence for developers but ensures privacy, making both Apple and users happy. The issue developers run into to is implementing it.
DeviceCheck requires communication with Apple’s servers, meaning you must have a server on your side to implement it at all. For developers working outside of large companies, spending time to understand implementation can appear unattractive. In reality, implementation can be really easy and in a way, serverless. For my own project (social), I stuck it out because the quality of users would be non-negotiable for the app’s success.