Building StandBy-Optimized Widgets in Rork Max

Step 2: Respond to dimming (night mode and always-on)

When isLuminanceReduced is true, cut the area of white and bright colors as much as you can. In my case the app was meant to sit at the bedside at night, so getting this right shaped the experience more than anything else.

struct AffirmationWidgetView: View {
    @Environment(\.isLuminanceReduced) private var dimmed
    var entry: AffirmationEntry
 
    var body: some View {
        VStack(alignment: .leading, spacing: dimmed ? 4 : 6) {
            Text(entry.affirmation)
                .font(dimmed ? .subheadline : .headline)
                .foregroundStyle(dimmed ? .red.opacity(0.85) : .white)
                .lineLimit(dimmed ? 2 : 3)
                .minimumScaleFactor(0.6)
 
            if !dimmed {
                // When dimmed, drop secondary info to shrink the lit area
                Text(entry.date, style: .time)
                    .font(.caption2)
                    .foregroundStyle(.secondary)
            }
        }
        .containerBackground(for: .widget) {
            dimmed ? Color.black : Color.indigo
        }
    }
}

The point is that when dimming, you don't just "darken the color," you "remove elements." The total count of lit pixels maps directly to perceived glare and to power, so cutting secondary text and decoration boldly makes the night experience better. At first I only turned the color red and kept the elements; placed at the bedside on a real device it was brighter than I expected, and I ended up settling on this decision to cut.

Step 3: Build around the always-on refresh rate

On an always-on iPhone, widget refresh is roughly capped at 1Hz, and it keeps drawing down the WidgetKit timeline refresh budget (around 40 to 70 reloads per day) as a separate allowance. A second-by-second countdown will not animate smoothly under always-on.

The realistic move here is to drop the "make it move" assumption and lean on system-managed displays like Text(date, style: .timer). If you design the timeline to emit an entry every minute, you can blow through the budget and have updates stop in the dead of night. Refresh-budget design is foundational to widgets in general, not just StandBy, so reading WidgetKit timeline refresh budget design alongside this will make your StandBy support a notch more stable.

Step 4: Interactive widgets work in StandBy too

Since iOS 17, interactive widgets built with App Intents (buttons and toggles) operate in StandBy as well. Adding a button to "advance to the next affirmation" was genuinely handy: I could switch it just by reaching over from the pillow.

struct NextAffirmationIntent: AppIntent {
    static var title: LocalizedStringResource = "Next Affirmation"
 
    func perform() async throws -> some IntentResult {
        AffirmationStore.shared.advance()
        return .result()
    }
}
 
// In the widget
Button(intent: NextAffirmationIntent()) {
    Image(systemName: "arrow.right.circle")
}
.buttonStyle(.plain)

That said, the tap target is hard to see when dimmed, so when isLuminanceReduced is true you have to decide whether to hide the button or leave only its outline. The App Intents design itself is covered in App Intents and Siri Shortcuts integration, which helps if you want to share the same entry point with Siri.

What Rork Max owns, and what you finish yourself

Let me lay out, honestly, the division of responsibility I felt through this build. Rork Max assembles the scaffolding — the WidgetKit Provider, Entry, and base view — from a natural-language instruction with fair accuracy. The systemSmall layout and even the App Intents skeleton were in a working state the moment they were generated.

On the other hand, the isLuminanceReduced branching that splits StandBy's three environments (day, night, always-on), the swap to containerBackground, and the timeline design that accounts for the refresh budget were not in the generated code. I see this less as a Rork Max weakness than as a consequence of StandBy being something you "only see once you charge a real device in landscape" — there is no way to detect it from a generation-time preview alone.

My operating rule settled into this split: let Rork Max handle the widget's skeleton, and always do one full pass on a real device before adding the StandBy-specific adjustments by hand. Even when using a generative tool, I've come to feel that these "environment differences a preview can't show" are something a person simply has to look at and finish — and accepting that is, in the end, the fastest path.

Three things to check during verification

When I check StandBy on a real device, there are three things I always look at. First, whether the widget appears in the intended layout while charging in landscape and locked. Next, I darken the room and wait a few dozen seconds, then check whether the text is readable once it switches to night mode. Finally, on a 14 Pro or later, I leave it in always-on overnight and confirm the next morning that updates didn't stop in the dead of night.

That third one in particular surfaces, when your design exhausts the timeline budget, as "the time is frozen at 2 a.m." App Store reviewers tend to flag this, and it ties into the freshness of a widget's underlying data, so it's reassuring to read it together with the freshness handling covered in stale data via App Group in widgets.

Start with a single widget you already have, add just the containerBackground declaration and the isLuminanceReduced branch, and charge a real device in landscape. The breakage you couldn't catch on the Home Screen should reveal itself on the spot.