• A strategy for saving entities between runs of the app. Allows apps to:

    • launch with the UI in a valid and populated (though possibly stale) state,
    • recover from low memory situations with fewer reissued network requests, and
    • work offline.

    Siesta uses any HTTP request caching provided by the networking layer (e.g. URLCache). Why another type of caching, then? Because URLCache has a subtle but significant mismatch with the use cases above:

    • The purpose of HTTP caching is to prevent network requests, but what we need is a way to show old data while issuing new requests. This is the real deal-killer.

    Additionally, but less crucially:

    • HTTP caching is complex, and was designed around a set of goals relating to static assets and shared proxy caches — goals that look very different from reinflating Siesta resources’ in-memory state. It’s difficult to guarantee that URLCache interacting with the HTTP spec will exhibit the behavior we want; the logic involved is far more tangled and brittle than implementing a separate cache.
    • Precisely because of the complexity of these rules, APIs frequently disable all caching via headers.
    • HTTP caching does not preserve Siesta’s timestamps, which thwarts the staleness logic.
    • HTTP caching stores raw responses; storing parsed responses offers the opportunity for faster app launch.

    Siesta currently does not include any implementations of EntityCache, but a future version will.


    Siesta calls EntityCache methods on a GCD background queue, so your implementation must be thread-safe.

    See more



    public protocol EntityCache