Putting a Working Button in a Rork App's Widget — Implementing App Intents So a Tap Acts Without Opening the App

Write the App Intent in the extension target

The button's substance is an App Intent. Put it on the extension (Swift) side. Here's a "toggle today's completion" intent for the habit tracker.

import AppIntents
import WidgetKit
 
struct ToggleHabitIntent: AppIntent {
  static var title: LocalizedStringResource = "Toggle today's habit"
 
  @Parameter(title: "Habit ID")
  var habitID: String
 
  init() {}
  init(habitID: String) { self.habitID = habitID }
 
  func perform() async throws -> some IntentResult {
    let defaults = UserDefaults(suiteName: "group.net.rorklab.habit")
    let key = "done_\(habitID)_\(todayKey())"
    let current = defaults?.bool(forKey: key) ?? false
    defaults?.set(!current, forKey: key)
 
    WidgetCenter.shared.reloadTimelines(ofKind: "HabitWidget")
    return .result()
  }
 
  private func todayKey() -> String {
    let f = DateFormatter()
    f.dateFormat = "yyyy-MM-dd"
    return f.string(from: Date())
  }
}

When perform() runs, your app is not launched. So reaching for AdMob initialization or the RN bridge in here will fail. Inside perform(), treat the only safe operations as reading/writing the shared store and notifying WidgetCenter. Anything heavy belongs in a sync on the app's next launch.

That final reloadTimelines(ofKind:) is the third part — the reload. Skip it and you get changed state with a stale picture.

Draw the button in the widget view

In the widget's SwiftUI view, bind the intent to a button. Button(intent:) is the API built for exactly this.

import SwiftUI
import WidgetKit
 
struct HabitWidgetView: View {
  let entry: HabitEntry
 
  var body: some View {
    VStack(alignment: .leading, spacing: 8) {
      Text(entry.habitName).font(.headline)
      Button(intent: ToggleHabitIntent(habitID: entry.habitID)) {
        Label(entry.isDone ? "Done" : "Not done",
              systemImage: entry.isDone ? "checkmark.circle.fill" : "circle")
      }
      .tint(entry.isDone ? .green : .gray)
    }
    .containerBackground(.fill.tertiary, for: .widget)
  }
}

HabitEntry carries the state the TimelineProvider read from the App Group. The provider reads the shared boolean, the view draws it, the button calls the intent, the intent rewrites the shared store and reloads. Close that loop and a check gets ticked without the app ever opening.

Trap #1: the button does nothing

This is where I first lost two hours. In the simulator I'd press the button and get nothing — no log, no state change.

The cause was where the App Intent lived. An App Intent invoked from Button(intent:) only runs if it's in the widget extension's target membership. Place the intent only in the app target while assuming the extension "imports" it, and the build succeeds while the runtime silently ignores it. In Xcode's File Inspector, confirm the intent's .swift file is checked for the extension target. If a config plugin generates your extension, verify after project.pbxproj generation that the plugin actually includes the intent file in the extension's sources.

One more thing: test on a device. Interactive widget behavior differs subtly between simulator and hardware, and reload timing in particular is more honest on a real device.

Trap #2: state rolls back right after the tap

The button worked. But tick a check, bring the app to the foreground, and the check is gone. A rollback.

The cause was a duplicated source of truth. The app treated its own persistent store (MMKV, in my case) as truth and wrote it out to the App Group on launch. Meanwhile the widget's intent writes the App Group directly. The instant the app returned to the foreground, it overwrote the App Group with its older value — as if to say "I'm the correct one" — erasing the widget's change.

The fix was to make writes one-directional. Treat the App Group as an inbox that receives widget-originated changes. On app resume, compare the App Group value against the app's own and merge by taking whichever has the newer timestamp. Just dropping the blind overwrite stopped the rollback.

// Merge on app resume (pseudocode)
let widgetValue = sharedDefaults.bool(forKey: key)
let widgetUpdatedAt = sharedDefaults.double(forKey: key + "_ts")
if widgetUpdatedAt > localStore.updatedAt(for: key) {
  localStore.set(widgetValue, for: key)   // adopt widget's value if newer
}
// Write the other direction only when local is newer

Keeping the source one-directional pays off well beyond widgets — it applies anywhere multiple processes touch the same state.

The real constraint: refresh budget

One operational note. An interactive widget's reloadTimelines requests an immediate redraw, but widgets as a whole live under an iOS-imposed refresh budget — designed to land around a few dozen automatic refreshes per day. User-initiated reloads from a button press are treated more generously, but if your intent's perform() hits an external API every time, the response lags and the tap loses its snappiness.

In my own setup, perform() does nothing but update the shared store and reload; server sync is batched on the app's next launch. Cast the widget as "a fast surface for actions at hand" and the app as "the place that absorbs heavy work in bulk," and you satisfy both the feel and the budget.

Once you're here, the next step

Start by closing the entire loop — button → shared store → reload → redraw — with a single boolean toggle. Once that minimal round-trip works even once, you can extend it with the same shape to lists of habits, quantity increments, and multiple widget sizes.

Bridging into territory Expo's stock features can't reach, with a config plugin and a small amount of Swift, is worth doing by hand once. After you've crossed that boundary yourself, the call between "this can stay in Rork (Expo)" and "from here it's faster to lean on Rork Max (native)" stops being a guess and becomes something you can feel. If you're stuck on the same round-trip, I hope this gives you a thread to pull.