Shop Minis update: optional consent, intents, storage limits, and migration guidance for partners

Table of Contents

1. Key Highlights:
2. Introduction
3. Optional consent: move from blocking to graceful degradation
4. Intents: contextual launches and a new distribution channel
5. Storage limits and migration: what to change and why
6. Product hooks, commerce buttons, and inventory awareness
7. Tooling, packages, and compatibility
8. Security and privacy: permission handling and secure storage
9. Testing, QA, and rollout practices
10. Migration plan and practical checklist
11. Partner distribution and product strategy: intents as a growth lever
12. Real-world example scenarios
13. What these changes mean for developers
14. FAQ

Key Highlights:

• Optional consent replaces all-or-nothing scopes: three new hooks let Minis check and re-request scopes and OS permissions, with a new request_blocked sentinel to differentiate states.
• Intents introduce contextual launches (try_on, view_in), creating distribution opportunities where buyer intent is highest; useIntent parses the launch context.
• Async storage limits (10 keys, 1 MB per key), deprecation of localStorage/sessionStorage in webviews, TypeScript 6, pnpm support, and updated ESLint rules require immediate developer action.

Introduction

Shopify’s Shop Minis platform introduces several changes that reshape how Minis request user permissions, store data, and integrate with the Shop app’s contextual experiences. Optional consent replaces the previous all-or-nothing scope model and brings three runtime hooks that let a Mini detect granted scopes, re-prompt users at the right moment, and check OS-level permissions such as camera access. Intents allow the Shop app to launch Minis from product pages and other high-intent contexts, expanding distribution opportunities beyond the Explore tab. New limits for Async and Secure storage, plus a ban on localStorage and sessionStorage in the webview, require apps to change persistence patterns. Tooling updates include pnpm support in the CLI, a TypeScript 6 SDK build, and ESLint rules that block phantom dependency imports.

This article explains each change, shows how to implement the new hooks and patterns, outlines migration steps for existing Minis, and offers practical UX and testing guidance so partners can update quickly and safely.

Optional consent: move from blocking to graceful degradation

Shop Minis must now handle users declining specific scopes. Consent is optional: if a user rejects a scope, the Mini should continue to function with reduced capabilities rather than failing outright. The platform provides three main hooks to let Minis adapt at runtime: useCheckScopesConsent, useRequestScopesConsent, and useCheckPermissions.

Why this matters

• Better user experience: Users gain fine-grained control over what a Mini can access. Minis that respect declined scopes retain more sessions and reduce abandonment.
• Developer responsibility: Apps that previously assumed scopes would always be granted must now implement conditional flows and fallbacks.

useCheckScopesConsent: detect granted scopes at runtime The useCheckScopesConsent hook lets a Mini determine which Shop API scopes the user has granted. Use the returned scopes array to conditionally render features that depend on specific permissions.

Example:

import {useCheckScopesConsent} from '@shopify/shop-minis-react'

function MyMini() {
  const {scopes} = useCheckScopesConsent()

  if (scopes.includes('product_lists:write')) {
    return <SaveToListButton />
  }

  return <SignInPrompt />
}

Practical UX patterns

• Feature gating: Hide or replace UI elements that require a declined scope. For example, offer a simplified flow (e.g., a manual save) when product_lists:write is not present.
• Progressive disclosure: Show a subtle affordance explaining the benefit of granting a scope and provide a clear call-to-action to enable it.
• Telemetry: Log which features are unavailable due to declined scopes to guide product decisions and prioritize where re-requesting consent makes most sense.

useRequestScopesConsent: re-prompt on direct user action Apps may re-request a scope only from a direct user interaction, not automatically. useRequestScopesConsent returns a requestScopesConsent function to invoke when a user performs a clear action that would unlock a capability.

Example:

import {useRequestScopesConsent} from '@shopify/shop-minis-react'

function GrantAccessButton() {
  const {requestScopesConsent} = useRequestScopesConsent()
  return (
    <button onClick={() => requestScopesConsent(['product_lists:write'])}>
      Enable saving products
    </button>
  )
}

Design guidance for re-prompt flows

• Tie re-requests to intent: Call requestScopesConsent only in contexts where the user clearly expects an outcome (e.g., "Save to a list" button).
• Provide context: Explain what the scope enables and reassure about privacy. Keep copy concise and directly connected to the action the user took.
• Avoid repeated prompts: If a user declines repeatedly, offer alternative flows rather than repeatedly asking for the same scope. The request_blocked sentinel (explained below) helps detect blocked states.

