Loop Development

Overview¶

The early history of the Loop app was touched on in the introductory LoopDocs Overview: Development History section.

The Loop Releases page lists releases since version 3.0 in reverse chronological order. For older release history, check out Loop 2 and older .

The current released version of the Loop app is always in the main branch of the LoopWorkspace repository.

The next version of the Loop app is developed using branches.

The dev branch is used by the developers to push out changes for users to test before that code is released
- Sometimes there are breaking changes in dev
- A breaking change is when you can build the dev branch over your existing app, but cannot leave the dev branch without deleting your app from your phone
- It's been a few years since this happened (when we went from Loop 2 to Loop 3), but it will be happening again soon with an upcoming merge from Tidepool
In addition there are specific feature branches that enable users to test new pump and cgm managers or features for existing managers before they are added to the dev branch
You should only test a development or feature branch if you are willing to be an active participant with the developers:
- Monitor announcements in zulipchat
- Provide feedback
- Build frequently to obtain the latest feature or bug-fix that is being tested
If you are willing to help out - this is the way the next release of Loop is improved.

Please read this entire page before using any version of Loop other than the released code.

Updates in `dev`¶

This section provides an overview of changes to dev compared to the current release: Loop v3.14.0.

The current version of dev is v3.14.1. It is functionally identical the released code. The only difference is we added an alert you must acknowledge if you are running the dev branch.

Please check the development channel in zulipchat for notifications when an update to the dev branch is expected so you will be prepared. Do this before you install a dev build from TestFlight.

Branches¶

In addition to the main and dev branches, which are tightly controlled and only updated through a formal pull request and approval process, there are also some feature and update branches. These branches are subject to more frequent updates, so users testing these branches should follow along in zulipchat for information.

The update_dev_to_M.m.# is where the next version of dev is tested before becoming part of dev and later being released as main
The branches starting with feat/ have one or more special features, like support for new pumps, CGM or the new universal pump manager for all types of Omnipods

The graphic below shows the main and dev branches along with some feature branches and an update branch.

Updates in Progress (Click to open/close)

Sometimes there is a work-in-progress branch, update_dev_to_M.m.# used to collect new items in preparation for the next dev branch. This allows people to test and comment on the updates before they land in the dev branch.
There are also feature branches for items like new pumps and new CGMs:
- The feature branches typically spin off of dev, but if a updates_dev_to_ . . . branch is in work, it is merged into the feature branches as items get included

Table of Active Branches¶

The table below lists active branches. Note that updates may occur and be announced in zulipchat a day or two before updates propogate to LoopDocs.

branch	version #	last updated	comments
main	3.14.0	14 May 2026	release
dev	3.14.1	23 May 2026	functionally the same as `main` 3.14.1: PR 452 add alert about dev branch
feat/dev-dana-medtrum - SHA `638d351`	3.14.0	14 May 2026	- adds support for Dana and Medtrum pumps - SHA for DanaKit is `c544c42` - SHA for MedtrumKit is `6060747` Medtrum User Interface Redesigned to be more like the Omnipod User Interac. Several fixes added for MedtrumKit, not yet in DanaKit
feat/eversense - SHA `059caf5`	3.14.0	15 May 2026	- adds experimental support for Eversense (includes Dana and Medtrum pumps support - same SHA as above) - this branch is ready for use to evaluate and report back - SHA for Eversense is `fe322a6`
feat/omnipodkit - SHA `553bf36`	3.14.0	15 May 2026	The new OmnipodKit pump manager, controls all Types of pods. Initially only the Eros and DASH pod types are available for feature branch testers - SHA for OmnipodKit is `9bf676e` Please read Feature Branch: OmnipodKit Pump Manager

Eversense Support

The Eversense CGM is now supported by the Loop app in a feature branch. To simplify maintenance, the branch which supports Eversense also supports the two new pumps: Dana and Medtrum.

The branch which support Evensense E3 and E365 CGM is simply called feat/eversense.

What is SHA? (Click to Open/Close)

SHA-1 means Secure Hash Algorithm 1. This is used to generate an alphanumeric code to identify which version of a repository is used.

