Snowflake Native Apps

A good app begins with the right split between data, logic and interface. You turn a provider’s product idea into components, decide what ships and what is requested from the consumer, and record the reasons.

• Gathering requirements from a provider’s product
• Data, logic and interface: what ships in the app
• Container and compute components inside an app
• Privileges the app needs from consumers
• Availability across regions and clouds
• Writing the architecture as a decision record

You build An architecture proposal for a Native App with components, privileges and trade-offs.

The manifest is the contract between an app and Snowflake. You write manifest.yml with its required fields, declare artifacts, privileges and references, and validate it before it causes an install to fail.

• manifest.yml structure and required fields
• Declaring artifacts: setup script, readme and interface
• Declaring privileges the consumer must grant
• Declaring references to consumer objects
• Configuration and version fields
• Validating a manifest and common mistakes

You build A manifest for a sample app declaring its files, privileges and references.

The setup script builds the app inside the consumer’s account, on install and again on every upgrade. You create application roles and versioned schemas, write idempotent statements, and test that it runs cleanly twice.

• What runs at install and upgrade time
• Application roles and schemas
• Versioned schemas for safe upgrades
• Creating objects idempotently
• Granting access to application roles
• Test-running a setup script

You build A setup script that creates versioned schemas and roles and installs cleanly twice.

The logic is what consumers actually use. You expose procedures and functions as the app’s interface, work with the app’s own privileges and consumer data through references, add a Streamlit page and log events for support.

• Procedures and functions as the app’s interface
• Using the app’s own privileges for its own data
• Using consumer data through references
• A Streamlit interface inside the app
• Containers and external access when needed
• Logging to event tables

You build A working app with procedures, a Streamlit page and logging to an event table.

Bugs found by consumers are expensive. You develop with the Snowflake CLI, install from a stage in development mode, read logs, test as a consumer with limited privileges, and check upgrades from older versions.

• Developing locally with the Snowflake CLI
• Installing from a stage in development mode
• Reading logs and events
• Testing as a consumer with limited privileges
• Testing upgrades from an older version
• Automating app tests

You build A test routine that installs, exercises and upgrades an app in a development account.

Releasing is more than uploading code. You add versions and patches to a package, use release directives to decide who gets which version, roll out to selected accounts first, and manage the privileges that control releases.

• Versions and patches: when to use each
• Adding a version to an application package
• Release directives and who gets which version
• Staged rollout to selected consumer accounts
• Release management privileges
• Deprecating an old version

You build A release plan with versions, patches and a staged rollout to selected accounts.

Getting an app in front of consumers has its own steps. You create a listing, prepare documentation, respond to security review findings, and control where and to whom the app is available.

• Creating a listing for an application package
• Security review and what it checks
• Public and private listings
• Documentation for consumers
• Responding to review findings
• Controlling availability by region

You build A listing and documentation pack for an app, ready for review.

You see the product through the consumer’s eyes. You install an app, read and grant its privilege requests, bind references to local objects, and watch how upgrades arrive and what happens when one fails.

• Installing an app and granting its privileges
• Binding references to consumer objects
• How upgrades arrive
• When an upgrade fails and what that leaves behind
• Consumer-side configuration
• Uninstalling cleanly

You build An install and upgrade walkthrough from the consumer’s side, explaining every privilege prompt.

Support is part of shipping. You diagnose failed installs and upgrades, trace privilege and reference problems, collect only the information a consumer has agreed to share, and write runbooks for common failures.

• Reading event logs shared by consumers
• Diagnosing failed installs and upgrades
• Privilege and reference problems
• Gathering information without seeing consumer data
• Support runbooks for common failures
• What telemetry a provider may collect

You build A support runbook covering the common install and upgrade failures.

You carry one app from requirements to a released, supported version: architecture, manifest, setup script, logic, tests, versioning and a listing. Then you walk through what a consumer would experience.

• Scoping the app and its consumers
• Building the manifest, setup script and logic
• Testing installs and upgrades
• Releasing a version with a listing
• Walking through the consumer’s experience

You build A released Native App with a manifest, tests, release plan and support notes.