{"id":62233,"date":"2023-11-28T19:01:11","date_gmt":"2023-11-28T17:01:11","guid":{"rendered":"https:\/\/koninis.me\/?p=62233"},"modified":"2023-11-29T12:39:28","modified_gmt":"2023-11-29T10:39:28","slug":"the-case-of-apples-changing-identifierforvendor","status":"publish","type":"post","link":"https:\/\/koninis.me\/index.php\/2023\/11\/28\/the-case-of-apples-changing-identifierforvendor\/","title":{"rendered":"The case of Apple’s changing identifierForVendor"},"content":{"rendered":"\n

We had a case where a client reported a bug in our iOS application, affecting all its users<\/strong>, after publishing an update that had unrelated code changes. We traced the problem on the fact that the identifierForVendor value suddently started to returned different value, due to a change unrelated with our release that was undocumented.<\/p>\n\n\n\n

\n\n<\/div><\/div>\n\n\n\n

According to Apple’s documentation for the identifierForVendor <\/p>\n\n\n\n

\n

The value of this property is the same for apps that come from the same vendor running on the same device.<\/p>\n\n\n\n

The value in this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor\u2019s apps from the device and subsequently reinstalls one or more of them.<\/p>\nApple’s documentation<\/a><\/cite><\/blockquote>\n\n\n\n

However this is not the full story. There are other cases where it changes and it is not obvious<\/em> but provide some insight to the inner workings of the algorithm that produces the identifierForVendor. <\/p>\n\n\n\n

It turns out that the client that faced the problem had changed its legal name and then had requested Apple to change the name used in its developer account. And this caused the identifierForVendor suddenly to return an other value after an new release was published signed with the new Distribution Certificate(referencing the new account name). <\/p>\n\n\n\n

We contacted Apple support for this and their response is that this behaviour is not documented but it is resonable<\/strong> of a developer to assume it. Specifically Apple’s support response was<\/p>\n\n\n\n

\n
\n

Although the IdentifierForVendor documentation only states that the identifierForVendor value is “determined by data provided by the App Store”, it’s reasonable to assume<\/strong> that the data provided by the App Store includes the vendor name, and that a change to the vendor’s name will result in a different identifierForVendor value when the app is updated.  As the documentation states, removal of all of the apps from a single vendor and subsequently reinstalling one or more apps from that vendor will also result in a new identifierForVendor value:<\/p>\n\n\n\n

https:\/\/developer.apple.com\/documentation\/uikit\/uidevice\/1620059-identifierforvendor\/<\/a><\/p>\n<\/blockquote>\nEmail correspondance with Apple support<\/cite><\/blockquote>\n\n\n\n


It is obvious from the Apple’s support answer that the documentation does not mention clearly when the identifieForVendor changes, so we are only left with making reasonable assumptions. To avoid making\u00a0assumptions<\/strong>\u00a0(reasonable or not) we should have a proper documentation. I should note that as the documentation states we should handle changes in the identifieForVendor gracefully. <\/p>\n\n\n\n

Perhaps someone should fork Apple’s documentation<\/strong> and accept PRs to improve it with rich examples and missing undocumented behaviour.<\/p>\n","protected":false},"excerpt":{"rendered":"

We had a case where a client reported a bug in our iOS application, affecting all its users, after publishing an update that had unrelated code changes. We traced the problem on the fact that the identifierForVendor value suddently started to returned different value, due to a change unrelated with our release that was undocumented.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_crdt_document":"","jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"everybody","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[45,1],"tags":[48,46,47],"class_list":["post-62233","post","type-post","status-publish","format-standard","hentry","category-apple","category-uncategorized","tag-api","tag-apple","tag-documentation"],"jetpack_featured_media_url":"","jetpack-related-posts":[],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/koninis.me\/index.php\/wp-json\/wp\/v2\/posts\/62233","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/koninis.me\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/koninis.me\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/koninis.me\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/koninis.me\/index.php\/wp-json\/wp\/v2\/comments?post=62233"}],"version-history":[{"count":12,"href":"https:\/\/koninis.me\/index.php\/wp-json\/wp\/v2\/posts\/62233\/revisions"}],"predecessor-version":[{"id":186565,"href":"https:\/\/koninis.me\/index.php\/wp-json\/wp\/v2\/posts\/62233\/revisions\/186565"}],"wp:attachment":[{"href":"https:\/\/koninis.me\/index.php\/wp-json\/wp\/v2\/media?parent=62233"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/koninis.me\/index.php\/wp-json\/wp\/v2\/categories?post=62233"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/koninis.me\/index.php\/wp-json\/wp\/v2\/tags?post=62233"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}