Each time you save a change to your GitHub repository, a unique SHA-1 is created. That identifier is used to tell GitHub a specific change that you want applied or identifies a specific version for that repository. These work for any compatible fork from the original GitHub repository.

The SHA-1 20-character value is abbreviated as SHA and typically only the first 7 or 8 characters are presented to identify the commit for a particular repository.

How to Build Feature Branches¶

For full instructions on building different branches, review these pages:

Browser Build: Build a Version in Development
- For short-cut instructions on adding the feature branch: Feature Branch
Mac Xcode: Build a Version in Development

Browser Build¶

Use the page linked above to add the desired branch name (from the table above) to your fork. In other words, where the directions indicate the dev branch, you substitute the branch name of interest.

Mac-Xcode Build¶

For Mac Xcode build, the lines you need to copy and paste into a Terminal window are explicitly provided below:

Download and build the feat/omnipodkit branch

/bin/bash -c "$(curl -fsSL \
  https://raw.githubusercontent.com/loopandlearn/lnl-scripts/main/BuildLoop.sh)" \
   - feat/omnipodkit

Download and build the feat/dev-dana-medtrum branch

/bin/bash -c "$(curl -fsSL \
  https://raw.githubusercontent.com/loopandlearn/lnl-scripts/main/BuildLoop.sh)" \
   - feat/dev-dana-medtrum

Download and build the feat/eversense branch

/bin/bash -c "$(curl -fsSL \
  https://raw.githubusercontent.com/loopandlearn/lnl-scripts/main/BuildLoop.sh)" \
   - feat/eversense

Version Number Plan¶

Please see Loop Version Numbering for the current method for version numbering for the main and dev branches.

The idea of having a feature branch is not new for the Loop app but hasn't been used for a few years. At this point, we have several feature branches.

The version number in the feature branch will match either the dev branch version number or a work-in-progress update to the dev branch which uses the naming convention update_dev_to_M.m.#.

In other words, the feature branch is up to date with other changes to dev or update_dev_to_M.m.# with the added support for the specific feature
Each feature has an associated repository that contains the feature
- When updates to the feature are added, the SHA for the feature branch and the SHA for the submodule(s) which support that feature will be reported in the table above and can be found by examining the LoopWorkspace repository for that feature branch

Feature Branch: OmnipodKit Pump Manager¶

You need to build the feat/omnipodkit branch if you want to test the new All Omnipod Types pump manager. Build instructions are found here: How to Build Feature Branches.

This pump manager comes with improved user interface and user experience for Omnipod Classic (Eros) and DASH pods including

Some layout adjustments
Some new labels
Some reworked sub-menus with added information or features
WARNINGS
- no translations added yet so English only for the initial roll-out
- no pod-keep-alive function added yet

The next time you change a pod, delete the pump manager you are using and add a new pump. See Change Pump Type for detailed instructions.

Select All Omnipod Types as your new pump manager.
Go through the onboarding of selecting notifications and reminders and insulin type.
You will then be presented with a screen to select the type of pod.
Choose the Classic (Eros) or DASH Pod type

The underyling control code should be the same, but we want more people testing it to ensure this works as well as the older pod managers. The developers have been using it on themselves before making this publicly available.

Do not use with iPhone 16 or 17e and Atlas pods

The new OmnipodKit does not have the pod-keep-alive feature incorporated. For now, if you use an iPhone 16 (any model) or iPhone 17e and have Atlas pods (the newer version for DASH pods), stick with the old Omnipod DASH selection.

Why OmnipodKit?

When the initial work to add DASH to the supported pumps was started in 2021, a completely separate pump submodule was created distinct from the Classic (Eros) pump submodule. In other words, OmniBLE handled DASH and OmniKit handled Eros.

A significant portion of the two repositories serve the same function. Whenever a fix or improvement was added to OmniBLE, it was duplicated and added to OmniKit. Having a universal pod manager saves significant developer resources.

OmnipodKit provides the individual support needed for different Pod Types while using a single copy of code for most of the logic and user interface.

The improvements that have been going on in the background landed in the new pump manager only - and were not replicated in the OmniKit or OmniBLE repositories.

