Configuration Options in gradle.properties for Building the Muse App

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) 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:

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. 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:

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:

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:

android.newDsl=true

Summary

• The org.gradle.jvmargs setting in 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 and 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}