useCheckPermissions: OS-level permissions useCheckPermissions checks platform permissions such as camera and photo library access. This differs from scopes, which grant access to Shop APIs. Permissions are requested and controlled by the operating system; Minis must check their states before invoking the related features.

Example:

import {useCheckPermissions} from '@shopify/shop-minis-react'

function CameraFeature() {
  const {permissions} = useCheckPermissions(['camera'])

  if (permissions.camera === 'granted') {
    return <CameraView />
  }

  return <RequestCameraButton />
}

User flow best practices

• Check before showing a camera UI to avoid abrupt denial states.
• Use clear affordances that describe why the permission is required and what will happen after granting it.
• Provide a fallback for denied permissions: let users upload an image instead of capturing one, or offer a manual configuration route.

request_blocked sentinel: distinguishing "not asked" from "blocked" When a user has declined a scope or permission and the platform will not re-prompt (for example, the user blocked future prompts), hooks return request_blocked rather than null. This lets the Mini detect whether the platform can still prompt and adjust UI and flows accordingly.

How to use request_blocked

• If permissions === 'request_blocked', show a discrete help message with instructions for re-enabling the permission in system settings.
• Offer alternatives: If a camera permission is blocked, present an image upload option.
• Avoid prompting: If state is request_blocked, do not attempt to call the re-request hook; instead guide users to settings or provide alternative workflows.

Example handling:

if (permissions.camera === 'granted') {
  // normal flow
} else if (permissions.camera === 'request_blocked') {
  // show instructions to enable camera in system settings
} else {
  // not asked yet or denied but re-promptable: show request button
}

State machine and testing Shopify documents a full state machine for scopes consent: granted, declined (and re-promptable), and request_blocked (declined and blocked). Test all states during QA: simulate grant, decline with re-prompt available, and decline with request_blocked. On Android and iOS, behaviors can differ because OS-level permission UIs and the Mini webview might treat prompts differently.

Intents: contextual launches and a new distribution channel

Intents let the Shop app launch a Mini from contextually relevant moments and pass the launch context. That transforms where and when Minis appear: they no longer rely solely on the Explore tab for discovery. Intents are most useful when Minis enhance a specific product or scene, such as virtual try-on or AR room placement.

Supported intents today

• try_on: Virtual try-on Minis for clothing, accessories, eyewear, hats — anything wearable.
• view_in: AR room-placement Minis for furniture, decor, and any product that benefits from visualization in a space.

How intents change distribution

• Surface Minis at points of purchase intent: A shopper viewing a product detail page is likely closer to conversion than a casual explorer. Being invoked at that moment increases engagement and conversion potential.
• Drive contextual experiences: A Mini launched with a product context can immediately present a tailored experience, removing the need for onboarding steps.

useIntent: parse launch context and route experiences useIntent returns an intent object containing the action and contextual data such as productId. Use it to route the user to the correct UI within the Mini.

Example:

import {useIntent} from '@shopify/shop-minis-react'

function MyMini() {
  const intent = useIntent()

  if (intent?.action === 'try_on') {
    return <TryOn productId={intent.productId} />
  }

  return <DefaultExperience />
}

Typical intent payloads and routing

• productId: the identifier for the product that launched the Mini.
• Contextual attributes: possible fields include variant information, images, or preselected options when available.
• Fallback: Always provide a default experience if the payload is missing or incomplete.

Implementation examples

Try-on flow (eyewear)

• Launch: User taps "Try on" on a product detail page.
• Payload: intent.action = 'try_on', productId, image assets for frames.
• Flow: Open camera overlay, auto-align based on face-detection models, render frames scaled to face dimensions, allow switching variants.
• Fallback: If camera permission is denied, allow the user to upload a selfie.

Room-placement flow (furniture)

• Launch: User taps "View in your room."
• Payload: intent.action = 'view_in', productId, AR model URL.
• Flow: Load AR model into SceneKit/ARCore view, allow scaling and placement, snapshot sharing.
• Fallback: Provide 2D visualizer with dimensions and room mockups if AR support is unavailable.

Design considerations for intent-powered Minis

• Fast start: Use the passed context to reach the primary interaction within 1–2 screens. Users come with intent; minimize friction.
• Explicit actions: Where a scope or permission is required, tie the request to the action that requires it (e.g., "Enable camera to try on").
• Telemetry: Capture intent origin events to analyze which contexts drive the most engagement and adjust placement or creative accordingly.

