Maintenance updates to the app platforms

[shankari]

This issue tracks changes required to support recent requirements from apple and google.
The requirements are:

• google: need to support API 28
  https://support.google.com/googleplay/android-developer/answer/113469#targetsdk
  The main changes will be related to background permissions since google now supports "When in use" and "Always" tracking options just like iOS. I will take this opportunity to also fix the onboarding flow on both platforms to clarify that people should use "Always"
• iOS: need to support Apple Sign-on
  https://developer.apple.com/app-store/review/guidelines/#sign-in-with-apple
  If you are using the token list auth method, or "your company’s own account setup and sign-in systems" (e.g. using OpenID Connect) then this is not an issue. However, if you are using Google Sign In, you will need this update. I might look into supporting other OpenID Connect providers (e.g. GitHub/Facebook) if it turns out to be easy to do so.

Apple also requires all apps to be upgraded to 64-bit, but that appears to be an OSX-only requirement.
https://support.apple.com/en-us/HT208436
At least, I haven't received any warnings about any of the iOS apps in the stores

I will try to make these changes without changing the min supported version (#438) and then upgrade those separately so that you can choose the migration path. But if this is too hard to do, I will upgrade but give you sufficient warning here.

Note that I don't plan to deploy the updated apps to the stores (e.g. e-mission and emTripLog) until December at the earliest, to allow existing studies to complete without interruption. But if you are building your own app, you can pull the changes and update/deploy your own apps.

Please let me know if you can help with testing the changes. Having multiple testers will make the changes more robust, and reduce individual testing/validation.

[PatGendre]

Hi @shankari , we have received a security warning on android related to angular.js, I've created an issue #464 , if this relevant you can add it in this update list?

[shankari]

Based on #483, it seems like there is an urgent need for app maintenance to support new iOS versions and new app store requirements. The last major update was in the Spring of this year, and took roughly one month of my time. Alas, I am graduating now, and I don't have time to spend a month on a maintenance update.

I anticipate having even less time in the future, so I would like to start transitioning the maintenance to a developer or developers who can periodically go through and make the changes necessary. Since it took me, the super skilled maintainer, a month for the last update, I would like to budget 2 person-months for a developer who is going to have a learning curve.

2 person months @ 40 hrs/wk, ~ $40/hr will come to around USD 13000.

Let's see if the community can come together to fund this. I know that @stephhuerre, @asiripanich, @st-patrick, @jf87, @xubowenhaoren are planning to deploy native versions soon.

13k/5 ~ USD 2500. Let's count me as a person since I care about the project. 13k/6 ~ USD 2100

Would you be willing to contribute USD 2100 each to upgrade the plugins to support the latest store requirements?

@xubowenhaoren you can contribute time instead of money if you like 😄

Since we are going to touch the plugins anyway, we can also fix the build issues and ensure that the most recent version of xcode works. We can also fix issues with the onboarding - e.g. add a screen that tells people that they need to select "Always Allow", explain why we need certain permissions, etc., add better error handling, etc.

Please let me know what you think. Email is fine if you are shy 😄 but the general trend for open source projects is complete transparency. e.g. check out https://www.bountysource.com/

[shankari]

If people would prefer a bountysource approach, I can split the update into multiple smaller issues of 2k - 3k each. But really, all the components need to happen for the update to work, so I think that a bounty approach doesn't really work for maintenance as much as for new features.

[shankari]

I spoke to SDSU today and they want to build a custom app too. So if we include them, this comes down to 13k/7 = approx $1860 per group. If you can round up to $2k, I won't complain 😄

[shankari]

In #480, @stephhuerre said that they would handle the upgrade to API 28. Woo!

If only somebody else would handle the support for Apple Sign in (@xubowenhaoren?) then both updates will happen organically from the community, which would be great....

[shankari]

@stephhuerre @asiripanich as part of the upgrade to API 28, android will also have options for "when in use" and "always" (https://support.google.com/googleplay/android-developer/answer/113469#targetsdk). It seems like this would be a good opportunity to introduce a screen in the onboarding that explains to the users what popup they are going to get and how to answer it.

We have had issues with end-users picking "when in use" instead of "always" on iOS before, and it would be good to fix this before we have the same issues on android as well.

Further, since the app knows what the OS version is, it can give the correct instructions - e.g. for iOS12, say "pick always" and for iOS13, say "pick when in use" just to avoid confusion. Since there are no native code changes for the location permissions on iOS, @asiripanich could even implement it in time for their January launch.

Let me know if either of your teams wants to take this on, and I can write out a high level design or create a draft PR as a starting point for the changes.

[asiripanich]

@atton16 I think we will need that feature for our up coming deployment. Please follow up with @shankari about the details.

[shankari]

@atton16, you want to look at calls to markConsented, which is the call that initializes the location fsm after the user says "I accept". If you have more specific questions I can respond after a few days