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

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.