@Fjalapeno do we still need this task? Seems like it is subsumed/duplicated by Universal links?

@JMinor this ticket can either be repurposed for that, or if you already have a ticket close it as a dupe.

What is "Universal links"? There is no explanation on mediawiki.org, nor a link to a definition or anything (e.g. from https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-12-2#iOS ). Is this the main task on the matter? If yes, can a definition be added to the task and a link to the task added to the few mentions on wiki?

@JMinor, can you respond to @Nemo_bis's comment?

As the reading web PM, I want to state the primary concern I have about this technology. To me, showing the apple-made 'download app' banner to users who do not have the app installed is a non-starter (until we decide that the app provides more value to the user).

If the user already has the app, I think a similar banner is debatably appropriate, given that we have a similar mechanism on Android and that the user has already chosen to download the app.

I hope there is a way for us to gain the benefits of indexing without showing a banner to users who have not already downloaded the app.

@BGerstle-WMF, question:

Are <meta> tags needed at all?

Given that the basic universal links config file patch was merged and deployed (cf. https://en.wikipedia.org/apple-app-site-association), from what I can tell, a few things remain to satisfy the following scenario, at least based on this page.

If and only if I have the app installed
When I click a Wikipedia URL
Then I get the option to open the link in the app

• A Content-Type header of application/json supplied on the universal links config file, probably somewhere in the puppet repo.
• App side and dev center side entitlement / provisioning update
• Implement app side hook to handle URLs at /wiki/

In other words, although there would be the need for a puppet deploy of a patch (@BGerstle-WMF?), it seems like it's possible there isn't a need for PHP coding.

However, what's unclear to me is whether deeplinking support (<meta> tags required) is needed in order for universal links to work in the first place. I don't think it is. The indexing documentation seems to imply deeplinking is primarily for Spotlight/Safari search integration. The risk of the Spotlight/Safari search integration is aggressive promotion of the app, the blocker @JKatzWMF identified.

I'm curious if, in the case that deeplinking support isn't needed for basic universal link interception, whether Spotlight/Safari search results when tapped also "just work" via basic universal link interception.

Now, if <meta> tag deep linking is needed to either (a) get universal links working at all or (b) confine which actual pages are eligible to be opened in the app at all, with a little luck it is as simple as updating this segment or its like in MobileFrontend and then making the necessary app side changes to handle the URL scheme in the <meta> tag (provided the web engineers want that approach instead of breaking it into a separate extension). But it does seem that then means we would have to come back to the question on whether the app would start being aggressively promoted with the 'download app' banner.

P.S. I see the 'Associated Domains' entitlement is in place on some of the non-prod channel provisioning profiles already.

Hey everyone, my apologies for not being very responsive.

@Nemo_bis please refer to @bd808's & my comments on the site association file ticket (T111829). In particular, it would probably be most informative to watch the WWDC video (streaming in Safari only).

@JKatzWMF

To me, showing the apple-made 'download app' banner to users who do not have the app installed is a non-starter (until we decide that the app provides more value to the user).
If the user already has the app, I think a similar banner is debatably appropriate, given that we have a similar mechanism on Android and that the user has already chosen to download the app.

@Jhernandez recently suggested we do all of this work on our own staging instance of MW. Assuming that actually work, this wouldn't affect any users in production, and would allow us to better understand the banner mechanism and what we might be able to do to custom-tailor the experience. That said, if we want a custom experience, we don't need to use Universal Links (i.e. do it the old-fashioned way w/ custom URL schemes and JS—see Flickr examples below).

I hope there is a way for us to gain the benefits of indexing without showing a banner to users who have not already downloaded the app.

There are certain aspects of indexing that can benefit all iOS users, even those using Safari only. However, that's only related to universal links in that we would be using the same (universal) links when publishing public "activities" from the app for Apple to index and surface to users across their platform. I suggest you read Flickr's article about adopting iOS 9 features (esp. the section on Search/Indexing) to get a better idea for what the benefits could be. If you want to discuss further, I'd kindly ask that we separate that discussion from this one, which is mainly about how the OS, Safari, and the app handle user taps on links to Wikipedia.

@dr0ptp4kt

A Content-Type header of application/json supplied on the universal links config file, probably somewhere in the puppet repo.

I recently learned this is actually incorrect and will need to be fixed, based on Flickr's article about adopting Universal Links which states that the content type needs to be application/pkcs7-mime. I highly recommend you read the article to understand their practical experience for getting this working. For some reason, they don't mention what they had to do on the website to support this, but note: flickr.com (as shown in the Safari inspector on my iPhone) has meta tags using the applinks scheme:

<meta property="al:ios:app_name" content="Flickr">
<meta property="al:ios:app_store_id" content="328407587">

There are also some Twitter meta tags, but I'm not sure if they're related. Interestingly, there's no URL tag to tell the app which URL to load, maybe it's inferred?

So, I tried to go to a specific image page, and found they were using a custom banner in the HTML of their page:

But again, no URL to pass to the app AFAICT, but this is a custom thing, so they probably just get the window's location.

Anyway, all of this is to say we have options, but only iOS 9's Universal Links can let users who prefer the app (assuming there are such users) get automatic redirects no matter where they encounter the link. It's also (in our opinion) the least invasive (i.e. not an interstitial). The point here is to prototype some stuff to see if we can get something working w/ iOS 9 universal links that makes everyone happy—most importantly our iOS users. If Universal Links aren't going to work for us, maybe we can do something custom, or nothing at all. We just have to decide, and IMO having a prototype w/ functional Universal Links integration will make figuring this out much easier.

Hey guys, do we know if there's a dependency on server-side technology in the Wikimedia stack, and what sort of thing?

Adding @Jdlrobson for the time being, and we can loop in more people if needed.

In T97785#1874105, @BGerstle-WMF wrote:

@Nemo_bis please refer to @bd808's & my comments on the site association file ticket (T111829). In particular, it would probably be most informative to watch the WWDC video (streaming in Safari only).

I can't tell whether you're serious or you're kidding me. Do you really meany that this project (the whole iOS-app-feature-Links?) doesn't have a written definition anywhere in the world?

Either way, I'm not interested in ghost software so I'll remove myself.

Great! Is this in the most recent release (5.0.5)?

jberkel, yes. All app link functionality should be complete in the 5.0.5 version. The last remaining open task was to add markup to support the applebot, but given Wikipedia is already part of their crawl its not necessary.

In 5.0.5 we released T135048 which lets other apps open Wikipedia via the "wikipedia:" url scheme (see ticket/pull request for specifics).

OK, just had a quick look at the PR (wikipedia-ios/pull/696) and tested locally. The app opens, but I don't see any code which handles the URL passed to the app.

For this to work the application delegate needs to implement application:openURL:options:.

If you want I can open a new PR with the needed functionality.

Thanks jberkel, sorry we missed that key point. I've created T141578 on our current release board, which you can use to submit the PR.

Please claim the task and move it to the Doing column when you start work, and move to Needs Code Review column when the PR is in.

Really appreciate the follow-up and look forward to the contribution.

@jberkel we only implemented routing for universal link URLs and didn't implement any handling for the old style custom URL schemes ("wikipedia://")

Another volunteer who is an app developer wanted a way to launch the app, so he just filed a ticket and implemented basic url scheme support so he could do that. But no other functionality was implemented.

Any help implementing the rest of the existing universal link functionality in the url scheme handling would be awesome.

Ah, it wasn't an oversight then, but not sure why you would just want to launch the app.

I'll have a go at it, shouldn't be too much work, esp. since the universal link handling is already in there.

@jberkel the app developer has a launcher/automation app on iOS. Some of his users requested the ability to open Wikipedia. I figure he may want more features, but thats all he wanted to get in for now.