Google Spent Three Years Warning Fitbit Users Before Deleting Accounts. Bite's Own Migration Just Said 'Contact Support.'

On September 11th, Google Health shipped version 5.08, “the smallest update since the May redesign” according to release notes across three separate outlets that track it. Buried in that small update was a big finish: a Google Account is now required to use the app at all, Fitbit account logins no longer work, and any account that never made the switch has had its data deleted. That sounds abrupt until you look at the runway. Google announced the Fitbit-to-Google-account requirement in September 2022. It gave existing users until early 2025, then pushed that to February 2nd, 2026, then pushed it again to May 19th, 2026. After that date, anyone who hadn’t migrated got a further window to download their own data before Google started processing deletions on July 15th. Three years, two public extensions, and a specific date announced each time. Whatever else is true about a company that size, it did not spring this on anyone.

I read that timeline the same week Bite finished its own account migration, and the contrast is not flattering. We moved our authentication off Clerk onto Supabase this month, and on September 18th we activated a custom domain for it, auth.bite.coach, so the sign-in sheet and our auth emails show our own name instead of a raw project ID on supabase.co. That’s a real migration, just at a scale of thousands of accounts instead of Fitbit’s tens of millions, and it carries the same basic obligation: tell people what’s changing, and don’t lose their account on the way through.

The engineering came close to failing that quietly. Supabase’s client library derives the local storage key it uses to keep you signed in from the first label of your project’s URL. Switch that URL to a custom domain without accounting for it, and every existing session stops matching its stored key, which is a fancy way of saying it would have signed out every user we had, with zero warning, the moment the new domain went live. The commit that made the switch caught this in the same breath and pinned the old key explicitly. No one got signed out. But I want to be honest about the shape of that near miss: Google spent three years telegraphing a deadline; we came within one line of code of silently logging out our entire user base with no announcement at all, and the only reason it didn’t happen is that whoever wrote the migration commit thought to check.

The sign-in flow had two smaller versions of the same problem sitting in it longer than anyone noticed. On Android, native Google Sign-In throws a DEVELOPER_ERROR when the app binary’s signing certificate isn’t registered against the right OAuth client, which is exactly the kind of failure a user experiences as “sign in with Google is just broken,” with no path forward except trying again. It now falls back to a browser-based flow instead of surfacing the error. On iOS, it turns out nobody had ever set the environment variable for our native Google client ID, not in .env, not in eas.json, not in the EAS build environment, which means every build we have ever shipped took the hosted browser route by default. Instead of a proper native Google consent screen, or at minimum a screen that said “Bite,” people signing in with Google on iOS have been looking at a prompt asking whether they want to let a raw Supabase project URL access their Google account. That’s not a data-loss bug. It’s a trust bug, and it shipped in every build until this week without anyone flagging it.

The one that actually matches Google’s failure mode landed today. Bite has three different Supabase error codes that all mean roughly the same thing: a returning user’s email doesn’t resolve cleanly under the new system, usually because their account predates the Supabase cutover. The copy for all three, inherited from our old Clerk-era error handling, told people their email “may need to be migrated from the old system” and to contact support. Here’s the part that actually bothers me: our backend already had a working self-serve fix for this. A function called ensure_profile_for_auth_user can find an existing unlinked profile whose email matches the new session and reattach it automatically, no manual intervention needed, which means the right move was always just to let the person sign up again. Nobody had pointed the error copy at that fix. So for however long that gap existed, since the cutover until this morning’s commit, anyone who hit it was told to file a support ticket for a problem the app could have quietly solved the moment they tried again. I don’t have a count of how many people actually hit that message and just left instead of emailing anyone. That’s the honest difference between our migration and Google’s: theirs came with three years of dated warnings, ours came with a “contact support” button standing in front of a fix we’d already built.

BITE of the Week

The account-recovery and sign-in fixes above landed this week alongside a real incident: on September 21st, a user logging food for the previous Sunday had that day’s entries wiped three times in four minutes. Bite only keeps the current and next week hydrated in memory, so reopening an older week after a reload caused each save to rebuild that day from nothing and overwrite what was actually stored. The fix has two parts, one in the client and one on the row: mergeWindowIntoFullPlan now keeps a day’s logged meals when a rebuild finds no shared entries with what’s cached, and a new database trigger enforces the same rule at write time so every installed build is covered, not just the next one people download. Alongside that, the glass-chrome navigation redesign got a second pass: the tab selection is now a capsule that trails behind your finger on a spring instead of snapping to the page, drawn as real iOS 26 glass over the tab bar, while Android keeps a plainer hairline-and-disc treatment; the dropdown menus and quick-add panel went flat and opaque instead of glass, after last week’s version left menu text sitting directly on whatever the dashboard behind it happened to show. All of this is packaged as 1.15.0, which recorded iOS build 118 for review on September 22nd; Android’s build is still pending submission. Nothing in 1.15.0 is in anyone’s hands yet. What’s actually live is still 1.14.0.

Three Quick Bites

1. A pooled analysis of 51 prospective cohort studies covering more than 8.8 million adults, published in the open-access journal Family Medicine and Community Health and covered by Medical Xpress on September 22nd, found that every additional 100 grams of daily ultra-processed food intake was associated with higher risk of cardiovascular disease, cancer, metabolic disorders, hypertension, digestive disease, and all-cause mortality. It’s a dose-response finding, not just a “some versus none” comparison, which is a harder result to wave off with a single counterexample food. Medical Xpress

2. A systematic review and meta-analysis of 87 clinical trials, published September 15th in the European Heart Journal and presented at the European Society of Cardiology, found the biggest cardiometabolic benefits of whole grains clustered at 60 to 100 grams a day, roughly four to six servings, with each additional 48 grams tied to further improvements in weight, waist circumference, cholesterol, and inflammatory markers. Lead author Helda Tutunchi of Tabriz University of Medical Sciences noted that population studies have linked whole grains to heart health for years while trial evidence stayed mixed; this is the first attempt to pin down an actual dose. ESC

3. Zocdoc announced its Care Access Network on September 22nd, opening its appointment-booking system so providers can be scheduled directly from inside Gemini, Amazon’s health AI, and search engines, not just Zocdoc’s own app. STAT News covered the underlying deal on the 17th. It’s a small preview of what “AI coach” is going to mean for a lot of health products going forward: not just a chat window, but a chat window with a functioning booking backend behind it, which is a much higher bar than giving good advice. HIT Consultant

Tool of the Week: Google Takeout

Since this issue is about a migration that gave people years of notice versus one that gave people a support ticket, this week’s pick is the free tool that would have actually saved anyone caught flat-footed by the Fitbit deadline. Google Takeout lets you export your data from any Google product, Fitbit included, as a downloadable archive you control, independent of whatever migration timeline the company running the service decides on. It’s not a fix for a company that doesn’t warn you. It’s the backstop for when they do warn you and you still don’t get around to it in time. Google Takeout

Thanks for reading. If you want a coach that tells you what’s happening to your account instead of a support ticket, Mr BITE is free on iOS and Android.

Collins, building Mr BITE