Partner onboarding and custom intents Shop Minis currently supports try_on and view_in. Partners with different use cases (recipe builders, gift finders, configurators) should contact the Shop Minis team to discuss onboarding and new intent support. Early conversations can help define a launch-context contract and expected payloads.

Storage limits and migration: what to change and why

To keep Minis fast and predictable, the platform places limits on persistent storage provided through the SDK:

• 10 keys max per Mini
• 1 MB max per key

Browser localStorage and sessionStorage are no longer permitted in the Mini webview. On Android they are disabled; on iOS they are reset between sessions. The partner ESLint config flags use of localStorage and sessionStorage.

Storage intent and design Async storage is intended for small structured data such as settings, short JSON blobs, and small tokens. Larger assets like images, audio, or video must be uploaded to a backend or uploaded via an SDK upload hook and stored as a URL.

Strategies to fit the limits

• Denormalize and compress: Combine small related items into a single JSON object keyed by purpose. For example, store app configuration in a single "settings" key rather than multiple keys.
• Limit key count: Plan keys carefully. Use namespaced keys like "user:profile" or "product:recentViews". Avoid per-item keys for large lists; instead, store arrays of ids and fetch details on demand.
• Chunking and external storage: For objects near the 1 MB limit, move binary blobs to a CDN or upload service and store the URL in Async Storage.
• Secure storage for secrets: Use useSecureStorage for tokens, refresh tokens, or other sensitive data. Note that useSecureStorage counts toward key and size limits.

Migration checklist from localStorage/sessionStorage

1. Audit code: Search for localStorage and sessionStorage usage across the codebase.
2. Identify purpose: For each use, decide whether to convert to useAsyncStorage, useSecureStorage, server-side storage, or ephemeral in-memory state.
3. Replace calls: Migrate getItem/setItem/removeItem to the Async/Secure storage hooks. These hooks are asynchronous and typically return Promises, so handle await/async or hook-based patterns.
4. Consolidate keys: Where multiple keys are used, combine them into a single object that fits under the 1 MB key-size limit.
5. Re-run ESLint: The Shop Minis partner ESLint config flags deprecated storage usage. Ensure the codebase is lint-clean.
6. Test persistence across sessions: On iOS and Android, verify that values persist as expected and that sensitive data resides in secure storage.

Example migration Before:

localStorage.setItem('cartItems', JSON.stringify(items))
const items = JSON.parse(localStorage.getItem('cartItems') || '[]')

After:

import {useAsyncStorage} from '@shopify/shop-minis-react'

function useCart() {
  const {getItem, setItem} = useAsyncStorage()

  async function save(items) {
    await setItem('cartItems', JSON.stringify(items))
  }

  async function load() {
    const raw = await getItem('cartItems')
    return raw ? JSON.parse(raw) : []
  }

  return {save, load}
}

Handling large datasets

• Avoid storing long histories or caches in Async Storage. Instead, store a cursor or IDs and fetch details on demand.
• For offline-first needs that require larger local storage, consider using a specialized storage provider or service that integrates with your backend and returns a URL for downloaded assets.

Performance and UX trade-offs Storing many large keys can increase startup time if you eagerly load everything. Implement lazy loading for non-essential keys, and prefer streaming or paged fetches for large lists. Use caching strategies that respect the storage limits and clear stale data regularly.

Product hooks, commerce buttons, and inventory awareness

Product hooks now expose availableForSale on product variants. The SDK’s commerce buttons (AddToCartButton and BuyNowButton) automatically handle out-of-stock variants, reducing the need for custom checks in common flows.

How availableForSale changes behavior

• Use it to disable or label variants that are out of stock, preventing add-to-cart attempts.
• For custom commerce flows, check availableForSale before rendering an actionable control. Buttons provided by the SDK already respect this state.

Example:

function VariantCard({variant}) {
  if (!variant.availableForSale) {
    return <div className="sold-out">Sold out</div>
  }

  return <AddToCartButton variantId={variant.id} />
}

Edge cases

• Inventory updates during sessions: If inventory can change during the user session, refresh variant availability on important actions like checkout or add-to-cart.
• Pre-orders and backorder workflows: If your product supports pre-ordering or backorder, treat availableForSale as an inventory marker and show the appropriate CTA (e.g., "Pre-order" or "Notify me").

Testing guidance

• Simulate inventory toggles in your staging environment to verify UI changes and button states.
• Validate checkout flows with both in-stock and out-of-stock variants to ensure proper error handling and messaging.

Tooling, packages, and compatibility

