Community client: Openship-App — Android (Kotlin Multiplatform) mobile companion

[kareemessam09]

Community client: Openship-App — Android (Kotlin Multiplatform) mobile companion

Hi! I've built an unofficial mobile client for Openship and wanted to share it, and ask how you'd like to handle it. 👋

What it is

• Name: Openship-App (Apache-2.0)
• Platform: Android today (minSdk 24), iOS planned — built on Kotlin Multiplatform, so the shared networking/models/UI already target iOS-ready code
• Stack: Kotlin 2.4, Compose Multiplatform, Ktor 3.5, the official Kotlin MCP SDK, Koin

What it does (For NOW)

• Connect to any instance (self-hosted or Cloud) by URL + PAT; multi-instance switcher, tokens in Keystore-backed storage
• Projects dashboard with deployment status, matching the web dashboard's language
• Live deploy logs over SSE (base64 decode, ANSI colors, stage stepper, resume via ?since=)
• Live server monitoring over SSE (CPU/RAM/disk/load — self-hosted only, hidden in cloud mode)
• Redeploy & rollback via your MCP endpoint, with graceful read-only fallback if tools are unavailable

Why I'm writing

It's built entirely against your public API, SSE streams, and MCP endpoint — no changes required on your side. I wanted to check in with you rather than just assume, on a few things:

1. Naming & branding — I've tried to stay respectful and mark it "unofficial" everywhere. If you'd prefer different wording, or the name is too close to "Openship," I'm happy to rename.
2. Listing — would you consider a "Community" section in the README/docs linking to it?
3. Adoption — no pressure at all, but if it ever made sense to fold into a monorepo (apps/mobile) or transfer under the org, I'd be open to it.

A couple of small things I noticed while building that might help upstream API stability for third-party clients (happy to file separately):

• The API has no versioning; I rely on tolerant JSON parsing (ignoreUnknownKeys) to survive additive changes
• MCP tool discovery is runtime-based, which works great — just flagging it as the pattern I depend on

Screenshots are in the repo README. Happy to answer questions or adjust anything.

Thanks for Openship — it's been genuinely fun to build against. 🙏

[Hydralerne]

Hello,

Thank you for your contribution

We’ve made an important design decision that will help us improve the project and make it easier to maintain.

We want the mobile app to be client-side only. It should work through the OpenShip API, exactly like a deployed OpenShip instance does. Because of this, the desktop model that uses an end-to-end connection won’t work for mobile, as it would require building a separate backend from scratch.

The best practice here is to keep the app driven by a single source of truth: the OpenShip API. So please follow the existing project API rather than introducing a separate backend or architecture.

The only end-to-end connection should be at a single point: when the server is fresh or doesn’t have the OpenShip CLI installed. In that case, the mobile app can connect to the server over SSH, install the CLI, then tunnel the API port and communicate with the OpenShip API through HTTP over that tunnel.

Additionally, please keep the mobile app under apps/mobile for better consistency with the project structure rather than maintaining it as a separate repository. Your contribution will be preserved either way.

Thank you again for the work

[kareemessam09]

Notted
I will work on the edits and get back soon

Thanks for the consideration 🙏