Repository navigation
Apple Health - (signed) NOOP App inactive #2514
Description
NOOP version
11.8.0
Platform
iOS
OS version
iOS 27.0
WHOOP strap / Oura ring model
WHOOP MG
Where the data is coming from
Live Bluetooth (WHOOP strap connected)
Test Centre profile
Connection & Sync
What happens
From
https://discord.com/channels/1523991899336216696/1524053474759806986/threads/1539009737948004462
What you expected instead
App / build:
NOOP 11.8.0
Installed via Feather using a digital signature(NEOSIGN, including Healthkit permission).
What works:
NOOP is successfully writing/syncing data to Apple Health, including:
- Heart rate
- Heart-rate variability (HRV)
- Sleep data
Issue:
Although the Health sync itself works, NOOP is displayed incorrectly in Apple Health:
- It appears without an app icon.
- It is listed under “Inactive Apps” in Apple Health.
- Not able to modify permissions. My watch and Phone was draining battery and I wanted to remove the write permission for the app. This not possible unless I delete and re-install the app
This makes it look as if NOOP is no longer active or not properly integrated, despite it continuing to sync data successfully.
Expected behavior:
NOOP should appear in Apple Health with its normal app icon and should be treated as an active app while it is actively reading from or writing to HealthKit.
Additional context:
The app was installed through Feather and digitally signed. I am not sure whether the signing/installation method causes this behavior, but it may be relevant.
Could this be a HealthKit entitlement, bundle identifier, app metadata, or signing-related issue?
(Copies and edited the text from the Discord because it is explained better than I could)
Steps to reproduce
Install the app with digital sign
Check the Health app
Strap log
Before you submit
- I attached my exported NOOP .zip (not a screenshot of the Live screen). If my bug is a clearly reproducible UI issue I described exactly how to see it instead.
- I attached or pasted a strap log above — or my bug is a clearly reproducible UI issue that doesn't need one (e.g. a typo, a button that does nothing) and I've described exactly how to see it.
- I checked the Troubleshooting guide — especially "history syncs but no data" (most often the strap isn't banking history to flash; charge it to 100% and reconnect).
- I checked the FAQ and — if I'm on a WHOOP 5.0 / MG — the 5.0/MG status page, or — if I'm on an Oura ring — the Oura ring support table, and this isn't an already-known limit (e.g. SpO₂, recovery/sleep on the 5/MG, or no Recovery / HRV on a ring-only day).
- I've left out anything personal (strap serial, account email, raw export).
Activity
ryanbr commentedon Sep 28, 2026
Thanks @anilet, and thanks for carrying the Discord write-up over. Your last question is the right one: this looks like signing, specifically the bundle identifier.
Apple Health keys every source on its bundle id, and resolves both the icon and the active/inactive state by matching an INSTALLED app with that id. No icon, listed under Inactive, and no permission toggles is what Health shows for a source record it cannot match to an installed app. Writes continuing to work fits the same picture: the app writes under whatever id it currently has, while the entry you are looking at is the one Health cannot resolve.
The
.ipaships unsigned ascom.noopapp.noop. Re-signers frequently rewrite that, either to allow side-by-side installs or to match the signing profile, and nothing in the app can control what a re-signer puts in Info.plist. So there is no code fix on our side for this one.What would confirm it: the bundle identifier the installed app actually reports. Feather shows it, or Settings, General, iPhone Storage, NOOP. If it is not exactly
com.noopapp.noop, that is the answer.On not being able to remove write permission: I checked, and there is genuinely no in-app switch for Health writeback. It gates only on the HealthKit authorization itself, so when Health will not show you the toggles, delete and reinstall is the only route, as you found. That is a real gap rather than something you missed, and it is worth its own change.
Filed #2553 for the diagnostic half: the iOS strap log does not print the bundle identifier today, which is why this took a round trip to narrow down instead of being visible in your export.
diag(ios): put app identity in the export, and name a broken backgrou…
iMonZ commentedon Sep 29, 2026
Running NOOP Staging — base 11.8.0 · 2026-09-29 · 62eab51 Pre-release
So Noop has the correct icon in Apple Health and can also read everything properly from Apple Health into the Noop App.
The only problem is that it's not writing anything into Apple Health.
So the Apple Health record stays empty.
fix(ios): align HR export sources and refresh write authorization
anilet commentedon Oct 7, 2026
I haven't updated to 12.0.0 yet, I am with Noop Forge now.
In Feather I can see that the bundle identifier is infact correct
but in Health it is showing as Inactive and as "Noop Staging"(Both Noop and Noop Forge)
ryanbr commentedon Oct 7, 2026
@anilet Thanks for going and checking, and for the screenshots. You were right to come back: my earlier answer was wrong, and your question has a direct answer in this repo.
Correcting what I said on 28 September. I blamed the re-signer for rewriting the bundle identifier. That was a guess, and it does not hold: the iOS target is built with the production identifier on purpose.
project.yml:344setsPRODUCT_BUNDLE_IDENTIFIER: $(BUNDLE_ID_PREFIX).noop, andConfig/BundleId.xcconfig:13setsBUNDLE_ID_PREFIX = com.noopapp. Socom.noopapp.noopis exactly what it should be, and Feather is showing you the right thing. Nothing was rewritten.Where "Noop Staging" comes from: us. One line below that identifier,
project.yml:345reads:It sits in the target's
basesettings with no per-configuration override, so it applies to every iOS build including the signed release. The built bundle isNOOP Staging.appwith an executable namedNOOP Staging.How it got that way:
719477a8d("staging: fork CI + NOOP Staging identity", 30 June) set the iOS target's bundle identifier and its product name to staging together. A later commit,83b0dc8bf, restored the production identifier when the prefix became configurable, and left the product name behind. So the iOS app currently ships a production bundle identifier with a staging product name, which is precisely the pair you are seeing: the identifier checks out, the label says Staging. The macOS target still carries both halves (project.yml:140-141), so it stays consistent with itself. iOS is the one that drifted.What I am not going to assert this time. Whether that product name is literally what Health is printing, I do not know yet. The shipped
Info.plistsets bothCFBundleNameandCFBundleDisplayNametoNOOP, so on paper Health ought to say NOOP. Two explanations fit what you see: Health falls back to the product or executable name when it cannot resolve the installed app, or a HealthKit source name is recorded once at first write and then kept regardless. Those are different problems with different repairs, so I would rather name the gap than guess at it twice.The test that separates them: a fresh install on a device that has never had NOOP on it. If the brand new Health source also reads "Noop Staging", the name is being read live and
project.yml:345is the whole story. If it reads "NOOP", then your entry is a stored source name from an earlier write and the repair is different. No rush, and only if you have a spare device.Either way the configuration mismatch is wrong and gets corrected on our side, so thank you for pushing back on it.
On your battery and permissions point, that part of my earlier reply stands: there is no in-app switch for Health write-back, it gates only on the HealthKit authorization, and delete-and-reinstall really was your only route. That remains a genuine gap.
@iMonZ, your report is a different bug. Correct icon, reads working, writes doing nothing is the symptom in #2644: the heart-rate write read a single device id, and newly-added write types were never re-requested, so the writer saw no share authorization and returned quietly. @kavemang's #2645 addressed both halves and it went out in 12.0.0, so a 12.0.0 build should start writing for you. If it still does not, please say so here and I will treat it as its own thread rather than folding it into this one.
If you do move to 12.0.0, @anilet, the export now carries the identity directly. The iOS export header prints
App: <version> (<build>) <bundle id>, which landed after 11.8.0. That is one line in an export instead of the round trip this took.ryanbr commentedon Oct 7, 2026
Two corrections to my comment above, both mine.
Wrong commit. I said
83b0dc8bfrestored the production bundle identifier. It did not: that one only made the prefix configurable via an xcconfig. The identifier was restored by749c94118, which shipped the production id for the AltStore source manifest (#26). I had searched for the templated setting string and mistook the commit that introduced the templating for the one that changed the value.I got ahead of myself again. I wrote that the staging product name "gets corrected on our side" before checking whether it was deliberate fork branding. It should not have been stated until I had looked, given I had just finished retracting one guess on this thread.
Having looked: it is a leftover, and
749c94118settles it in its own words. It dropped the.stagingsuffix from the iOS-family bundle ids because iOS has no App Store app to install beside, NoopApp being closed, so the overlay served no purpose there and only broke sideloading. It enumerated the identifiers it changed and never reachedPRODUCT_NAME, which has read "NOOP Staging" since the original staging-identity commit. The same reasoning applies to the name. #2719 renames it, and macOS keeps both halves deliberately.Something more useful came out of this, @anilet, and it is relevant to you since you sideload. Checking the above turned up that both fork workflows have been announcing, in every set of release notes, that the build "installs beside the official app (separate data)" for all three platforms at once. For iOS that has been false since
749c94118: the ipa carries the production bundle identifier, so it replaces an installed official app and uses its data rather than keeping its own. Android and macOS do install beside; only the iOS claim was wrong, and it was wrong in the direction that could cost somebody data they expected to be left alone. #2719 makes that claim per platform.Still unestablished, and still the open question here: whether Apple Health is printing that product name live, or showing a source name it recorded once and kept. The plist already carried
NOOPfor both display keys, so the rename is not offered as a repair for what you are seeing. A fresh install on a device that has never had NOOP is what separates the two.fix(ios): name the app NOOP, and say per-platform whether a build ins…
anilet commentedon Oct 7, 2026
Thanks @ryanbr for the explanation.
I had to reset the phone and the watch to get rid of the battery draining issue. Would that count as a fresh install?.
If so it did not fix the naming.
I have learned "the forks using the same data" and over writing it the hard way. It deleted the Noop folder and created a Noop Forge folder when I installed the fork. Luckily I had it backed up just in case.
fix(ios): name the app NOOP, and say per-platform whether a build ins…
anilet commentedon Oct 9, 2026
Seems like the Health is infact getting the name from the Product Name.
I was installing v12.0.0 and I am getting this