The CLI and SDK changes affect local development, dependency management, and TypeScript compatibility.

pnpm support npx minis create now detects pnpm and supports it alongside npm and yarn. When prompted by the CLI, select pnpm to scaffold projects that use pnpm’s lockfile and workspace features.

Practical notes for pnpm users

• CI adjustments: Ensure your CI uses pnpm install instead of npm ci or yarn install where appropriate.
• Peer dependency behavior: pnpm’s stricter peer dependency rules may expose unresolved peers; add required peer deps to package.json or resolve them via pnpm overrides.

SDK and package versions

• @shopify/shop-minis-platform: 0.17.0
• @shopify/shop-minis-react: 0.20.0
• @shopify/shop-minis-cli: 0.3.11

TypeScript 6 The SDK now targets TypeScript 6.0.2 (previously 5.8.3). Upgrading projects should:

• Update TypeScript to at least 6.0.2.
• Address new compiler errors or stricter type checks caused by TS6 improvements.
• Review tsconfig interactions with third-party typings.

ESLint and phantom dependency imports The partner ESLint config now flags imports of packages not declared in package.json. This prevents accidental reliance on transitive dependencies that may break in production.

Allowed transitive SDK deps Certain transitive dependencies are now explicitly available: clsx, tailwind-merge, and cva. Using these inside your Minis is permitted without declaring them as direct dependencies.

Migration recommendations

• Lock dependency versions: Use a package manager lockfile and CI to ensure consistent installs.
• Audit imports: Ensure all imported packages appear in package.json.
• Update TypeScript and fix type regressions: Use the compiler output to identify and fix issues.

Security and privacy: permission handling and secure storage

Permissions and consent are privacy-sensitive. The platform changes place responsibility on Minis to request permissions transparently and avoid abusing re-prompting.

Principles to follow

• Least privilege: Request only the scopes and permissions necessary for the feature.
• Action-driven requests: Only re-prompt from a direct user action that clearly benefits from the permission.
• Clear consent copy: Explain briefly why a permission is needed and how it improves the experience.
• Secure secrets: Store tokens and credentials in useSecureStorage, not Async Storage.

Handling permission denials and request_blocked

• When request_blocked appears, guide users to system settings rather than attempting to re-prompt.
• Provide alternative flows where possible to avoid blocking users who refuse permissions.

Data minimization and retention

• Avoid storing unnecessary user data in persistent storage.
• If you must store personal data, use encrypted secure storage and respect the platform’s storage limits.
• Implement data deletion routines: allow users to clear stored data and ensure secure removal.

Regulatory considerations

• For Minis operating in regions with strict privacy laws, ensure data collection and consent flows meet legal requirements, e.g., provide a privacy notice when collecting personal data and implement mechanisms for users to request deletion where required.

Testing, QA, and rollout practices

Comprehensive testing is essential to catch edge cases introduced by optional consent, permissions, and storage rules.

Test matrix

• Scopes: granted, declined (re-promptable), request_blocked.
• Permissions: granted, denied, request_blocked, not_asked.
• Storage: over-limit scenarios (simulate attempts to write a >1MB key), key count overflow (more than 10 keys).
• Intents: try_on and view_in with complete and partial payloads; missing productId; malformed payloads.
• Browser storage deprecation: confirm localStorage and sessionStorage are flagged by ESLint and do not persist across sessions.

Automated tests

• Unit tests: Mock useCheckScopesConsent, useRequestScopesConsent, useCheckPermissions, and useIntent to assert UI behavior for each state.
• Integration tests: Use device farms or emulators to test permission prompts and AR/camera flows on iOS and Android.
• End-to-end tests: Simulate the full user flow from a product page launch into the Mini via intent.

Rollout recommendations

• Feature flags: Use a server-side or config-based feature flag to enable new flows incrementally.
• Beta testers: Invite a group of power users to try Minis with permissions and intents enabled, collect feedback, and iterate.
• Telemetry: Capture consent and permission metrics to measure friction points and identify which features are frequently affected by declined scopes.

Debugging tips

• Log consent and permission states, but avoid logging sensitive data.
• Reproduce request_blocked by repeatedly declining prompts or disabling prompts via system settings.
• Test on both Android and iOS devices because webview behavior and OS permission flows differ.

Migration plan and practical checklist

A concrete step-by-step plan will speed adoption and reduce regressions.

Phase 1 — Audit and inventory

• Search for localStorage and sessionStorage usage.
• List all scopes requested by your Mini and map them to features.
• Identify where OS-level permissions are requested (camera, photos, microphone).
• Count Async/Secure storage keys and estimate per-key sizes.

