Skip to content

RFC: RestSharp.Maui companion package for platform-specific quirks #2388

Description

@alexeyzimarev

Motivation

A growing set of MAUI / mobile-specific gotchas can't be fixed in core RestSharp because:

  • Core targets netstandard2.0 / net8.0+ and must remain free of iOS / Android workload dependencies.
  • Platform fixes often require calling into Foundation / NSURLSession / Java.Net types that only exist under TFM-specific workloads (net9.0-ios, net9.0-android, etc.).
  • Documenting the workarounds (see Docs: iOS/MAUI cookie handling workaround #2387) helps, but every consumer ends up copy-pasting the same recipe.

A small TFM-targeted companion package could collect these recipes as one-liner extension methods.

Proposed surface

// RestSharp.Maui
public static class RestClientOptionsExtensions {
    /// <summary>
    /// Configures the underlying handler to suppress NSURLSession's cookie storage,
    /// so Set-Cookie headers reach RestSharp's per-request parser intact.
    /// Multi-tenant safe — no shared cookie state at any layer.
    /// </summary>
    public static RestClientOptions UseIosCookieFix(this RestClientOptions options);

    // Room for future fixes:
    // - UseIosCertificatePinning(...)
    // - UseAndroidNetworkSecurityConfig(...)
    // - UseEphemeralNetworking()
}

Usage in a MAUI app:

var options = new RestClientOptions(baseUrl).UseIosCookieFix();

Open questions

  1. Naming. RestSharp.Maui vs RestSharp.Platforms vs separate RestSharp.iOS + RestSharp.Android packages. I lean toward RestSharp.Maui — single package, MAUI is the dominant consumer of platform-specific HTTP quirks.
  2. TFM matrix. Probably net8.0-ios, net9.0-ios, net10.0-ios, net8.0-android, net9.0-android, net10.0-android, plus netstandard2.0 no-op fallbacks so consumers can reference it from shared projects without conditional compilation.
  3. Maintenance burden. Every iOS / Android SDK bump may need a sanity check. Worth it only if 2-3+ platform fixes accumulate. Today we'd ship with just UseIosCookieFix.
  4. Discovery. Would need a README pointer and a docs section explaining when to reach for it. Risk: people who don't read docs still hit the original bug.

Decision needed

Tracking: depends on #2387 (docs landing first) and follows from the design discussion in #2168.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions