我的技术分享

Appearance

一句话结论 ​

不能。iOS 在系统与审核层面不提供也不允许获取“跨应用/跨安装/跨设备”的稳定唯一标识。你能拿到的只有在特定前提下“较稳定”的替代物（如 IDFV、Keychain 自生成 UUID、经用户授权的 IDFA）以及隐私友好型的归因/信誉能力（如 SKAdNetwork、DeviceCheck、App Attest）。核心原因：IDFA 需 ATT 授权，IDFV 受卸载规则影响，指纹识别被明令禁止。(Apple Developer)

主流“标识/信号”一览（能否“稳定唯一”？） ​

能力是否可跨应用是否可跨安装是否可跨设备说明
IDFA✅（同意后）✅（用户可随时关闭、重置）❌iOS 14.5+ 必须先获 ATT 授权，拒绝则返回不可用/全零。用于广告归因而非强绑定身份。(Apple Developer)
IDFV✅（同开发者 Team）❌❌当设备上同一开发者的所有 App 被删光后再装，IDFV 会变化（Apple 文档明确）。(Apple Developer)
Keychain 自生成 UUID❌通常 ✅❌实践上多次重装仍在，但非官方保证，在抹除设备/恢复/重置钥匙串等情况下会丢失；不要当作强承诺。(苹果支持)
DeviceCheck（二进制 2 位 + 令牌）✅（同开发者 Team）✅❌由 Apple 服务器保存每设备两位状态，可跨重装，用于“每设备限领”“反作弊基线”。不是 ID。(Apple Developer)
App Attest（设备内密钥对）✅（同应用）❌❌用来证明“请求来自你真 App + 真设备环境”，密钥不随重装保留，更像完整性证明而非 ID。(Apple Developer)
推送 Token✅（同开发者可收集）❌❌可能随系统/账号/还原而变，不能当唯一 ID。（官方未承诺稳定性）
SKAdNetwork / AdAttributionKit———聚合归因，无设备级 ID，隐私优先，不需 ATT。(Apple Developer)

结论：没有一个选项能满足“三跨”（跨应用/跨安装/跨设备）的绝对稳定唯一。

为什么做不到“稳定唯一”？ ​

  1. 政策与审核：Apple 明确禁止通过收集多种设备信号进行指纹识别，无论用户是否同意跟踪都不允许；并用隐私清单 + 必填理由 API强力约束。(Apple Developer)

  2. API 设计：

    • IDFA受 ATT 管控；用户拒绝即不可用。(Apple Developer)
    • IDFV天生绑定“设备 × 开发者”，按文档规定满足条件就会变。(Apple Developer)
    • Keychain适合保存敏感“小数据”，但未文档化保证“卸载后仍在”的行为，不能当契约写进需求。(苹果支持)

2025 年主流、合规的“设备识别/反作弊/归因”组合拳 ​

目标：够用且合规，实现“同设备再来能识别、用户不授权也能基本控滥用、广告可归因”。

  1. 基础安装标识（侧重可用性）

    • 采用 IDFV（优先） + Keychain 自生成 UUID（兜底），仅存哈希（加盐）用于去标识化统计与“安装级”识别。不要把它当“永不变”的强 ID。(Apple Developer)

  2. 广告与增长

    • 若用户授权 ATT → 用 IDFA；未授权 → SKAdNetwork/AdAttributionKit 做聚合归因，避免用户级跟踪。(Apple Developer)

  3. 反作弊与完整性

    • DeviceCheck：跨重装维持“每设备 2bit 状态”（如是否已领过新人礼包）。
    • App Attest：校验 App 与设备环境的完整性（反注入/模拟/批量刷）。注意重装即“从头开始”。(Apple Developer)

  4. 账号体系优先

    • 从设备标识转向账号标识（含 Passkeys 登录），跨设备、跨平台的稳定性来自账号而非设备。

  5. 合规红线

    • 指纹识别禁止；使用“可能被滥用”的 API 需在隐私清单中声明合法理由。(Apple Developer)

适配你现有 Swift 代码的微调建议（只给改动片段，复杂逻辑上方含注释） ​

你的整体思路对路：IDFV/Keychain + 可选 IDFA，并做加盐哈希与策略。下面是若干稳健性/合规性细节小修。

