Move SDKs out of the monorepo into separate repositories

[brionmario]

Background

Currently, all SDKs live inside the ThunderID monorepo alongside the core product. This setup is creating friction as the project matures:

---

• Blocked pipelines — Product and SDK delivery pipelines are separate by nature, but they share the same PR queue, so they block each other unnecessarily.
• Tag pollution — A single tag namespace means SDK version tags mix with product release tags, making the history noisy and harder to reason about.
• No SDK-specific GitHub Releases — GitHub Releases are tied to the product release cycle. We cannot publish release notes, changelogs, or assets scoped to an individual SDK without polluting the product release stream.

Trade-offs

Keeping SDKs in the monorepo

✅ Pros

• Single PR touches product and SDK changes together — useful when a backend change requires a coordinated SDK update.
• Shared tooling, linting, and CI configuration with no duplication.
• Easier cross-cutting refactors (rename a type, update an endpoint contract) in one commit.
• Simpler onboarding — one repo to clone, one place to search.

❌ Cons

• PR queues are shared, so a high-volume SDK change (e.g. multi-platform release) blocks unrelated product PRs and vice versa.
• Git tags for SDK versions pollute the product tag namespace (e.g. sdk/ios/v1.2.0 alongside v2.5.0).
• GitHub Releases can only be scoped to the repo, not to a subdirectory — SDK release notes either get buried in product releases or require a separate manual process.
• CODEOWNERS and branch protection rules become harder to scope: a reviewer required for Go backend changes may be unintentionally required on a Flutter PR.
• Larger clone and CI checkout cost for SDK contributors who do not need the full product source.
• SPM resolves packages via a GitHub Release URL scoped to this repo. The SwiftUI SDK depends on the iOS SDK via a local path (../ios) in development, but must be patched to a published GitHub Release URL at release time — creating a two-phase publish process that is error-prone and hard to test end-to-end before tagging.

Moving SDKs to separate repositories

✅ Pros

• Independent PR queues — SDK releases never block product releases and vice versa.
• Clean tag and release namespaces per ecosystem; GitHub Releases work naturally.
• Granular CODEOWNERS, branch protection, and CI pipelines per ecosystem.
• External contributors (community SDK maintainers) get a focused, approachable repo without navigating the full product monorepo.
• Easier to open-source or transfer ownership of a specific SDK independently.

❌ Cons

• Coordinated changes spanning product + SDK require two PRs and careful sequencing.
• Tooling, CI templates, and secrets must be duplicated or centralised in a shared GitHub Actions org-level setup.
• More repos to monitor, triage, and keep in sync (Go module proxies, dependency bots, security alerts).
• Cross-repo search and bisection is harder — tracing a bug from a product API change to an SDK behaviour requires jumping between repos.

Proposal

Ecosystem-based repositories

Extract each SDK into its own repository, grouped by ecosystem:

Ecosystem	SDKs	Distribution	Registry / Resolution
iOS	ios, swiftui	SPM	GitHub Release URL
Android	android, compose	Gradle / Maven	GitHub Packages (Maven)
Flutter	flutter	Dart pub	pub.dev
JavaScript	(planned)	npm	npm registry

Each repo gets independent versioning, changelogs, CI/CD pipelines, and GitHub Releases — fully decoupled from the product release cycle.

Note on Android/Compose: The Compose SDK depends on the Android SDK artifact published to GitHub Packages. Both repos would need to publish to the same GitHub org packages namespace for the dependency to resolve cleanly.

Open questions

Naming convention

Two options on the table:

Option A — Prefixed (thunderid-<ecosystem>)

• thunderid-ios
• thunderid-android
• thunderid-flutter
• thunderid-javascript

✅ Pros: clear branding, works well if the org hosts non-ThunderID repos in the future.
❌ Cons: slightly more typing, longer repo URLs.

Option B — Short (<ecosystem>)

• ios
• android
• flutter
• javascript

✅ Pros: clean and minimal.
❌ Cons: less explicit branding; could clash if the org ever hosts other projects.

To Discuss

1. Which naming convention do you prefer, and why?
2. Any concerns about the migration path (open PRs, existing consumers pinned to monorepo paths, CI secrets, etc.)?

[brionmario]

Vote for your preferred repo naming convention!

👍 = Option A — prefixed product name

• thunderid-ios
• thunderid-android
• thunderid-javascript

🚀 = Option B — short

• ios
• android
• javascript

👀 = Option C — sdk suffixed

