Sandbox and App Store review

Flick executes JavaScript inside your app. Your compiled Swift code defines the app actions, observable state, and view inputs available to it. Publishing a Flick changes the JavaScript running against that interface.

Define the native capabilitiesCopy Anchor Link

The Quick start declares a counter action, a counter value, and a named view:

import FlickSDK

@FlickScope(url: "https://acme-corp.com")
enum MyApp {
    enum Action {
        @FlickAction(failure: Never.self)
        case increment
    }

    enum State {
        case count(Int)
    }

    enum Views {
        struct Card: Codable, Sendable {
            let title: String
        }
    }
}

The generated TypeScript API describes these declarations. Your Swift handlers implement the behavior, and your observations choose which values to publish:

.taskForFlick(for: \.increment) {
    count += 1
}
.observeForFlick(count, for: \.count) {
    Flick.Publish($0)
}

A Flick opened through the control can display count differently or invoke increment twice; it still runs this Swift handler. Writing state requires a Swift set: closure, as shown in Publish state.

Adding a new Swift action implementation or native bridge requires rebuilding the app. A fixed capability boundary still permits changing behavior through existing capabilities.

Access depends on where the Flick runsCopy Anchor Link

Flicks opened through the Flick control use its selected context. The SDK restricts action dispatch and state access to that context and the execution’s declared capabilities.

Handlers and observations must be registered in the mounted SwiftUI hierarchy. Required capabilities must be available when execution starts. Closing the selected scope or losing a required capability ends the execution.

A published named view such as Flick(.card, title: "Hello") receives its explicit inputs. It does not inherit the host’s action and state registry. Rendering and other installed SDK bridges are separate from this registry.

Use the control-based examples in Expose actions and Publish state for access to app actions and state.

These checks happen in the native runtime. Generated TypeScript types help authors use the interface correctly; runtime checks enforce access to the app’s registered actions and state.

App Store reviewCopy Anchor Link

Explain both the compiled interface and the behavior of downloaded content in your review notes. Include the SDK’s native rendering and bridges as well as the actions and state your app exposes.

Apple’s App Review Guidelines apply to the complete app and the software it offers:

1. 2.5.2 restricts downloaded code that introduces or changes app functionality.
2. 4.7 permits specified kinds of software outside the binary, with additional requirements for privacy, moderation, purchases, and age restrictions.
3. 4.7.2 requires prior Apple permission to expose native platform APIs or technologies to that software.
4. 4.7.3 requires explicit user consent in each instance before sharing data or privacy permissions with individual software.
5. 4.7.4 requires an index with metadata and universal links to the software offered.

The compiled interface and runtime limits on app actions and state explain the capability boundary. They do not establish App Store approval or exempt changing content from review requirements.

Auditing publicationsCopy Anchor Link

The proposed publication transparency log would record every publication to a view address with its content hash and timestamp. Reviewers could inspect versions and verify the recorded history.

This log requires design and implementation. Current publication history does not provide that public, tamper-evident guarantee.