Remove manual Safari fallback for unhandled universal links - #185430

Huh, did you verify that the bug was a regression? Like did it work with an older version of Flutter? I would not expect the app launch sequence to be related if it's related to a specific Flutter version (unless it was UIScene related, but that was introduced in Flutter 3.38).

Were you able to recreate locally and verify that this fixed it?

@vashworth I didn't test prior Flutter versions since it was bisected to #164247 and I was able to reproduce the bug locally. I also verified that the fix works

The fix was applied to both the Appdelegate and the UIScene since they both have their process for handling the deeplink

I didn't test prior Flutter versions since it was bisected to #164247 and I was able to reproduce the bug locally. I also verified that the fix works

@okorohelijah Can you try reverting to the old API and see if it works (it's one line of code so you don't have to bisect)? From your PR description this doesn't seem related to that change.

@hellohuanlin I tested by reverting my change and #164247 separately:

If I revert #164247 (returning to the deprecated 1-arg openURL:), the cold start works. It seems iOS was silently ignoring that deprecated call during the early launch phase.
If I restore #164247, the 3-arg openURL: is strictly honored by iOS, which triggers the jump to Safari.

The issue is that sendDeepLinkToFramework: calls completion(NO) if it times out (3 seconds) or if the Dart framework returns false. This then hits the (!success && throwBack) check in the AppDelegate, which triggers the openURL: call updated in #164247.

Rather than dropping the link, is it possible to delay the operation until the framework is ready?

sendDeepLinkToFramework: already delays via waitForFirstFrame:3.0 before sending the route to Dart. The problem is that the first frame often renders (e.g., a loading screen) before the app's own initialization (database, auth, etc.) is complete.

When that happens, Dart's onGenerateRoute returns null. From the engine's perspective, "not ready yet" and "genuinely fails" look identical so both return success=NO. We can't tell how long a specific app's initialization will take, and increasing the timeout would just delay the jump to Safari without solving the ambiguity.

It seems iOS was silently ignoring that deprecated call during the early launch phase.

What do you mean by that? Does using the deprecated 1-arg openURL work?

@vashworth Yes, the deprecated API "works" in the sense that it doesn't bounce to Safari, but it does so by failing silently. When the engine tries to relay back to the system via the legacy [UIApplication openURL:url], iOS sees the app is in the middle of a cold-start transition and simply doesn't execute the command.

@vashworth Yes, the deprecated API "works" in the sense that it doesn't bounce to Safari, but it does so by failing silently. When the engine tries to relay back to the system via the legacy [UIApplication openURL:url], iOS sees the app is in the middle of a cold-start transition and simply doesn't execute the command.

But it doesn't route the deeplink, yes? It opens the app but just to the main screen?

@vashworth the link routing opens because the routing is correct. The problem in this case is that the initialization is just late but because of the timeout, late and failing is treated the same. The legacy api isn't meant meant to work but it works because it ignores [UIApplication openUrl:url] (which is meant to open safari) but the new api honors it

Okay I think I understand. Basically what this PR does is makes it so if a url is not handled by the flutter app, then on cold start it fails silently (keeping the app open and not redirecting to safari) and on warm start it redirects to safari.

From the issue report, it sounds like the users have come to expect cold start to silently fail because on their older version of Flutter it would call deprecated openURL: to redirect to safari, but since that API is deprecated, it would silently fail. Then after upgrading to the new version of Flutter that uses openURL:options:completionHandler, it starts redirecting to safari as the code originally intended.

I wonder how it works natively. I'm pretty sure that it does not bounce to safari like we do. The AASA should handle directing invalid urls to safari.

@okorohelijah Can you look through the git history and see if you can figure out why we introduced relaying it to the system in the first place?

@hellohuanlin @vashworth I discovered something new: The 3-second waitForFirstFrame timeout is NOT being hit!

Here is the exact timeline of what happens:

iOS wakes up the app and hands the Deep Link to the Engine.
The Engine immediately forwards it to Dart. Dart receives it perfectly on time.
During initialization, the developer intentionally delays routing. In the repro project, onGenerateRoute explicitly returns null because loading is true

if (loading) {
        // Save link until the app is loaded to handle later.
        globalPendingDeepLink = pathOrUri;
        return null;
      }

When onGenerateRoute returns null, Flutter's Navigator falls back to _onUnknownRoute.
Because the developer didn't pass an onUnknownRoute callback to MaterialApp, the framework throws an internal exception (Null check operator used on a null value in app.dart:1590).
Because of this exception, Dart immediately returns false to the Objective-C Engine via the method channel.
The Engine receives false (signaling "Dart failed to handle the route") and executes its hardcoded fallback: [UIApplication openURL:url], which forcefully kicks the user out of the app and opens Safari.

I still propose this fix because Apple's native design pattern for continueUserActivity allows native apps to return false if they receive a link they aren't ready for, and iOS natively handles this by silently dropping the link and letting the user stay inside the app. The implementation rn intercepts that false and forces a Safari bounce. wdyt?

Can you look through the git history and see if you can figure out why we introduced relaying it to the system in the first place?

@vashworth I looked through the history (specifically PR #52643) to trace why this manual openURL: fallback was introduced. It was originally added to handle unsupported paths (bouncing unrecognized links to Safari) but because Apple's continueUserActivity API requires an immediate synchronous BOOL return, the Engine couldn't wait for Dart's asynchronous response and was forced to immediately return YES. Returning YES swallowed iOS's native Safari fallback behavior, so we had to manually simulate the bounce later using openURL: when Dart eventually returned false.

I tested by creating a native app and I confirm that the invalid urls(custom and universal links) just remain on the app instead of the safari bounce. The safari bounce happens only if the app doesnt open in the first place. That is, the path isnt registered in the AASA but once the app opens iOS handsoff completely

Thanks a lot for the detailed clarification, that's crystal clear! I see the PR is on its way to being merged, so perfect. 🙏

The PR description should be updated to reflect changes -- e.g. hasBeenActive.

autosubmit label was removed for flutter/flutter/185430, because - The status or check suite Google testing has failed. Please fix the issues identified (or deflake) before re-applying this label.