Finding
Sources/MistKit/Service/Assets/URLSession+AssetUpload.swift:47 defines:
```swift
public func upload(_ data: Data, to url: URL) async throws -> (statusCode: Int?, data: Data) {
let request = URLRequest(forAssetUpload: data, to: url)
let (responseData, response) = try await self.data(for: request)
...
}
```
There is no `@available` annotation on this extension or function, but URLSession.data(for:) (the async overload) requires macOS 12.0+ / iOS 15.0+ / tvOS 15.0+ / watchOS 8.0+. The function's primary callers, CloudKitService+AssetUpload.swift:40 and CloudKitService+AssetOperations.swift:42, are pinned at @available(macOS 11.0, iOS 14.0, tvOS 14.0, watchOS 7.0, *). Package.swift declares deployment targets of .macOS(.v10_15) / .iOS(.v13) / .tvOS(.v13) / .watchOS(.v6).
So the call to data(for:) is unguarded against deployment targets that don't have the API.
Why it matters
Either:
- CI is silently skipping the lowest deployment targets (and the build would actually fail there), or
- A pre-concurrency Foundation backport happens to make the call compile, but that's brittle and undocumented.
The PR #298 review proposed bumping the asset-upload service surface to macOS 12 / iOS 15 / tvOS 15 / watchOS 8, motivated by adopting async URLSession.upload(for:from:delegate:). Commit `4e968ac` on the PR #322 branch made that bump, but it didn't reach `main` — `CloudKitService+AssetUpload.swift` and `CloudKitService+AssetOperations.swift` still pin macOS 11 / iOS 14.
Suggested fix
Either:
- Pin the floor: add `@available(macOS 12.0, iOS 15.0, tvOS 15.0, watchOS 8.0, )` to the `URLSession.upload(_:to:)` extension and the two `CloudKitService+Asset` extensions, and bump the corresponding `#available` guards in tests. (This is the v1.0.0-beta.1 review proposal.)
- Or stop using `data(for:)` on the older targets — e.g., conditionally compile against `URLSession.upload(_:from:)` with completion handler bridging on macOS 11 / iOS 14.
The first option is much simpler and is what the v1.0.0-beta.1 review already proposed.
Found while
Resolving #313 (PR #326). Captured here rather than expanded in scope.
Finding
Sources/MistKit/Service/Assets/URLSession+AssetUpload.swift:47defines:```swift
public func upload(_ data: Data, to url: URL) async throws -> (statusCode: Int?, data: Data) {
let request = URLRequest(forAssetUpload: data, to: url)
let (responseData, response) = try await self.data(for: request)
...
}
```
There is no `@available` annotation on this extension or function, but
URLSession.data(for:)(the async overload) requiresmacOS 12.0+ / iOS 15.0+ / tvOS 15.0+ / watchOS 8.0+. The function's primary callers,CloudKitService+AssetUpload.swift:40andCloudKitService+AssetOperations.swift:42, are pinned at@available(macOS 11.0, iOS 14.0, tvOS 14.0, watchOS 7.0, *).Package.swiftdeclares deployment targets of.macOS(.v10_15) / .iOS(.v13) / .tvOS(.v13) / .watchOS(.v6).So the call to
data(for:)is unguarded against deployment targets that don't have the API.Why it matters
Either:
The PR #298 review proposed bumping the asset-upload service surface to macOS 12 / iOS 15 / tvOS 15 / watchOS 8, motivated by adopting async
URLSession.upload(for:from:delegate:). Commit `4e968ac` on the PR #322 branch made that bump, but it didn't reach `main` — `CloudKitService+AssetUpload.swift` and `CloudKitService+AssetOperations.swift` still pin macOS 11 / iOS 14.Suggested fix
Either:
The first option is much simpler and is what the v1.0.0-beta.1 review already proposed.
Found while
Resolving #313 (PR #326). Captured here rather than expanded in scope.