I always liked this feature in loop, to be able to drag your finger back on the insulin graph and the past IOB would display. I found this helpful for tinkering with settings.

Description
I think iaps is the best diy loop app in IOS.
But remote control is difficult to use，and it's not always in time. can we change it ,like Loop.

My iAPS build number is stuck on 1 and no Branch number.This has been the case for me for main and dev versions. I just realized this flaw when I saw screenshots of shots of settings in Discord posts.

I believe due to wrong sorting the TDD weighting calculations are always the same:

Should be falseto be descending order

On the Settings -> Nightscout Config screen, having a 'button' mirroring 'Backfill glucose' that allows someone to force an update of statistics / preferences would be great.

99.9% of the time, "once a day" is fine, but when looking at / debugging settings with someone else, being able to get more up to date data is helpful, especially if a case manager / doc in the office wants to confirm that a patient has properly applied changes, if needed.

Hi, according to the documentation a value of 90 minimum is mandatory for Remaining Carbs Cap. However, the system allows you to enter wayyyyyy lower than that. If the limit is supposed to be 90 lowest in accordance with the docs, not accepting lower values in that field may be a good idea.

I was wondering if there is a possibility in Temporary targets to also allow adjustment of SMB and UAM basal minutes. For people with basals lower than 0.3 to be able to allow iAPS to run for a short period with higher SMB/UAM for large carb meals. Giving the opportunity to run almost FCL.

Hi,
our son is using iaps a long time and is really happy so far. since a few weeks iAPS highlights the required insulin dose in RED if the prediction would cause in a low BG. Would it be possible to add this feature to apple watch as well?
Currently the Apple Watch value recommends insulin but in some cases we should wait for a while.
Thanks best MArkus

Scheduled basal (dotted line) is not displayed in HUD.

