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

[IgorFedorchuk]

Всегда думал что самый популярный способ получения идентификатора девайса, пришедший на смену 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;
}

[sadsmile]

А не лучше использовать [[UIDevice currentDevice] identifierForVendor], и уже его записывать в keychain?
Это может быть полезно если есть несколько приложений на одном устройстве.

[IgorFedorchuk]

Предложеный Вами подход также имеет право на существование. Все зависит от целей, для которых нужен UDID. Вот ссылка на статью, в которой описываются плюсы и минусы разных подходов для получения идентификатора девайса.

[Jihar]

Сегодня отказали в публикации, сославшись на этот же пункт правил, с таким же текстом итд. Возможно из-за TestFlight, сами advertisingIdentifier не использовали, да и AdSupport.framework не линкуется в проект.

[Jihar]

Причина оказалась во Flurry — использовалась версия 4.2.4, в ней «strings» показывает использование ASIdentifierManager и, собственно, advertisingIdentifier. Версия 4.3.1 от этих проблем избавлена. Советую обновиться :)

[Jihar]

Апдейт — похоже ошибся, 4.3.1 точно так же использует ASIdentifierManager.

[scorcher]

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 пока нету новой версии.

Попробуем загрузить приложение.

[scorcher]

ну и собственно релиз был только ради этого:

Version 4.3.2 ­ 02/06/2014
Addressed issue related to referencing IdentifierForAdvertisers that could lead to app being flagged during Apple review process.

[Triang3l]

А всё потому, что Parse и TestFlight IDFA используют совместно с IDDQD, а Mixpanel — нет.

[WaveCut]

IDKFA и NOCLIP не запрещены!

[pewpew]

IDCLIP же

[WaveCut]

Совершенно верно! Вот вам за внимательность :)

[KorDen32]

Parse и TestFlight не берут ключи, ограничиваясь full ammo, а Mixpanel видимо решили и ключи взять — на этом и погорели

[Viktorianec]

Сбросьте, пожалуйста ссылку на статью про запрет получения mac-адресов, показать коллегам. Заранее спасибо.

[im_berzki]

вот, например

и конкретно про MAC

[Viktorianec]

Ещё раз благодарю.

[mOlind]

С mac адресом они поступили совсем просто: там теперь выдаются нули. Мы генерили UUID пользователя с использованием mac-a, а потом удивлялись почему это у нас так много пользователей с одинаковым ID. :) Теперь выдаем новым пользователям GUID не привязанный ни к чему, как описано в первом комменте.

[risik]

Да что же такое-то, а? :)
Apple не дает разработчикам сидеть без работы. А есть ссылка на англоязычный вариант новости? Для партнеров.

[Apps4All_post]

Вот тут, например.

[Jihar]

Согласен :)
Сначала iOS7, теперь AdSupport, на очереди — вот-вот — arm64.

[egormerkushev]

Так, а что на счет Flurry?

[purrrminator]

Flurry не требует adSupport, а вот Google Analytics требует. Интересно, что будет с ним

[egormerkushev]

Выше пишут

Сегодня отказали в публикации, сославшись на этот же пункт правил, с таким же текстом итд. Возможно из-за TestFlight, сами advertisingIdentifier не использовали, да и AdSupport.framework не линкуется в проект.

[dude1phoenix]

Да, Google Analytics интересует больше всего.

[Jihar]

Ответил чуть выше — habrahabr.ru/company/apps4all/blog/211300/#comment_7273350

[dude1phoenix]

А добавьте UPD с ссылками на то, что уже точно будет заблокировано (как выяснилось)
* Flurry в случае неактуальной версии и пр.

[Skie]

Зарежектили из-за последней версии Flurry 4.3.1, других вариантов нет.
Советую проверить либы в теримнале по подобию:

strings Flurry/libFlurry_4.3.1.a | grep advertisingIdentifier