# Configuration Options in gradle.properties for Building the Muse App

> Discover essential gradle properties for the kkoshin/muse app. Fine tune build settings for memory, AndroidX, KMP, and R class behavior for Android and iOS.

- Repository: [Ko Shin/muse](https://github.com/kkoshin/muse)
- Tags: how-to-guide
- Published: 2026-03-05

---

**The `gradle.properties` file in the kkoshin/muse repository defines eight critical Gradle and Android settings—including memory allocation, AndroidX migration, Kotlin Multiplatform source set layouts, and R class behavior—that control how the Muse application compiles and packages across Android and iOS targets.**

The Muse project utilizes a Kotlin Multiplatform Mobile (KMM) architecture, requiring precise build configuration to manage both Android and iOS targets from a single codebase. The `gradle.properties` file located at the repository root ([`gradle.properties` line 1‑16](https://github.com/kkoshin/muse/blob/main/gradle.properties#L1-L16)) serves as the central hub for these settings, influencing everything from compiler memory limits to cross-platform dependency linking.

## Gradle Daemon and JVM Configuration

### Memory Allocation and Encoding

The **`org.gradle.jvmargs`** property configures the Gradle daemon's runtime environment with specific performance parameters:

```properties
org.gradle.jvmargs=-Xmx4096M -Dfile.encoding=UTF-8 -Dkotlin.daemon.jvm.options="-Xmx4096M"

```

This allocates **4 GB of heap memory** (`-Xmx4096M`) to prevent out-of-memory errors during large multi-module compilations. The UTF-8 encoding flag ensures consistent character handling across different operating systems, while the nested Kotlin daemon options mirror the heap limit for the Kotlin compiler process itself. According to the source code, these settings are essential for stable builds when processing Kotlin/Native artifacts alongside Android resources.

## Android Build Behavior

### R Class Generation and Transitivity

Setting **`android.nonTransitiveRClass=true`** enables non-transitive R classes, forcing each library module to generate its own isolated `R` class rather than sharing a single transitive one. This reduces compilation time and eliminates unnecessary coupling between modules, representing the modern Android Gradle Plugin (AGP) default behavior.

### AndroidX Migration

The **`android.useAndroidX=true`** flag mandates AndroidX libraries over the legacy Support Library. This ensures compatibility with modern Android APIs and third-party dependencies that have migrated to the AndroidX namespace.

### Compiler and DSL Control

Two properties manage how Kotlin integrates with the Android build system:

- **`android.builtInKotlin=false`** — Disables the built-in Kotlin support provided by AGP, forcing the build to use the explicitly declared Kotlin Gradle plugin version for finer compiler control.
- **`android.newDsl=false`** — Retains the classic Android Gradle DSL syntax rather than adopting the newer experimental DSL.

Notably, both `android.builtInKotlin=false` and `android.newDsl=false` appear twice in [`gradle.properties`](https://github.com/kkoshin/muse/blob/main/gradle.properties). This duplication is harmless, as Gradle properties follow a "last write wins" precedence model.

## Kotlin Multiplatform Configuration

### Source Set Layout Version

The **`kotlin.mpp.androidSourceSetLayoutVersion=2`** property selects the newer Android source set layout for Kotlin Multiplatform projects. This aligns the module structure with current Kotlin MPP conventions, simplifying the organization of platform-specific code in `commonMain`, `androidMain`, and `iosMain` directories.

### iOS CocoaPods Integration

For Apple targets, **`kotlin.apple.deprecated.allowUsingEmbedAndSignWithCocoaPodsDependencies=true`** suppresses deprecation warnings when embedding and signing CocoaPods dependencies. This prevents build failures when integrating iOS-specific libraries through CocoaPods, which the Muse project uses for native iOS functionality.

### Code Style Enforcement

The **`kotlin.code.style=official`** setting enforces the official Kotlin coding style across the entire project. This affects IDE formatting rules—such as indentation and brace placement—ensuring consistent code formatting without impacting runtime behavior.

## Practical Configuration Examples

Adjust these properties to adapt the build for different environments:

**1. Reducing Memory for CI Environments**
For continuous integration runners with limited resources, decrease the heap allocation:

```properties
org.gradle.jvmargs=-Xmx2048M -Dfile.encoding=UTF-8

```

**2. Restoring Transitive R Classes**
If legacy dependencies require the older R class behavior, disable non-transitive mode:

```properties
android.nonTransitiveRClass=false

```

**3. Adopting the New Android DSL**
To migrate to the newer DSL syntax, update the flag and modify your `build.gradle.kts` files accordingly:

```properties
android.newDsl=true

```

## Summary

- The `org.gradle.jvmargs` setting in [`gradle.properties`](https://github.com/kkoshin/muse/blob/main/gradle.properties) allocates 4GB heap memory and UTF-8 encoding for stable compilation.
- **Non-transitive R classes** and **AndroidX** are enabled by default to optimize build performance and maintain modern compatibility.
- Kotlin Multiplatform settings control iOS CocoaPods integration and Android source set layout version 2.
- Duplicate entries for `android.builtInKotlin` and `android.newDsl` follow Gradle's "last wins" semantics without causing errors.
- These configurations interact with [`build.gradle.kts`](https://github.com/kkoshin/muse/blob/main/build.gradle.kts) and [`settings.gradle.kts`](https://github.com/kkoshin/muse/blob/main/settings.gradle.kts) to define the complete build environment.

## Frequently Asked Questions

### What does `android.nonTransitiveRClass=true` do in the Muse build?

This setting forces each module to maintain its own isolated `R` class rather than inheriting resources from dependencies. It reduces compilation time and prevents resource ID conflicts between modules, which is particularly important for the Muse project's multi-module KMM structure.

### Why is `org.gradle.jvmargs` configured with 4GB of memory?

The 4GB allocation (`-Xmx4096M`) accommodates the memory demands of compiling Kotlin Multiplatform code for both Android and iOS targets simultaneously. According to the kkoshin/muse source, this prevents daemon crashes when processing large Kotlin/Native artifacts alongside Android resource linking.

### How do the Kotlin Multiplatform settings affect iOS builds?

The `kotlin.mpp.androidSourceSetLayoutVersion=2` property standardizes how Android-specific code is organized within the shared KMM structure, while `kotlin.apple.deprecated.allowUsingEmbedAndSignWithCocoaPodsDependencies=true` specifically enables iOS CocoaPods integration by bypassing deprecation warnings during the embed-and-sign phase of iOS framework generation.

### Can I safely remove the duplicate `android.builtInKotlin` and `android.newDsl` lines?

Yes, the duplicate entries are harmless because Gradle processes properties sequentially and applies the last defined value. You can consolidate them into single declarations without affecting the build, though the current configuration explicitly reinforces these critical compiler settings.