When the app is delivering a bolus (Omnidpod Eros) and in the interim it tries to apply a loop, it will throw an error/warning on the screen that the pump has an invalid state. Moreover, when "Extended" confidence alerts are enabled: it looks (though I'm not sure if its a coincidence and alerts for another reason, insulin lvl may have been below threshold) makes the Omnipod sound beep alerts.

It'd be nice if the app can suppress this warning/alarm when it knows it is delivering the bolus and the progress isn't at 100% yet.

I noticed in the data portion of health that iAPS is logging tons of “0 units” basal to Apple Health. I’m not sure if that’s intentional, but imho it’s rather useless as Apple Health doesn’t deal with temp basals or anything; only records total doses, TDD and average. Therefore this is, imho, unnecessarily generating a lot of data in the health app that’s taking up space needlessly.

Enter fat/protein and select meal presets also on Watch app

The Target Ranges section should be renamed to something like Target Glucose to make it less confusing. Technically there is no setting for ranges, but a set of single values that change by a defined schedule.

Settings screen	Target Ranges screen

I would prefer to be able to se the full context when looking at the enacted pop-up. Most notably, the current BG value is not shown otherwise. This commit, based on a previous commit by @mountrcg might be a potential fix.

Might have to check if this works the same for different phone sizes:

bjornoleh@c73a3cd

Offset Enacted popup for concurrent view with Header information

based on https://github.com/mountrcg/freeaps/commit/09804413dd1a0ec3e4a0b64dc5ec82250bdc4b9f 
but without opaque pop-up, and the empty box height is adjusted from 90 to 70. 
Works well on iPhone 13 mini, but not tested on other screen sizes.

Before:

After:

As title suggests ... I build app and began to set up app; i.e. Specifically CGM and pump. CGM was set as Dexcom. I tried to go back into CGM and the app closes out and returns back to home screen.

iPhone 12 mini on iOS 16.4.1
iAPS build v1.5.0-1
Branch: Main 91fc844
Dexcom 6G
Omnipod Dash pod

Feature Request:

Similar to DIY Loop for IPhone. I would love to be able to visually see or determine what if any Profile Overrides (%) might be in place, in Nightscout. Ideally this could be shown visually as a bar showing the start and stop time of the override, as well as a Pill under the Time at top left.

I have attached 2 screenshots.
1 shows the bar at lowest portion of NS display (circled in red). Is the Override was a preset, then the Presets name could be shown.

2nd Screen shows an example of the Override Pill.

Although I've now stopped using XDrip4iOS as my CGM, I do still use it at night as a follower as it has one great feather that's not available in iAPS - a locked screen showing clock and CGM. This means I can have it on by bedside table on the charger and it shows me the time, as well as the current BG value. This is invaluable in the night. This screen is locked so it stays on and prevents the screen saver from activating.

Discord reports:

1. https://discord.com/channels/1120154740857245808/1123067925746700379/1136625513755070495
2. https://discord.com/channels/1120154740857245808/1123067925746700379/1136897524821659668

These reports are possibly related, but needs more checking.

Not an issue per se but more of a requested function.

When adding carbs and moving to the bolus screen. If for some reason you want to back out of the bolus screen, it would be nice if iAPS would confirm if you still want to log the carbs. Current state is that when you back out (close) the bolus screen carbs are still logged. Deleting the carb entry is easy enough if one knows of this "bug" , but a more frustrating thing is if you have plugged in protein and fat. The equivalent carb entries are broken out into singular carb entries over many hours.

I can break this request out into two... but would it be possible for fat and protein entries to be captured as a single entry with text to show amount over defined duration?

Thanks!

Hi,

When using the option to replace the Pod (Eros, not expired yet), it will get you to the Deactivate Pod screen as it should. After successfully deactivating the existing Pod, you're forwarded to the "Pair Pod" screen so you can setup a new Omnipod. This screen will, instead of looking for a new Omnipod, unfortunately keep saying "No pod paired". It shows a "Retry"-button, which doesn't work and it won't actually give any option to try and pair the pod. It won't look for a new pod either.

To fix it, you're forced to go back to the deactivate pod window and then back to the existing, now deactivated, omnipod. Then you can again choose "Replace pod", which will throw an error that the pump is deactivated and offers "Discard Pod". Once removed, you're again forwarded to "Pair Pod" and this time: it will actually try looking for the new Omnipod and you can actually properly link it.

During normal operations, updating said once a day isn't a problem, but it would be nice if at the bottom of the 'Statistics' Settings screen, there was a button for "Refresh uploaded data", or something like that ... not even really looking for statistics to be updated, but the ability to refresh preferences after changes are made to it

Our office does virtual appointments, and being able to have a patient make changes and have those changes instantly ( even with a press of a button ) update the online values would save a lot of "and now share your preferences.json file"

Thx

On the Statistcs view for Day the header for Redings says readings today instead of for last 24 hrs. Seems to be due to
checking for number of days between last and first reading in ordered stats.

        // First date
        let previous = glucose.last?.date ?? Date()
        // Last date (recent)
        let current = glucose.first?.date ?? Date()
        // Total time in days
        let numberOfDays = (current - previous).timeInterval / 8.64E4

However due to the 5min loops the time difference between first and last reading of last 24 hours is often less than 1.440 min or a day. Checking for <1.435min seems to do the job

            // Total time in days
            let numberOfMinutes = (current - previous).timeInterval / 8.64E4 * 24 * 60

            VStack(spacing: 5) {
                Text(numberOfMinutes < 1435 ? "Readings today" : "Readings / 24h").font(.subheadline)
                    .foregroundColor(.secondary)
                Text(bgs.readings.formatted(.number.grouping(.never).rounded().precision(.fractionLength(0))))
            }

The system doesn't give alarms when insuline is running low.
Would be nice to have the option to set specific alarms for specific issues (like Xdrip)
Alarms on high or low bloud sugar, alarms on system failures (no glucose values, no pump connection), alarms (warnings) when insuline or battery running low.

In Loop, you are able to import profile settings from Nightscout when onboarding ... it would be cool if this could be implemented in iAPS as well.

The idea is that an endo in the clinic could pre-populate Nightscout before a patient visit, and when the patient gets there, when they setup iAPS' nightscout settings, as the first step, basal/isf/icr settings are pulled down and auto-populated.

Would love the optional ability to add text to Carb Entries. Where the text also gets uploaded to Nightscout.

in NS this is the "foodType"

I think an optional line directly under the Carbs line (it would be the 2nd line then)
It could also be populated by default when using a Meal Preset by the name of the preset.

While the NS entry is what I am really focused on, as that is where most analysis takes place.
Examples. We log 1g carbs for low treatments. It would be nice to see a note of how much she actually took. ie. log 1g but she actually took 15g.
I think Caregivers who use and monitor a T1D would find this very useful.
Currently, I have to text my daughter when she is out, if I see something going strange to find out what the 25g she just ate was. Was it candy or bacon and eggs ?

A small request ( maybe? )

Can we put all of the Nightscout settings under Nightscout?

Allow Treatments Upload
Allow Glucose Upload
Allow Statistics Upload

I am working with someone on recovering after her phone blew up, and didn't realize how many menu that we needed to go through just to get Nightscout fully populated 😭

Its not often that we have to do something like this, but it would be nice if it was all in one place ...

With autotune turned off, it would be nice if you could go into Autotune and:

• run now
• set basals

where your scheduled basals would be updated based on the calculated 'hourly basals' from autotune ... it would most likely be more accurate then most folks "personal estimates" and maybe improve accuracy of the dynamic features?

Suggestion-- for those still needing to prebolus. Can you add in a function for a timer?

Could be a predefined duration. i.e. 15 minutes and check box for user to select. This feature would be really helpful for those still needing to prebolus (would assume anyone not using an ultra rapid insulin). Would have to interface with native clock/timer app on iphone

Just documenting a thought ... there was a recent discussion on discord about Afrezza, which is an inhaled insulin that has been on the market for about 10 years now ... its peak is at ~30m, and its DIA is only 90 minutes ... dosing only works in 4U increments ...

See the following for details https://www.healthline.com/diabetesmine/afrezza-inhaled-insulin

What would be cool is if when bolusing ( via carb or manual bolus ), we could differentiate insulin being used ... for instance, if I had an option setting for 'Using Afrezza' in Settings, then the bolus screen would give two recommended values:

Pump vs Afrezza

If I need 10U of insulin, it would look something like:

Afrezza: 8U
Bolus: 2U

But the IOB calculator would need to factor in that the DIA of the 8U is only 90minutes, not the full DIA as per the pump settings ... I wouldn't want iAPS to factor in insulin at 5 hours that disappeared hours before ...

No idea on how difficult this sort of thing would be to pull off, but figured I'd at least document the concept ... I can just imagine being able to eat a pizza and having most of the BG from the carbs disappear almost as fast as it was being digested :)

Description

Remote bolus can be sent using the “announcement” event type in NightScout Care Portal as described in the documentation.
Recent tests have shown that this feature stops working permanently after an uncertain number of successful bolus announcements.
The cause of this issue seems to be associated with a remote bolus announcement that was sent but couldn’t be enacted due to external/unknown factors (like a pump/network error).
While these kinds of errors are expected to happen once in a while, the functionality of the remote bolus announcements is expected to continue working with future announcements after recovering from a failed bolus.

How to reproduce it

The issue can be reproduced by editing the freeaps/announcements.json and freeaps/announcements_enacted.json files in a way that the latest event (first element) is present only in the first file, but not in the second one.
After that any new remote bolus created in NS will not be enacted.
Example:

announcements.json

[
  {
    "created_at" : "2023-07-12T11:54:46.092Z",
    "notes" : "Bolus:0.1",
    "enteredBy" : "freeaps-x-remote"
  },
  {
    "created_at" : "2023-07-12T11:43:14.934Z",
    "notes" : "Bolus:0.25",
    "enteredBy" : "freeaps-x-remote"
  }
]

announcements_enacted.json

[
  {
    "created_at" : "2023-07-12T11:43:14.934Z",
    "notes" : "Bolus:0.25",
    "enteredBy" : "freeaps-x-remote"
  }
]

Proposed solution

After some troubleshooting it was detected that when all the announcements are fetched from NS, they are filtered by the latest enacted announcement (what makes sense since already enacted announcements should not be processed more than once) and from there the algorithm selects the most recent once, since only one announcement can be processed in a 10 minutes period of time.
The issue seems to be that instead of selecting the latest one to enact, it actually selects the oldest one, because the order of the elements comes sorted in the opposite way that the algorithm is expecting. This causes that in every new loop the algorithm keeps on picking the same announcement over and over and it can never be enacted because it’s older than 10 minutes.

I'll soon create a PR with my proposed solution. I’ve already tested it with many different scenarios, all tests being successful. That being said, this was my first time reading, debugging and fixing swift code, and I'm also new to iAPS. I can definitely use some help from the community to validate my solution :)