This will be a significant time saver for developers moving forward for updating code and adding support for new types of pods.

feat/omnipodkit supports other plugins

For the convenience of the developers and testers, this feature branch, feat/omnipodkit, also supports the new pump and cgm managers that are found in the other feature branches.

In other words:

Eversense is available as a CGM
Dana and Medtrum are available as a pump, in addtion to OmnipodKit and all the older pump managers

Feature Branch: Pod Keep Alive Feature¶

The feat/pod-keep-alive branch has been deleted. It was updated and incorporated into the released code. Please build the main branch over your existing app. All your selections will remain as you configured them when building the feat/pod-keep-alive branch.

See Pod Keep Alive Feature.

Feature Branch: Dana and Medtrum Support¶

Anyone using Dana or Medtrum pumps must build one of these branches. The pump manager support is identical. The difference is the second one includes support for the Eversense CGM. Build instructions are found here: How to Build Feature Branches.

feat/dev-dana-medtrum
feat/eversense

New Pump Managers

These are new Pump Managers and may have known or unknown bugs. Please only use a feature branch if you are prepared to follow along in zulipchat and are willing to help test and resolve issues. This is critical when using new pump managers.

Please ensure you have the latest version of a given branch by synching before you build:
- Browser Build: be sure you select feat/dev-dana-medtrum or feat/eversense branch
  - The Build Loop action automatically syncs your fork when building
  - Be sure to install the resultant build from TestFlight onto your phone
- Mac-Xcode: you can update your clone or download a fresh copy
  - if updating your clone, be sure to type git pull --recurse in your LoopWorkspace folder to include updates to all submodules
  - See Mac-Xcode Build for fresh download instructions

Bluetooth Connection Issues for Dana and Medtrum

Both the Dana and Medtrum pumps are designed to stay in continuous Bluetooth commnication with the pump controller. This is quite different from the older Pod and Medtronic pumps.

The behavior of your OS-AID system needs to properly handle bolus and temp basal rate events in progress if that communication is interrupted. This can happen if someone walks away from their phone during a bolus or while a temp basal rate is in progress.

Please read the rest of this section to learn about how this might affect an older or current version of your OS-AID app.

Recently Closed Issue for Medtrum¶

Medtrum Bluetooth Comms Loss Updated

MedtrumKit - fixed on 29 April 2026¶

MedtrumKit Issue 112 reported that MedtrumKit did not properly handle a Temp Basal Rate (TBR) event if BLE comms was lost at the time the TBR completed.

MedtrumKit PR 118 provided an updated management of TBR providing accurate handling of TBR when BLE was interrupted and later restored.

MedtrumKit - fixed on 25 March 2026¶

MedtrumKit Issue 92 reported that when the Medtrum moved out of Bluetooth range, the app reported an interrupted bolus when in fact the bolus continued. This led to underreported values for Active Insulin, also known as Insulin on Board (IOB).

MedtrumKit Pull Request 93 fixed this issue. Now if Bluetooth communication is lost, the pump manager relies on expected timing to continue the bolus progress display. The bolus is not considered final until BLE is restored and the app is able to communicate with the pump.

Open Issue for DanaKit¶

DanaKit Bluetooth Comms Loss Not Fixed

DanaKit - Issue is still open¶

The Medtrum Issue report led to testing for DanaKit. The bolus issue has a slightly different error signature. This two issues are still open, so Dana users need to be aware of them.

DanaKit Issue 36 reported that DanaKit did not properly handle a Temp Basal Rate (TBR) event if BLE comms was lost at the time the TBR completed.

DanaKit Issue 34

When Bluetooth communication is interrupted during a bolus, the pump manager reports the bolus as finalized even if it is still being delivered
If this happens, you cannot cancel from the app
The OS-AID treats that bolus as finalized as soon as communication is lost

This is less serious of a problem because the reported IOB matches what the pump was told to deliver. But of course, it will be fixed.

Issue Fixed Earlier¶

Temp Basal Accounting Corrected

