This was discussed elsewhere (in zulip, I think), but the main thing that needs to be addressed there is that rather than overwriting Loop's main profile each time, Loop should be updated to be "multi profile" aware in a fuller sense, so that the profile set can be uploaded to backend services, and switches from one profile to another are recorded semantically as switching a profile, and not overwriting a profile.

Profiles has been updated with a few new features:

• Indication of the currently active profile with a checkmark.
• Manual Profile Sorting with drag and drop.
• After modifying therapy settings, Profiles will now suggest updating your profile. Alternatively, save these new settings as a separate profile.
• Profile Renaming

This was discussed elsewhere (in zulip, I think), but the main thing that needs to be addressed there is that rather than overwriting Loop's main profile each time, Loop should be updated to be "multi profile" aware in a fuller sense, so that the profile set can be uploaded to backend services, and switches from one profile to another are recorded semantically as switching a profile, and not overwriting a profile.

Having them uploaded would also make it possible to retrieve them during the onboarding, showing the current profile in Nightscout is a requested feature. In the latest version, Loop is made aware of the latest Loaded (and therefore considered the current) profile.

How do you see the workflow for uploading "multi profile". For example: Should there be "Default" until a profile is created, or all profiles are removed. When saving a profile, it should trigger an update. Switching profile should set the current one as active in Nightscout. When having a profile active, making changes in therapy settings without saving them to the/a profile, what would that mean? I would very much like some reasoning about how you think about things like these.

Good questions. So yes, to minimize changes to existing UX in onboarding and such, there should be a "default".

The upload should work how you describe; when a profile is changed, it needs to be uploaded, and when the currently active one is changed, that needs to be uploaded as well. To do this, though, you'll need the below change.

The biggest change is rather than storing profiles in files on the phone, the core StoredSettings data model needs to be updated to include the full set of profiles, and which one is active. This gives us a full history of what settings where at any point in time, and will be included in an export of critical logs, etc. And this data model change will propagate through the RemoteDataService parts of Loop, so any service (not just nightscout) could store this data as well.

After the storage is updated and the data is piped to remote data services, then the last part is probably making sure the UX is good for onboarding and settings editing. I don't think that a user should have to edit settings, and then decide if they want to update the saved profile. When they are using a non-default profile, and they edit it, that should be clear user intent. It's important that they know what they are doing, though, so when editing settings and using a non-default profile, we should be clear about that in the UI.

There were also some user requests about making more visible which profile is currently being used on the main status page.

Thanks for the feedback! Using StoredSettings and storing changes to the current profile makes things clearer, therapy settings should perhaps indicate that there is an active profile as well.

Regarding the UI for active profiles in the main view, do you already have a design approach for how this should be highlighted?

I'll look in to how StoredSettings is structured and next step would probably be a suggestion of how a multi profile StoredSettings could look like.