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.
Tidepool Loop is an independent version of Loop. Tidepool Loop started with Loop code, added safety features, and additional FDA approved device integrations. Much of the Tidepool Loop improvements are also published as open source, which volunteers in the community are free to incorporate back into Loop. The device integrations for Tidepool Loop are generally closed source when required by device manufacturers.
next-dev branch - it is awesome, but still being testedThe next version of the Loop app is developed using branches.
dev branch is used by the developers to push out changes for users to test before that code is releaseddev are made via PRs to LoopWorkspace and are announced in zulipchatdev branch if you are willing to be a tester, build frequently and pay close attention to each updatenext-devmain or dev from next-dev but it is not guaranteeddev branchPlease read this entire page before using any version of Loop other than the released code.
dev¶This section provides a permanent link for the overview of changes to dev compared to the current release: Loop v3.14.11.
The dev branch is subject to frequent updates. Follow along in zulipchat for information about those updates.
dev Branch is not necessarily updated with every commit to dev, it provides a table of updates to dev between releases with additional information as neededThose on the Dana pump must keep building the feature branch, feat/all-managers, which is kept up-to-date with the dev branch.
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 branches. These branches are subject to more frequent updates, so users testing these branches should follow along in zulipchat for information.
dev branch at v3.14.10, we stopped using the update_dev_to_M.m.# interim branchesdev branch for a while nowdev and the version will be bumped one more time before releasing dev to mainfeat/ have one or more special features, like support for new pumps or CGM; they are kept up to date with changes in the dev branchnext-dev branch for early adopters of what will eventually be Loop version 4, but is currently tagged as v3.15.xThe graphic below shows the main and dev branches along with some feature branches. This is a snapshot in time. Always check Table of Active Branches.
dev branchThe table below lists active branches.
maindevnext-dev to be merged here soondev Branchnext-devnext-dev Branchfeat/all-managersDanaKit @ eadb9fe supportfeat/tandem-closed-betaSHA-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.
For full instructions on building different branches, review these pages:
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.
For Mac Xcode build, you can use the regular build script and choose main, dev or next-dev as a branch. For other branches, please see Build other branches.
Please see Loop Version Numbering for the current method for version numbering for the main and dev branches.
dev Branch¶This section provides an overview of changes since the last release, if any, but may lag the current state of the dev branch.
WARNING
next-dev branch will be merged into the dev branchnext-dev yet, be sure to switch to the main branchnext-dev Branch¶The document linked below provides an overview of updates brought from Tidepool Loop to "DIY Loop", as found in next-dev.
The document linked above does not include more recent updates which you find discussed in zulipchat and highlighted below. But the document does provides a solid basis for understanding the new features.
Backward Compatibility is Limited
Once you build next-dev on your personal phone, you may run into issues trying to return to released code at this time.
next-dev, your database will probably be maintained (but this is a compatibility feature that has not been tested)next-dev are different and might not be clearedmain or dev after testing next-dev on your personal phone, that you be prepared to delete the app and rebuild, which means you lose connection to your existing Omnipod Pod or Medtrum PatchThis is the open PR for next-dev: PR 454
Please follow along in zulipchat: Loop next-dev Status
The next-dev branch will eventually be released as Loop version 4. The preset (override) behavior is quite different than in Loop versions 2 and 3.
Preset Behavior is Different
The preset (override) behavior of the released version of Loop remembers the insulin needs factor at the time a dose is delivered throughout the duration of insulin activity.
The new code no longer does that. As soon as the preset is cancelled, the ISF and CR return to their scheduled values. The old, often repeated, do not use extreme overrides because they mess up predictions, is no longer true. You may need to adjust your preset values when you switch to the next-dev branch.
In particular - tricks like changing the insulin needs factor of a currently running override, no longer work and should be forgotten.
The Open-Beta is completed for Omnipod 5. Support is found in the released version of the Loop app. Please switch your build to the Loop main branch. There is no need for a development branch to get Omnipod 5 support.
Earlier development code required a CGM with a heartbeat
Support for Omnipod 5 is available in the released version.
If you have any trouble with Omnipod 5, or any of the Omnipod Types, report them at your favorite help site, How to Find Help.
Omnipod Users: Update to v3.14.11
There were important fixes to Bluetooth connection timing in v3.14.11.
Update to v3.14.11 for iPhone 16/17e with Atlas DASH Pods
If your phone model is a 16 or 17e and you use Atlas DASH Pods:
The Pod Keep Alive code was completely revamped and cleaned up in v3.14.7 through v3.14.11. See OmnipodKit Information for more details.
Medtrum support was added to the released code, main, v3.14.2 or later.
Eversense support was added to the released code, main, v3.14.2 or later.
For Dana support, you must build a new feature branch, feat/all-managers.
Build v3.14.11
There were some important fixes for connectivity in the latest feat/all-managers.
New Managers
The feat/all-managers branch is used to add new Pump Managers and CGM Managers which may have known or unknown bugs. Once the managers are deemed reliable, they are added to the dev branch and subsequently released.
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.
feat/all-managers branchgit pull --recurse in your LoopWorkspace folder to include updates to all submodulesBluetooth 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.
These issues were fixed in MedtrumKit and the lessons learned will be applied to DanaKit.
There are known issues for DanaKit, which is why that pump manager is not yet in the dev branch
Please read the rest of this section to learn about how this might affect an older or current version of your OS-AID app.
DanaKit Bluetooth Comms Loss Not Fixed
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.
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.
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.
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.
The feat/all-managers branch replaces several retired feature branches. If you need a feature branch for a Dana pump - you need to build this branch. Be sure to review the Status For Dana Support section.
If you previously used a feature branch for Medtrum or Eversense support, you can switch to the main branch, with updates coming in to the dev branch.
When you build the main or dev (v3.14.2 or newer) branch or next-dev (v3.15.0 or newer) branch over an older build, your Pod is automatically transitioned to use a new Pump Manager: OmnipodKit. You will notice the user interface is a little different from the older managers (OmniKit and OmniBLE).
Update to v3.14.11 or later
The Pod Keep Alive feature was rewritten with various improvements and bug fixes implemented over the last few versions. Please update to v3.14.11 as soon as possible.
Even if you do not use an iPhone 16/17e model with Atlas DASH Pods, it is still worth updating.
For those who do use an iPhone 16/17e model with Atlas DASH Pods, you will get better performance with v3.14.11 and should leave the Pod Keep Alive setting at the default value of "When Open".
One of the biggest things is that you can Switch Pod Type between Pods without deleting the pump manager. That means all your configuration choices for desired notifications and type of Insulin are maintained when you change Pod Type. With the main (v3.14.2) branch, only Eros and DASH are supported. With the dev (3.14.3 or newer) or next-dev ( 3.15.0 and newer) branches, Eros, DASH and Omnipod 5 are all supported.
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 Type 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.
These updates were made in-place to the dev branch so there is not a single PR to be referenced.
| Date | # of commits | Summary |
|---|---|---|
| 11 Oct 2026 | 2 | Increment version number to v3.14.10 |
| 12 Oct 2026 | 1 | Update support files for automated testing with CircleCI |
| 12 Oct 2026 | 1 | Update OmnipodKit to bring in 3 fixes: 1. Deactivate Fix: Shorten time from 4 to less than 1 minute before offering to Discard Pod in case of signal loss and update messages 2. Trio Eros Fix: Enable clean deletion of pump manager with Eros Pods 3. Alert Fix: automatic retry to clear Pod Beeping alerts if initial acknowledgement to pod was missed |
| 14 Oct 2026 | 1 | Update OmnipodKit: reduce the likelihood of 203 Faults for the combination of iPhone 16/17e Plus Atlas see Update to eager-connect for iPhone 16/17e Plus Atlas |
| 15 Oct 2026 | 1 | update LoopKit: share the Core Data model used by next-dev - maintains next-dev information if user transitions to and from dev branch |
| 17 Oct 2026 | 1 | Update LoopSupport: send analytics to ingest.loopkit.org maintain our own storage prior to using Amplitude for analysis |
| 21 Oct 2026 | 7 | Update EversenseKit, Loop, LoopKit, LoopOnboarding, LoopSupport, OmnipodKit minimum deployment is iOS 17.6 implement Report a Problem method update Pod Keep Alive language for OmnipodKit fix certification issue for Eversense |
| 22 Oct 2026 | 4 | Enable user to view the Diagnostic Report before sharing it update translations Bump version to 3.14.11 in preparation for release modify translation flags |
At this point, all commits were made to the release/v3.14.11 branch. This was merged into main for the release.
| Date | # of commits | Summary |
|---|---|---|
| 22 Oct 2026 | 2 | Bump version to 3.14.11 in preparation for release modify translation flags |
| 23 Oct 2026 | 1 | Update README |
| 24 Oct 2026 | 1 | Restore the Loop Report name as the subject when sharing the Diagnostic Report via email |
Refer to LoopWorkspace dev branch commit history for all commits.
eager-connect for iPhone 16/17e Plus Atlas¶This fix should reduce the likelihood of 203 Faults for the combination of iPhone 16/17e Plus Atlas DASH Pods.
Modify the eager-connect method for Bluetooth communication with Pods:
The Bluetooth connection method for Pods has undergone several revisions driven by both the increased incidence of 203 Faults for Atlas DASH Pods and the very slow connection for iPhone 16/17e with Atlas Pods.
Loop Release v3.14.7 used the first modification from keep-connected to ble-heartbeat and was associated with a reduction in 203 Faults but did not provide relief for slow Bluetooth connection for users of iPhone 16/17e with Atlas Pods.
Loop Release v3.14.8 and v3.14.9 used the second modification of eager-connect which did provide relief for slow Bluetooth connection for users of iPhone 16/17e with Atlas Pods, however, these implementations essentially kept the 16/17e plus Atlas combination always connected to Bluetooth, which we believe makes 203 faults more common.
This update should provide the improvements for all iPhones and all Pod Types.
This fix to OmnipodKit came into the pump manager with OmnipodKit PR 190 (to dev). It was also backported to next-dev.
Note - the numbering is "limited" to 3.14.x for Loop 3 because next-dev, which will be Loop 4, is using 3.15.x.
The updates developed in the dev branch before the release of v3.14.2:
The updates developed in the dev branch before the release of v3.14.0:
The updates developed in the dev branch before the release of v3.10.0:
The updates developed in the dev branch before the release of v3.10.0:
The updates developed in the dev branch before the release of v3.8.0, are provided in reverse chronological order.
The changes are to maintenance scripts and to translations with no change to the function of the code:
dev v3.7.x was same as main v3.6.x.All updates are reported in Loop 3.6.0
Check Version History for minor updates found in 3.6.x.
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.
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:
master - but is now maincarthage 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.
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.
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
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.)
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.
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.
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.
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.
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).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 shareLoop Settings and then scroll almost to the bottom and select Export a Critical Event Log and then shareThis 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.