In order to make it easier to compare TIR between patients, including the euglycemic TIR values as part of statistics would be nice

TIR %ages ( median ) would drop as a result, since its a tighter range, but I can add that range to the full_list.php page as well, so that when comparing an individuals TIR to the group median, they would be able to compare apples to oranges, as well as seeing their TIR % based on their personalized range ...

Added for tracking as discussed on Discord and as Jon already had been thinking about doing this as well:

Working with U-200 I started wondering if it'd be worthwile to implement different insulin strengths. You keep the same settings/profiles in iAPS and you bolus and log the same amounts of insulin and carbs, but the system will: a.) when set to U-200 mode reduce the insulin output on the pump by 50% relative to U-100 and b.) for U-400 it will reduce it by 75% relative to U-100, and c.) it will also have to multiply the remaining amount of units available in the reservoir. (Eg: Omnipod Dash that starts counting down from 50U would show 100U instead when on U-200 mode)

So what you see as the user is when you want X amount of units: you always get that exact same amount of units regardless of the insulin strength; also in reports and Nightscout. 1U is always 1U - we're using the unit as the standard for measurement rather than how many units per ml were in the pen and are now in your pump. As such, we just ensure the amount of millilitres required to deliver that amount of units are reduced in the background to account for the pump only 'speaking' U-100. On the pump itself, if it has a display, this will confusingly looks like reducing "units", but we're just compensating for its dumbness. (Eg; if we want 2U on U-200 mode: we tell the U-200 filled pump, which always thinks it has U-100 in it, to inject "1U" to compensate for the higher insulin strength. And 2U/hr of basal will be set to 1U/hr on the pump.)

