Explain TestFlight process in more detail

[4gra]

For various reasons it can be useful to distribute Loop via TestFlight (testing multiple versions, installing quickly on new phones without access to a Mac, etc.), though it carries drawbacks (90-day expiry, hypothetical risks that the App Store process takes a dislike to the whole thing, etc).

Nonetheless this process has been documented well by the xdripswift project: https://xdrip4ios.readthedocs.io/en/latest/install/personal_testflight/ and though the focus of this document is different (providing builds for a larger user group) the steps involved are exactly the same and can be followed to achieve the same result (I verified them today).

I'd suggest it might be useful to outline why TestFlight might be useful to Loop developers if not all loopers, some of the drawbacks, and to shamelessly gratefully replicate the bulk of those instructions here.

Recent Loop chats have highlighted that there are unique philosophical issues around the DIY nature of Loop and building for others, so this page could be a useful place to elaborate - but that's perhaps a more nebulous secondary goal.

[4gra]

I have some minor comments on bumps I hit building Loop master for this process - namely that the Upload step complained about missing NSHealthShareUsageDescription and NSHealthUpdateUsageDescription values from the WatchKitExtension (well, to be clear, XCode complains about NSHealthShareUsageDescription but it could actually refer to either key). But I'll verify that they're still a current problem on latest master / dev before I put them in the body of the issue.

[4gra]

I should also mention I'm happy to make this into a PR. I'm just going in gently at this stage until I understand the requirement.

[Kdisimone]

The issue and discussion regarding test flight distribution is not new. It’s been brought up by users before. Without pulling up all those discussions again, the short version is that we have intentionally left test flight instructions out of docs

https://www.facebook.com/groups/TheLoopedGroup/permalink/1898895463660444/

Has good info on why not in the comments.

“ Distributing an app that controls insulin dosing via TestFlight would constitute distributing a class III medical device in the eyes of the FDA, which they claim requires FDA clearance even if it's a non-commercial activity. Solely distributing source code avoids a constitutional fight over FDA authority under the commerce clause, by remaining clearly within the bounds of first amendment protection.

More practically, using TestFlight would make the person doing so responsible for certain things, like ensuring that everyone gets timely updates, rather than the responsibility lying with the person who built their own medical device. Taking personal responsibility for your own APS is a key part of the safety culture that allows the #WeAreNotWaiting movement to innovate so quickly while ensuring that no one's life is put at risk (beyond the inevitable risks of living with T1D, which we significantly reduce) by ignorance or an excessively trusting attitude that might make someone think they don't need to test their system for themselves and make sure it works well for them.”

[4gra]

The explanation is much appreciated!

[ps2]

@Kdisimone is very much right that there are ethical, regulatory, and legal reasons to not set up a non-FDA approved app for distribution to other people in the public, and these largely center around who has the responsibility for various aspects of providing safe usage of the app. Responsibilities for updates, support, adverse event reporting, and postmarket monitoring are some of them.

There are situations where those responsibilities are clearly defined, however. In some cases of explicit caregiving, where one is personally responsible full time for the health of another, such as caring for children/teens, elderly parents or other close individuals, these responsibilities should be clear. In these cases, TestFlight can be a great tool for keeping the app updated, can provide backups for quick re-install if needed, and allows reverting to previous versions easily.

I think documenting how to do so would be a useful addition to LoopDocs, along with some clear and prominent guidance that it is not intended to be used to use in cases where the above responsibilities might be questioned.

[marionbarker]

@4gra If you could assist in writing this - it would be greatly appreciated. Please look at the current structure and provide a suggestion for where you think it should go. It's easy to add pages to the website and we can put links to the page at appropriate locations of other pages. If you are not familiar with using mkdocs, I can work from a shared google docs and convert it to mkdocs format.

[Kdisimone]

Respectfully still disagree with adding this to loopdocs. It’s a tremendous burden supporting technical question for even the easy workspace script building already. Supporting TestFlight errors and questions when people don’t know how provisions, certificates, and updates work would be a nightmare. I don’t see how we wouldn’t burn out our helpers by adding TestFlight to the list.

I’d rather see a channel in Zulipchat be responsible for these instructions, if someone really wants to “advertise” TestFlight option. It is a good spot as test flight builds and distribution should be geared towards a more tech-smart audience. Loopdocs has a much larger laymen group that needs a clean, unconfusing path to build and use.

[Kdisimone]

In short, if someone is inclined to do remote app management for someone, it’s responsible to expect them to take on TestFlight learning themselves. Loopdocs already has a full plate of info to convey. TestFlight building instructions we should leave to Apple and Q&A for loopers in particular should be in Zulipchat

[ps2]

I guess that's a different issue. I'm not sure I can evaluate the load on support for this. I just think that there are some really good, and responsible uses for TestFlight distribution, so I wouldn't want to exclude it for those reasons. It's not really about being remote; In the cases I've listed, those people are often living with you, but it still brings a lot of benefits. Some people even use it to get builds on their own phone, as it provides the backup/revert capabilities. I'll leave it to those providing day to day support to decide if this would bring up too many support issues, more than it would reduce those questions about how to do it in the first place, that the docs would alleviate.

[4gra]

My intention is certainly not to increase support burden but I appreciate it's not for me to assess. Nonetheless the use I envisage is not in extending the reach of Loop binaries to additional people, but just to give additional flexibility in testing and deployment to those doing the building.

In making this suggestion I appreciate that as a general principle Loop should not normally be deployed further than one's USB cable can reach, and clarifying this would be a focus of any potential rewrite.

[Kdisimone]

I’ve asked the moderator group and received a resounding “no thanks” on test flight building instructions or mention in Loopdocs.

I see this as similar to the issue of building on VM vs Apple. We have one person willing to dig super deep and became a super responsive helper in looped (and still is). He keeps a blog current for Loop-specific VM help. I have a link to it in the FAQs

but to be honest, even that would get overwhelming for our moderators, if he wasn’t so good at responding regularly everyday to VM questions.

TestFlight is very helpful for dev work, but….developers shouldn’t need Loop’s instructions on how to produce and install a TestFlight version 😉 Apple has great instructions on that already.

I’m going to close this again, but hopefully this additional discussion has been helpful to understanding the TestFlight issue. It’s not that I have a problem with TestFlight…it’s that I know for certain lay people would be building for friends, having failures or problems, and our support system can’t take being stretched to undertake what that would bring.

I’ll think about adding a faq similar to VM question and link back to Apple website for instructions, since this question does come up occasionally.

[ps2]

Definitely going to respect the support community's desires here if they think it's increasing scope too much. I agree that LoopDocs doesn't need to tackle every desire, and it can do better by focusing.

I will say I don't use TestFlight for dev work; it's more about getting builds on other phones, so I don't think it's correct to characterize it as a dev tool. I'd continue to recommend that people with kids look into this method of getting updates onto their kids' phones. It's particularly useful for teens who guard their phone with religious fervor. :)

[Kdisimone]

I had same teen type. I feel that pain. Perhaps loopdocs can explain that, after the first build, you can build onto your kid’s phone without plugging into computer. Wireless updates while in the house. I never thought it was that widespread a help, but that sounds like bad assumption now 🤣