Six identical rejections and the wording you received suggest that Apple is objecting to the software-only BAC estimate itself, not to the absence of another disclaimer.
Guideline 1.4 does not need to list every prohibited measurement individually. Section 1.4.1 allows Apple to reject health measurements when the claimed accuracy or methodology cannot be validated. In your case, App Review has now stated explicitly that a blood-alcohol estimate without associated measurement hardware is not considered appropriate.
TestFlight approval is useful evidence that the build was accessible and functional, but I would not treat it as a substantive approval of the product for App Store distribution.
I would pause further unchanged submissions and choose between two materially different product paths.
Path 1: Keep BAC by using actual measurement hardware
If BAC is essential, integrate a supported breathalyser rather than estimating concentration solely from self-reported drinks. The review package should identify:
- the exact hardware model and manufacturer;
- how the app receives the measurement;
- calibration and accuracy information;
- supported operating conditions and known limitations;
- any applicable regulatory or laboratory documentation;
- whether the device is commercially available to every user who can access the BAC feature.
The app should distinguish clearly between a device measurement and any historical drink log. Do not infer that a user is safe to drive, and do not calculate a “safe driving time.”
Path 2: Convert Abvy into a drink journal
If you do not want a hardware dependency, remove every output that represents or implies a physiological measurement. That includes:
- BAC percentages or ranges;
- “alcohol in your system” graphs;
- predicted sobriety times;
- countdowns to being under a legal limit;
- impairment or driving-readiness labels;
- notifications implying that the user is now sober;
- BAC terminology in the name, subtitle, keywords, screenshots and website.
Tracking beverages, alcohol units or standard drinks is materially different from estimating blood concentration, but the interface should not gamify consumption or establish drinking targets.
A disclaimer attached to the same BAC calculation is unlikely to change the result because the potentially harmful output remains available.
For the pending appeal, I would ask one narrow question:
“We understand that App Review considers a software-only BAC estimate inappropriate under Guideline 1.4, regardless of disclaimers. Before preparing another build, could the App Review Board confirm whether compliance requires removing every estimated BAC, physiological alcohol-level and sobriety-time output, or whether Apple would consider such functionality when it is based on readings from documented external measurement hardware?”
If the appeal is unsuccessful, do not submit the same calculator with different wording. Prepare a change matrix showing each rejected output, where it was removed from the binary and metadata, and what non-physiological journaling function replaced it. Attach a continuous video of the exact submitted build and updated screenshots.
Existing BAC apps are not reliable precedent. They may have hardware integrations, different documentation, older review histories or functionality that Apple has not evaluated under the same circumstances.
The strongest next step is therefore a product decision, not a seventh explanation: either provide a real measurement source or stop presenting an estimated physiological BAC value.