Phase 2 — Replace deprecated APIs

• Migrate localStorage/sessionStorage to useAsyncStorage or useSecureStorage as appropriate.
• Consolidate keys to respect the 10-key and 1 MB per key limits.
• Update code to use useCheckScopesConsent to gate features.
• Add requestFlows: replace automatic re-prompts with explicit user-initiated calls to requestScopesConsent.

Phase 3 — Add fallbacks and UX

• Implement graceful degradation for features that rely on declined scopes.
• Add alternative flows for blocked permissions (upload instead of camera capture).
• Add clear, concise consent messaging tied to user actions.

Phase 4 — Integrate intents

• Implement useIntent parsing and route to the correct Mini experience.
• Support try_on and view_in where relevant; contact the Shop Minis team for custom intents.
• Validate payloads and add robust fallback behavior.

Phase 5 — Update tooling

• Upgrade TypeScript to 6.0.2 and fix type regressions.
• Ensure package.json lists all dependencies used, and run ESLint to catch phantom imports.
• If using pnpm, switch CLI prompts and CI to use pnpm install.

Phase 6 — Test and ship

• Run the full test matrix described above.
• Deploy behind a feature flag.
• Monitor telemetry for consent and permission declines, storage errors, and conversion metrics.

Partner distribution and product strategy: intents as a growth lever

Intents make it possible to surface Minis when shoppers are actively considering specific products. That changes how Mini creators should think about distribution and product-market fit.

Use cases that benefit most

• Virtual try-on: Eyewear, jewelry, shoes, hats.
• AR room visualization: Furniture, lighting, decor.
• Configurators and customizers: Allowing immediate preview of customized products during browsing.
• Gift finders and recipe builders: Contextual recommendations related to the product being viewed.

Measuring success

• Engagement uplift: track session starts triggered by intents vs. Explore tab launches.
• Conversion lift: measure add-to-cart and conversion rates for users who used the Mini vs. those who did not.
• Retention: evaluate whether users return to the Mini after an initial experience started via intent.

Go-to-market playbook

• Start with high-intent placements: prioritize PD pages and checkout-adjacent contexts where customers are decision-ready.
• Optimize the first interaction: rapid loading and minimal permissions friction increase chances a user completes the intended action.
• Collaborate with brands: product pages with good photography and properly curated assets increase Mini success.
• Onboard early: contact the Shop Minis team to discuss additional intents or special integrations.

Real-world example scenarios

Example 1 — Sunglasses try-on Mini

• Intent: try_on launched from product page.
• Flow: useIntent reads productId and variant image URLs. Mini checks for camera permission via useCheckPermissions. If granted, open camera overlay and render frame overlays; if request_blocked, show instructions and a "Upload selfie" button. If the user wants to save a look, request product_lists:write using requestScopesConsent tied to the "Save look" button.

Example 2 — Rug visualizer AR Mini

• Intent: view_in launched from a living-room product detail.
• Flow: useIntent receives productId and AR model URL. Check camera and AR permissions. Load the AR model and let the user place it in the scene. If AR is unsupported or blocked, present a 2D room mockup with a scaled overlay and provide approximate measurements.

Example 3 — Gift-finder configured via Mini

• Intent: custom gift_finder (partner-requested, not yet standard).
• Flow: Partner coordinates with the Shop Minis team to add the intent. Mini receives context about recipient categories or a base product that shaped the gift idea, then walks the user through configurable filters to find matches. Scopes for product lists may be requested only when the user chooses to save or share.

What these changes mean for developers

The platform updates prioritize user control, predictable performance, and contextual relevance. Developers must adapt to optional consent flows, implement permission-aware UX, respect new storage constraints, and roll out changes carefully. Minis that adopt these patterns will see fewer failed sessions, higher conversion from contextual launches, and better compliance with platform expectations.

Immediate priorities

• Replace localStorage/sessionStorage usage and consolidate Async Storage keys.
• Add conditional rendering based on useCheckScopesConsent and useCheckPermissions.
• Use requestScopesConsent only on explicit user actions and handle request_blocked gracefully.
• Implement useIntent routing to take advantage of high-intent launches.

Longer-term opportunities

• Use intents to place Minis at moments of peak buyer intent.
• Leverage telemetry to optimize where and how Minis ask for consent.
• Experiment with custom intents for specialized workflows through the Shop Minis team.

FAQ