The reasoning behind it is that this leads to:

• a.) Consistency. It is similar to using Humalog/Lyumjev pens with increased potency. With the pens Eli Lily provides, 1U on the dial is still 1U injected - this doesn't change. The mechanism reduces the insulin (in ml) administered, not the user. So with U-200 when you inject 100 units, it injects only 0.5ml instead of the 1.0ml it would've been on U-100. This ensures the user doesn't have to change anything, the only thing that changes for the user is that the pen lasts twice as long.
• b.) Prevents confusion when you have to do the maths yourself whilst coming from U-100 and are used to doing bolus calculations in your head or correcting quickly
• c.) Keeps nightscout output consistent so for analysis you don't have to multiply it by 2 or 4 for the interpreter (eg: endo) to understand it. Plus some added bonuses if the care team hates U-200/U-400.
• d.) Keeps settings cross-compatible with any insulin type and strength, nothing changes; you just have more units available to work with (a 200U Omnipod becomes 400U or 800U)
• e.) Makes tuning work better and cross-compatible between different insulin types as it has the same data to work with, only minor tweaks may be necessary after switching to a different concentration.
• f.) It's actually more correct imho. Artificially "reducing" the units you're delivering in the profile and for bolus and basal is technically lying to the system. You're not suddenly actually using 50%-75% fewer units of insulin, no: you're still using the same amount of units. You just have to "lie" about that because the pump isn't capable of speaking U-200/U-400, but this lie finds its way to all your settings, reports, the algorithm, etc. It becomes more confusing to analyse those reports as well when every delivery you see must be multiplied by 2 or 4 to get to the true amount of units delivered.

Possible negative effects I honestly couldn't directly find any, especially as Eli Lily chose the exact same strategy with their pens. (Reduce output in millilitres, rather than making the user reduce their number of units - they chose to use the unit as the standard rather than the units per ml as well.) The current negatives are you have to maually change profile and manually remember it and the nightscout, AT and AS data get's "tainted" when you switch insulins. If it's as easy as switching in-app from U-100 to U-200 when you switch insulin type: that's easier and probably safer.

There are some caveats, however, such as:

