Enumerations

Undocumented

This defines the various levels of logging that a message may be tagged with. This allows hiding and showing different logging levels at run time depending on the environment

Strategy for resolving feature flag variants relative to the on-disk persistence layer and the network.

• networkOnly: Never read or write persisted variants. Variant lookups always wait for the network call. Default; matches behavior prior to variant persistence. If a persisted blob exists from a previous session that used a persisting policy, it’s wiped on init.
• persistenceUntilNetworkSuccess(persistenceTtl:): Serve persisted variants immediately when available, refresh from the network in the background. Persisted entries older than persistenceTtl are ignored on read but NOT deleted (the next successful fetch overwrites them).
• networkFirst(persistenceTtl:): Prefer fresh values from the network, but fall back to persisted variants when the network call fails. Same TTL semantics as persistenceUntilNetworkSuccess.

TTL handling — non-positive persistenceTtl on a persisting policy is a misconfiguration. At SDK init the requested policy is run through effective(_:), which collapses any persisting policy with persistenceTtl <= 0 to .networkOnly (with a warning logged). Persistence-with-no-useful-TTL would write to disk on every fetch but never serve anything from disk, so the SDK substitutes the meaningful interpretation. The factories themselves don’t sanitize — they preserve exactly what the developer asked for so callers can introspect.

Convenience zero-argument forms persistenceUntilNetworkSuccess() / networkFirst() use defaultTTL (24 hours) — equivalent to passing persistenceTtl: VariantLookupPolicy.defaultTTL.