Deep Links no iOS com Swift: Info.plist, AppDelegate e Universal Links — sem pacote (Parte 3)

Seguindo a série sobre deep links em Flutter sem pacote. Desta vez: iOS nativo.

A lógica é a mesma do Android. As APIs são completamente diferentes.

---

No Post 3 implementei:

• Info.plist com CFBundleURLTypes para registrar o custom scheme (fitconnect://)
• Runner.entitlements com Associated Domains para Universal Links
• AppDelegate.swift com:
  • FlutterMethodChannel → link no cold start
  • FlutterEventChannel → stream com app aberto
  • open url → custom scheme
  • continue userActivity → Universal Links

// Custom scheme
override func application(_ app: UIApplication,
    open url: URL,
    options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
    handleDeepLink(url: url, isInitial: false)
    return super.application(app, open: url, options: options)
}

// Universal Links
override func application(_ application: UIApplication,
    continue userActivity: NSUserActivity,
    restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool {
    guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
          let url = userActivity.webpageURL else { return false }
    handleDeepLink(url: url, isInitial: false)
    return true
}

---

Coisas que quebram fácil

• testar Universal Links colando no Safari (não funciona — use iMessage ou Mail)
• esquecer o prefixo applinks: no Associated Domains
• apple-app-site-association não configurado no servidor (Post 5)
• link chegando duas vezes no cold start — lastProcessedLink resolve

---

Fonte (post completo no Medium)

https://medium.com/@crdornelles/deep-links-no-ios-implementa%C3%A7%C3%A3o-nativa-com-swift-flutter-parte-3-d37569fd0a15

---

Se alguém já teve Universal Link abrindo no Safari em vez do app mesmo com tudo configurado — conta como resolveu. Esse é o problema mais comum nessa etapa.