• a.) The stored settings on the pump will be different than what the app shows, such as the basal rates. Whilst the app in this setup will show the same basal rates + ISF + I:C as on U-100, we do instruct the pump in the background to deliver 50% less on U-200 and 75% less on U-400. So 1U/hr basal will be 0.5U/hr shown on the pump with U-200 and 0.25U/hr shown with U-400. An in-app warning above/next to the basal rates (and other factors) plus a clear explanation in the docs is a good idea for starters. People must also be made aware that if for whatever reason they manually bolus directly from their pump (eg: Medtronic), they need to remember to do the maths.
• b.) The minimum bolus delivery (and minimum basal per hour) is different and is a hardware limitation. Eg: if 0.05 is the minimum, on U-200 that'd be equivalent to 0.1U and on U-400 that'd be equivalent to 0.2U minimum.
• c.) People using other software to generate reports from data stored on their pump, such as Glukoo or Tidepool, may see their insulin administration is reduced by 50% or 75% compared to what is shown in-app and in Nightscout. With the current supported pumps, that's likely not an issue (as they cannot be read with such tools to my knowledge); but it may be a problem in the future. It's important to point that out and/or get in touch with the developers of such tools to allow setting insulin strength.

Thank you for your consideration and thanks in advance to everyone providing input/suggestions/feedback on this.

latest dev code with the euglycemic stored in statistics.json seems to be mis-reporting Hba!c as 0:

     "Statistics": {                          +
         "HbA1c": {                           +
             "day": 0,                        +
             "week": 0,                       +
             "month": 0,                      +
             "total": 46.7                    +
         },

My Statistics view looks right, so it doesn't look like a data lose after last upgrade ... just zero values for those fields ... checked yours two, as you are reporting Euglycemic values too, same ... day/week/month all 0, total is 46.7 ( other scale, obviously ) ...

Borrowing a feature from AAPS, when treating BG below urgent low setting, there is a high TT automatically applied (user defined value and duration) to prevent over correcting and resulting in another low.

Typically this treatment would be a fast acting carb and likely to spike BG back up into range. If the UAM sees spike it may overcorrect

I have tested the new TempTarget with adjustable HalfBasalTarget functionality extensively. It often falls back to the HBT from preferences instead the one from the oref2_variables:
Desired set ratio 50% with TT 180, which should set HBT at 180.

• loop was calculated
• Variables are saved properly in oref2_variables, is enabled true and hbt at 180
• but autosens reports 33% instead of 50%, 33% would be calculated if HBT set at 140, which is the current value in preferences

Dev Branch, latest commit / TT set in Experimental / Popup after 1st Loop / fielecontent oref2_variables

I cannot ascertain what the problem is, as I also observe proper setting of the Insulin ratio with the TempTarget SensitivityRatio being calculated with the correct HBT. However as @Jon-b-m chooses not to publish Oref Source code there is nothing I can do at the moment to help fix this.

It's easiest tested with Ratios set to 50% as TempTarget will be the same as Halb Basal Exercise Target setting.

However to more easily analyze this issue I will put forward 3 PR's. Non of those PR's fixes the issue, though.
1.) show the TT based Sensitivity adjustment in InfoPanel besides the TempTarget -> #21

2.) fix rounding issues that outputs calculation results of mg/dL TempTargets with 1 digit and also with 2 digits with both measurement units in the history if one switches units in Preferences -> #22

3.) another UI solution that improves on usability and easyness in my view -> #23

Description:
Note: Example in mmol/L and with target 5.5 mmol/L, have not tested if this affects mg/dl also)
When entering a meal with a carb amount that would make eventual glucose hit the cap 22.3 mmol/L, the "Insulin recommended" in the bolus calculator uses "(22.3-5.5) / ISF" as calculation regardless of the carb amount.

With higher ISF settings (my 6 year old son for instance that have ISF between 17-21 during the day, and CR between 15-25g/U) this makes the bolus calculator recommend a too low bolus at mealtime in almost all cases. Our workaround is off course to enter a bolus amount based on manual calculation, but it would be great if the bolus calculator could be accurate with all kinds of ISF and CR settings.

Nightscout has a Profiles section (Profile Editor), that can store profile changes.

Using Loop as an example, if the "Normal" or Base profile in Settings are changed, then a new Profile is created and uploaded to NS with a Record Valid from current date.

1. This allows people to view the history of Profile changes
2. Allows caregivers to check on profile settings when access to T1D phone is not readily available
3. There might be downstream benefits to NS reporting, not sure about that though

This is a lesser priority, but still useful (in my opinion)