The accounting used by Loop requires specific feedback from the Pump Managers. This important information was not initially added to the Dana or Medtrum pump managers. Those both were developed first for Trio which uses a different algorithm and accounts for insulin dosing differently.

This oversight is fixed for both Dana and Medtrum.

Medtrum was fixed on 17 Feb 2026
Dana was fixed on 26 Feb 2026

If you were using Loop with one of these pumps before those dates, be aware that when you update your build, your settings may need to be adjusted.

For more information see the closed MedtrumKit Issue: Loop and Medtrum Pump Manager: Basal Delivery Accounting is Not Correct
For more information see the closed DanaKit Issue: Loop and DanaKit: Observe Pump Event Details in Loop

Feature Branch: Eversense Support¶

Recently Closed Issue for Eversense¶

Eversense Placement Guide updated

EversenseKit - fixed on 30 April 2026¶

EversenseKit Issue 26 reported that the placement guide graph was not updating when attaching the Transmitter over the sensor.

EversenseKit PR 30 fixed the problem. The solution was to enable debug mode while using the placement guide and disable debug mode when done.

There is a new feature branch available, feat/eversense which supports the Eversense E365 and E3 transmitters. In addition to Eversense support, this branch also has the same pump support as the feat/dev-dana-medtrum branch.

For anyone who tests this branch with Eversense, if there are issues with your use of Loop with Eversense please report in this zulipchat channel.

Be sure to include:

a description of your issue
your phone model and iOS version
your build method:
- Browser Build
- Mac-Xcode and include Xcode version
which version of code you are running (branch name and SHA)
share your Eversense logs (at bottom of the Loop Eversense screen)

If you prefer to create an issue directly at the Eversense repo, create it here:

https://github.com/bastiaanv/EversenseKit/issues

Note

This was tested using an E365 transmitter attached to a small vial containing a sensor in glucose solution

This enabled testing the Eversense behavior with Loop on a test phone

No testing with the E3 (3-month, 90-day) sensor has been performed

Older updates¶

Updates from v3.8 to v3.10¶

The updates developed in the dev branch before the release of v3.10.0 are found in these PR.

Updates from v3.6 to v3.8¶

The updates developed in the dev branch before the release of v3.8.0, are provided in reverse chronological order.

v3.7.7¶

The changes are to maintenance scripts and to translations with no change to the function of the code:

There are some updates to translated strings that people who use Loop in other languages may notice
- The DanaKit pump translations now work
- Parts of the Favorite Foods sections are now translated
- Many common keys used in more than one submodule are linked so they only need to be translated one time to appear in the app
With v3.6.2, the method to Add Identifiers when using Browser Build for the Loop app changed.
- The new method requires the time-sensitive capability be added manually
- This change was captured in LoopDocs but not in testflight.md
- The instructions found in testflight.md were updated
For developers who might want to know, this update included
- conversion to use String Catalogs for localization in the submodules with associated tweaks to Xcode configuration
- updates to the CircleCI configurations

v3.7.6¶

Updated some localization (strings translated to different languages)
- Added scripts to make localization more streamlined
Cleaned up some code
- Fixed a bolus problem with iOS 26
- Discarded some unneeded files
- Updated to Xcode 16.4 for browser build and CircleCI quality testing

v3.7.5¶

Added support for Dana-i and DanaRS-v3 pump models

v3.7.0 through v3.7.4¶

dev v3.7.x was same as main v3.6.x.

Updates from v3.4 to v3.6¶

All updates are reported in Loop 3.6.0

Check Version History for minor updates found in 3.6.x.

Updates from v3.2 to v3.4¶

Features new with v3.4, originally in the Updates in dev section before the release, have been inserted into the appropriate part of the LoopDocs website (indicated by the up-right arrow after the link). The links below are left to assist people in finding the features.

What are Git Branches?¶

There is a lot of discussion about branches with Loop but the concept is simple. Basically, they are all slightly different versions of Loop...kind of like different edits of the same book.

To really understand what branches are, we should probably explain a little more about the software and how development works. You can watch a 30-minute long, classic Katie DiSimone video explanation about branches created when Loop Version 2.0 was newly released. Keep in mind while watching the video:

Details that are different:

