BYOK Web App vs Native App: What Changes?

A BYOK web app and a native BYOK app can offer the same basic idea—your provider accounts, your API keys, one AI workspace—while having very different security, storage, networking, and lifecycle constraints.

The most important difference is not visual polish. It is the platform boundary.

BYOKchat Web
┌──────────────────────────┐
│ Browser sandbox          │
│ IndexedDB / site data    │
│ Browser CORS rules       │
│ Web lifecycle            │
└──────────────────────────┘

BYOKchat iOS / macOS
┌──────────────────────────┐
│ Native app sandbox       │
│ Apple Keychain           │
│ Native networking        │
│ OS app lifecycle         │
└──────────────────────────┘

Both can be local-first. They are not the same security model.

The short comparison

Area	Web app	Native iOS/macOS app
Install required	No	Yes
Updates	Immediate website deployment	App update / platform distribution
API-key storage	Browser-local storage / IndexedDB	Apple Keychain
Chat/workspace storage	Browser-local	Local app storage
BYOK cloud chat sync	Not required	Not required
Browser CORS	Yes	No browser CORS layer
Local/LAN endpoints	Browser restrictions apply	More direct native networking model
Background work	Browser/tab lifecycle	Native OS lifecycle/background rules
File access	Browser picker/sandbox	Native platform file integrations
Offline UI/history	Depends on whether the web app shell is locally available; stored data may remain	App UI is installed locally; stored data may remain
Cloud generation offline	No	No

The right choice depends on what you value more: instant access and zero installation, or stronger native credential storage and deeper platform integration.

Both can be local-first

“Native” does not automatically mean local-first, and “web” does not automatically mean cloud-synced.

A hosted web application can still keep its conversation database in the browser instead of uploading it to an application server. Conversely, a native app can synchronize every chat to a cloud backend if that is how it is designed.

BYOKchat’s design goal is local-first on both surfaces:

Workspace at rest
    → local platform storage

Generation request
    → provider you selected

Approved remote tool call
    → MCP/tool service you configured

Minimal product analytics
    → small first-party analytics service

The platform changes how local storage is implemented, not the overall philosophy.

Read How Private Is a BYOK AI Chat App? for the complete trust-boundary model.

API-key storage: browser database vs Apple Keychain

This is the most important security difference.

Web

The current BYOKchat web app keeps provider credentials inside browser-local application storage. The app uses local databases including IndexedDB for provider configuration/credentials and related workspace state.

JavaScript running under the trusted chat.byok.pro origin needs access to the credential so it can make provider requests.

The trust boundary is therefore:

browser
└── trusted site origin
    └── app JavaScript
        └── local credential database

See Where Does a BYOK Web App Store Your API Key? for the detailed security discussion.

Native

On iOS and macOS, provider credentials can be stored in Apple Keychain, which is designed specifically for secrets.

The native client can keep ordinary workspace configuration separate from credentials:

App database
├── chats
├── projects
├── provider settings (non-secret)
└── preferences

Apple Keychain
├── provider API keys
├── secret headers
└── MCP credentials

That separation is a strong reason to prefer native when credential protection is your highest local-security priority.

Does the web app upload my chats because it runs from a website?

No—not necessarily, and BYOKchat Web currently does not depend on a BYOK cloud conversation-sync account.

The HTML/JavaScript application is downloaded from the website, but persistent conversation data can remain in the browser database.

This is an important distinction:

Code delivery       → from website/CDN
Conversation store  → browser-local
AI request          → selected provider

The hosting platform still receives ordinary network metadata required to serve the site and assets. That is different from the application maintaining a server-side copy of your chat history.

Direct provider requests work differently on web and native

Both platforms can send requests directly to an AI provider, but browsers add a security layer: CORS.

Web request

chat.byok.pro
     │
     │ browser checks provider CORS policy
     ▼
AI provider

The provider must permit requests from that browser origin and allow the methods/headers the client needs.

Native request

BYOKchat native
     │
     │ native HTTPS request
     ▼
AI provider

Native networking is not gated by browser CORS.

This is why a custom endpoint can work perfectly in the Mac app and fail in the web app even with the same base URL and credential.

Read Why Some AI APIs Don’t Work in the Browser: CORS Explained.

Local AI is usually easier from native apps

Suppose LM Studio is running on your Mac at a local-network address.

A native client can attempt a direct connection subject to normal network, TLS, firewall, and platform policies.

A browser client may additionally encounter:

• CORS;
• secure-context/mixed-content restrictions;
• private-network protections;
• browser handling of local addresses;
• origin-specific permission behavior.

The topology itself can also be confusing:

Mac
├── LM Studio: localhost:1234
└── BYOKchat Mac → localhost works

Phone
└── browser/native app
      └── localhost means the PHONE, not the Mac

To reach the Mac from another device, you need a reachable LAN/private-network address and a server configured to listen appropriately.

See How to Connect Ollama or LM Studio to BYOKchat and Why localhost Does Not Work From Your Phone.

Browser lifecycle vs native app lifecycle

Long AI generations expose another platform difference.

Browsers may throttle or suspend background tabs depending on the browser, device, memory pressure, energy policy, and operating system. Mobile browsers are especially aggressive about reclaiming resources.

Native apps also face lifecycle restrictions—especially on iOS—but they can use platform-specific mechanisms and design around app foreground/background transitions more directly.

Neither environment should assume a network stream lives forever.

A resilient AI client should persist enough state to recover from interruption:

request starts
    │
    ├── stream continues → normal completion
    │
    └── app/tab interrupted
           │
           ├── preserve known partial state
           ├── mark request interrupted
           └── offer safe retry/recovery

Read How to Handle App Backgrounding During AI Generation and How to Resume or Recover an Interrupted AI Generation.

Files and attachments

Both web and native apps can support file selection, but the integrations differ.

Web

A browser typically receives files through an explicit file picker or supported browser API. The site does not have unrestricted access to your filesystem.

The current BYOKchat web app reads supported attachments locally and stores them with the conversation. It does not need to upload a file to BYOK infrastructure merely to make it available to the local chat database.

Native

Native apps can integrate more deeply with platform document pickers, drag-and-drop, share flows, file bookmarks/security-scoped resources where relevant, and other OS features.

In both cases, using an attachment with a cloud model can still send attachment content to the selected provider when required for that request.

Local storage does not change the provider data path.

MCP and tools

Remote MCP is possible on both web and native clients, but the transport constraints differ.

A browser-based MCP connection needs the remote HTTP endpoint to support browser access, including CORS.

Native clients can connect without that browser-specific requirement.

The permission model should remain consistent:

Model requests tool
      │
      ▼
Local permission check
      │
      ├── deny → no external call
      │
      └── allow
             │
             ▼
          MCP server

The platform should not change the principle that tool authorization belongs to the client, not to untrusted model output.

See How to Build an MCP Client Permission System.

Backups and portability

Local-first applications need an explicit portability story because there is no cloud account silently carrying your workspace everywhere.

A portable backup can move conversation content between installations or platforms, while secrets should remain excluded.

That separation is important:

Portable backup
├── conversations
├── attachments
├── tool events
└── workspace content

Not portable by default
├── API keys
├── secret headers
├── MCP credentials
└── local security state

If a backup contained every credential, importing it on another device would also become a secret-distribution mechanism.

Read Backup and Restore Security for Local AI Chats.

Updates: web wins on immediacy

The web app can ship an improvement and make it available the next time you load the site.

That is useful for:

• provider compatibility fixes;
• newly released model metadata;
• renderer improvements;
• bug fixes;
• new web-safe capabilities.

Native apps have a more deliberate release/update cycle. That can be slower, but native binaries also provide a more stable packaged execution environment than code fetched from a website on each deployment.

Neither is universally better; they optimize different things.

Offline behavior

Locally stored browser data can still exist when the network is unavailable, but that does not guarantee the web application’s UI/runtime is available offline. The browser must also have the application shell and required assets available locally.

A native app packages its UI/runtime locally by definition, while a web app needs explicit caching/service-worker behavior if full offline loading is a goal.

Cloud generation still requires network access in either case:

Offline
├── local conversation data may still exist
├── native installed UI remains available
├── web UI depends on cached/offline-capable app shell
├── local model on reachable device may work
└── OpenAI/Anthropic/Gemini cloud call cannot work

Do not equate “local-first data” with “all features work offline.”

Analytics can remain minimal on both

Platform choice does not require invasive analytics.

A privacy-conscious client can collect bounded first-party product/reliability counters while excluding prompts, responses, credentials, file contents, and tool payloads.

The goal is to answer questions such as:

Did provider setup fail more often after a release?
Is generation completion rate dropping?
Which broad feature is actually used?

without turning user conversations into telemetry.

Read Privacy-Preserving Analytics for AI Apps.

Native apps can integrate more deeply with the OS

A native client has opportunities a website either cannot match or can only approximate:

• Keychain secret storage;
• system share integrations;
• platform file workflows;
• keyboard/menu/window behavior on macOS;
• app intents/shortcuts on iOS;
• richer drag-and-drop;
• native notifications;
• local network APIs and platform permission flows;
• platform-specific background/recovery mechanisms.

Those features matter if the AI client is a daily productivity tool rather than an occasional website.

The web app is easier to try and move between machines

The web has a different superpower:

open URL → configure provider → use app

There is no App Store install, no binary update, and no platform-specific package.

For a user trying BYOK for the first time, that dramatically reduces friction.

The tradeoff is that credentials and workspace data belong to that browser profile unless you explicitly export/move them.

Which should you choose?

Choose the web app when

• you want immediate access with no install;
• you use a trusted browser profile;
• your providers/endpoints support browser access;
• you value fast product updates;
• browser-local credential storage fits your threat model.

Choose native iOS/macOS when

• you prefer Apple Keychain for provider secrets;
• you use local/LAN endpoints that are awkward under browser CORS;
• you want deeper OS integration;
• you rely on native file/window/share workflows;
• you prefer a packaged app execution environment.

Use both when

You want the web client for convenience and native apps for your main trusted devices.

A local-first product should make portability explicit rather than pretending cloud sync is the only way to use multiple surfaces.

What does not change

Across web and native, the core BYOK principles can remain the same:

• you choose the provider;
• you supply the credential;
• provider billing remains yours;
• conversations can remain local at rest;
• AI content goes to the provider when you ask that provider to process it;
• external tools receive data only when their workflow requires it;
• analytics can remain minimal and content-free;
• exports should exclude credentials.

The platform changes implementation details. It does not have to change ownership of your AI setup.

Further reading

• Where Does a BYOK Web App Store Your API Key?
• Why Some AI APIs Don’t Work in the Browser: CORS Explained
• How Private Is a BYOK AI Chat App?
• Designing a Local-First AI Chat Architecture
• How to Store API Keys Safely
• How to Connect Ollama or LM Studio to BYOKchat