72H Fasting Contest

main screen

Inspiration

A 72-hour goal can feel abstract when viewed as one long countdown. I wanted to turn it into a clear sequence of milestones, add optional social accountability, and keep safety information visible throughout the experience.

What it does

72H Fasting Contest is a native iPhone app for tracking a 72-hour fasting challenge. It includes:

a live timer and progress view;
milestones at 12, 24, 36, 48, 60, and 72 hours;
local reminders and milestone notifications;
history, statistics, streaks, rankings, and achievement badges;
global and weekly leaderboards;
private contests with invite codes; and
anonymous sign-in without email, phone, or password.

The app asks users to accept a safety agreement and explicitly consent before leaderboard profile and fasting-session data are uploaded. It is a motivation and tracking tool, not a medical device.

How I built it

The app uses SwiftUI and a shared AppViewModel, with Codable models for profiles, fasting sessions, contests, badges, and preferences. A ContestBackend protocol separates the UI and domain workflow from Firebase and provides an offline/local fallback.

Connected features use Firebase Anonymous Authentication and Cloud Firestore. Realtime listeners power leaderboards, while local Codable snapshots keep cached data available. Firestore security rules validate ownership, permitted fields, contest membership changes, elapsed-time limits, and session state transitions. Server timestamps prevent a client from completing a 72-hour challenge early by changing its local clock.

How I used Codex and GPT-5.6

Codex powered by GPT-5.6 acted as my AI pair programmer during Build Week. It helped translate the product idea into SwiftUI screens, design the data models and central app-state workflow, implement Firebase authentication and Firestore persistence, build realtime leaderboards and private contests, and create the backend abstraction and offline behavior.

Codex also helped reason through timer state, milestones, server-validated completion, privacy consent, safety language, Firestore rules, simulator/build issues, accessibility, dark mode, and the final testing documentation. I chose the product direction, reviewed the generated changes, configured Firebase, tested the app, and iterated with Codex. The shipped app does not call OpenAI APIs at runtime and sends no data to OpenAI.

Challenges and decisions

The biggest technical challenge was making a social timer trustworthy without overcomplicating the client. The app uses Firebase server timestamps and restrictive Firestore state transitions so a completed result requires 72 hours of server-observed elapsed time. I also chose anonymous authentication to reduce onboarding friction while still enforcing per-user ownership.

Privacy and safety

Users see a clear fasting disclaimer and consent disclosure. The app does not use HealthKit, collect medical records, show ads, or track people across apps. Firebase receives only the fields needed for profiles, sessions, contests, leaderboards, and badges.

Testing

The public repository contains Firebase setup instructions, security rules, a manual acceptance checklist, and exact Xcode build steps. The final iOS Simulator build succeeded with the Firebase dependencies resolved.

Built With

cloud-firestore
codex
firebase-authentication
gpt-5.6
swift
swiftui
usernotifications
xcode