When and How to Remove Features Nobody Uses — Auditing and Safely Retiring Functionality in Rork-Built Apps

The Minimal Usage Measurement — One Event, Split by Parameter

When measuring feature usage, I avoid creating a dedicated analytics event per feature. The analytics console turns into an event junkyard, and six months later you cannot read it.

I fix the event name to a single feature_use and distinguish features with a parameter. This code pins the measurable features down with a type and keeps a monthly local tally:

// featureUsage.ts — feature usage tracking (one event + parameter)
import AsyncStorage from '@react-native-async-storage/async-storage';
import analytics from '@react-native-firebase/analytics';
 
// Lock the measurable features into a type (prevents typos and stray events)
export type FeatureId =
  | 'slideshow'
  | 'favorite_export'
  | 'double_wallpaper'
  | 'search_filter'
  | 'widget_config';
 
const KEY_PREFIX = 'feature_usage_v1';
 
function monthKey(date = new Date()): string {
  const y = date.getFullYear();
  const m = String(date.getMonth() + 1).padStart(2, '0');
  return `${KEY_PREFIX}:${y}-${m}`;
}
 
export async function trackFeatureUse(id: FeatureId): Promise<void> {
  try {
    // 1) Send to the analytics backend (fixed event name, feature as parameter)
    await analytics().logEvent('feature_use', { feature_id: id });
 
    // 2) Keep a monthly count on-device too (handy in a debug menu)
    const key = monthKey();
    const raw = await AsyncStorage.getItem(key);
    const counts: Record<string, number> = raw ? JSON.parse(raw) : {};
    counts[id] = (counts[id] ?? 0) + 1;
    await AsyncStorage.setItem(key, JSON.stringify(counts));
  } catch {
    // Never let measurement failures break the app itself
  }
}

The call site is a single line at the feature's entry point:

const openSlideshow = () => {
  trackFeatureUse('slideshow');
  router.push('/slideshow');
};

Why only the entry point? Because a retirement decision needs exactly one number: the share of users who open the feature. Once you start measuring every interaction inside the feature, the measurement itself becomes a maintenance burden.

On the analysis side, break feature_use down by feature_id and divide by monthly active users. My first cut line is a 30-day usage rate of 1%.

For keeping the event schema itself type-safe across apps, I wrote up the approach in Guarding Analytics Events With Types Across Six Rork Apps — A Shared Event Layer.

Remove, Keep, or Bury — The Decision Criteria

After one or two months of data, it is decision time. My criteria are deliberately not a single axis of usage rate.

• Under 1% 30-day usage, and the people who do use it use it rarely — a removal candidate. It is working for no one
• Under 1% usage, but its users open it almost daily — keep it. Move it out of prime menu real estate and into the depths of settings. Features carried by a few heavy users hurt your reviews far more than the raw usage rate suggests
• Low usage, but featured in your store listing — resolve the mismatch with screenshots and description first, then decide
• Any usage rate, but it breaks on every OS update — the only options are removal or a rebuild. Half-hearted life support is the most expensive path of all

The slideshow fell into the first bucket: 0.7% usage, and even its users opened it less than twice a month. Meanwhile, a dual-screen wallpaper setting with similar usage stayed — its users touched it five or more times a week, so it moved deeper into settings instead of dying.

Numbers carry the decision most of the way, but the final push is a more personal question: do I want to keep maintaining this? In indie development, your own motivation is a finite resource too.

Retire in Three Stages — A Remote Config Driven Flow

Even once a feature is condemned, I never delete it in the next release. The retirement happens in three stages:

1. deprecated (notice period) — a "retiring soon" badge appears on the entry point, and opening the feature shows the planned end date. Two to four weeks
2. removed (entry point gone) — the menu item disappears. The code stays
3. code deletion — the next store release physically removes the code and its dependencies

Driving the stage through Remote Config means you can advance without waiting on store review — and roll back instantly if something goes wrong.