The way the code is organized has changed: see LoopWorkspace
The default branch name used to be master - but is now main
carthage is no longer used to determine which submodules (frameworks) are pulled in to build Loop (see LoopWorkspace)

The information in this video is still generally useful with the last half focused on automatic-bolus - the automatic-bolus dosing strategy has now been incorporated into Loop main branch. Loop has moved on to using only one stable branch (main), with dev suggested for developers/testers.

`Loop` GitHub Information¶

Loop developers own an account in GitHub called LoopKit. Within that account, the developers have several repositories that support Loop in particular. A repository is like a book...let's think of it like a cookbook for now. Within the LoopKit account, there are repositories for Loop itself, LoopDocs, and various other supporting "frameworks" that are helper repositories for Loop to build correctly. For example, Loop's repository has a lot of info about the app itself; the outward-facing things that you interact with. How information is put to you and taken in from you...that's in Loop repository code. But, there's more than just a user interface for Loop. Loop has to do a lot of complex work like Bluetooth communications, algorithm math, pump communications, etc. The Loop app has help from frameworks to do those other parts. CGMBLEkit for some of the transmitter parts of Loop, RileyLink_ios for the pump managers (talking to the pumps and decoding their information), LoopKit for the algorithm about carbs and insulin curves, etc.

When you build Loop, you actually start with LoopWorkspace which points to all the other repositories needed for a complete Loop app.

Loop as a Cookbook¶

So let's imagine Loop as a cookbook. The developers are the authors/chefs of the recipes (code) in the cookbook. The authors spend countless hours testing new recipes, taste testing, and documenting improvements. They send the drafts to the editor, who makes suggestions and eventually, the cookbook is finalized. There are no grammar issues, and no typos, the photos are beautiful and the recipes are yummy. They publish the book and you see a gorgeous final product on the shelves. That is called a release, and it is the main branch. This book has been well-tested and is super stable. Every time you cook with those recipes, you know exactly what you're getting and lots of people have had a chance before you to make sure that it all tastes good. The main branch is stable and tested.

But then...the chefs/developers go on a trip. They are inspired by new cuisine and want to add new recipes to the old cookbook. (Things like Omnipod support and the overrides are new "recipes" that were developed since the last main release, for example.) But, the process of developing a recipe is arduous. There was a lot of trial and error involved. Lots of tweaking ingredients (code). The editors try out the new recipes and offer feedback (similar to the Issues List on GitHub). While the recipes are being developed, they have a version of the old cookbook that gets marked up...edited in pencil a lot. Scribbles and notes in the side. Revisions happen frequently because that's what testing new recipes is all about. These marked-up versions of the cookbook are called the dev branch. Short for "development" branch. Like the name sounds...this is where new developments are happening, new recipes, and tweaks.

After much testing and tweaking, eventually, the recipes get the flavors right (bugs in code are squashed) and enough people have provided feedback and careful observations of results...that the book goes to the publishing house for the next printing. The cookbook is republished with an updated edition number and new recipes are highlighted. When this happens in Loop, Loop's main branch is updated with the new features coming from dev (aka, the dev branch is merged into the main branch). When that happens, the main branch gets another release version. At this point, dev and main are identical. They remain so until the development team for Loop starts working on the next batch of improvements, which could be in the next hour or even days later, but then the cycle starts again. The developers will start editing the code again and dropping those edits in the dev branch for further development.

What's going on in the `dev` branch?¶

The dev branch is where the next version of Loop is being developed and tested.

If you choose to build Loop using a dev branch, you need to be aware that the dev branch may update code frequently and unannounced in the traditional sense that most users in the Looped group or Instagram would see. Developers are not helped by people being in a dev branch if those users mistakenly think of it as a stable main branch with lots of detailed docs to go with it. People should only use a dev branch build if they EDUCATE themselves on the expectations and how to properly manage dev information and updates. People using the dev branch should also have regular access to a computer to be able to rebuild quickly if a new bug/fix is identified.