Q: What happens if a Mini still hard-fails when a scope is declined? A: The platform expects Minis to handle declined scopes gracefully. If a Mini hard-fails, partners should update the Mini to use the new hooks and implement fallbacks. The platform may flag Minis that block the experience when consent is declined.

Q: Can I re-prompt for a scope automatically? A: No. Re-requests must be triggered by a direct user interaction. The useRequestScopesConsent hook must be called from a user-initiated event (a button click, for example).

Q: How does request_blocked differ from null? A: request_blocked indicates the platform will not re-prompt the user for that scope or permission. null indicates the state is unknown or not asked yet. Use request_blocked to provide instructions for enabling permissions in system settings or to show alternative flows.

Q: Do I need to change how I handle camera and photo permissions? A: Yes. Use useCheckPermissions to determine the OS-level permission state before presenting camera UIs. Provide alternative flows (upload from library) when permissions are denied or blocked.

Q: How strict are the storage limits? A: Async and Secure storage limits are enforced: 10 keys per Mini, 1 MB per key. These limits are intended for small structured data. Store larger assets externally and save URLs.

Q: What should I do about localStorage and sessionStorage usage in my Mini? A: Replace them with useAsyncStorage or useSecureStorage. The ESLint config flags browser storage usage. Audit the codebase, migrate storage calls to the SDK hooks, and consolidate keys to fit the new limits.

Q: Which intents are supported today and how do I use them? A: try_on and view_in are supported now. Implement useIntent to read the action and context passed by the Shop app and route users to the appropriate experience. Contact the Shop Minis team to request new or custom intents.

Q: Will the SDK changes break existing Minis? A: Breaking changes should be limited if Minis do not rely on forbidden APIs like localStorage and they handle scope declines gracefully. However, update TypeScript to 6.0.2 if your project uses TypeScript to avoid type incompatibilities. Test thoroughly, particularly around permission and consent flows.

Q: How should I handle out-of-stock variants? A: Product hooks expose availableForSale on variants. Use the SDK-provided commerce buttons (AddToCartButton, BuyNowButton) where possible; they already handle out-of-stock states. For custom flows, check availableForSale before allowing adds to cart.

Q: Is pnpm required? A: No. The CLI now detects and supports pnpm, npm, and yarn. Choose pnpm if it fits your workflow; update CI and local developer docs accordingly.

Q: What about phantom dependencies flagged by ESLint? A: Ensure all imported packages are declared in package.json. The partner ESLint config blocks imports of packages not declared. Allowed transitive SDK deps—clsx, tailwind-merge, cva—are explicitly available.

Q: Who should I contact to request a custom intent? A: Reach out to the Shop Minis team. Partners can discuss new use cases and onboarding for additional intents.

Q: How should I test request_blocked flows on devices? A: On Android and iOS, simulate denying and blocking permission prompts. For scopes, simulate declines and blocked states if your staging environment supports them. Build unit tests that mock the hook return values, and perform integration tests on device farms to verify real-world behavior.

Q: What is the recommended UX for re-requesting a scope? A: Tie re-requests to an explicit user action that clearly benefits from the permission. Keep prompt copy concise, explain the immediate benefit, and avoid repeated or nagging requests.

Q: Are there performance considerations tied to the new storage limits? A: Yes. Eagerly loading large keys can increase startup time. Use lazy loading and keep keys small to ensure Minis remain fast. Move large blobs off-device and store URLs instead.

Q: Do these changes affect GDPR or other privacy requirements? A: The changes reinforce privacy best practices—least privilege and explicit consent. Ensure that your data collection, retention, and deletion practices comply with applicable regulations; treat these SDK changes as an opportunity to align with legal obligations.

Q: Where can I find official documentation about these features? A: The Shop Minis documentation on shopify.dev has updated pages for Scopes Consent, Intents, and the relevant hooks: useCheckScopesConsent, useRequestScopesConsent, useCheckPermissions, useIntent, useAsyncStorage, and useSecureStorage. Consult the docs for complete state diagrams and implementation details.

Q: What should I prioritize in the next release of my Mini? A: Replace browser storage usage, implement useCheckScopesConsent and useRequestScopesConsent for scope-driven features, implement useCheckPermissions for OS-level features, ensure graceful degradation, and add intent handling for contextual launches where relevant.

---

These platform updates give Minis clearer paths to reach users at moments of high intent while strengthening privacy, security, and performance guarantees. Address the migration checklist, apply the UX patterns for permission handling, and leverage intents where the Mini's value is most visible to fully take advantage of the new capabilities.