Install

Two commands, and a third if you ship to iOS. The first you run once per project, the second every time you want a component. Nothing is added to your Gradle build, because there is nothing to add.

Before you start

You need JDK 17 or later, which you already have if you are building Android or Kotlin Multiplatform. Nothing else: the CLI is a single jar with no dependencies of its own, and it is not a Gradle plugin, an npm package or a SDKMAN candidate.

Download lamintra.jar from the latest release (v0.10.0). It is the only thing you download.

1. Set the project up, once

$ java -jar lamintra.jar init

init reads your project off disk to work out where components should go. It does not evaluate Gradle, so it is fast and it cannot be broken by a build script it does not understand.

lamintra init

Detected from your project:
  Type         : Kotlin Multiplatform
  Source root  : composeApp/src/commonMain/kotlin
  Root package : com.yourorg.yourapp
  Components   : com.yourorg.yourapp.ui.components.*

Use these settings? [Y/n]

Accepting writes .lamintra/config.json, and that file is the entire footprint of the tool in your repository. If detection is wrong, or your layout is unusual, answering n asks you the same questions directly.

2. Add a component, whenever

$ java -jar lamintra.jar add button

$ java -jar lamintra.jar add button

Installed button with zero manual fixes needed.

Any of the 8 names on the components page works: swipe-row, sheet, button, card, text-field, list-row, switch, segmented.

3. Optional: native iOS chrome

$ java -jar lamintra.jar scaffold ios-shell

Compose draws to its own canvas, so it cannot draw the iOS tab bar or navigation bar. On iOS 26 that matters more than it used to: Liquid Glass is applied by the system through SwiftUI's TabView and NavigationStack, so an app that draws its own chrome in Compose does not get it, and no amount of styling will produce it.

This writes the other arrangement: SwiftUI owns the tab bar and the navigation stacks, Compose renders the content of each screen. Two Swift files, two Kotlin files, and it follows the structure JetBrains documents.

$ java -jar lamintra.jar scaffold ios-shell

  wrote: iosApp/iosApp/LamintraShell.swift
  wrote: iosApp/iosApp/ComposeScreen.swift
  wrote: composeApp/src/iosMain/kotlin/.../ui/shell/ShellEntry.kt
  wrote: composeApp/src/commonMain/kotlin/.../ui/shell/ShellRoutes.kt

Two things it deliberately does not do. It will not add the Swift files to your Xcode target, because editing a .pbxproj from a command line is how project files get corrupted; drag them in once. And the view it writes is not @main, because the Compose Multiplatform template already ships one and a second does not compile, so you point your existing app at LamintraShell(). Both are printed after it runs. Requires a Kotlin Multiplatform project; it stops with an explanation on an Android-only one.

Typing lamintra instead of java -jar

Every command below is written as java -jar lamintra.jar, which assumes the jar is in the directory you are standing in. It does not have to be: a full path works anywhere, and quoting it matters on Windows because an unquoted path can be read as a redirect.

java -jar "C:\tools\lamintra.jar" init

There is no lamintra on your PATH, because the tool is a jar rather than an installed binary. If you would rather type one, alias it once. Pick your shell:

doskey lamintra=java -jar C:\tools\lamintra.jar $*

function lamintra { java -jar C:\tools\lamintra.jar @args }

alias lamintra='java -jar ~/tools/lamintra.jar'

The first is cmd, the second PowerShell, the third bash or zsh. All three last for the session only. To keep one, put the doskey line in a startup script, the function in your $PROFILE, or the alias in ~/.bashrc or ~/.zshrc. Every command on this page then works with lamintra in front instead of java -jar.

What "with zero manual fixes" actually means

This is the part that is not marketing. A copy-pasted .tsx file runs wherever you drop it. A copy-pasted .kt file does not compile at all unless its package declaration matches its physical location on disk, which is a hard Kotlin compiler rule rather than a convention.

So a component published under com.lamintra.button is broken the moment it lands in your com.yourorg.yourapp tree. The CLI rewrites the package declaration, the internal imports, and the file path together, so the file compiles where it lands. That is the whole reason this is a tool and not a page of snippets.

The rewrite is boundary-safe: rewriting com.lamintra.button never touches a package that merely shares its prefix.

Where the code comes from

The CLI fetches from the public registry repository, pinned to the tag v0.9.0 rather than to main. A push to the registry cannot change what your add installs; only upgrading the CLI can.

The registry is public, so you can read exactly what a command will write before you run it.

Deleting Lamintra

Delete lamintra.jar and the .lamintra directory. That is the whole uninstall. The components stay, because they were only ever your files: they import compose.foundation and nothing else, so there is no artifact to remove from your build and nothing to unblock you.

This is the one claim the nearest alternative cannot make. It is also the reason there is no "upgrade" command: once a component is in your repository, it is yours to change, and a tool that rewrote your edits later would be taking that back.