[$2000] Deep links are broken on iOS

[marcaaron]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Install the New Expensify app
2. Sign in and close app
3. In a browser, follow a deep link like https://new.expensify.com/settings

Expected Result:

App should open to the settings page

Actual Result:

Safari or other default web browser opens the page

Workaround:

Open the app directly

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: v1.2.71-1
iOS Version: 16.3.1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by: @shawnborton
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1676413158858859

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01d64bfcd13e8d5909
• Upwork Job ID: 1627724629399916544
• Last Price Increase: 2023-02-27

[MelvinBot]

Triggered auto assignment to @arielgreen (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[MelvinBot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[mvtglobally]

@marcaaron we had an old Issue on this which was closed. There was a bigger discussion. I'll try to link it in a bit

[mvtglobally]

@marcaaron @arielgreen

#13882 (comment)

[marcaaron]

Thanks @mvtglobally (great memory)!

I'll leave a comment over there. They seem like the same issue so if anything we will keep this one open and leave that one closed.

[MelvinBot]

Job added to Upwork: https://www.upwork.com/jobs/~01d64bfcd13e8d5909

[MelvinBot]

Current assignee @arielgreen is eligible for the External assigner, not assigning anyone new.

[MelvinBot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @parasharrajat (External)

[MelvinBot]

Triggered auto assignment to @NikkiWines (External), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[arielgreen]

Added external

[bradjin8]

Is it still open for new ones?

[allroundexperts]

@NikkiWines @parasharrajat This seems to be a feature request. Did it ever worked on iOS? As far as I can see, DeepLinkWrapper was never implemented for native platforms. It is just done for Desktop.

[allroundexperts]

Ref: #10893

[parasharrajat]

Ok, @allroundexperts. We are happy to take proposals here.

@bjin9 Yes it is open.

[parasharrajat]

Next time, please post complete proposals. Also, do explain why

we're restricting the app to open the links on mobile here src/components/DeeplinkWrapper/index.website.js.

[cubuspl42]

Proposal

Please re-state the problem that we are trying to solve in this issue.

We're trying to make universal links work between the web app and the mobile app on iOS.

What is the root cause of that problem?

1. The url event from the Linking API is handled, but only report URLs seem to be supported (ReportUtils.openReportFromDeepLink).
2. Like @s77rt mentioned, apple-app-site-association have a generic binary file MIME type binary/octet-stream. I haven't verified that it's actually a blocker, though.

What changes do you think we should make in order to solve the problem?

1. I propose to extend the handling of the url event for the other deep link types, via a new helper.
2. apple-app-site-association should have a MIME type application/json. Specifics would depend on how the app is hosted in production. If it's hosted on Firebase Hosting (as firebase.json is checked into source control), it's possible to cofigure it there.

[s77rt]

This may be due to https://new.expensify.com/.well-known/apple-app-site-association not setting the correct content-type header value, it should be application/json.

[marcochavezf]

Oops, the PR to change the content-type for the AASA file was merged, but the deep links are not opening the installed iOS app instead of the browser.

[marcochavezf]

The universal link diagnostics and the AASA validator indicate that everything is fine:

Upload.from.GitHub.for.iOS.MOV

But links to production and staging are still opening the browser

e.g.

https://new.expensify.com/r/3504895439653267

https://staging.new.expensify.com/r/3504895439653267

[s77rt]

It may be worth to check if this is related to cache, I think apple check those urls once a week but not really sure

[s77rt]

@marcochavezf Can you please remove the "HOLD" from the title, this is not fixed yet.

[marcochavezf]

It may be worth to check if this is related to cache, I think apple check those urls once a week but not really sure

Yeah, that was my first thought, but it has already passed a week since the apple-app-site-association file was updated. Probably we'd need to wait for a few days more.

[MelvinBot]

@marcochavezf, @parasharrajat, @arielgreen Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[marcochavezf]

Update here. It seems that we'd need to wait until the other change is deployed to production and test again.

[arielgreen]

@marcochavezf is this still held?

[marcochavezf]

The other files were already updated on production and staging, but the deep links are not still working.

[marcochavezf]

Looking for more ideas of what could be the issue here.

[mczernek]

I did some research on that and found some interesting things.

It was extremely difficult for me to get any one app to handle universal links. However I discovered that most domains uses different formats of AASA file than we do. Great example (and working one!) is YouTube:

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "EQHXZ8M8AV.com.google.ios.youtube.dev",
                "paths": [
                    "NOT /yt/*",
					// Whole bunch of NOTs here,
                    "*"
                ]
            },
            // tonns of other appIDs
		]
	}
}

The differences to our file are:

• instead of components they have paths which is array of strings
• they don't have webcredentials key within applinks

There are other domains that follow similar format (pretty much every one I checked) but with webcredentials in it.

Interestingly youtube.com is the only one that Diagnostics in Settings finds correct (apart from us, but unlike us YouTube actually works).

[mczernek]

After some more investigation I have one more thought to be tested.

In fact, iOS does not query our associated file directly. Instead, it uses apple-cdn by getting from url such like https://app-site-association.cdn-apple.com/a/v1/new.expensify.com

For some reason it does return 404 for our domain, while it works for pretty much every other I tested. My guess would be that there is something wrong with our response when serving associated-domains file. In fact, there are quite some headers and two cookies being returned. Can we try simplify that as much as possible and leave only relevant headers and no cookies. For reference, this is set of headers returned by branch for one of apps:

content-type: application/json; charset=utf-8
content-length: 1362
vary: Accept-Encoding
server: openresty
date: Tue, 28 Mar 2023 14:34:49 GMT
strict-transport-security: max-age=31536000; includeSubDomains
x-cache: Miss from cloudfront
via: 1.1 2e4b77c76f89825e36f12179cf1b33ea.cloudfront.net (CloudFront)
x-amz-cf-pop: WAW51-P1
x-amz-cf-id: 8lgANq-rSQNzbOs4GuRIniAxHrXVjNrQCw9dVy48ZLPKPkdzc6OM-g==

[parasharrajat]

I think it is definitely that 404 error issue.

[marcochavezf]

Thanks for the insights @mczernek! We're discussing with the infra team the headers issue.

[marcochavezf]

After more investigation seems that our firewall is blocking Apple's crawler from pulling the AASA file from our servers. Infra already updated the rule. So I think we should only need to wait a few days to corroborate if the apple-cdn is updated.

[marcochavezf]

It's working now!

RPReplay_Final1680179383.MP4

[marcochavezf]

For future reference, if someone has a similar problem in the future, the problem was the firewall.

We were getting this error from the headers of the apple cdn Apple-Failure-Reason: SWCERR00101 Bad HTTP Response: 403 Forbidden:

And someone else that had the same error, posted in the apple developer forum that the problem was their firewall configuration: https://developer.apple.com/forums/thread/675324?answerId=668081022#668081022

[marcochavezf]

I will close this one since it's working on staging (app from TestFlight) and production. Thank you all so much for your help!