Fix daily check persistence after successful lookup

[HituziANDO]

Summary

• Record daily version checks only after the App Store returns a valid version
• Keep failed lookups eligible for another check on the same day
• Extract daily scheduling behind replaceable clock and state-store dependencies
• Record review scheduling dates as StoreKit request attempts and document the behavior
• Add deterministic coverage for success, failure, date transitions, and review attempts

Root cause

Daily conditions persisted the current date while evaluating eligibility, before the asynchronous App Store lookup completed. A failed lookup therefore consumed the daily allowance until the next day. Review conditions used the same combined evaluation-and-mutation pattern, which obscured that StoreKit only confirms a request attempt rather than presentation.

Impact

The existing public condition types remain source-compatible. Daily and launching-and-daily conditions now share the same transition rules, failed lookups remain retryable, and scheduling behavior can be tested without external services or the system clock.

Validation

• Mac Catalyst test suite: 21 tests passed
• Generic iOS framework build passed
• Native macOS framework build passed
• SwiftFormat 0.53.7 applied
• Xcode project file validation passed

Closes #14

[Copilot]

Pull request overview

This PR fixes daily scheduling persistence so daily version-check conditions only record a date after a successful App Store lookup (and review conditions record attempt dates), by extracting scheduling behind injectable clock/state-store dependencies and adding deterministic unit tests.

Changes:

• Introduces DailySchedule with injectable SUKClock and SUKSchedulingStateStore, plus an execution gate for concurrent version-check lookups.
• Updates version-check and review-request conditions to separate eligibility evaluation from recording success/attempts; updates SUK to record success only after a valid lookup response.
• Adds scheduling-focused unit tests and documents the new persistence behavior in the README.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
README.md	Documents updated daily scheduling semantics for version checks and review attempts.
Framework/SwiftyUpdateKitTests/SwiftyUpdateKitTests.swift	Adds deterministic tests covering success/failure, day transitions, concurrency, and review attempts.
Framework/SwiftyUpdateKit.xcodeproj/project.pbxproj	Adds DailySchedule.swift to Xcode project build phases.
Framework/Sources/VersionCheckCondition.swift	Adds success-recording + execution-control protocols; updates daily conditions to use DailySchedule.
Framework/Sources/SUK.swift	Refactors version check flow to inject lookup dependency and record success post-lookup; centralizes review-request attempt recording.
Framework/Sources/RequestReviewCondition.swift	Updates review conditions to use DailySchedule and record attempt dates.
Framework/Sources/ITunesSearchAPI.swift	Introduces AppStoreLookup abstraction and default ITunesAppStoreLookup.
Framework/Sources/DailySchedule.swift	New scheduling abstraction for daily eligibility, persistence, and execution gating.
.github/workflows/ci.yml	Updates CI simulator destination.

Suppressed comments (1)

Framework/Sources/SUK.swift:346

• When the App Store response is missing a version, this branch returns without calling next(nil). That leaves callers with no completion signal (similar to the failure case), so noop/newRelease logic may never run on invalid payloads.

                              let storeVersion = lookUpResult.version
                        else {
                            // Ignore an error.
                            logf("version does not exist in the response data.", log)
                            executionController?.finishVersionCheck()

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.