[swift5] fix: make the urlsession client compile on Linux

[wiebren]

The swift5 urlsession client does not compile on Linux:

URLSessionImplementations.swift:9:8: error: no such module 'MobileCoreServices'

and once past that,

error: 'URLSession' is unavailable: This type has moved to the FoundationNetworking
module. Import that module to use it.   (254x)

The cause

URLSessionImplementations.mustache guards the Apple-only module with

#if !os(macOS)
import MobileCoreServices
#endif

!os(macOS) is true on Linux and Windows, so the import fires exactly where the module
does not exist. The guard came in with #15060 ("feat(swift5): allow to swift build in
linux"), which fixed the macOS build and the one Linux job CI runs — but that job builds
only the alamofireLibrary sample, which never compiles URLSessionImplementations.swift,
so the regression was invisible.

Behind the import, the same file uses URLSession/URLRequest without the
#if canImport(FoundationNetworking) import that every other support template
(APIs.mustache, Configuration.mustache, Models.mustache, Extensions.mustache,
JSONDataEncoding.mustache) already carries — on Linux those types live in
FoundationNetworking, not Foundation. And the pre-macOS-11 fallback in mimeType(for:)
calls UTTypeCreatePreferredIdentifierForTag unconditionally; if #available is a runtime
check, so that branch is still compiled on Linux and fails even after the import is
fixed.

The fix

The standard guards, in both places:

• #if canImport(FoundationNetworking) import FoundationNetworking #endif — same as the
  other support files;
• #if canImport(MobileCoreServices) around the import and around the
  UTTypeCreatePreferredIdentifierForTag fallback in mimeType(for:). The function's
  early returns are otherwise untouched; every path that previously returned
  "application/octet-stream" now falls through to the single trailing return of the same
  value (keeping a return inside the compiled-out branch would trip swiftc's
  "will never be executed" warning on Linux), so behavior on Apple platforms is unchanged:
  UTType lookup on macOS 11+/iOS 14+, MobileCoreServices fallback on older OS versions.

To keep this fixed, the CI matrix now builds the urlsessionLibrary petstore sample on
ubuntu-latest next to the existing alamofireLibrary entry.

The swift6 generator's twin template has the identical #if !os(macOS) guard and the same
fix applies there; happy to extend this PR or follow up, whichever you prefer.

Tests / verification

• Samples regenerated with ./bin/generate-samples.sh ./bin/configs/swift5-*.yaml; the
  diff is confined to the generated URLSessionImplementations.swift files.
• The regenerated urlsessionLibrary petstore sample builds cleanly on Linux (swift build
  in a swift:6.1 container) — on master the same build fails with the errors above. (The
  only diagnostics left are pre-existing Sendable warnings, e.g. SessionDelegate vs.
  Linux FoundationNetworking's URLSessionTaskDelegate: Sendable — unrelated to this
  change.)
• macOS behavior unchanged: the module is imported wherever it exists, and the
  mimeType(for:) fallback still runs on Apple platforms older than the UTType APIs.

Existing upstream issues: none found (searched MobileCoreServices, swift linux,
FoundationNetworking swift5).

PR checklist

• Read the contribution guidelines.
• Built the project and updated samples (./bin/generate-samples.sh ./bin/configs/swift5-*.yaml; docs export unchanged).
• Technical committee: @4brunu

---

Generated with Claude Code

---

Summary by cubic

Fixes the swift5 and swift6 urlsession clients so they compile on Linux. Previously the MobileCoreServices import was guarded by #if !os(macOS) (true on Linux and Windows) and URLSession/URLRequest were used without importing FoundationNetworking, which hosts those types on Linux.

• Adds #if canImport(FoundationNetworking) import FoundationNetworking #endif to both templates, matching the other support templates.
• Guards the MobileCoreServices import and the UTTypeCreatePreferredIdentifierForTag fallback with canImport(MobileCoreServices).
• Refactors mimeType(for:) to end with a single trailing return of "application/octet-stream", so Apple-platform behavior is unchanged.
• CI now builds the urlsessionLibrary petstore sample on ubuntu-latest; the previous Linux job only built alamofireLibrary, which never compiles this file.

^{Written for commit 68d3a60. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 12 files

_{Re-trigger cubic}

[wiebren]

The ci/bitrise check fails in the 'Run Swift6 tests' step on swift6/combineLibrary - a sample this PR does not touch. The same failure occurs on every Bitrise build of this app since February 2026, including master pushes (e.g. build a5ad0d4b, 2026-08-26), so it is a pre-existing CI issue on the osx-xcode-26.2.x stack, unrelated to this change.

[4brunu]

Hi @wiebren could you please also fix this in the swift 6 generator? Thanks

[wiebren]

@4brunu done - the swift6 urlsession template gets the same two guards (canImport(MobileCoreServices) around the import and the UTType fallback, plus the canImport(FoundationNetworking) import), and the swift6 samples are regenerated; the swift6 urlsessionLibrary sample builds clean with Swift 6.3.3.

One note: the swift5 half of this PR also adds the urlsessionLibrary sample to the ubuntu-latest job of samples-swift5.yaml so the fix stays covered, but there is no GitHub Actions workflow building swift6 samples at all (swift6 is only exercised on Bitrise). If you'd like an equivalent samples-swift6.yaml I'm happy to add one, here or as a follow-up.

[4brunu]

One note: the swift5 half of this PR also adds the urlsessionLibrary sample to the ubuntu-latest job of samples-swift5.yaml so the fix stays covered, but there is no GitHub Actions workflow building swift6 samples at all (swift6 is only exercised on Bitrise). If you'd like an equivalent samples-swift6.yaml I'm happy to add one, here or as a follow-up.

Yes please