Urgent: Despite hitting save every time, my targets won’t save and revert to 4. I have a temp target set now for safety reasons.

It appears the carb ratio has a minimum value of 1u:3gr. I'm not sure if this limit was chosen by some design (couldn't find anything about it), but I for example need it to be lower. Was wondering if there's no particular reason for a cap of 3, if it could be removed. I found that modifying the json to a lower number simply reverts back to 3.

Only creating this because it was suggested ... am not sure how to effectively pull this one off, so wasn't going to ask ...

I use an app called myFitnessPal ( there are a few different ones out there ) to calculate my Carb/Fat/Protein values, and right now, manually enter them into iAPS for dosing. mFP has a huge database of foods ( individual foods plus pretty much every restaurant imaginable, and ability for users to add more ), so pretty much anything you can think of can be found ...

Each user has their own sub-database of what they eat ( ie previously looked up ), so I can easily either put together a new meal based on individual components, or store a meal and call that up ( ie. I built up my pizza, from crust through to toppings and just pull that pizza in each time since I alway eat the same pizza ) ...

When you enter food, it does time stamp it / group it, but if you add a food, they only give you 4 categories:

• Breakfast
• Lunch
• Dinner
• Snacks

So if I enter a snack in now ( 11:44 ) and another snack later tonight, it shows in Apple Health as one big snack at the same time, not two different snacks ( testing that to double check )

The point being that even though the app writes to Apple Health, not sure how easy it will be to pull the data out due to how it groups the data ... if you pulled in 'the most recent non-iAPS Carb/Fat/Protein values, if I'm correct about how it writes to Apple Health, you could get values later in the day that includes previous values, inflating the numbers.

As I said, am testing to double check ... just added a snack and will add a second one in a few hours ... short term test ( couple of minutes ) appears to validate the 'one big number' theory, but the system may just be seeing the short time between entries as my building my one snack, not as two different ones ... will update ticket in a few hours ...

Multiple time a day I lose connection to my Orange Link. If i close iAPS completely and reopen it again, the connection is reestablished and works. Not sure what is going on there. Did not have this issues running a much older version of iAPS.

What can I do to help fix this issue? Do you need logs, or more info? Screenshots?

Hi,

When attempting to set the following targets:
00:00 5.8 - 6.3mmol/l
07:00 5.6 - 6.1mmol/l

I noticed that that second entry always goes back to 5.6-5.6.
Upon inspecting the JSON file, it seemingly did write it properly; but due the conversion it was an exceptionally large fraction (eg: 6.09340030303030303). When changing the upper target to 6.0 or 6.2: it does display properly. Only setting it to 6.1 results in the lower target also being shown for the upper target.

Actual Behavior
After creating a new Profile, the Override Profile Target field converts into mg/dl units.

Expected Behavior
After creating a new Profile, the Override Profile Target value should keep user-defined glucose units.

Open/Hide

Screenshot

1. Validate Secrets pass
2. Add Identifiers pass
3. Create Certificates pass
4. Build iAPS error
   I have followed the tutorial, but it still doesn't work, I suspect it is my account problem.
   please help me.
   How should I solve him, I don't have an Apple computer, I can only build it through github actions.

Below is the error logs.

