Crossa is a compiler-powered native runtime platform that turns shared .cra definitions into high-performance Android and iOS APIs backed by a common C++ runtime.
Most mobile applications implement the same backend interaction twice:
Backend API
│
├── Android
│ ├── API declarations
│ ├── DTOs
│ ├── serialization
│ ├── parsing
│ ├── networking
│ └── error handling
│
└── iOS
├── API declarations
├── models
├── Codable
├── parsing
├── networking
└── error handling
Crossa changes that architecture.
You describe shared behavior once.
Crossa compiles it into a platform-neutral representation, performs the expensive runtime work natively in C++, and exposes clean Kotlin and Swift APIs to the application.
.cra Source
│
▼
Crossa Compiler
│
▼
Typed Crossa IR
│
┌─────────┴─────────┐
│ │
▼ ▼
Native Generation Platform Generation
│ │
▼ ┌─────┴─────┐
Crossa C++ Runtime │ │
│ Kotlin Swift
│ │ │
└─────────────┴───────────┘
│
Android / iOS Apps
The result is one source of behavior and one native execution engine, instead of multiple platform implementations performing the same work independently.
A Crossa source file can describe a native operation like this:
model User(
id: Int,
name: String
)
@AsyncAfter
fun getUser(id: Int): User {
re CrossaRequest {
path: "/v1/users/#id",
method: GET
}
}
Crossa understands:
Function
├── name: getUser
├── parameter: id: Int
├── result: User
├── execution: AsyncAfter
└── operation
├── type: CrossaRequest
├── method: GET
└── path
├── Static("/v1/users/")
└── Parameter(id)
It does not generate two independent networking implementations.
Instead:
Android / iOS invocation
│
▼
Generated platform API
│
▼
Stable native boundary
│
▼
Crossa C++ Runtime
│
├── Request construction
├── Path interpolation
├── Query/header/body encoding
├── Networking
├── Connection reuse
├── Response buffering
├── Response parsing
├── Native model creation
├── Scheduling
├── Cancellation
└── Error handling
│
▼
Typed Native Result
│
▼
Success(User)
Failed(CrossaError)
Cancelled
Crossa exists to move repeated infrastructure away from application code and into a shared compiler + native runtime architecture.
Android implementation
+
iOS implementation
+
duplicated models
+
duplicated parsing
+
duplicated request logic
+
different behavior
+
different performance characteristics
Shared Crossa definition
│
▼
Compiler
│
▼
Shared native execution
│
┌───┴───┐
▼ ▼
Android iOS
This architecture is designed to provide:
- One shared execution model
- One parsing implementation
- One serialization implementation
- One error model
- One scheduler
- One native networking engine
- Less managed-heap pressure
- Fewer platform-boundary crossings
- Fewer unnecessary copies
- Deterministic generated APIs
- Consistent behavior across Android and iOS
Crossa follows one fundamental rule:
Performance-critical work belongs in C++.
Kotlin and Swift are platform-facing APIs.
They are not secondary implementations of the Crossa runtime.
For networking, C++ owns:
Request validation
Request planning
URL construction
Path interpolation
Query encoding
Header construction
Body serialization
Transport execution
Connection reuse
Timeouts
Cancellation
Response buffering
Response decoding
Native object storage
Errors
Scheduling
Memory ownership
The intended data path is:
Network Bytes
│
▼
Native Buffer
│
▼
Native Decoder
│
▼
Native Typed Representation
│
▼
Platform View / API
Not:
Network Bytes
│
▼
C++ String
│
▼
JNI / Swift Copy
│
▼
Platform String
│
▼
Platform JSON Parser
│
▼
Duplicated DTO Graph
Crossa tries to eliminate work rather than simply move it around.
Crossa uses a canonical C++ compiler frontend.
.cra
│
▼
Source Loader
│
▼
Lexer
│
▼
Parser
│
▼
AST
│
▼
Project Linker
│
▼
Semantic Analysis
│
▼
Typed Crossa Representation
│
▼
Crossa IR
│
▼
Optimization + Linking
│
├───────────────────┐
▼ ▼
Native Runtime Platform APIs
Every platform consumes the same validated semantics.
There is no Kotlin .cra parser.
There is no Swift .cra parser.
There is no platform-specific interpretation of the language.
Crossa uses the .cra extension for its intentionally small language.
It is designed to express Crossa behavior — not to compete with Kotlin, Swift, C++, or JavaScript.
fun add(a: Int, b: Int): Int {
re a + b
}
var name: String = "Crossa"
print("Running #name")
model User(
id: Int,
name: String,
active: Bool
)
fun isValidAge(age: Int): Bool {
if (age >= 18) {
re true
} else {
re false
}
}
@AsyncAfter
fun getUsers(): List<User> {
re CrossaRequest {
path: "/v1/users",
method: GET
}
}
The language describes what should happen.
The compiler determines what that means.
The native runtime performs the expensive work.
Crossa execution policies include:
@Sync
@Async
@AsyncAfter
They describe execution semantics rather than creating arbitrary threads.
For example:
@AsyncAfter
fun getUsers(): List<User> {
re CrossaRequest {
path: "/users",
method: GET
}
}
has the logical result:
List<User>
while the application receives a terminal state:
CrossaState<List<User>>
├── Success(data)
├── Failed(error)
└── Cancelled
The work is scheduled using Crossa's shared bounded native scheduler.
Crossa's Android distribution model is based around an AAR containing the generated Kotlin API and native runtime integration.
Crossa
│
▼
Generated Android Module
│
├── Kotlin API
├── JNI Bridge
├── Native Libraries
└── Runtime Metadata
│
▼
AAR
│
▼
Android Application
The Kotlin API remains ergonomic while expensive work stays native.
Typical application-facing behavior can conceptually look like:
usersController.getUsers { state ->
when (state) {
is CrossaState.Success -> {
val users = state.data
}
is CrossaState.Failed -> {
val error = state.error
}
CrossaState.Cancelled -> Unit
}
}JNI is treated as an architectural boundary.
Crossa aims to minimize:
- JNI calls
- marshalled objects
- repeated lookups
- large JVM object graphs
- per-field native crossings
- unnecessary managed allocations
Crossa's iOS distribution model is based around an XCFramework with a Swift-facing API over the native runtime.
Crossa
│
▼
Generated iOS Module
│
├── Swift API
├── Stable Native Boundary
├── Native Runtime
└── Runtime Metadata
│
▼
XCFramework
│
▼
iOS Application
A Swift-facing API can conceptually expose:
usersController.getUsers { state in
switch state {
case .success(let users):
print(users)
case .failed(let error):
print(error)
case .cancelled:
break
}
}Swift receives an ergonomic API without becoming responsible for Crossa's networking or parsing pipeline.
CrossaRequest is a compiler/runtime builtin.
It represents a native request operation:
@AsyncAfter
fun getUser(id: Int): User {
re CrossaRequest {
path: "/v1/users/#id",
method: GET
}
}
The compiler resolves the interpolation before runtime:
"/v1/users/#id"
▼
RequestPathPlan
├── Static("/v1/users/")
└── Parameter(id)
At runtime Crossa executes the already-compiled request plan.
There is no need to repeatedly parse the original .cra string.
For large responses such as:
List<User>
Crossa's architecture does not require eagerly creating thousands of equivalent Kotlin or Swift objects.
The runtime can retain typed data natively and expose lightweight platform-facing views where appropriate.
Response Buffer
│
▼
Native Parser
│
▼
Native List<User>
│
├──────────────┐
▼ ▼
Android View Swift View
Materialization can still be performed when application ownership requires it.
It simply does not need to be the default architecture.
Crossa prefers knowing work at compile time instead of discovering it repeatedly at runtime.
That enables architecture such as:
Generated request plans
Generated response schemas
Static operation identifiers
Precompiled interpolation
Capability pruning
Dead operation elimination
Deterministic metadata
Native model layouts
Schema-aware parsing
The goal is to reduce:
reflection
runtime discovery
temporary allocations
intermediate object graphs
copies
boundary crossings
repeated parsing
Crossa is designed as more than a networking library.
Crossa
Compiler
│
▼
Shared IR
│
▼
Runtime Core
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Networking Database WebSocket
│ │ │
└──────────────────┼──────────────────┘
│
▼
Stable ABI
│
┌───────┴───────┐
▼ ▼
Android iOS
Runtime modules share the Crossa runtime core.
They do not create independent runtimes or depend on each other unnecessarily.
Networking is the first major Crossa runtime capability because it proves the complete architecture:
Definition
│
▼
Compiler
│
▼
Typed IR
│
▼
Generated Request Plan
│
▼
Native Request Encoding
│
▼
Native Transport
│
▼
Native Response Buffer
│
▼
Native Parsing
│
▼
Typed Native Result
│
├─────────────┐
▼ ▼
Android iOS
The same compiler/runtime foundation is designed to eventually support additional native modules.
Database
WebSocket
Raw sockets
Binary protocols
Streaming
Caching
File transport
Compression
Cryptographic services
Telemetry
These are applications of the same runtime architecture — not separate Crossa products glued together.
Crossa development follows several non-negotiable ideas.
Performance-sensitive work stays native.
Android and iOS expose APIs; they do not duplicate runtime behavior.
Prefer specialization and generation over reflection and dynamic discovery.
Buffers, operations, native objects, responses, and views have clear lifetimes.
Queues, workers, buffers, pools, and caches must not grow without limits.
Data should remain in its most useful representation for as long as possible.
JNI and Swift/native crossings are architectural costs and should remain coarse-grained.
Identical sources and toolchains should produce equivalent generated output.
Crossa does not assume that native code automatically means faster software.
Performance decisions are benchmark-driven.
Crossa is not:
- a Kotlin Multiplatform replacement
- a UI framework
- a JavaScript runtime
- a general-purpose programming language
- a Retrofit clone
- a Ktor clone
- an OkHttp clone
- a URLSession clone
- a generic JSON library
- a collection of unrelated Android and iOS implementations
Crossa is a:
compiler-powered native runtime platform with generated platform APIs.
The long-term developer flow is intentionally simple:
Write / generate Crossa definitions
│
▼
Run Crossa compiler
│
▼
Generate native artifacts
│
┌──────┴──────┐
▼ ▼
Android AAR iOS XCFramework
│ │
▼ ▼
Add to app Add to app
The mobile application should consume generated APIs rather than rebuilding the underlying infrastructure.
Crossa performance is designed around the complete application data path.
We care about:
- request encoding time
- response parsing time
- allocations
- copies
- native memory
- managed memory
- JNI crossings
- Swift/native crossings
- scheduler overhead
- object materialization
- binary size
- cold startup
- connection reuse
- concurrency
- sustained workload behavior
The goal is not to win artificial microbenchmarks.
The goal is to remove unnecessary work from real mobile applications.
Crossa treats both mobile platforms as first-class targets.
| Android | iOS | |
|---|---|---|
| Public language | Kotlin | Swift |
| Native core | C++ | C++ |
| Distribution | AAR | XCFramework |
| Runtime work | Native | Native |
| Networking | Native | Native |
| Parsing | Native | Native |
| Scheduling | Native | Native |
| Platform role | Thin API | Thin API |
The architecture is shared.
The APIs remain native to each platform.
Crossa starts with networking.
The larger goal is a reusable compiled runtime platform:
Crossa Runtime
┌──────────────┼──────────────┐
│ │ │
Networking Database Realtime
│ │ │
│ ┌───┴───┐ ┌───┴────┐
│ │ │ │ │
│ Cache Files WebSocket Socket
│
└──────────────┬───────────────
│
▼
Shared Core
│
┌─────┴─────┐
▼ ▼
Android iOS
One compiler.
One runtime architecture.
Multiple native capabilities.
Crossa is built around a simple idea:
Do expensive shared work once, in the right place, and expose the smallest useful surface to every platform.
The language describes the work.
The compiler understands the work.
The runtime executes the work.
Android and iOS consume the result.