The feature list nobody reads twice
The most common fitness app brief I see is a list of about thirty features, and the one feature that decides whether anyone keeps using the app is usually item nineteen, written as "workout log."
That's backwards. The log is the app. Every chart, every plan, every streak, every coach message is built on top of what a person typed or synced after a set of squats. If the log takes forty seconds and three screens, nothing above it matters, because the data never arrives.
So this is my ranked list of the ten fitness app features that matter in 2026, and the order is the argument. I'll also cover the platform rules that changed underneath these features (Google Fit is running out of road at the end of 2026), the privacy law that now reaches fitness data outside HIPAA, and the numbers I refused to print. All of it was checked on September 30, 2026.
If you're still choosing who builds the thing, I compared firms separately in my guide to fitness app developers. This piece is about what they should build.
More features is the wrong model
The belief most founders bring is that a fitness app wins on feature count: the competitor has meal plans, video classes, a community feed and an AI coach, so we need all of that plus one more.
It doesn't hold, bc fitness features aren't independent. They stack. A personalized plan is only as good as the progress data feeding it. Progress data is only as good as the log and the sync. A streak that breaks because the watch didn't sync last night teaches the user the app can't be trusted, and that lesson sticks harder than any badge.
Think of it like a kitchen. You can buy a sous vide machine, a pasta roller and a smoker, but if the fridge doesn't keep food cold, you're not cooking anything. The fridge is boring. It's also the only appliance every meal depends on.
Therefore: build the fridge first, and build it properly. The features further down this list are real and worth building, but only once the ones above them work every time.
How I ranked them
The order is based on dependency, not popularity: a feature ranks higher when more of the other nine rely on it working. I didn't rank by survey demand, because I couldn't find a fitness feature survey with a published sample and method that I'd stake a ranking on.
Two tie-breakers. First, cost of getting it wrong: a feature that can breach a store rule or a privacy law ranks above one that can only disappoint. Second, how hard it is to retrofit. Offline support and consent models are painful to add after launch, so they get more weight than their visibility suggests.
To be clear, this is judgment, not measurement. It's the judgment of someone who has shipped a fitness product end to end, and I'll show you that product later, but it's still an opinion with reasons attached.
The ten features
Here are the ten fitness app features, in the order I'd build them. Each one has what it is, why it sits where it does, and the trap I see most often.
Fast Workout Logging
the log is the product
Fast workout logging comes first because every other feature reads from it. The test I use is simple: can someone log a set with sweaty hands, between sets, in under about five seconds, without reading anything?
That means prefilled values from last session, big tap targets, a numeric keypad rather than a text field, and no confirmation dialogs. It means the rest timer starts itself. It means an exercise library that searches by what people actually call a movement, not only its textbook name.
The trap is designing the log for the demo instead of the gym floor. A beautiful exercise picker with animated illustrations is lovely the first time and a tax every time after. Put the illustrations one tap away and keep the path to "logged" short.
Health Data Sync
HealthKit and Health Connect, done right
Health data sync ranks second because people already have years of steps, heart rate and sleep in their phone, and an app that ignores it starts every user from zero. On iPhone that store is HealthKit. On Android it's Health Connect.
Apple describes HealthKit as a central repository for health and fitness data across iPhone, Apple Watch, iPad and visionOS, with users granting access one data type at a time. Google's Health Connect guide describes the same shape on Android: data stored on the device, granular per-type permissions, and standardized types from heart rate and steps to sleep sessions, exercise routes, training plans and even FHIR medical records. Google says Health Connect is integrated into the Android framework starting with Android 14, and the library supports devices back to SDK 28.
The deadline you need to know: Google's Fit migration guide says the Google Fit APIs will be supported until the end of 2026, and its migration FAQsays developers have been unable to sign up for them since May 1, 2024. If your Android app still reads from Fit, that's three months of runway as I write this. Google points mobile apps to Health Connect and web or cloud platforms to its Google Health API.
The trap is asking for every permission at once on first launch. Ask for what the current screen needs, explain why in one sentence, and handle "no" gracefully. On Android, Google Play also wants each Health Connect permission declared with a justification in the Play Console, so a bulk request is a review problem as well as a trust problem.
Wearable Workouts
a watch app that records, not just displays
Wearable workout support ranks third because the watch is where serious users actually train, and a phone in a pocket is a poor heart rate sensor. The feature is a real companion workout app, not a notification mirror.
On Apple Watch, the HealthKit workout APIs (HKWorkoutSession and its live workout builder) run a session and collect heart rate and energy as it happens. On Wear OS, Google's Health Servicesoffers ExerciseClient for active workouts, PassiveMonitoringClient for background data and MeasureClient for spot readings, on Wear OS 3 and higher. Google's pitch for it is battery: one service configures the sensors instead of every app fighting over them.
Garmin is two different doors. Connect IQ lets you build watch faces, data fields, widgets and full device apps in Monkey C (Garmin lists version 9.2.0, updated August 25, 2026). The Garmin Health APIis a server-side feed of steps, heart rate, sleep, stress and more, but it's a business program: Garmin approves applicants, aims it at corporate wellness, population health and patient monitoring, and says commercial use requires a license fee.
Rings and straps have their own terms. Oura's API help page says Gen3 and later users without an active membership can't access their data through the API, including through partner apps, so your integration silently goes dark for anyone who lapses. The WHOOP developer platform offers OAuth 2.0, sleep, recovery and strain data and webhooks, and notes that its v1 webhooks have been removed.
The trap is promising "works with every wearable" in the pitch deck. Pick the one or two devices your users actually wear, and read everything else through HealthKit or Health Connect, where many devices already write their data.
Honest Progress Tracking
charts that tell the truth
Progress tracking ranks fourth because it's the reason people log at all: they want to see that the work is doing something. The feature is trend lines, personal records, body measurements and a clear view of the last four to twelve weeks.
Honest matters more than pretty. Daily bodyweight bounces with water and salt, so show a smoothed trend beside the raw points. Mark gaps as gaps rather than drawing a confident line across a week of missing data. When sources disagree (the watch says one calorie number, the phone says another), say which one you used.
The trap is the celebration that isn't earned. An app that congratulates a user on a "record" created by a sync glitch loses credibility it doesn't get back.
Personalized Plans
adaptive, with guardrails in the engine
Personalized plans rank fifth because they're what people pay for, but they depend entirely on the four features above. A plan that adapts to logged performance and synced recovery data is useful. A plan that adapts to nothing is a PDF.
The part most briefs skip is the guardrail. Any feature that sets calories, weight targets or training load can hurt someone if it follows a user's ambition without limits. Put the limits in the calculation engine, where they can be unit tested, not in a warning label on the screen.
Do you need an AI coach for this? Not necessarily. Deterministic rules are easier to test, easier to explain to a user who asks "why this number?", and easier to defend if something goes wrong. I'll show you a product where we made that call on purpose.
Coach Connection
messaging and sharing on the user's terms
Coach connection ranks sixth because for trainers, gyms and teams it's the whole business model, and for everyone else it's optional. The feature is a coach seeing a client's progress, assigning work and messaging them.
The design question is consent. What a person eats or how they slept is more private than whether they did the workout. The model I recommend is separate switches for separate kinds of data, held by the user, revocable at any time, and enforced on the server so a stale app build can't skip the check.
The trap is giving the coach a login to the athlete's app. It's the quickest thing to build and the hardest to take back.
Nutrition Tracking
fewer taps, clear sources
Nutrition tracking ranks seventh because it's the feature people abandon fastest when it's slow, and it only matters once training is being logged. The feature is a food log with a searchable database, barcode scanning, saved meals and macro totals.
The quality of the food data decides everything. A small, clean database with verified macros beats an enormous crowdsourced one where the same banana has eleven entries. Let people save a meal once and log it again in one tap, because most people eat the same ten things.
The trap is treating diet data as ordinary data. Under the privacy rules below, diet is explicitly in the list of things that make an app a health service.
Offline Mode
logging that works in the basement
Offline mode ranks eighth on visibility and much higher on regret, because it's very hard to add after launch. Gyms are in basements, trails are out of range, and a log that spins and fails there gets abandoned.
The pattern is local-first for anything personal: write to on-device storage, show it immediately, sync when a connection returns. The exception is anything shared by nature, such as a coach's view of a team, which should stay server-owned so cached data can never pretend to be live.
The trap is sync conflicts. Decide early what happens when the phone and the watch both edited the same workout, and write that rule down.
Subscriptions and Paywall
built to the store rules
The subscription paywall ranks ninth because it only earns once the app is worth paying for, but it ranks at all because getting it wrong can block your release. Apple's guideline 3.1.2(a)says an auto-renewable subscription must provide ongoing value, last at least seven days and be available across all of the user's devices.
Apple's subscription guidanceadds the screen rules: show the subscription name, duration and full renewal price, make the billed amount the most prominent price, state a free trial's length and the price after it, and give people an easy way to manage or cancel. One introductory offer is allowed per subscription group, with offer codes, promotional and win-back offers for other moments.
The trap is the paywall before the first workout. Let someone log a session and see a result before you ask for money. And remember guideline 5.1.1(v): if the app lets people create an account, it must let them delete it from inside the app.
Streaks and Social
motivation without manipulation
Streaks and social features rank last because they amplify whatever is underneath them. On a solid log they help. On a flaky sync they punish people for your bugs.
Build streaks that forgive: a rest day that counts, a weekly target instead of a daily one, a freeze that users earn. Keep social opt-in and private by default, because a public feed of body weight is a very different product from a private training log.
The trap is the dark pattern. A streak that nags someone into sharing data isn't consent in any sense a regulator or a user would recognize, and under the FTC rule covered below, an unauthorized disclosure of health data can itself count as a breach.
What about video and on-demand classes? They're a real product line, and for a studio brand they may be the product. I left them off the ranking because they depend on content production more than on app features, and a class library with no logging underneath it can't show anyone their progress.
The platform rules that shape them
The platform rules decide how half of these features can be built, so here they are in one place. Apple's App Review Guidelines are the strictest on fitness data specifically.
Here is guideline 5.1.3, in plain terms.
- Data from HealthKit, Motion and Fitness and similar sources may not be used or disclosed to third parties for advertising, marketing or use-based data mining, except to improve health management or for health research, and then only with permission.
- You must disclose the specific health data you collect from the device.
- You must not write false or inaccurate data into HealthKit.
- You may not store personal health information in iCloud.
- Guideline 2.5.1 adds that HealthKit should be used for health and fitness purposes and integrate with the Health app.
The iCloud line surprises people more than any other. If your architecture plan says "sync via CloudKit," stop and redesign that path before it reaches review.
Google's equivalent lives in the Play policy for Health Connect. It lists permitted uses (fitness, wellness and coaching, rewards for healthy habits, corporate wellness, medical care, research and health-integrated games) and prohibits transferring or selling health data to advertising platforms or data brokers and using it for personalized ads or credit and insurance decisions.
| Platform | What it gives you | The rule that bites | Status checked Sept 30, 2026 |
|---|---|---|---|
| Apple HealthKit | Central on-device health store, per-type permissions, iPhone, Apple Watch, iPad, visionOS | Guideline 5.1.3: no ads or data mining, no false data, no personal health info in iCloud | Current |
| Android Health Connect | On-device store, per-type permissions, steps, heart rate, sleep, routes, training plans | Play Console declaration per permission; no transfer to ad platforms or data brokers | In the framework from Android 14; library supports SDK 28 and up |
| Google Fit APIs | Legacy recording, history, sensor, session, goals and BLE APIs | No new signups since May 1, 2024 | Supported until the end of 2026 |
| Wear OS Health Services | ExerciseClient, PassiveMonitoringClient, MeasureClient | Wear OS 3 and higher only | Current |
| Garmin Connect IQ | Watch faces, data fields, device apps, widgets in Monkey C | Garmin app store review | Connect IQ 9.2.0, updated Aug 25, 2026 |
| Garmin Health API | Server-side feed of steps, heart rate, sleep, stress and more | Business program, Garmin approval, license fee for commercial use | Current |
| Oura API | OAuth access to ring data | Gen3 and later users need an active membership for API access | Current |
| WHOOP API | OAuth 2.0, sleep, recovery, strain, webhooks | v1 webhooks removed; build on v2 | Current |
The practical consequence: HealthKit and Health Connect are two separate integrations with two separate review processes, even if the rest of your app is one shared codebase. That's true whether you build natively, which is what our iOS app development and Android app development teams do, or on a shared layer such as React Native, where the health bridges still need native modules on each side.
The watch side has more to it than fits here. If a companion watch app is central to your product, I went deeper on the device side in the wearable app development guide.
Privacy law for fitness apps
A fitness app outside HIPAA is not outside health privacy law. Two rules matter most for a US launch, and both were settled before 2026 began.
The first is the FTC's Health Breach Notification Rule. The FTC finalized amendments on April 26, 2024, by a 3 to 2 vote, clarifying that it applies to health apps and similar technologies not covered by HIPAA. The amendments took effect July 29, 2024, and Venable's summary notes the covered list of online services includes those tracking fitness, sleep and diet.
Two parts of that rule change how you build. A breach includes an unauthorized disclosure, not only a hack, so sharing data without the person's authorization can count. And notice is due without unreasonable delay and no later than 60 calendar days after discovery, with the FTC notified at the same time when 500 or more people are affected.
Read that first part again, because it's the one that catches fitness apps. An analytics or advertising SDK that receives workout or diet events can be the disclosure. Audit every SDK in the app for what it receives.
The second is Washington's My Health My Data Act. According to the Washington Attorney General, its main obligations applied from March 31, 2024 for most businesses and June 30, 2024 for small businesses. It covers consumer health data including information inferred from non-health data, selling that data requires valid authorization, and violations can be enforced by the Attorney General and through private lawsuits under the state Consumer Protection Act.
I'm not a lawyer, and this isn't legal advice. Other states have their own consumer health and privacy statutes, and I haven't verified each one here. What I'd take from the two above is the design rule: collect the health data a feature needs, disclose it, keep it off advertising pipes, and make deletion real.
What we built and refused to build
Our clearest fitness example is our own product, Fighter Cut, a weight-cut, physique and nutrition app for combat athletes that Frenchy Digital built and owns. It maps onto this list closely, including the parts where we said no.
Feature 8, offline mode, was a founding decision. The athlete app is local-first on IndexedDB, works fully offline with no account, and only reaches the backend for accounts, clubs and billing. A fighter can log food, water, sessions and tape measurements with no signal in a gym basement.
Feature 5, plans with guardrails, is where we refused the most. The planning engine caps a diet week at a 750 kcal daily deficit, grades weekly loss as safe, caution or unsafe, and prints the shortfall when a target can't be reached safely instead of inventing a number. There's no AI coach, and the app makes zero AI API calls, bc a fighter's body isn't a place for a model to improvise.
Feature 6, coach connection, became a separate app. The Corneris the coach and gym side, on the same backend but deliberately server-owned. A fighter holds two separate switches: one shares weigh-ins, sessions and completed assignments, and a second shares a fortnight of nutrition (daily totals, meals and the recipes behind them). Meal photos and a fighter's own notes never reach a coach under any switch, turning either switch off deletes what it shared, and row-level security in the database enforces all of it.
To be clear about status: both apps were on TestFlight with public release gated to October 2026 when their case studies were written, and we don't publish downloads or users for a product that hasn't launched. So this proves the architecture, not the market. That's the honest boundary.
If you want the wider view of the fitness vertical and how we work in it, the fitness industry page collects it.
What it costs
A fitness app with all ten features is a substantial build, and the honest way to price it is hours times rate. Frenchy Digital bills senior-led work at $150 to $225 an hour, full source code and IP transfer to you, and there's a 30-day post-launch warranty.
Here's a worked scenario, not a quote. Consider an app with logging, progress, plans and a paywall on one cross-platform codebase, both health data bridges, an Apple Watch companion and a coach side. The hours below are illustrative planning figures for that scope.
| Scenario line | Hours (scenario) | At $150/hr | At $225/hr |
|---|---|---|---|
| Logging, progress, plans and paywall on one cross-platform codebase | 450 | $67,500 | $101,250 |
| HealthKit and Health Connect bridges | 120 | $18,000 | $27,000 |
| Apple Watch companion workout app | 130 | $19,500 | $29,250 |
| Coach side with consent switches | 100 | $15,000 | $22,500 |
| Total | 800 | $120,000 | $180,000 |
So 800 hours lands between $120,000 and $180,000. Divide by a typical ten-month build and you get roughly $12,000 to $18,000 a month, which is the number I'd hold up against your runway before choosing scope.
Where can it come down? Drop the watch app and read watch data through HealthKit and Health Connect instead: that's 130 hours, or $19,500 to $29,250, off the scenario. Launch on one platform first and you remove one of the two health bridges. The things I wouldn't cut are the log, the sync and the privacy work, because they're what everything else rests on.
Red flags in a proposal
The fastest way to judge a fitness app proposal is to check what it says about data. These are the signs I'd push back on.
- It still names Google Fit as the Android data source. Google says those APIs are supported only until the end of 2026.
- It plans to sync personal health data through iCloud. Apple guideline 5.1.3(ii) prohibits that.
- It includes advertising or analytics SDKs with no plan for what health events they receive.
- It promises integration with every wearable, with no mention of Garmin's approval and license terms or Oura's membership requirement.
- It has no offline plan for logging.
- It quotes a retention or engagement percentage as a guaranteed outcome.
- It has no in-app account deletion, which Apple guideline 5.1.1(v) requires when accounts exist.
- It holds back source code or IP after launch.
Numbers I refused to print
Fitness app articles usually lean on retention figures, and none are here because none survived checking. The familiar lines say that most users quit a fitness app within a month, or give a precise day-30 retention percentage.
I chased them. They circulate through analytics vendors' blogs and get recopied without a published sample, method or definition of "active." A number without a denominator can't tell you anything about your app, so I don't print it, and I'd be wary of any proposal that does.
Same for claims that wearable sync or personalization raise engagement by a set percentage, and for fitness app market size estimates, which vary widely between research sellers. I also didn't print a civil penalty figure for the FTC rule, because I didn't verify the current amount this session. And our own products' usage numbers aren't here because the products hadn't publicly launched.
Limitations
- The ranking is judgment based on feature dependency and retrofit cost, not a user survey.
- Google gives the end of 2026 for Fit API support but no exact shutdown day; check the migration guide before planning around a date.
- I did not verify Apple's watchOS and iOS version availability for the workout session APIs; check the current documentation.
- State privacy law beyond Washington was not reviewed here, and nothing in this article is legal advice.
- The cost table is an illustrative scenario with assumed hours, not a quote.
- Garmin's Health API license fee is not published on its overview page.
- Everything was checked on September 30, 2026, and platform rules change without notice.
Three things this week
- 1.Time yourself logging one set in your app, or your prototype, with the phone in one hand. If it takes more than about five seconds, that's the first ticket.
- 2.Search your Android codebase for Google Fit calls. If any exist, schedule the Health Connect migration now.
- 3.List every third-party SDK in the app and what health or fitness events it receives. Anything that reaches an ad or analytics pipe without disclosure is your highest risk.
Start with the log. Everything else is built on it.
For the other verticals in this series, start with the healthcare app features ranking, which covers the HIPAA side that fitness apps usually sit outside.
Want a Second Opinion on Your Feature List?
Book a discovery call with Frenchy Digital, a senior-led Black-owned Los Angeles agency operating since 2016. Bring your feature list and target devices, and you get a fixed-price phased proposal.
Planning a Fitness App?
Book a discovery call. Bring your feature list and the devices your users wear, and we will tell you which features to build first and which to cut.
1517 S Bentley Ave Apt 204, Los Angeles CA 90025
Frequently Asked Questions
Sources & References
- 1Apple: App Review Guidelines (2.5.1, 3.1.2, 5.1.1, 5.1.2, 5.1.3)↗
- 2Apple Developer: HealthKit documentation↗
- 3Apple Developer: HKWorkoutSession↗
- 4Apple: Auto-renewable subscriptions↗
- 5Android Developers: Health Connect guide↗
- 6Android Developers: Google Fit migration guide↗
- 7Android Developers: Google Fit migration FAQ↗
- 8Google Play Console Help: Health Connect permissions policy↗
- 9Android Developers: Health Services on Wear OS↗
- 10Garmin Developers: Garmin Health API↗
- 11Garmin Developers: Connect IQ overview↗
- 12Oura Help: The Oura API↗
- 13WHOOP Developer Platform↗
- 14FTC: Health Breach Notification Rule↗
- 15FTC: FTC finalizes changes to the Health Breach Notification Rule (April 26, 2024)↗
- 16Venable: final changes to the Health Breach Notification Rule↗
- 17Washington Attorney General: My Health My Data Act↗
