Update the app expiration alert for GitHub and Xcode builds

[marionbarker]

The method has been updated several times. Editing this first comment to match current state (because this is the first item most people see).

This PR supplies appropriate expiration information on the Loop Settings screen and the modal alert when expiration nears.

1. use an isTestFlightBuild function from @billybooth
2. if that function returns true, use the build date plus 90 days to estimate the time at which the "Loop" Beta has Expired message will appear
   • It also checks if expiration from the provisioning profile is sooner, and in that case, it uses that time
3. if that function returns false - the alert continues to use the provisioning profile

This has been tested for both Mac-Xcode builds and GitHub Builds uploaded through TestFlight.

[dabear]

This doesn't account for the case where profile expiration is sooner than 90 days. Also hard coding the number of days to 90 might break in the future if apple changes this value on their end.

[marionbarker]

Thanks @dabear.

• I agree that code should be updated to check if the expiration date is sooner than "now + 90days" and in that case, the overwrite of the profile_expire_date should be skipped
• I have no comment regarding what Apple might do in the future

Summary:

• By inspecting old TestFlight builds, I can say that the reported date in Loop is related to the expiration date for the Distribution Certificate created with Create Certs
• I was assured that deleting Distribution certificate does not affect TestFlight builds and I confirm that is true

Results (number of days reported on 2023-Aug-22) :

• "New certificate" and this PR: Loop Settings indicates 1 day less than TestFlight (which listed 91 days yesterday)
• "New certificate": Loop Settings indicates new cert provides a year (but Testflight does not)
• "Old certificate": Loop Settings for all TestFlight builds indicate the expiration is in 159 day

Details:
I installed builds onto my test phone with TestFlight expirations reported from 16 days to 90 days.

• This spreadsheet lists the TestFlight and Loop reported days until expiration
• I have recently deleted Distribution Certificates because of testing for LoopWorkspace PRs 71 and 77
  • some of the not-yet-expired TestFlight builds were created with one of several "New" certificates from this testing
  • older builds were created with an "Old certificate" and it must be the same "old" cert because all report same number of days until expiration

[ps2]

Certificates do expire, and this prevents uploading newly built versions of Loop. The thing that prevents Loop from running on the phone is the provisioning profile, and that expires also. This PR should not be overwriting the profile expiration date with a hardcoded timestamp based off the build date.

The build system can check for expiration on certificates, and we could theoretically trigger an auto update of certs and profiles when the expiration is near.

[ps2]

And the date reported in Loop is based off of the provisioning profile expiration date, which may or may not coincide with the certificate expiration date.

[marionbarker]

I wanted to get this discussion started with something I tested that does modify the notification behavior for a user.

I’m happy to make modifications.

In addition, I do not think using the directory name of /Users/runner is particularly robust. (See first sentence.)

There is also a separate PM discussion about a possible PR for the build process that can create new certs at need - separate topic but wanted to mention it.

[ps2]

The current method of using the provisioning profile expiration date as the warning is the correct date to warn the user about when the app will stop working.

[marionbarker]

Thanks to @bjorkert for the improved version of capture-build-details.sh.

• It uses 'GITHUB_ACTION' to determine if it is a GitHub rather than a Mac-Xcode build
• It calculates github_expire_date (should we call it testflight_expire_date?) of 90 day from now
• The value for profile_expire_date is only overwritten when github_expire_date happens sooner

Tested with Mac-Xcode

• No change to expiration date with this PR

Tested with GitHub build

• seems like the expiration reported is 1 day before that stated by TestFlight
• see Build 142 in spreadsheet

[dnzxy]

The build system can check for expiration on certificates, and we could theoretically trigger an auto update of certs and profiles when the expiration is near.

Hi @ps2, building on the previous work regarding automated builds, @billybooth and I are actually planning on implementing a scheduled action that will check for certificate and/or provisioning profile expiry and renew those automatically. It’s still at a discussion stage, because we are currently working on further validating around common build errors and providing improved, i.e. actionable, error messages to end-users, but it’s on our unofficial to-do list.

[ps2]

The goal of this is to support providing the user a warning about TestFlight build expiration, correct? Github doesn't have anything to do with the app expiration that TestFlight imposes.

There are ways to detect a TestFlight build, it appears: https://stackoverflow.com/questions/26081543/how-to-tell-at-runtime-whether-an-ios-app-is-running-through-a-testflight-beta-i

I suggest using the above technique to determine whether the build is a TestFlight build in the ProfileExpirationAlerter class (probably rename this class to AppExpirationAlerter), and if so, then use the (already recorded) com-loopkit-Loop-build-date, to determine when to show an alert.

It's still possible (though unlikely) that the profile may expire before the TestFlight build date, so we should probably consider that.

The wording of the messaging to the user should also be updated:

Either:

• Check profile and TestFlight expiration dates independently and tell the user which one is expiring (preferred)
• Make the wording generic i.e. "app is expiring", vs "profile is expiring".

[bjorkert]

I also receive the sandboxReceipt as the receipt file for Mac Xcode builds. I'll explore other options, and if needed, I can set a TestFlight flag when the GITHUB_ACTION is set.

[billybooth]

@bjorkert said:

I also receive the sandboxReceipt as the receipt file for Mac Xcode builds. I'll explore other options, and if needed, I can set a TestFlight flag when the GITHUB_ACTION is set.

Pete linked to an article in the associated issue #1881:

@ps2 said:

Note to self: maybe try reading the mobileprovision file: https://www.process-one.net/blog/reading-ios-provisioning-profile-in-swift/

Definitely seems viable, since it reads the embedded mobileprovision, although perhaps not straightforward as the above suggestion (that doesn't work). As I re-read the stackoverflow answer, it indicates that "sandboxReceipt" is the name of the receipt file for local (Xcode) builds as well, i.e., you'll only get a "receipt" file for an App Store app:

combinatorial said:

Note that sandboxReceipt is also the name of the receipt file when running builds locally and for builds run in the simulator.

[bjorkert]

I did not get any of the ways to detect testflight distribution to work, so I made a BuildDetails flag for it like for example buildDateString.

Dialogs and texts shows TestFlight information and update links goes to gh-update.

[marionbarker]

I tested using my repository with code that matches this PR, up through commit 874c393.

Test Summary:

• Messages on Loop Settings screen were as expected
• Modal alert for expiring soon was not observed - test method error; see notes at end of this comment

Test Overview:

• Mac-Xcode build: Messages continue to be presented using my provisioning profile expiration date
• GitHub build installed on a test phone via TestFlight
  • Times below are in PDT (the dates in the Loop Report are UTC, but messages on Loop Settings screen and in App Store Connect are local time)
  • Initiated Build Action: Aug 28 2023 5:38
  • Build completed and the buildDate in the Loop Report was Aug 28 2023 5:53
  • App Store connect says "Upload Date, Aug 28, 2023 at 6:07 AM"
  • It is actually the Upload Date that limits the "Beta" on the phone

Test Details:
Use test phones so I can modify the time on the phone.

• Mac-Xcode build:

  • checked that messages on Loop Settings screen were consistent
  • checked that messages on Loop Settings screen switched to verbose mode (with red font) when < 3 days
  • checked that I got "Loop" is No Longer Available when time was advanced to provisioning profile expiration

• TestFlight Installation of GitHub build (my build number 156):

  • checked that messages on Loop Settings screen were consistent
  • checked that messages on Loop Settings screen switched to verbose mode (with red font) when < 3 days
  • checked that I got "Loop" Beta has Expired when time was advanced to 90 days added to the Upload Date (not the Build Date)

Modal Alert comment:

• I was not able to see the modal alert after one time when I did see it. Figured that out.
• I was changing the phone time so I could tell exactly when the app stopped working (for Xcode or GitHub/uploaded through TestFlight)
• The consequence is my lastAlertDate was near the expiration date for my provisioning profile; and therefore I would not get another modal alert in my testing

[marionbarker]

There was a logic error in the modal alert for expiration (only checked provisioning profile). That was fixed with commit 211a337.

Test Modal Alerts as a separate test:

• Delete the Loop app from the test phone to remove the memory of lastAlertDate
• For Xcode test, change expirationAlertWindow to exceed days until provisioning profile expires and build
  • Got the modal alert immediately (no need to onboard the new app)
• Delete the Loop app from the test phone to remove the memory of lastAlertDate
• For GitHub build / TestFlight Upload, set up special branch dev_try4_2052_force_alert that points to a version of Loop which matches 21a337 plus a modification to the expirationAlertWindow to be 91 days and build
  • Got the modal alert immediately
  • Confirmed the link takes me to the GitHub Update page for LoopDocs

[marionbarker]

Thanks to @billybooth for the improved isTestFlightBuild function.
This has been tested with both Xcode and GitHub/TestFlight.

[ps2]

Looks good to me. A couple nits; won't hold up merging if you're opposed to the suggestions.

[ps2]

nit: maybe rename this appExpirationSection

[marionbarker]

Tested - success (see composite)

Test details:

• Test 1: Successful build and run on simulator (profileExpiration is N/A for this case)
• Test 2: Successful build and run with Mac - Xcode:
  • Build as per the PR, Loop Settings screen refers to App Profile / Profile Expiration; date matches my provisioning profile expiration date
  • Modify to force modal alert expirationAlertWindow: TimeInterval = .days(400)
    • Modal Alert header is Profile Expires Soon
  • Added modification to force red font/verbose message: settingsPageExpirationWarningModeWindow: TimeInterval = .days(400)
    • Settings screen font is red and message is verbose (screen shot saved but not shown in composite above)
  • For setting screen and modal alert, the links go to LoopDocs page for updating with mac-xcode build
• Test 3: Successful build and run with GitHub/TestFlight Upload
  • Build (162) as per the PR, Loop Settings screen refers to TestFlight / TestFlight Expiration (90 days added to buildDate)
    • buildDate time is 2:42 pm, upload time is 2:54 pm
    • for this case, warning will be too early by 12 minutes which is fine
  • Build (163): Modify to force modal alert expirationAlertWindow: TimeInterval = .days(400)
    • Modal Alert header is TestFlight Expires Soon
• For setting screen and modal alert, the links go to LoopDocs page for updating with GitHub Browser build

[ps2]

Thanks all!