我面临着类似的问题。以下是我提出的解决方案 - 我自己将实施第二个。
第一个解决方案:
编辑:正如 John Ballinger 在下面的评论中指出的那样,UIDevice-with-UniqueIdentifier-for-iOS-5 的作者 gekitz 将其许可证更改为 MIT :) 谢谢 John!
如果您只需要一个可靠的 UDID 替代品,试试这个,请注意它的许可证。您也可以在 GitHub 上搜索其他解决方案。
第二种解决方案:
对此解决方案的更新:我放弃了这个想法,因为太多开发人员告诉我它会违反 HIG。
更加灵活,允许与您的附属公司一起跟踪安装活动(例如,通过为每个附属公司分配一个特定的“UDID”值,您可以稍后在安装应用程序并将“UDID”发送到您的服务器后检查)。
SO 用户:请让我们知道以下任何一项是否可能违反 HIG 并实际上导致申请被拒绝(尤其是步骤 5、6 和 7)。
- 准备一个指向执行脚本的页面的链接,该脚本会留下一个唯一值的 cookie(例如,由您的服务器生成的“UDID”)。
- 用户在 Mobile Safari 中点击该链接。脚本存储 cookie,然后使用您的应用程序重定向到 iTunes 页面(例如
http://itunes.apple.com/us/app/skype/id304878510?mt=8&uo=4)。
- App Store 应用程序启动并显示您的应用程序的页面。
- 用户安装应用程序并启动它。
- 在第一次启动时:在启动后,您会显示一个警告,要求用户激活应用程序(只需一个按钮就足够了,例如“激活”)。
- 注意:您需要确保当应用程序进入后台并恢复时警报仍然可见。另外,你需要有
- 用户点击“激活”,您的应用程序退出/暂停,iOS 打开 Safari 并转到页面(例如,在您的应用程序中硬编码的链接),该页面读取 cookie 值(我们的“UDID”)并使用 URL 方案启动您的应用程序传递“ UDID”值。
- 注意:您需要允许 Safari 打开该链接(可能需要一些额外的编码,不确定);
- 我相信某些带有 EULA 的页面(例如)必须呈现给用户和一个允许继续的按钮,所以用户体验对用户来说是清楚的(即没有经验让应用程序离开打开 safari 并且在第二个 safari 退出并打开之后你的应用程序)。
- 应用程序启动/恢复,存储“UDID”并解锁允许显示主 UI 等的应用程序。
- 现在,您可以在向统计服务器等生成事件时使用存储的“UDID”。
- 您可以稍后通过共享链接(在我的情况下是在时事通讯中分发的应用程序的 URL 方案链接)来更新/删除您的“UDID”,这将打开您的应用程序并传递新值。
注意:您需要涵盖许多边缘情况,例如使用(或不使用)URL 方案或推送通知等启动/恢复应用程序。
PS出去一段时间,但稍后会检查您的反馈。谢谢!