#2388·RestSharp

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

Author: alexeyzimarevCreated Jun 2, 2026Updated Jun 2, 2026
Labelsfeature-requestrfc

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 #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

csharp
// 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:

csharp
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

  • Ship now with a single helper (UseIosCookieFix) covering #2168 / #2385?
  • Wait until 2-3 platform fixes accumulate to justify the package?
  • Reject and keep all platform recipes in docs only?

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