You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
macOS: widget links (linkurl / <link>) open ScriptWidget instead of the URL #48
On macOS, clicking a widget that sets linkurl (or contains a <link url="…">) brings ScriptWidget's window to the front, and the URL itself is never opened. On iOS the same package forwards the link: ScriptWidgetApp's onOpenURL hands anything that is not ScriptWidget's own scheme to DeepLinkManager.openDeepLink, which calls UIApplication.shared.open.
To reproduce
$render(<vstackframe="max"linkurl="https://xnu.app/scriptwidget"><text>Open the site</text></vstack>);
Add it to the macOS desktop or Notification Center and click it.
Expected: the URL opens with its default handler, as on iOS. Actual: ScriptWidget's main window comes forward; nothing else happens.
Cause
WidgetKit delivers widgetURL / Link destinations to the containing app. The iOS app handles them; ScriptWidgetMacApp has no onOpenURL (or application(_:open:)) handler, so on macOS the URL is dropped.
Suggested fix
Mirror the iOS behaviour in macOS/ScriptWidgetMac/App/ScriptWidgetMacApp.swift, e.g.:
Ideally a forwarded link would not also raise ScriptWidget's window, so the click goes straight to its destination; an NSApplicationDelegateapplication(_:open:) implementation may suit that better than onOpenURL. (I have not built this — it is from reading the source.)
Related, on iOS
The iOS handler returns early when url.host() is nil, so a link with an empty host such as scriptable:///run/Name (the only form Scriptable accepts) is silently dropped rather than forwarded. Forwarding those too would let a widget open another app's URL scheme regardless of its host convention.
Use case
I render cards in a widget and want a click to open a detailed page for that card (an HTML file on macOS). On iOS the forwarding already works for URLs with a host; on macOS every click lands in the app.
Thank you for the detailed report, reproduction example, and investigation! They made the missing macOS URL handler straightforward to identify.
I've opened #49 to forward widget link destinations through NSWorkspace, including file URLs and custom schemes without a host. ScriptWidget's internal schemes are excluded to avoid forwarding loops. The routing regression test and full local release-readiness gate passed.
The PR focuses on macOS forwarding; the related iOS host check is unchanged. Desktop click behavior and window activation still need a manual smoke test, so I haven't claimed that this prevents the ScriptWidget window from coming forward.
The fix has now been merged in #49. I'll submit the updated app for App Store review soon.
Thank you again for the detailed report and reproduction steps—they were very helpful in tracking this down. Once the update is available, please let me know how widget links work for you on macOS!
Activity
everettjf commentedon Oct 4, 2026
Thank you for the detailed report, reproduction example, and investigation! They made the missing macOS URL handler straightforward to identify.
I've opened #49 to forward widget link destinations through
NSWorkspace, including file URLs and custom schemes without a host. ScriptWidget's internal schemes are excluded to avoid forwarding loops. The routing regression test and full local release-readiness gate passed.The PR focuses on macOS forwarding; the related iOS host check is unchanged. Desktop click behavior and window activation still need a manual smoke test, so I haven't claimed that this prevents the ScriptWidget window from coming forward.
everettjf commentedon Oct 4, 2026
The fix has now been merged in #49. I'll submit the updated app for App Store review soon.
Thank you again for the detailed report and reproduction steps—they were very helpful in tracking this down. Once the update is available, please let me know how widget links work for you on macOS!