// useFeatureStage.ts — control a feature's lifecycle stage via Remote Config
import { useEffect, useState } from 'react';
import remoteConfig from '@react-native-firebase/remote-config';
 
export type FeatureStage = 'active' | 'deprecated' | 'removed';
 
export function useFeatureStage(featureKey: string): FeatureStage {
  const [stage, setStage] = useState<FeatureStage>('active');
 
  useEffect(() => {
    remoteConfig()
      .fetchAndActivate()
      .then(() => {
        const value = remoteConfig()
          .getValue(`stage_${featureKey}`)
          .asString();
        if (value === 'deprecated' || value === 'removed') {
          setStage(value);
        }
      })
      .catch(() => {
        // On fetch failure, stay active — never kill a feature over a network hiccup
      });
  }, [featureKey]);
 
  return stage;
}

The entry point renders according to the stage:

const stage = useFeatureStage('slideshow');
 
if (stage === 'removed') {
  return null; // Hidden from the menu (the code still exists)
}
 
if (stage === 'deprecated') {
  return (
    <MenuItem
      label="Slideshow"
      badge="Retiring soon"
      onPress={openSlideshowWithSunsetNotice}
    />
  );
}
 
return <MenuItem label="Slideshow" onPress={openSlideshow} />;

Why three stages? Because deleting in one step turns even a barely-used feature into "it vanished overnight" distrust in your reviews. Since adopting the notice period, across all six apps I have not received a single one-star review caused by a feature retirement.

The failure default matters too: falling back to active on a failed fetch is deliberate. Flip it the other way and users in airplane mode watch features disappear. Defaults always sit on the "keep things as they are" side.

The Removal Pitfalls — Debris Outside the Menu

Removing the menu item does not remove every door into the feature. These are the ones I have actually tripped over.

Deep links and widgets. Old announcement notifications and home screen widgets can still navigate straight into a retired screen. Catch it at the routing entry point and redirect home gracefully instead of crashing in silence:

// Route requests into retired screens back to home
if (route === 'slideshow' && stage !== 'active') {
  router.replace('/');
  showToast('The slideshow feature has been discontinued');
  return;
}

Stored data. Feature-specific data — playback intervals, playlists — becomes orphaned the moment the code is gone. It is small, but if a migration routine keeps referencing dead keys, it will confuse every future debugging session. My rule: purge the orphaned storage two versions after the code deletion ships.

Store listing assets. Screenshots or descriptions showing a removed feature mislead users and can draw reviewer attention during app review. The asset audit happens together with the removal submission, every time.

Release notes. It is tempting to ship the deletion quietly. I write one honest line instead: "The slideshow feature has been discontinued. To those who used it, I am sorry to see it go." Telling people first has consistently produced calmer reviews than being found out later.

Measure After Deletion — Success Looks Like Nothing Happening

Retirement does not end at deletion. For about 30 days, I watch four numbers:

• Related crash count — it should be zero now
• Support tickets and review mentions — for the slideshow, two tickets, one of them a restoration request
• Retention and DAU — unchanged means success; a drop means you missed heavy users your measurement could not see
• Dependency count and build size — I was able to drop the sleep-prevention dependency entirely

The success signal of a removal is not a dramatic improvement. It is the absence of any change: retention flat, crashes down, verification time shorter. Unglamorous, but that is the profit of a feature audit.

The reclaimed time goes back into the features people actually use. The hours that used to keep the slideshow alive shipped two improvements to search — a feature with 45% usage. Investment in a 45% feature repays far more reliably than investment in a 0.7% one.

The first step is neither measurement nor architecture. It is writing the list. Sometime this week, write down ten features in your app and recall the last time you touched each one. If even one of them is older than three months, this playbook has work to do.

If you have read an article about deleting features all the way to the end, you are almost certainly someone who intends to grow an app for the long term. I hope your audit turns out to be a satisfying tidy-up.