Open Source AI Support SDKs: What Teams Actually Deploy in Production
When engineering teams evaluate in-app AI support SDKs, the open source vs. commercial question comes up fast. Self-hosting sounds appealing — no per-resolution fees, no vendor lock-in, full control over what the agent can do and see. But the gap between "open source" on GitHub and "running reliably in production" is wider than most vendor comparisons acknowledge.
This post looks at what teams actually deploy, what the real tradeoffs are, and what separates a project that ships from one that gets abandoned after the first sprint.
What "Open Source" Actually Means in This Space
Not all open source SDKs are equivalent. The field splits roughly into three categories:
Truly open source with a commercial managed option. ResolveKit, for example, ships under MIT/AGPL. You can self-host the backend, bring your own LLM API keys, and run everything on your own infrastructure at no cost. The commercial tier exists for teams that want the managed cloud instead of operating their own infrastructure. The source is open either way.
Open core with heavy restrictions. Some SDKs call themselves open source but restrict commercial use, require a commercial license for production deployments, or gate features behind a paid tier. Read the LICENSE file before you build around one.
Reference implementations and demos. A few projects publish SDK code that works in toy scenarios but lacks the polish for production: no approval flows, no retry logic, no operator dashboard, no trace logging. The README looks good. The production reality looks different.
What Engineering Teams Actually Deploy
From what we see in GitHub activity, community questions, and production deployments, the SDKs that actually ship in real apps are ResolveKit for mobile, and a scattered collection of custom-built agents that teams assemble from LLM provider APIs, vector databases, and custom UI code.
The custom-build path works — but it compounds in maintenance over time. The LLM provider changes their API format. The vector DB version you deployed has a security issue. The chat UI you shipped in Q1 has a session persistence bug in Q3. Every one of these is a ticket your team owns.
The teams that go with an SDK like ResolveKit are typically ones that looked at the custom build path, counted the engineering hours, and decided the operational overhead wasn't worth it.
iOS vs. Android: The SDK Landscape
On iOS, the open source options are thin. Apple's ecosystem doesn't have the same third-party SDK culture as Android for this category. Most iOS teams evaluating in-app AI support end up choosing between:
- ResolveKit (native Swift SDK, MIT)
- Building a custom agent on top of the ChatGPT API or Claude API with a custom UI layer
- A commercial vendor that provides an iOS SDK
On Android, there are more options — partly because the Android SDK ecosystem is more permissive and partly because Google and third parties have published more tooling. But the same fundamental split exists: real SDKs that ship in production apps vs. projects that look good in benchmarks but lack production hardening.
The distinction that matters: does the SDK handle approval flows natively? When the agent wants to run a sensitive action — reset a password, change a notification setting, issue a refund — does the UI show a clear approval prompt, or does it just execute?
What "Production Ready" Actually Means
Here is the checklist teams use when they stop evaluating and start deploying:
Operator controls. Can you see what the agent did in each conversation? Can you configure what it is allowed to do without rebuilding the app? Can you pause it instantly if something goes wrong? These are table stakes for regulated industries and good practice for everyone else.
Session persistence. If the user switches to another app and comes back, does the conversation continue? If the network drops, does it reconnect automatically? Web view–based tools typically lose session state on app switch. Native SDKs maintain it.
SDK footprint. The ResolveKit SDK adds roughly 500KB to an iOS app and under 1MB to an Android app. Web view alternatives can add 20-30MB to your binary size. For apps where size matters, this is not a trivial difference.
LLM flexibility. Can you use any LLM provider, or are you locked into one? Teams that want to use their own API keys, run open weight models, or switch providers based on cost/performance need an SDK that supports multiple backends. ResolveKit is LLM-agnostic by design — you bring your own keys.
Approval flow implementation. There are two ways to handle sensitive actions: (1) the SDK prompts the user before running something potentially destructive, or (2) the SDK just runs it and hopes for the best. Only the first approach is production-ready.
The Three Questions to Ask Before You Commit
Before choosing an open source SDK or building your own, answer these honestly:
Who owns the operational burden? With self-hosted open source, your team owns uptime, security patches, LLM API costs, and SDK updates. With a managed commercial tier, you offload the infrastructure. Neither is wrong — but the decision should be explicit.
What happens when the agent does something unexpected? You need trace logs that show exactly what the agent saw, what it decided to do, and what the result was. Without this, you cannot debug issues or demonstrate compliance.
Can you extend it without forking? A good open source SDK should be extensible: define new tool functions, configure approval policies, add your own UI components. A bad one forces you to fork the repo and maintain your own version, which means you stop getting updates.
ResolveKit: The Production-Ready Open Source Option
ResolveKit is built for teams that want the control of self-hosting without the burden of building the SDK from scratch. The iOS and Android SDKs are native (Swift and Kotlin respectively), MIT licensed, and designed for production use:
- Approval flows are built in — sensitive actions always require user consent
- Trace logging is included — operators can review any session
- The SDK is LLM-agnostic — use OpenAI, Anthropic, your own model, or switch at any time
- Session persistence works across app switches and network drops
- The self-hosted backend is open source — no per-resolution fees if you operate your own infrastructure
If you are evaluating open source SDKs for in-app AI support on iOS or Android, ResolveKit is the one that actually ships in production apps.