Из App Store удаляют приложения, использующие IDFA, но не показывающие рекламу

    Вчера Хабр писал о том, что Google Play стал удалять приложения за альтернативные способы приёма платежей, а сегодня стало известно, что Apple на минувшей неделе также начала вычищать App Store. Удалению подверглись приложения, которые получали IDFA (Identifier for Advertisers) пользователей, но не показывали ему никакой рекламы. IDFA сейчас самый популярный способ отслеживания пользователей на платформе, идентификатор пришел на смену UDID.

    Весь 2013 год прошел для Apple под знаком перевода разработчиков на его использование – компания запрещала приложения с куки, получение MAC адресов устройств и т.п. Сейчас, когда большинство приложений перешли на него, Apple идет дальше и начинает учить разработчиков правильному его использованию.



    В пункте правил 3.3.12 Apple прямо указывает, что идентификатор может использоваться только для обслуживания рекламы. Однако, например, Tapstream, чьи приложения были удалены в пятницу, объясняет, что IDFA сейчас используется для массы других целей, например для отслеживания установок, пользовательской аналитики.

    Его, к примеру, использует Mixpanel – соответственно приложения с интегрированной аналитикой компании также подверглись запрету. «Мы определили, что ваше приложение использует iOS Advertising Identifier, но не включает рекламы. Это не соответствует правилам», — написала Apple разработчикам.

    Apple советует им проверить код и сторонние библиотеки на вхождение такого кода:

    class: ASIdentifierManager
    selector: advertisingIdentifier
    framework: AdSupport.framework
    

    по возможности удалив его.

    Кроме Mixpanel, у которой, кстати, есть и альтернативный ID, IDFA работает в Parse и TestFlight, однако о бане их приложений пока ничего не известно.

    Лежащая на поверхности причина для «ужесточения» правил по использованию IDFA – забота о безопасности пользователей и их данных. С другой стороны есть мнение, что такой шаг скажется на всей мобильной рекламной индустрии и даст преимущества Apple iAd. Кроме того некоторые говорят, что такой шаг это борьба с платежными сервисами, типа Stripe, Braintree и PayPal, которые могут использовать IDFA для идентификации пользователей и устройств. Наконец, есть идея, что этот шаг может заставить издателей перейти от CPI модели с CPC, и тем самым, опосредованно, помочь Apple в борьбе с накрутками рейтингов, еще одной темой, с которой Apple давно уже борется.
    Apps4All
    56.26
    Company
    Share post

    Comments 27

      +7
      Всегда думал что самый популярный способ получения идентификатора девайса, пришедший на смену UDID, такой

      +(NSString *)generateUUID
      {
          CFUUIDRef theUUID = CFUUIDCreate(NULL);
          CFStringRef string = CFUUIDCreateString(NULL, theUUID);
          CFRelease(theUUID);
          NSString *uuid = (__bridge NSString *)string;
          [SSKeychain setPassword:uuid forService:[[NSBundle mainBundle] bundleIdentifier] account:userAccaunt];
      
          return uuid;
      }
      
        0
        А не лучше использовать [[UIDevice currentDevice] identifierForVendor], и уже его записывать в keychain?
        Это может быть полезно если есть несколько приложений на одном устройстве.
          0
          Предложеный Вами подход также имеет право на существование. Все зависит от целей, для которых нужен UDID. Вот ссылка на статью, в которой описываются плюсы и минусы разных подходов для получения идентификатора девайса.
        0
        Сегодня отказали в публикации, сославшись на этот же пункт правил, с таким же текстом итд. Возможно из-за TestFlight, сами advertisingIdentifier не использовали, да и AdSupport.framework не линкуется в проект.
          +1
          Причина оказалась во Flurry — использовалась версия 4.2.4, в ней «strings» показывает использование ASIdentifierManager и, собственно, advertisingIdentifier. Версия 4.3.1 от этих проблем избавлена. Советую обновиться :)
            0
            Апдейт — похоже ошибся, 4.3.1 точно так же использует ASIdentifierManager.
              0
              rugionpro:Afisha n$ strings ./Pods/FlurrySDK/Flurry/libFlurry_4.3.1.a  | grep advertisingIdentifier | wc -l
                     1
              rugionpro:Afisha n$ strings ~/Flurry-iOS-4.3.2/Flurry/libFlurry_4.3.2.a  | grep advertisingIdentifier | wc -l
                     0
              


              Разродился Flurry на апдейт, но в cocoapods пока нету новой версии.

              Попробуем загрузить приложение.
                0
                ну и собственно релиз был только ради этого:
                Version 4.3.2 ­ 02/06/2014
                Addressed issue related to referencing IdentifierForAdvertisers that could lead to app being flagged during Apple review process.
          +8
          А всё потому, что Parse и TestFlight IDFA используют совместно с IDDQD, а Mixpanel — нет.
            +9
            IDKFA и NOCLIP не запрещены!
              +7
              IDCLIP же
                +5
                Совершенно верно! Вот вам за внимательность :)
                image
              +3
              Parse и TestFlight не берут ключи, ограничиваясь full ammo, а Mixpanel видимо решили и ключи взять — на этом и погорели
              +3
              Сбросьте, пожалуйста ссылку на статью про запрет получения mac-адресов, показать коллегам. Заранее спасибо.
                  +1
                  Ещё раз благодарю.
                  0
                  С mac адресом они поступили совсем просто: там теперь выдаются нули. Мы генерили UUID пользователя с использованием mac-a, а потом удивлялись почему это у нас так много пользователей с одинаковым ID. :) Теперь выдаем новым пользователям GUID не привязанный ни к чему, как описано в первом комменте.
                  0
                  Да что же такое-то, а? :)
                  Apple не дает разработчикам сидеть без работы. А есть ссылка на англоязычный вариант новости? Для партнеров.
                    +1
                    Вот тут, например.
                      0
                      Согласен :)
                      Сначала iOS7, теперь AdSupport, на очереди — вот-вот — arm64.
                      0
                      Так, а что на счет Flurry?
                        0
                        Flurry не требует adSupport, а вот Google Analytics требует. Интересно, что будет с ним
                          0
                          Выше пишут
                          Сегодня отказали в публикации, сославшись на этот же пункт правил, с таким же текстом итд. Возможно из-за TestFlight, сами advertisingIdentifier не использовали, да и AdSupport.framework не линкуется в проект.
                            +1
                            Да, Google Analytics интересует больше всего.
                            0
                            0
                            А добавьте UPD с ссылками на то, что уже точно будет заблокировано (как выяснилось)
                            * Flurry в случае неактуальной версии и пр.
                              +1
                              Зарежектили из-за последней версии Flurry 4.3.1, других вариантов нет.
                              Советую проверить либы в теримнале по подобию:
                              strings Flurry/libFlurry_4.3.1.a | grep advertisingIdentifier
                              

                              Only users with full accounts can post comments. Log in, please.