iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Kotlin Multiplatform (KMP) can share a 3D game’s logic, and Compose Multiplatform (CMP) can share its UI, across the platforms the official material covers. What the official material does not establish is that one 3D renderer works on all five targets, or that a game has reached 60 frames per second on any of them. The title’s three claims need separate checks: the code-sharing claim, the renderer claim, and the frame-rate claim.
What KMP and CMP each share
KMP is the code-sharing layer. Common Kotlin code compiles for several targets, and each target can add platform-specific code where shared declarations are not enough. JetBrains describes KMP as supporting gradual sharing, so a team can move one module at a time instead of rewriting a game in a single step (JetBrains, What is Kotlin Multiplatform).
What KMP can carry in a game
Good candidates for common code are game rules, simulation, entity and state models, input mapping logic, save formats, and a platform-neutral description of what a scene contains. None of these depend on how pixels reach the screen, so they are the parts least likely to differ between targets.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteWhat Compose Multiplatform adds
CMP shares UI code: menus, settings screens, pause overlays, and heads-up displays. It is a UI layer rather than a 3D renderer. A 3D scene has to be drawn into a surface that the UI layer hosts, and the renderer that fills that surface is a separate decision with its own per-platform status.
#1 Best Overall
What the survey figures do and do not show
JetBrains’ KMP Survey (Q2 2024) reported that 55% of users saw improved collaboration after adopting KMP, and 65% of teams reported improved performance and quality. These are respondents’ own reports, not controlled measurements, and they say nothing about frame rates in a 3D game.
Which five platforms are you targeting?
JetBrains’ Kotlin Multiplatform quickstart sample uses five target categories: Android, iOS, desktop, web, and server (JetBrains, Kotlin Multiplatform quickstart). The sample shows that these targets can live in one project. It does not show a 3D game running on all five. Your release matrix may differ, so name the exact five before you test anything.
Rank #2
| Target | What the official material establishes | Question to answer for a 3D game |
|---|---|---|
| Android | Listed as a target category in the quickstart sample. | Which graphics path runs on Android, and what is the minimum device tier? |
| iOS | Listed as a target category. Builds require a Mac with Xcode (JetBrains, Build and run a Kotlin Multiplatform application). | Which renderer path runs on iOS, and has it been checked on a physical device? |
| Desktop | Listed as a target category in the quickstart sample. | Which operating systems and graphics drivers are in scope? |
| Web | Listed as a target category. The build and run documentation describes a web compatibility mode that can produce both JS and Wasm builds. | Which build (JS or Wasm) and which browsers are in scope? |
| Server | Listed as a target category in the quickstart sample. | Is this a simulation or networking target? Rendering cannot be validated on it. |
A game that renders locally may replace the server category with a second desktop operating system. Whatever five you choose, document them as the release matrix.
Free tools Windows power users keep installed
One-click scans. No signup required.
Can a 3D renderer cover the same matrix?
Two renderer projects are the obvious candidates. Neither source shows a complete game engine across the full matrix, and a platform appearing in a project’s target list does not establish identical APIs or feature parity.
Filament
Google’s Filament describes itself as a real-time physically based renderer. Its repository lists Android, iOS, Linux, macOS, Windows, and WebAssembly among its targets (Google, Filament repository).
SceneView
SceneView documents a community KMP core with platform-specific rendering integrations. Its README describes the CMP integration as alpha and covering a viewer subset, so it should not be treated as a finished CMP game renderer at the time of writing (SceneView maintainers, SceneView project README).
| Criterion | Filament | SceneView |
|---|---|---|
| Platform coverage | Lists Android, iOS, Linux, macOS, Windows, and WebAssembly as targets. | Documents platform-specific rendering integrations; a full target list is not stated in the cited README. |
| Maturity and status | Not stated in the cited source. | CMP integration described as alpha, covering a viewer subset. |
| Native versus shared renderer | Not stated in the cited source. | Shared KMP core with platform-specific rendering integrations. |
| CMP integration effort | No CMP integration is described in the cited source. | Alpha, viewer subset only. |
| Graphics API availability per target | Not stated in the cited source. | Not stated in the cited README. |
| Asset and shader workflow | Not stated in the cited source. | Not stated in the cited README. |
| Input and lifecycle integration | Not stated in the cited source. | Not stated in the cited README. |
| Profiling and frame-time tools | Not stated in the cited source. | Not stated in the cited README. |
| Maintenance status | Not stated in the cited source. | Community project; status can change. |
How to evaluate a candidate renderer
- Build one lit mesh with a camera and one light, using the same scene description on every target in your matrix.
- Render it inside the CMP surface your game will use, not in a standalone test window.
- Check input and lifecycle: pause and resume on Android and iOS, window resize on desktop, and visibility changes in the web build.
- Log which graphics path each target actually used. A listed platform does not prove that path ran.
- Measure frame times on that scene using the method in the frame-rate section below.
- Decide per target: shared renderer, platform-specific renderer, or a documented fallback.
Architecture: what stays common and what does not
A workable split separates the game from the drawing surface. The sources support KMP’s gradual sharing and platform-specific code, but they do not show one universal graphics backend, so plan for the renderer to differ between targets.
- Common code: game rules, simulation, state, data formats, and the platform-neutral scene description.
- Declared boundaries (expect/actual): render surface creation, lifecycle callbacks, asset file access, input device events, and the frame clock. Each boundary is declared once in common code and implemented per target.
- Platform renderer code: the code that talks to a renderer library or graphics API on each target. This layer is most likely to diverge, and it is where the matrix checks above matter most.
Setup friction you will hit
- iOS needs macOS. The build and run documentation states that iOS targets require a Mac with Xcode.
- Each target has its own run configuration. The same project is launched through platform-specific run configurations, so test runs must be recorded per configuration.
- Web can produce two builds. The build and run documentation describes a web compatibility mode that can produce both JS and Wasm builds.
Is 60 fps achievable?
At 60 frames per second, each frame has a budget of about 16.7 ms (1,000 ms divided by 60). That budget must cover all game logic, scene update, render submission, and presentation for the frame. This is arithmetic, not a measurement. None of the sources cited here reports a frame-rate result for a 3D game on these targets, so 60 fps remains a design target until your own data supports it.
Best Value
Define the test matrix before measuring
- Exact device model, OS version, and GPU or graphics chip for each target. For desktop, record the operating system version and graphics driver.
- Build type. Claims should come from release builds; debug builds are for diagnosis.
- Graphics settings and display resolution, held constant across targets.
- Scene workload: number of meshes, lights, and draw-heavy objects, identical on every target.
- Test duration long enough to show thermal behavior. Record battery and charging state on mobile devices and laptops.
- Physical device or emulator and simulator. Simulator and emulator results are not device results.
Report frame-time distributions, not one average
An average FPS figure hides hitches. Record frame time for every frame, then report the median, the 95th and 99th percentile frame times, and the share of frames above 16.7 ms. Report first-run and warmed-up results separately, because one-time startup work can dominate the first seconds of a session.
Quick Recap
Apply these reading rules:
- A stable 60 fps result means frame times stay under 16.7 ms for the full test duration on named hardware.
- A brief peak, a single run, or a simulator observation is not a stable result.
- A claim about every platform requires a passing row for each of the five targets.
When one target misses the budget
- Confirm the build is release and that the scene and settings match the other targets.
- Confirm which renderer path ran. If the paths differ, you are comparing two renderers, not one game on two platforms.
- On web, test the JS and Wasm builds separately before attributing a miss to the platform.
- On mobile, lower the workload and rerun after a cool-down to separate sustained thermal throttling from a code problem.
- If one target stays over budget at the lowest workload, treat that target as not validated for 60 fps and say so in the release notes.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
