Ios

The foundation is solid. The daemon runs, the API accepts data, the iOS app logs meals and shows predictions. But "it works" is not the same as "it works well." The next phase is six focused improvements that take islet from a system that functions to one that feels right. The shape of the work Six plans, ordered by dependency. Some are small fixes to obvious gaps. Some are structural changes that touch the database schema, the API, and the iOS app in a single pass. All of them come from the same source: using the system every day and noticing where it falls short. ...

The screen cracked in a way that made the laptop useless as a laptop but perfectly functional as a computer. The M2 chip, 16GB of RAM, and 512GB of storage still worked. Throwing it away or paying for a screen replacement both seemed wrong. So it became a server. The hardware MacBook Pro M2, 2022. The display is physically intact but the LCD panel has internal damage — a spreading dark region that covers about 60% of the screen. Enough to make it unusable for direct interaction. Not enough to trigger a warranty claim (it was out of warranty anyway). ...

Two changes that have nothing in common except timing. On Friday, islet gained per-user SQLite databases for multi-user data isolation. On Saturday, the iOS food logger gained local food templates for instant meal estimation without an API call. One is about infrastructure. The other is about speed. Both matter more than they look. Safety note: islet is a personal project and is not medical advice. It does not make dosing decisions. The single-user assumption Until Friday, islet had one SQLite database. One file. One user. Every glucose reading, every meal, every treatment went into the same tables. That was fine when the only user was the person who built it. ...

On Wednesday evening, the islet web UI got a navigation overhaul: hash routing, a floating action button, a Canvas 2D glucose chart, and dedicated pages for food and treatment input. Eighteen hours later, the iOS app got the same overhaul: TabView, a floating action button, a SwiftUI Charts glucose chart, and sheet modals for input. Same design. Same information architecture. Not a single line of shared code. Safety note: islet is a personal project and is not medical advice. It does not make dosing decisions. ...

The islet iOS app shipped a day ago with four screens. It already felt like too many. The food logger had five stacked tag pickers, a chat interface hidden behind a button, and a meal history on a separate screen. Every meal entry meant navigating in, filling out a form that looked like a medical questionnaire, then navigating back. The data was right. The experience was wrong. Safety note: islet is a personal project and is not medical advice. It does not make dosing decisions. All carb estimates are informational only. ...

For nine days, islet has lived in a terminal. The daemon runs on a Raspberry Pi, the analytics engine crunches numbers in the background, the API accepts uploads — all invisible unless you know the right curl command. Logging a meal meant SSH and a CLI. That works at a desk. It does not work holding a fork. Safety note: islet is a personal project and is not medical advice. It does not make dosing decisions. PCU values are informational only and must not be used as dosing advice. ...