Would you consider adding prefersInApp support to OpenURLEffect for OS 26+?

[vistar941]

Proposal: Add prefersInApp support to OpenURLEffect for OS 26+

Hi Point-Free team,

Thank you for the fantastic work on swift-dependencies. It has become an essential building block in how we manage side effects in our SwiftUI apps.

I'd like to propose adding first-class support for the new prefersInApp parameter introduced in OpenURLAction on OS 26, and I'd be happy to work on a PR if this sounds like a good direction.

---

Motivation

OS 26 introduced a new overload of OpenURLAction.callAsFunction(_:prefersInApp:), which allows callers to opt into opening URLs via SFSafariViewController (an in-app browser) rather than routing them to Safari. This can also be configured at the view level via the .onOpenURL(prefersInApp:) modifier.

// New in OS 26
@MainActor @preconcurrency
func callAsFunction(
    _ url: URL,
    prefersInApp: Bool
)

// View modifier equivalent
@MainActor @preconcurrency
func onOpenURL(prefersInApp: Bool) -> some View

Many apps benefit from keeping users within the app when opening web content — this addition makes that straightforward without requiring a custom WKWebView setup or third-party libraries.

---

The Problem

The current OpenURLEffect in swift-dependencies only exposes:

public func callAsFunction(_ url: URL) async -> Bool
public func callAsFunction(_ url: URL) async  // @_disfavoredOverload

swift-dependencies/Sources/Dependencies/DependencyValues/OpenURL.swift

Lines 41 to 58 in e1f234a

	public struct OpenURLEffect: Sendable {
	private let handler: @Sendable (URL) async -> Bool
	public init(handler: @escaping @Sendable (URL) async -> Bool) {
	self.handler = handler
	}
	@available(watchOS, unavailable)
	@discardableResult
	public func callAsFunction(_ url: URL) async -> Bool {
	await self.handler(url)
	}
	@_disfavoredOverload
	public func callAsFunction(_ url: URL) async {
	_ = await self.handler(url)
	}
	}

There is no way to express prefersInApp: true through the existing API. While it's possible to define a project-local OpenURLEffect replacement, opening URLs is one of the most fundamental effects in a SwiftUI app. Having prefersInApp support baked into the package itself would benefit the entire community without burdening each project with boilerplate.

---

Proposed Addition

Add a new callAsFunction overload to OpenURLEffect that accepts a prefersInApp parameter, and update the liveValue handler accordingly:

  // New overload for iOS 26+
  @available(iOS 26, macOS 26, tvOS 26, watchOS 26, visionOS 26, *)
  @available(watchOS, unavailable)
  @discardableResult
  public func callAsFunction(_ url: URL, prefersInApp: Bool) async -> Bool {
    await self.handler(url, prefersInApp)
  }

  @available(iOS 26, macOS 26, tvOS 26, watchOS 26, visionOS 26, *)
  @_disfavoredOverload
  public func callAsFunction(_ url: URL, prefersInApp: Bool) async {
    _ = await self.handler(url, prefersInApp)
  }

The liveValue would be updated to forward prefersInApp to EnvironmentValues().openURL(_:prefersInApp:) on supported OS versions, with a fallback to the current behavior on earlier versions.

---

Question

Would adding prefersInApp support to OpenURLEffect be something you'd consider including in the library?

I'm happy to:

• Open a PR with a full implementation
• Discuss alternative API shapes (e.g., keeping the handler as (URL) async -> Bool and using a separate overload-based approach)
• Write tests for the new behavior

Thanks again for all the great work — looking forward to hearing your thoughts!

[vistar941]

Implementing this would also resolve the discussion raised in #197