http-cache_skill

This skill generates a production-ready HTTP caching layer in Swift, enabling offline support, Cache-Control parsing, and ETag-based requests to reduce API
  • Swift

56

GitHub Stars

3

Bundled Files

2 months ago

Catalog Refreshed

3 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill rshankras/claude-code-apple-skills --skill http-cache

  • http-cache-patterns.md9.9 KB
  • SKILL.md5.8 KB
  • templates.md15.9 KB

Overview

This skill generates a production-ready HTTP caching layer for Swift projects. It provides Cache-Control parsing, ETag/Last-Modified conditional requests, stale-while-revalidate behavior, and optional offline fallback. Use it to reduce API calls, add offline support, and improve perceived app performance.

How this skill works

The generator inspects your project for networking and caching code and creates a set of Swift files that implement cache storage, header parsing, and conditional request handling. It produces a decorator you can wrap around an existing APIClient (or a standalone cache you call directly), plus optional reachability integration for offline behavior. Responses are stored in a disk-backed cache with respect for Cache-Control headers and support for ETag / 304 flows and stale-while-revalidate.

When to use it

  • You want to reduce redundant API calls and lower bandwidth usage.
  • You need offline fallback that serves cached responses when the network is unavailable.
  • You want proper handling of Cache-Control, ETag, and Last-Modified headers.
  • You want stale-while-revalidate behavior to show fresh UI quickly while updating in the background.
  • You’re integrating with an existing APIClient and prefer a decorator-based approach.

Best practices

  • Run the generator only after confirming Swift 5.9+ and iOS 16+/macOS 13+ deployment targets.
  • Prefer the decorator integration when an APIClient exists to minimize invasive changes.
  • Choose cache sizes based on typical payloads; Medium (25 MB / 100 MB) is a good default for mobile apps.
  • Respect server Cache-Control headers by default; use cache-first selectively for endpoints with stable data.
  • Add tests that assert cached vs network behavior and conditional 304 flows.

Example use cases

  • Wrap an existing URLSession-based APIClient with CachingAPIClient to transparently add caching.
  • Enable offline mode for a news feed: serve stale articles when offline, then revalidate in background.
  • Reduce API calls for user profile or configuration endpoints with long max-age or forceCache policies.
  • Implement per-endpoint policies: noCache for sensitive endpoints, cacheFirst for static assets.
  • Add NetworkReachability to serve stale content only when the device has no connectivity.

FAQ

Yes. Use the decorator integration to wrap your existing APIClient so callers use the caching client with minimal changes.

How are ETag and 304 responses handled?

The cache stores validators (ETag/Last-Modified) and sends If-None-Match/If-Modified-Since headers; on 304 the cached body is reused and headers updated.

Can I control cache size and strategy?

Yes. The configuration exposes memory/disk presets and per-endpoint CachePolicy: respect server headers, cache-first, manual, or no-cache.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
http-cache skill by rshankras/claude-code-apple-skills | VeilStrat