If you choose to use a dev build, you can stay abreast of developments in a number of ways...but they will all require you to do some legwork and keep yourself informed. This is not a situation where you should expect a fancy Loopdocs page updated regularly with current "dev updates"...that's just not the way the dev branch works (at least normally). There is, however, an attempt to organize the current status of development in the Updates in dev section.

Use Zulipchat forums for Loop.
This forum has several streams of conversations (streams) depending on interest. I highly recommend following all the streams so you do not miss conversations. You can select by stream and by topic within a stream to focus on a given conversation.

Zulip Chat Streams

If you are using the dev branch, you must be in the #development stream.
If you want to know when LoopDocs gets updated, follow the #documentation stream.
Code changes are called commits in GitHub.
The #github stream will have an automated post whenever a new commit is made and it will give a brief line description of the commit.

img/zulipchat.png

You can also go directly to the git commit history for each of the branches if you'd like. Note that LoopWorkspace is the card-catalog for all the books (repositories) used by Loop.

If you click on the commit, you can see exactly what changes to the code were made. It's an interesting learning experience. In red is the old code, and in green is the updated code. The line numbers and file names of the edited code are also there to help.)

img/commit.png

I don't expect many of you would understand exactly what the edits mean, or how the new code might function. However, I bring up the topic of git commit history so that you can use that to realize just how often the dev branch is updated. Go ahead and look at the number and frequency of commits in that branch. That's why no one would want to maintain a documentation list of the changes in the dev branch. It's just too much of a moving target.

Watch the `Loop Repository` and `Issues List`¶

Open the Loop repository and subscribe to the Issues.

You can choose to watch the repository so that you get emails when new Issues are reported. This is a good way to find out if other people are reporting odd behavior that you are wondering about. If you use dev and wonder about something you are seeing in Loop, you can check Issues list to see if others are noticing the same. If so, you can help by capturing information and reporting it. Not super helpful to just say "Yeah, me too..." but better if you can attach screenshots, Issue Reports from Loop settings, and a thorough description of the problem you are seeing. Be a part of the solution by thoughtfully providing information to help debug.

img/watching.png

Become familiar with your data sources¶

Another useful thing if you'll be on dev branches undergoing a lot of active change...know how Loop works and where to look for additional information about what you are seeing. For example, if you see an IOB value that looks odd, you should know to look at the insulin deliveries stored in the Health app.

Generate an Issue Report and a Critical Event Log¶

Issue Report vs Loop Issue

The action in the Loop app where you select Issue Report generates a human-readable LoopReport file that you can share which has a lot of useful information.

The Loop Issue mentioned in Watch the Loop Repository and Issues List is a website at GitHub where known Issues with the Loop app are kept in permanent storage.

The names are similar, but the activity is quite different.

Know how to generate an Issue Report and Export a Critical Event Log when you see a problem so you can provide that if asked.

An Issue Report is a log file generated by the Loop app that has a lot of information the developers can parse to figure out what Loop was doing when you were having a problem. Some items go back 84 hours (pump and cgm messages), others are limited to a few hours (decision arrays) and some items are overall status (build version number and phone model / iOS).
A Critical Event Log contains a zip of 7 individual zips. Each zip is for one day and contains the complete set of data used for Loop decision making. The event log goes back 7 full days.

To issue these reports:

Loop Settings and then scroll almost to the bottom and select Issue Report and thenm share
Loop Settings and then scroll almost to the bottom and select Export a Critical Event Log and then share

Create a Debug Report¶

This 6-minute long, classic Katie DiSimone video shows how to capture debugging logs. If you are testing a new branch, this is a valuable skill to assist developers in identifying problems. In addition to showing you how to generate and save the debug text information, the video explains how to create a gist with the debug information using your GitHub account and file an official Issue on the Loop GitHub repository. This may be required in some cases. But start by chatting directly on Zulipchat with the developer. What you are experiencing may already be known. If the developers need you to open a new Issue, they will say so on Zulipchat.

`Repositories` and Code¶

If you're a developer looking for direct links to the code and documentation in GitHub:

For more information on how to contribute code to the Loop project, please review:

If you want to contribute code improvements, please join Loop Zulipchat and be sure to subscribe to all the channels. Meet the developers and testers who make this app, and learn about what is coming next.