[04:22:03]: $ set -o pipefail && xcodebuild -workspace ./FreeAPS.xcworkspace -scheme FreeAPS\ X -configuration Release -destination 'generic/platform=iOS' -archivePath /Users/runner/Library/Developer/Xcode/Archives/2023-06-18/iAPS\ 2023-06-18\ 04.22.03.xcarchive archive | tee /Users/runner/work/iAPS/iAPS/buildlog/FreeAPS-FreeAPS\ X.log | xcpretty
[04:22:04]: ▸ 2023-06-18 04:22:04.248 xcodebuild[16985:78348] DVTCoreDeviceEnabledState: DVTCoreDeviceEnabledState_Disabled set via user default (DVTEnableCoreDevice=disabled)
[04:22:06]: ▸ 2023-06-18 04:22:06.135 xcodebuild[16985:78348] [MT] IDEFileReferenceDebug: [Load] <IDESwiftPackageCore.IDESwiftPackageSpecialFolderFileReference, 0x600003cca000: name:langs path:group:langs> Failed to load container at path: /Users/runner/Library/Developer/Xcode/DerivedData/FreeAPS-ffhbcjzbszlapbgzecdzvzprscam/SourcePackages/checkouts/SwiftDate/Sources/SwiftDate/Formatters/RelativeFormatter/langs, Error: Error Domain=com.apple.dt.IDEContainerErrorDomain Code=6 "Cannot open "langs" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "langs" as a "Swift Package Folder" because it is already open as a "Folder".}
[04:22:15]: ▸ Run script build phase 'Swiftformat' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'FreeAPS' from project 'FreeAPS')
[04:22:15]: ▸ ** ARCHIVE FAILED **
2023-06-18 04:22:04.248 xcodebuild[16985:78348] DVTCoreDeviceEnabledState: DVTCoreDeviceEnabledState_Disabled set via user default (DVTEnableCoreDevice=disabled)
2023-06-18 04:22:06.135 xcodebuild[16985:78348] [MT] IDEFileReferenceDebug: [Load] <IDESwiftPackageCore.IDESwiftPackageSpecialFolderFileReference, 0x600003cca000: name:langs path:group:langs> Failed to load container at path: /Users/runner/Library/Developer/Xcode/DerivedData/FreeAPS-ffhbcjzbszlapbgzecdzvzprscam/SourcePackages/checkouts/SwiftDate/Sources/SwiftDate/Formatters/RelativeFormatter/langs, Error: Error Domain=com.apple.dt.IDEContainerErrorDomain Code=6 "Cannot open "langs" as a "Swift Package Folder" because it is already open as a "Folder"." UserInfo={NSLocalizedDescription=Cannot open "langs" as a "Swift Package Folder" because it is already open as a "Folder".}
Run script build phase 'Swiftformat' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'FreeAPS' from project 'FreeAPS')
** ARCHIVE FAILED **
[04:22:15]: Exit status: 65
[04:22:15]:

[!] Error building the application - see the log above
[04:22:15]: Maybe the error shown is caused by using the wrong version of Xcode
[04:22:15]: Found multiple versions of Xcode in '/Applications/'
[04:22:15]: Make sure you selected the right version for your project
[04:22:15]: This build process was executed using '/Applications/Xcode_14.3.app'
[04:22:15]: If you want to update your Xcode path, either
[04:22:15]:
[04:22:15]: - Specify the Xcode version in your Fastfile
[04:22:15]: ▸ xcversion(version: "8.1") # Selects Xcode 8.1.0
[04:22:15]:
[04:22:15]: - Specify an absolute path to your Xcode installation in your Fastfile
[04:22:15]: ▸ xcode_select "/Applications/Xcode8.app"
[04:22:15]:
[04:22:15]: - Manually update the path using
[04:22:15]: ▸ sudo xcode-select -s /Applications/Xcode.app
[04:22:15]:

+---------------+------------------------------+
| Build environment |
+---------------+------------------------------+
| xcode_path | /Applications/Xcode_14.3.app |
| gym_version | 2.213.0 |
| export_method | app-store |
| sdk | iPhoneOS16.4.sdk |
+---------------+------------------------------+