• ios-sdk
• android-sdk
• javascript-sdk

❤️ = Option D — sdks suffixed

• ios-sdks
• android-sdks
• javascript-sdks

🎉 = Option E — developer-resources suffixed

• ios-developer-resources
• android-developer-resources
• javascript-developer-resources

React to this comment to cast your vote.

[pavinduLakshan]

feels like thunderid- prefix would be redundant for the repo name because the org name already implies it.

[senthalan]

I am thinking, Shouldn't we have the 'sdk-' prefix?

[brionmario]

I am thinking, Shouldn't we have the 'sdk-' prefix?

I think the current trend is to avoid the -sdk suffix, since it can imply that all development tooling needed to work with the technology is contained within the repo (official SDKs as well as third-party SDK integrations, etc.).

Also, since we are grouping multiple SDKs under a single umbrella, using sdk- would likely make things messy and less scalable over time.

ex:

• https://github.com/stripe/stripe-android
• https://github.com/clerk/javascript
• https://github.com/logto-io/js

[brionmario]

There were few concerns regarding not having a suffix or a prefix to specify the contents of the repo, hence option B had to be diqualified.

We decided to move forward with ❤️ = Option D mainly because of the following reasons.

• Clearly states the contents of the repository.
• We are not going to have just the official SDK in here rather the official SDK, 3rd party integrations (ex: app-auth-ios), related samples. (sdk suffix was not considered mainly due to this multi responsibility requirement)

[sagara-gunathunga]

Among the several valid reasons mentioned in the proposal, the dependency between product releases and SDK releases and vice versa is a real issue that makes life harder for users.

Keeping SDK changes aligned with product changes is definitely an advantage, but I believe we can still maintain that relationship with a bit of additional coordination and effort, even if we move forward with separate repo.

While I’m aligned with this proposal, I also think we should aim to minimize the number of SDKs we create and group related SDKs whenever possible. Otherwise, maintaining all of them will become a significant overhead, and over time we will likely end up with outdated repos.

For each new SDK, once it becomes mature enough for adoption, we should evaluate whether it truly requires its own repo or whether it can be expanded and accommodated within an existing SDK repo.

[brionmario]

+1

[darshanasbg]

There are two proposals,

Whether to maintain SDKs outside of the core product, or maintain SDKs in a mono repo with the core product.
Whats the naming convention of the SDK repos, if we are moving out.

We need to focus on getting on an agreement on the first proposal, before going into the second.

With that, ill be focusing on the first proposal here onwards.

@brionmario could you explain the following point bit further?

SPM resolves packages via a GitHub Release URL scoped to this repo. The SwiftUI SDK depends on the iOS SDK via a local path (../ios) in development, but must be patched to a published GitHub Release URL at release time — creating a two-phase publish process that is error-prone and hard to test end-to-end before tagging.

The offline chat we have yesterday, you said there is a blocker to get the iOS SDKs released with the mono repo approach. Is it the above point or is it something else?

Basically, what i'm trying to evaluate, whether there are any blockers when operating in either of these modes. If there are blockers we need to consider them first.

[brionmario]

The offline chat we have yesterday, you said there is a blocker to get the iOS SDKs released with the mono repo approach. Is it the above point or is it something else?

Yes. This is related to the issues regarding iOS SDK releases to Swift Package Manager (SPM).
Swift package manager works directly with the repository URL and is versioned by Git tags.

• Package ref (GitHub URL): https://github.com/thunderid/ios
• Package version (GitHub Tag): version referred by the Git tag

ex:

let package = Package(
    name: "Quickstart",
    platforms: [.iOS(.v16), .macOS(.v13)],
    dependencies: [
+        .package(url: "https://github.com/thunderid/ios", from: "1.0.0"),
    ],
    targets: [appTarget]
)

The problem comes during versioning in monorepo setups. Since SPM only supports repository-level semantic version tags, and does not support scoped tags like sdk/ios/1.0.0 and expects plain semantic version strings (e.g. 1.0.0, 2.3.1).
So the iOS SDK cannot be independently versioned or released within the same repository.

ref: https://docs.swift.org/package-manager/PackageDescription/PackageDescription.html

[darshanasbg]

Following up on this:
So this means there is a blocker to maintain SDKs in the ThunderID mono repo (at least for the iOS SDK). Considering that and the consistency aspect, +1 to go ahead with maintaining multiple repos.

We need to work on sorting the cons that comes with moving SDKs out. Please track that as a sub task of this effort.

[brionmario]

Ack.