## Engineering terms: native apps

From Vibe Coding 101 (https://vibe-coding-101.brighteng.org/). When a request describes one of these problems, use the named technique, say its name, and run its check. Each term's page has the full entry and a prompt.

- **offline-first**: Design a useful local workflow that tolerates missing connectivity. Use when: Users need to keep reading or editing while disconnected. Do: Persist local intent, show pending state, and reconcile with the authoritative service when available. Avoid: Calling local data universally authoritative when the server must still enforce access or business rules.
- **deep link**: A deep link addresses a particular location or action in an application. Use when: A shared link should open a specific record or screen. Do: Parse and validate the target, preserve it across sign-in, and test app lifecycle states. Avoid: Using a link’s parameters as trusted commands or access permission.
- **safe area**: Safe-area insets describe regions where important content can remain unobscured by system UI or display features. Use when: Controls overlap the home indicator, cutout, or system bars. Do: Use the platform’s current inset information at the appropriate layout boundary. Avoid: Padding every nested container and creating unnecessary empty space.
- **navigation stack**: A navigation stack records a sequence of destinations. Use when: A multi-screen workflow loses its place when navigating back. Do: Model destinations and state ownership explicitly, including tab and modal boundaries. Avoid: Resetting navigation state on an unrelated view update.
- **push notification**: A push notification delivers an external event through a platform notification service. Use when: An app must notify users when it is not actively displaying the relevant screen. Do: Handle token changes, permission states, and payload validation; test notification entry paths. Avoid: Treating one device token as a permanent user identifier.
- **app lifecycle**: Applications move between active, inactive, background, and terminated states according to their platform. Use when: Returning to an app loses a draft or leaves stale work running. Do: Persist important intent promptly and define resume reconciliation without resetting unrelated UI state. Avoid: Depending on a final shutdown callback to save the only copy of user data.
- **OS permission**: Operating-system permissions mediate access to protected capabilities. Use when: A feature needs camera, location, files, or another protected resource. Do: Ask in context, explain the feature need, and provide usable denied and restricted states. Avoid: Looping the request when the OS will no longer show another prompt.
- **OTA update**: An over-the-air update replaces supported application assets or code without a full binary install. Use when: A deployed mobile app needs a compatible code or asset update. Do: Identify compatible runtimes and use a staged update with a recovery path. Avoid: Treating every source change as eligible for an OTA release.
- **main process vs renderer**: Desktop shells such as Electron separate privileged application work from the renderer. Use when: A desktop UI needs filesystem or operating-system access. Do: Keep privileged operations behind narrow validated messages and trusted process boundaries. Avoid: Exposing the entire filesystem or shell API through a convenience bridge.
- **IPC**: Inter-process communication exchanges data or requests between processes. Use when: A renderer or worker must request work from another process. Do: Expose specific operations, validate inputs at the receiving side, and preserve structured errors. Avoid: Assuming messages are trusted because both processes are part of the same application.
- **context isolation**: Electron context isolation separates the page’s JavaScript environment from privileged preload code. Use when: An Electron renderer needs a small amount of privileged integration. Do: Keep isolation enabled and expose only specific validated operations through the supported bridge. Avoid: Assuming context isolation alone supplies every sandbox or authorization property.
- **single instance**: Single-instance behavior routes subsequent launches to an existing application instance. Use when: Launching an app twice starts competing windows or local services. Do: Acquire the instance boundary early and handle subsequent activation messages explicitly. Avoid: Focusing the old window but discarding the new launch payload.
- **code signing**: Code signing binds an artifact to a signing identity and detects covered modifications. Use when: A native release must establish its publisher and artifact integrity. Do: Use the target platform’s release signing workflow and verify the final packaged artifact on that platform. Avoid: Checking a locally signed build while distributing a different unsigned package.
- **desktop auto-update**: Desktop auto-update retrieves and installs a new application release through a defined trust and lifecycle process. Use when: A shipped desktop app must update safely on user machines. Do: Use the framework’s supported updater and verify authenticity, failure handling, and user-data compatibility. Avoid: Letting untrusted renderer content choose the update source.
- **app sandbox**: An application sandbox restricts access to system resources. Use when: A native app needs protected resources without unrestricted system access. Do: Identify the smallest required access and test real signed builds with allowed and denied operations. Avoid: Assuming a remembered path always retains the operating system’s access grant.
- **webview**: A WebView embeds web content in a native application. Use when: A native app displays remote content alongside privileged local features. Do: Separate trusted application content from remote content and validate navigation and message origins. Avoid: Disabling web security to fix a request without understanding the boundary removed.
- **secure storage**: Use the platform’s protected storage for suitable credentials or keys. Use when: An application must retain a credential between launches. Do: Choose the protected storage API and lifecycle policy, then test access and deletion. Avoid: Keeping a second plaintext copy in preferences, diagnostics, or a migration file.
- **app link**: A verified app link associates an HTTPS domain with an application through platform verification. Use when: Shared web URLs should open an installed app when the platform permits. Do: Configure the association and test platform verification, installed and uninstalled behavior, and cold start. Avoid: Testing only an in-app URL handler while the OS association file is unreachable.
- **background execution**: Background execution uses the operating system’s supported scheduling or execution model. Use when: Work needs to resume or complete despite application suspension. Do: Choose the platform mechanism and checkpoint work so it tolerates interruption. Avoid: Assuming a background scheduling request guarantees an exact start time.
- **adaptive layout**: An adaptive layout responds to available space and presentation context. Use when: A phone layout becomes unusable in a tablet pane or resized window. Do: Use current layout constraints and test transitions between narrow and wide presentations. Avoid: Measuring size once at launch and treating it as permanent.
- **in-app purchase**: In-app purchases exchange a store transaction for a defined entitlement. Use when: An application unlocks paid content or a subscription. Do: Follow the store’s supported verification path and handle restore, renewal, expiry, and revocation. Avoid: Granting permanent access from an unverified local premium flag.
- **build variant**: A build variant selects a deliberate combination of configuration and packaging. Use when: Testing must use different services or identity without changing the production app. Do: Define variant-specific identity, configuration, and signing, then inspect the produced artifacts. Avoid: Assuming different display names alone create separate installed applications.
- **dynamic type**: Dynamic Type adapts text to the user’s preferred size on Apple platforms. Use when: A native screen clips text at accessibility sizes. Do: Use supported text styles and flexible layout, then test the largest relevant sizes. Avoid: Disabling font scaling to preserve a screenshot’s original layout.
- **biometric authentication**: Biometric authentication can authorize a local operation through the operating system. Use when: A sensitive local action needs device-user verification. Do: Use the platform authentication and key-access policy with explicit fallback and invalidation behavior. Avoid: Showing a biometric prompt while the protected key remains accessible without it.
- **sync conflict**: A synchronization conflict occurs when changes cannot be combined safely under the chosen policy. Use when: Two offline or concurrent editors change the same record. Do: Track versions or the required causal information and choose merge, rejection, or user resolution. Avoid: Showing a conflict message after one version has already been discarded.