@cmadeo looking good! Just had a couple of questions:

@cmadeo @JMinor Thanks for mocking this up! Here are a few of notes we have from engineering sync:

Note for QA: this fix is in the TestFlight build 6.7.4 (1791).

Note for QA: this fix is in the TestFlight build 6.7.4 (1791).

Note for QA: this fix is in the TestFlight build 6.7.4 (1791).

Caveat: let's do this if we can't single out distinct device data in possible MEP data logging backend.

Note I was able to do this manually so it now says 6.7.3, but automated as a part of our tag_release fastlane lane would be better.

PR in progress: https://github.com/wikimedia/wikipedia-ios/pull/3828

PR in progress: https://github.com/wikimedia/wikipedia-ios/pull/3828

I also found a separate reason for why our survey modal might still show for users. Survey announcement managed objects are deleted immediately from the database after the endpoint is fetched and processed, so I didn't think it was a case of database objects hanging around longer than expected. However, it seems that the announcement payload itself is cached, despite our explicit request in the fetcher for it to ignore the cache. This is a bug likely introduced with the mobile-html release, where we added caching hooks within many of the data fetching methods in Session.swift. This still wouldn't cause bugs because we explicitly check the end date shortly before displaying the survey modal in ArticleViewController+SurveyAnnouncements.swift, however in looking at the history of our wikifeeds updates, the endDate was at one point 2021/02/01. So if that's the version that is cached, and a user opens the app (they seem to need to be in offline mode) and visit an article in the list, the prompt still shows.

I may have found a way to trigger this bug. Here are the things I've tried on the AppStore build:

@Pcoombe darn, thanks for the heads up - I'll take a look today.

Progress is in the ui-test-screenshots branch. So far it:

StorageManager PR (now merged into main): https://github.com/wikimedia/wikipedia-ios/pull/3806

@cmadeo This is great Carolyn, thanks for thinking this through! I'll give this some further thought and I'd like to sync with the engineers on it as well before saying more, but I did want to mention a couple of things:

Most of the initials on this are done to begin working against:

Update: We have removed grunt-browserify from our dependencies to remove dependabot alerts. The next step is to evaluate if we want remove the grunt setup entirely.

New PR: https://github.com/wikimedia/wikipedia-ios/pull/3802

@Jgiannelos @Mholloway We are reworking the way our app handles wiki language variants and have a question in regards to the backends. It looks like by default, we try to send all requests with an Accept-Language header, which takes their iOS device language preferences and constructs a standard value with a format looking like en-us, zh-hans;q=0.67, zh-hant;q=0.33, depending on their settings. Moving forward we will allow language variant preferences to be selected and sorted in the app settings as opposed to device settings.

Related to