Choose Native Features by Retention Impact, Not by Checklist

Writing widgets so they become a reason to return

A widget does not work by merely displaying something. The conditions are that the user feels today's meaning without opening the app, and that it stays light. Even after letting Rork Max generate it, this part is worth nailing down in your own words.

import WidgetKit
import SwiftUI
 
// You decide when the timeline refreshes next.
// Refreshing too often drains battery and gets throttled by the OS — counterproductive.
struct DailyEntry: TimelineEntry {
    let date: Date
    let streak: Int      // streak days — a small motive to open the app today
    let todayDone: Bool
}
 
struct StreakProvider: TimelineProvider {
    func timeline(in context: Context, completion: @escaping (Timeline<DailyEntry>) -> Void) {
        let entry = DailyEntry(date: .now, streak: SharedStore.streak(), todayDone: SharedStore.isDone())
        // Refresh once, at next midnight. That is enough, and the cost is minimal.
        let nextMidnight = Calendar.current.startOfDay(for: .now.addingTimeInterval(86_400))
        completion(Timeline(entries: [entry], policy: .after(nextMidnight)))
    }
    func placeholder(in context: Context) -> DailyEntry { DailyEntry(date: .now, streak: 0, todayDone: false) }
    func getSnapshot(in context: Context, completion: @escaping (DailyEntry) -> Void) {
        completion(DailyEntry(date: .now, streak: SharedStore.streak(), todayDone: SharedStore.isDone()))
    }
}

The key is refresh frequency. I have hit this many times in production: try to refresh a widget often and the OS throttles it, leaving the display stale anyway. "Once a day at midnight" is enough in most cases. Surface a small motive to return, like a streak count, and the widget becomes a retention device rather than decoration.

Work backward from the feature to justify $200/month

Rork Max is $200/month. Given that Expo-based Rork starts at $25, how to justify that gap is the practical question. I work backward from "does the native feature I truly want actually move retention or conversion?"

Decision flow (the order I actually use)
1. Put into words: what experience most determines this app's retention?
2. Does that experience require a native feature React Native cannot reach?
   -> No: Expo-based Rork is enough. The $200 is unnecessary.
   -> Yes: continue.
3. Is that feature on the "high impact" side (e.g., widgets)?
   -> Yes: paying $200 for Rork Max is a sound investment.
   -> No (decorative-leaning): ship on Expo first and watch.

Run this backward analysis and, for most apps, the rational path is: ship on Expo-based Rork first, and move to Rork Max only once you are convinced the retention core is a native feature. Paying $200 up front to carry every native feature tends to be a choice that widens surface area and prepays upkeep cost.

Always verify added features with numbers

Once you adopt a feature, confirm whether it works with numbers. If you added a widget, compare 7-day and 30-day retention between users who installed it and those who did not. Cross-check against AdMob or RevenueCat metrics to see whether conversion shifted. If it is not working, remove it without hesitation. A feature that leaves only upkeep drags down the whole app.

Even in apps I have run for a long time, I have removed features that looked flashy but nobody actually used. Afterward, crashes dropped and ratings stabilized. The courage to subtract features strengthens the business far more than addition does.

Conclusion: draw a map of retention, not of features

Rork Max's native feature list is a map of what is possible. But what matters in indie development is the map of retention — why the user comes back tomorrow. Use Rork Max's power only at the points on that map where you can honestly say a native feature is essential.

As a next step, name one feature in your current app that you can flatly say "retention would drop without this." That is the candidate for the native feature you should actually invest in. I hope this helps anyone working on the same problem.