[04:22:15]: ▸ /Users/runner/work/iAPS/iAPS/FreeAPS.xcodeproj: error: Provisioning profile "match AppStore ru.artpancreas..FreeAPS.watchkitapp.watchkitextension" doesn't match the entitlements file's value for the com.apple.security.application-groups entitlement. Profile qualification is using entitlement definitions that may be out of date. Connect to network to update. (in target 'FreeAPSWatch WatchKit Extension' from project 'FreeAPS')
[04:22:15]: ▸ /Users/runner/work/iAPS/iAPS/FreeAPS.xcodeproj: error: Provisioning profile "match AppStore ru.artpancreas..FreeAPS" doesn't match the entitlements file's value for the com.apple.security.application-groups entitlement. Profile qualification is using entitlement definitions that may be out of date. Connect to network to update. (in target 'FreeAPS' from project 'FreeAPS')
[04:22:15]: ▸ warning: Run script build phase 'Swiftformat' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'FreeAPS' from project 'FreeAPS')
[04:22:15]: ▸ note: Run script build phase 'Run Script' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'FreeAPS' from project 'FreeAPS')
[04:22:15]: ▸ /Users/runner/work/iAPS/iAPS/FreeAPS.xcodeproj: error: Provisioning profile "match AppStore ru.artpancreas..FreeAPS.watchkitapp" doesn't match the entitlements file's value for the com.apple.security.application-groups entitlement. Profile qualification is using entitlement definitions that may be out of date. Connect to network to update. (in target 'FreeAPSWatch' from project 'FreeAPS')
[04:22:15]:
[04:22:15]: ⬆️ Check out the few lines of raw xcodebuild output above for potential hints on how to solve this error
[04:22:15]: 📋 For the complete and more detailed error log, check the full log at:
[04:22:15]: 📋 /Users/runner/work/iAPS/iAPS/buildlog/FreeAPS-FreeAPS X.log
[04:22:15]:
[04:22:15]: Looks like fastlane ran into a build/archive error with your project
[04:22:15]: It's hard to tell what's causing the error, so we wrote some guides on how
[04:22:15]: to troubleshoot build and signing issues: https://docs.fastlane.tools/codesigning/getting-started/
[04:22:15]: Before submitting an issue on GitHub, please follow the guide above and make
[04:22:15]: sure your project is set up correctly.
[04:22:15]: fastlane uses xcodebuild commands to generate your binary, you can see the
[04:22:15]: the full commands printed out in yellow in the above log.
[04:22:15]: Make sure to inspect the output above, as usually you'll find more error information there
[04:22:15]:
+------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Lane Context |
+------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| DEFAULT_PLATFORM | ios |
| PLATFORM_NAME | ios |
| LANE_NAME | ios build_iAPS |
| KEYCHAIN_PATH | ~/Library/Keychains/fastlane_tmp_keychain |
| ORIGINAL_DEFAULT_KEYCHAIN | "/Users/runner/Library/Keychains/login.keychain-db" |
| LATEST_TESTFLIGHT_BUILD_NUMBER | 1 |
| LATEST_TESTFLIGHT_VERSION | |
| BUILD_NUMBER | 2 |
| SIGH_PROFILE_TYPE | app-store |
| MATCH_PROVISIONING_PROFILE_MAPPING | {"ru.artpancreas..FreeAPS"=>"match AppStore ru.artpancreas..FreeAPS", "ru.artpancreas..FreeAPS.watchkitapp"=>"match AppStore ru.artpancreas..FreeAPS.watchkitapp", "ru.artpancreas..FreeAPS.watchkitapp.watchkitextension"=>"match AppStore ru.artpancreas.***.FreeAPS.watchkitapp.watchkitextension"} |
+------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
[04:22:15]: Error building the application - see the log above

+------+--------------------------------+-------------+
| fastlane summary |
+------+--------------------------------+-------------+
| Step | Action | Time (in s) |
+------+--------------------------------+-------------+
| 1 | default_platform | 0 |
| 2 | setup_ci | 0 |
| 3 | update_project_team | 0 |
| 4 | app_store_connect_api_key | 0 |
| 5 | latest_testflight_build_number | 0 |
| 6 | increment_build_number | 5 |
| 7 | match | 2 |
| 8 | latest_testflight_build_number | 0 |
| 9 | increment_build_number | 0 |
| 10 | update_code_signing_settings | 0 |
| 11 | update_code_signing_settings | 0 |
| 12 | update_code_signing_settings | 0 |
| 💥 | gym | 81 |
+------+--------------------------------+-------------+

[04:22:15]: fastlane finished with errors
Error: Process completed with exit code 1.

I tried to set the High/Low parameters for the Statsview in release before your latest change to 40-90 and 110-270. When inputing a value outside these boundaries iAPS crashes. Verified on Simulator as well.

The more detailed TIR statistics underneath the graph is not showing all intervals in dev 2.1.7

Either the pop up is wrong, or the Models file is wrong:

    var suspendZerosIOB: Bool = true

The pop up states that it defaults to False

could you add 7 day average for TDD into statistics ... currently only past 24h is available, but like the longer time average to use for calculations ( ie. ISF = 100 / TDD ) ...

     "Insulin": {                             +
         "TDD": 82.75,                        +
         "bolus": 82.25,                      +
         "temp_basal": 0.5,                   +
         "scheduled_basal": 0                 +
     },                                       +

thx