Stable Diffusion AI (SDAI): a Kotlin Multiplatform client for Android and iOS image generation
Stable Diffusion AI client app for Android and iOS
At a glance
- What is it?
- SDAI is a mobile front end for self-hosted and hosted Stable Diffusion backends, built in Kotlin Multiplatform. It is strongest when you already run a server; the on-device paths are Android-heavy and vary by build flavor.
- Who is it for?
- Adopt SDAI if you already run an AUTOMATIC1111 or SwarmUI server, or want one mobile UI over AI Horde and hosted APIs, and you accept that Android local generation is the only on-device path with several runtimes. Skip it if you need a self-contained iOS app that generates without a network backend, since the README lists no Android or iOS local provider for that case beyond the documented iOS Core ML and PrismML Bonsai paths.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 18, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What SDAI actually is, and the gap it fills
SDAI, short for Stable Diffusion AI, is a cross-platform AI image generation client for Android and iOS written in Kotlin. The repository describes it as an open-source client that gives one mobile workflow for self-hosted Stable Diffusion servers, hosted image APIs, crowdsourced generation, and platform-specific local generation where supported. The emphasis on client matters. This is not a diffusion engine, and it does not ship model weights as its main product. It is the remote control.
The problem it targets is fragmentation on the phone side. If you run AUTOMATIC1111 at home, you interact with it through a browser tab that was designed for a desktop. If you also want to try AI Horde or a hosted API, you juggle different apps or different web UIs, each with its own prompt form and its own gallery. SDAI puts those backends behind one prompt form and one local gallery, and it keeps the result on the device rather than in a provider account. The README states plainly that the app contains no ads and no telemetry, which is the kind of claim a self-hosting audience checks first.
The intended user is someone technical enough to own a Stable Diffusion server or an API key, but who wants to trigger and review generations from a phone. A second audience is Android users who want on-device generation and are willing to pick a build flavor that packages the native runtime.
One prompt form over eight backends, and where the work really happens
The architecture visible from the repository is a Kotlin Multiplatform project split into modules: app, core, data, domain, network, presentation, storage, feature, demo, build-logic and qa. That is a conventional clean-architecture layout for KMP, and the topics list confirms the stack: Compose UI, Material3, Koin for dependency injection, Room for the local database, coroutines, and an MVI-style ViewModel layer. The practical consequence is that the shared modules hold the generation form, the gallery and the provider abstraction, while platform-specific code handles the native diffusion runtimes.
The provider matrix is the core of the design. AUTOMATIC1111 WebUI and SwarmUI are treated as your own servers, with model, LoRA and embedding discovery. AI Horde works with the default anonymous key or your own Horde API key. Hugging Face, OpenAI Images, Stability AI, Fal.ai and ArliAI are hosted APIs that each require a key. ArliAI is labelled an alpha provider in the README, which is a fair warning rather than a marketing line.
Data flow for a remote generation is straightforward: the shared form collects prompt, negative prompt where supported, seed, steps, CFG scale, size, model and LoRA selection, then the network module posts that to the selected provider. The returned image lands in the local gallery with its details, and the app offers zoom, sharing, native platform save flows and zip export. The gallery is local, so switching providers does not scatter your history across accounts.
Local generation is where the matrix gets uneven. Android has four documented local paths: Microsoft ONNX Runtime, Google AI MediaPipe, stable-diffusion.cpp SDXL, and Local Diffusion PrismML Bonsai. iOS has Silicon Diffusion Core ML and Silicon Diffusion PrismML Bonsai. MediaPipe is excluded from the FOSS flavor, and custom local model paths are available outside the Play build. Those two constraints alone decide which APK many users should download.
Installing SDAI and running a first generation
The README does not document a build-from-source install procedure; it points to the published distribution channels instead. The quickest path is the store listing for your platform: Google Play for the playstore flavor, F-Droid for the foss flavor, and the App Store for iOS. A nightly Android build is also published as sdai-full-nightly.apk on the releases page, and NIGHTLY_BUILDS.md covers that process.
If you would rather build the project yourself, the repository is a Gradle KMP project with a wrapper at the root. The README does not list the required JDK version or the Android SDK level, so treat the wrapper as the entry point and expect to read build.gradle.kts and gradle.properties for the actual toolchain constraints:
git clone https://github.com/ShiftHackZ/Stable-Diffusion-KMP.git
cd Stable-Diffusion-KMP
./gradlew assembleFullThe flavor names come from the README's own matrix: playstore, full and foss. Building assembleFull produces the GitHub/release variant, which is the one that includes the local runtimes without the Play Store restrictions. On Windows the wrapper is gradlew.bat.
Once the app is installed, the first real use is a remote generation against a server you control. Start AUTOMATIC1111 with its API enabled on your machine, then in SDAI open the provider selection, choose AUTOMATIC1111 WebUI, and enter the server address. The README describes this provider as connecting to your own Stable-Diffusion-WebUI API server and lists demo mode alongside txt2img, img2img, inpaint, models, LoRA, embeddings and hypernetworks. Demo mode is the sensible first step, because it exercises the form and the gallery without depending on your server being reachable from the phone.
For an on-device run, the README says to check local-device fit before heavy runs with the on-device benchmark, then review storage and network usage from Settings. Do that benchmark before downloading a multi-gigabyte model onto a phone.
The build flavor choice is the real limitation
The most consequential constraint in SDAI is not a missing feature, it is the split between distribution flavors. Google AI MediaPipe local generation is marked as available on playstore and full, and excluded from foss. If you install the F-Droid package because you want a build without Google components, you lose that local runtime. The README does not present this as a temporary state, so plan around it.
There is a second boundary around custom model paths. The matrix notes that custom local model paths are available outside the Play build, which means the Play Store package restricts you to whatever catalog the app exposes. For stable-diffusion.cpp SDXL the README lists catalog GGUF, safetensors and ckpt models with CPU, OpenCL and Vulkan backend selection, which is a meaningful amount of control, but the Play build narrows it.
iOS is the sharper limitation. The README lists no AUTOMATIC1111-style local server runtime for iOS, and the on-device options are Core ML and PrismML Bonsai. It also states that SDXL catalog entries for Silicon Diffusion Core ML are disabled until device-gated QA is stable. Anyone expecting the iOS app to match the Android local feature set will be disappointed by the matrix as written.
Finally, this is a client. Every hosted provider requires an API key, and every self-hosted provider requires a reachable server. If your server is not exposed to the internet, SDAI is only useful on your home network unless you add your own tunnel. The README does not document a built-in relay.
How SDAI differs from the AUTOMATIC1111 web UI and from Draw Things
The obvious alternative for a self-hoster is the AUTOMATIC1111 web UI itself, opened in a mobile browser. The difference is the interaction model. AUTOMATIC1111 is a server-rendered desktop interface; SDAI is a native client with a local Room-backed gallery, native share and save flows, and zip export. SDAI also abstracts over providers, so the same form can target AI Horde or a hosted API when your server is off. What you give up is the full extension surface of the web UI. If your workflow depends on a specific AUTOMATIC1111 extension or script, the client form will not expose it.
On iOS, the closest comparison is Draw Things, a native app that runs diffusion models on the device. The approaches differ at the root: Draw Things is a self-contained local generator, while SDAI is primarily a client for servers and APIs, with on-device generation added per platform. If your goal is generating offline on an iPhone with no server involved, a self-contained local app matches that goal more directly. If your goal is driving a server you already maintain, SDAI is the better fit because the server keeps the heavy compute and the phone stays a thin client.
A third comparison is any generic HTTP client or a chat-style app pointed at an image API. Those can call an endpoint, but they do not give you Stable Diffusion controls such as steps, CFG scale, seed and LoRA selection, nor a gallery with generation details.
Maintenance, licence and what upgrading costs you
The repository is not archived, and the last push was on 2026-09-14, two days before this writing. Releases are frequent: 1.1.2 on 2026-07-19, 1.1.1 on 2026-07-16, and an Android full nightly on 2026-06-14. That cadence suggests active development, and the nightly channel means Android users can track changes between tagged releases, at the cost of running unreleased code.
Upgrade cost is mostly about the local model assets rather than the app. The README describes explicit downloadable or imported model assets for the iOS Core ML path and catalog-based model selection for the Android stable-diffusion.cpp path. Those assets are large, and the README does not document a migration or cleanup process for them, so storage planning is on you. The on-device benchmark and the storage and network figures in Settings are the tools the project offers here.
SDAI is licensed under AGPL-3.0. For an end user installing the app, that is a source-availability guarantee. For anyone embedding the code in a network service, the copyleft obligations are the ones to read carefully in the LICENSE file; this is a description of the licence, not legal advice. The README also links a Zenodo DOI and a CITATION.cff, which indicates the project expects academic citation.
Editorial conclusion
Adopt SDAI if you already run an AUTOMATIC1111 or SwarmUI server, or want one mobile UI over AI Horde and hosted APIs, and you accept that Android local generation is the only on-device path with several runtimes. Skip it if you need a self-contained iOS app that generates without a network backend, since the README lists no Android or iOS local provider for that case beyond the documented iOS Core ML and PrismML Bonsai paths. Before committing, verify which APK flavor you are installing (playstore, full or foss), because MediaPipe local generation is excluded from the FOSS flavor, and check the on-device benchmark on your own hardware before planning long offline runs.
Frequently asked questions
Can SDAI generate images on Android without an internet connection?
Yes, on Android builds that package a local runtime. The README lists four on-device paths: Microsoft ONNX Runtime, Google AI MediaPipe, stable-diffusion.cpp SDXL, and Local Diffusion PrismML Bonsai. MediaPipe is excluded from the FOSS flavor, and custom local model paths are available outside the Play build.
Which backends can SDAI connect to for remote image generation?
AUTOMATIC1111 WebUI, SwarmUI, AI Horde, Hugging Face Inference API, OpenAI Images API, Stability AI, Fal.ai and ArliAI. The hosted options require an API key, while AUTOMATIC1111 and SwarmUI connect to servers you run yourself.
Does SDAI work on iOS the same way it does on Android?
No. The provider matrix shows iOS using the shared remote providers plus Silicon Diffusion Core ML and Silicon Diffusion PrismML Bonsai for on-device generation. The Android-only local runtimes, including ONNX Runtime, MediaPipe and stable-diffusion.cpp SDXL, are not listed for iOS.
Community notes