[Investigation] Widgets behavior issue in the mobile app

[sktbrd]

Context

Reported (not yet personally reproduced) that something is off with widgets in the mobile app. Not yet clear whether these are native widgets (home screen) or internal app components, and the exact problem isn't clear yet.

Goal

First clarify what's meant by "widgets" and what's actually wrong, then reproduce and identify the root cause.

Areas to check

• Determine if these are native widgets (iOS/Android home screen) or internal components
• Compare behavior against expected (what should widgets look/behave like vs what they actually do)
• Check for errors/warnings in console or logs
• If native: may require separate per-OS investigation

Next steps

• Get more detail from whoever reported it, if possible
• Reproduce and narrow down the actual symptom
• Report findings here before opening a fix PR

Suggested label: needs-investigation, needs-repro, mobile

[Bielcx]

Code-level investigation (no repro yet)

Answering the first checkbox: these are native iOS home screen widgets, not internal app components. There are four, all in the SkateSpots WidgetKit target (targets/widget/index.swift:246-254): Nearest Spot, Spot Map, Top Spots and Add Spot. iOS only — there is no Android equivalent.

Everything below comes from reading the code. I have not reproduced any of it (no iOS build available to me), so I've marked what's provable from the source vs. what's a hypothesis.

Most likely cause: the widget is stale by design

The widget never fetches anything itself. It only renders whatever the app last wrote into the App Group (group.com.bgrana.skatehive), and the timeline is policy: .never (targets/widget/index.swift:120 and :151), so WidgetKit is explicitly told never to refresh on its own. The only refresh path is the app calling reloadAllTimelines() (modules/widget-bridge/ios/WidgetBridgeModule.swift:29).

The problem is what feeds it. The user's location is only read on the Map tab (app/(tabs)/map.tsx:222 and :266-277) and persisted as "last known location". On app foreground, useSpotWidgetSync (lib/hooks/useSpotWidgetSync.ts:36-59) reuses that stored location — it never requests a fresh fix.

Consequences:

• A user who travels and opens the app normally still sees their home-city spots, labelled with the frozen distance (▸ 400 m for a spot 50 km away), because distanceKm is computed in JS at push time (lib/widgets/spotWidget.ts:27-30) and baked into the payload. It only corrects itself if they visit the Map tab.
• A user who installs the widget but never opens the Map tab stays on "NO SIGNAL" forever — useSpotWidgetSync.ts:44 returns silently when there's no stored location.
• If the app isn't opened at all, the widget freezes indefinitely with no staleness indicator (the SYNC //HH:MM stamp just keeps showing the old time).

This matches "something is off with the widgets" better than anything else I found.

Other findings

Confirmed in code:

• Dedupe can poison itself. lib/widgets/spotWidget.ts:40 records the payload signature before attempting the push and never reverts on failure — so if a write fails, that payload can't be retried for the rest of the session.
• Three layers of silent failure. If the native module fails to link, modules/widget-bridge/index.ts:11-18 swallows it into null, :24 optional-chains the call, and lib/widgets/spotWidget.ts:60-64 has another empty catch. Result: total no-op, zero logs. There's already an isWidgetBridgeAvailable flag exported for exactly this — it is not used anywhere.
• Add Spot widget lands on the login screen. It deep-links to /spot-create?camera=1 (targets/widget/SpotWidgetViews.swift:413), but the navigation guard only exempts /map when logged out (app/_layout.tsx:64-65).
• Spot Map renders the 🛹 placeholder instead of the map in snapshot contexts — getSnapshot returns real data with snapshot: nil (targets/widget/index.swift:88-90).
• Release risk: scripts/sync-widget-version.js only runs via pnpm prebuild:ios. Anyone running expo prebuild or expo run:ios directly ships the widget with CURRENT_PROJECT_VERSION = 1, which App Store Connect rejects. The script also exits 0 silently if the .xcodeproj isn't named SkateHive (:31-34).

Hypothesis, needs a device to confirm:

• Widget extension running out of memory. targets/widget/ImageLoader.swift:14-15 decodes images at full size with no downsampling, and the timeline loads up to 5 in parallel (index.swift:143) plus an MKMapSnapshotter render. Widget extensions are capped around 30 MB — if spot thumbnails are full-resolution IPFS originals, this is a jetsam kill, which surfaces as a blank or stuck widget with no error anywhere.

Not a cause, worth recording: the widget never touches CoreLocation — it depends entirely on userLat/userLng from the payload (targets/widget/Shared.swift:28-29), and the app only holds "when in use" permission (app.json:78-83). So there's no possible background update path in the current design; that's why staleness is structural rather than a bug to patch.

Unrelated, found while setting up

The production build registers the exp+skatehive-app:// scheme, because expo-dev-client is listed in app.json:59 plugins for all builds. Scanning a dev-server QR code opens the TestFlight app instead of Expo Go. Harmless to users, confusing for contributors.

Next steps / question for the reporter

The findings split cleanly: staleness + dedupe + auth guard are JS fixes; memory, snapshot and versioning are Swift/build fixes worth batching into one native build.

@sktbrd — could whoever reported this say which symptom they actually saw? "NO SIGNAL" that never goes away, a blank widget, or a spot showing an obviously wrong distance? Each points at a different one of the above.