Hey @JoeWalsh please respond whenever you have the time - no urgency - I was wondering what the numbers were for the iOS app and while reviewing blockers on T186627.

@Jdlrobson in the last 30 days, 94% of sessions were on versions of the iOS app that no longer require MobileView. @JMinor is there a particular % of sessions or some other metric you'd like to hit before we say this is resolved?

I didn't have a predetermined threshold, but can dig into it and set one.
I'd be curious if this % is stable (as in people are stuck on that version
and can't/won't update) vs a continuing trending decline. I'll follow up,
but will say we don't have to be 100% off from my perspective.

Good to know we don't need 100%.

Note, we might have a option of redirecting the mobileview API to some other response or reducing the response to something simple like an upgrade message if the only concern is around making sure these apps render something. From my point of view it's easier to maintain the API for this reason if it just returns static content provided I know what the content should be. Let me know if that's something I can consider.

Example potential response:

{
    "mobileview": {
        "sections": [
            {
                "id": 0,
                "text": "Please upgrade your app."
            }
  }
}

In T236731#6323153, @JoeWalsh wrote:

@Jdlrobson in the last 30 days, 94% of sessions were on versions of the iOS app that no longer require MobileView. @JMinor is there a particular % of sessions or some other metric you'd like to hit before we say this is resolved?

@JMinor @JoeWalsh Has this value changed a year later? Can we remove the code or at least make the API redirect per T236731#6463939 ? I ask because the web team is trying to offload its legacy infrastructure which it's not doing a good job of maintaining. cc @sdkim

Been a while since @JoeWalsh was around these parts, but apologies for the slow follow up.

Below is a graph of the % of "safe" traffic, which while small at 98.4% has not reached the threashold I was aiming for (<1%), yet, though at current rates could reach such in ~3mos. In addition the most common pre 6.6 version is also our last working version for some older device generations, so I believe these numbers may represent something of an equity audience who may not be able to afford to update etc. Finally these numbers are via Apple's reporting which is opt-in and may be biased to newer devices as well. So as of today I'm not ready to kill their versions outright, but I would like to take more proactive steps to do so in an accommodative way in the next quarter or two.

Our team has two potential approaches in mind:

1. Place a bit of a banner in the MobileView html content which will only show on the older iOS apps and warn of a shutdown and encourage them to update or use the mobile web site if updating is not possible. We believe this would be the most effective way of reaching folks, and our team could submit the patch for the banner, etc though we'd need your/web team's bandwidth for code review, etc. I'd say this banner could run for as short as a month and then we could proceed to deprecation.
2. If the above is not feasible we'd use the wiki feeds announcement system to place a similar card in the explore feed for these versions. We think this is less likely to be effective as it requires the user to transit the Explore feed (whereas a notice in the html would be seen on all articles) and is designed only to be seen once.

I have long supported this transition and I am sympathetic to the risk and complexity carrying this legacy system entails. We're not quite there yet in my judgment but I think we're close.

Just a note, I believe Sam and I are the only remaining people comfortable with this code. This anxiety could be reduced if I could find a team to officially maintain this and be on call for any issues.

Placing a banner seems like a good step regardless to notify users and bring that number down. I am happy to help with code review. I think this should be a relatively straightforward edit to:
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/Api/ApiMobileView.php#L684

$html = $YOUR_BANNER_HTML . $mf->getText();

The only potential complexity would be around translation, but the language is accessible in this piece of code via:

$langConverter = $this->getLanguageConverter();

Should we create a card for making a banner?

Thanks! Subtask created.

In the last month, 0.73% of our sessions came from apps using MobileView API. (Source: App Store Connect Analytics.)

Version		% sessions this version or earlier
5.1.0 & before*	0.00%
5.2.0		0.01%
5.3.0		0.01%
5.4.0		0.01%
5.5.0		0.01%
5.6.0		0.02%
5.7.0		0.02%
5.8.0		0.06%
6.0.0		0.10%
6.1.0		0.12%
6.2.0		0.20%
6.3.0		0.28%
6.4.0		0.43%
6.5.0		0.45%
6.5.1		0.73%
6.6.0		0.79%
6.6.1		0.83%
6.6.2		0.98%
6.7.0		1.04%
6.7.1		1.07%
6.7.2		1.22%
6.7.3		1.49%
6.7.4		1.86%
6.8.0		2.03%
6.8.1		5.13%
6.8.2		100.00%

(Before 6.5.0, keeping this to minor releases for readability.)

• There are still sessions going back to 3.3.0, but they round to 0%.

@JMinor can we close this ticket?