swift
// 复杂逻辑：避免在主线程阻塞等待 ATT；且用授权状态判断，不再依赖 isAdvertisingTrackingEnabled
@objc public static func getIDFAOrNull(_ requestATT: Bool) -> String? {
    if #available(iOS 14.5, *), requestATT,
       ATTrackingManager.trackingAuthorizationStatus == .notDetermined {
        // 在后台队列同步等待，但调用方请勿在主线程直接调用此方法
        let sem = DispatchSemaphore(value: 0)
        DispatchQueue.global().async {
            ATTrackingManager.requestTrackingAuthorization { _ in sem.signal() }
        }
        _ = sem.wait(timeout: .now() + 2.5) // 稍放宽等待时间
    }
    if #available(iOS 14.5, *) {
        guard ATTrackingManager.trackingAuthorizationStatus == .authorized else { return nil }
    }
    let id = ASIdentifierManager.shared().advertisingIdentifier.uuidString
    let stripped = id.replacingOccurrences(of: "-", with: "").replacingOccurrences(of: "0", with: "")
    return stripped.isEmpty ? nil : id
}
swift
// 复杂逻辑：方法名更准确；保留旧别名避免上层改动
@objc public static func prefetchIdfaAfterConsent() {
    _ = getIDFAOrNull(true)
}
// 兼容旧安卓同名别名（避免破坏现有调用）
@objc public static func prefetchOaidAfterConsent() {
    prefetchIdfaAfterConsent()
}
swift
// 复杂逻辑：cacheKey 加上 policy，确保不同策略下缓存不串
private static func cacheKey(optionsJson: String, exposeRaw: Bool) -> String {
    let pol = (try? parseOptions(optionsJson))?.policy ?? "global"
    return "o:\(optionsJson)#p:\(pol)#c:\(consent ? 1 : 0)#s:\(strict ? 1 : 0)#x:\(exposeRaw ? 1 : 0)#salt:\(salt)"
}
swift
// 复杂逻辑：对 IDFA 的 IdValue 也允许受控暴露原值（默认 false），与其它源对齐
if includeEff.contains("idfa") {
    let idfa = effectiveStrict ? nil : getIDFAOrNull(opts.requestATT)
    let limited = (idfa == nil)
    let msg = limited ? "no-permission-or-limited" : nil
    // 将 exposeRaw 传入，而不是强制 false
    result["idfa"] = buildValue(source: "idfa", value: idfa, exposeRaw: opts.exposeRaw, limited: limited, msg: msg)
}

额外提示

  • 不要在主线程里调用会等待 ATT 的方法，避免卡 UI。
  • isAdvertisingTrackingEnabled 在 ATT 时代并非决定性信号，以 ATTrackingManager 状态为准。(Apple Developer)

推荐的最小可行方案（MVP 落地顺序） ​

  1. 服务端建模：install_id（Keychain UUID 的加盐哈希） + id_source（idfv/guid/idfa…）+ first_seen_ts。
  2. 客户端策略：policy: "cn" 下默认 ["idfv","guid"]；"global" 才考虑 idfa。你代码已支持。
  3. 增长归因：集成 SKAdNetwork/AdAttributionKit；用户授权后再启用 IDFA 路径。(Apple Developer)
  4. 反作弊：上线 DeviceCheck 的 2bit 状态（如 hasClaimed / isFlagged），关键流程用 App Attest 做请求完整性校验。(Apple Developer)
  5. 合规：在隐私清单中申报“必填理由 API”，并不要实现任何“设备指纹”。(Apple Developer)

关键参考 ​

  • IDFA 需 ATT 授权与获取限制。(Apple Developer)
  • IDFV 的变更规则（删除同 Vendor 的所有 App 后会变）。(Apple Developer)
  • Keychain 是敏感小数据的安全存储，但卸载持久性非官方契约（工程圈普遍观察到“多次重装仍在”）。(苹果支持)
  • DeviceCheck / App Attest 的用途与持久性特征。(Apple Developer)
  • SKAdNetwork/AdAttributionKit 做隐私友好型归因。(Apple Developer)
  • 禁止设备指纹与隐私清单“必填理由 API”。(Apple Developer)

小结 ​

  • 没有“一把通吃、永不变”的 iOS 设备唯一标识。
  • 工程上用 IDFV + Keychain UUID（哈希） 做“安装级”识别，授权后再用 IDFA；归因走 SKAdNetwork；反作弊以 DeviceCheck/App Attest 为主；长期稳定靠账号体系。
  • 合规优先：别做指纹识别；把隐私清单与 ATT 路径打通，体验与审核两不误。

本站总访问 — 次