Skip to content

Let Gradle handle KMP build caching on Xcode builds #60

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 11, 2025

Conversation

cartland
Copy link
Contributor

This resolves an Xcode build warning:

Run script build phase 'Compile Kotlin Multiplatform' will be run during every build because it does not specify any outputs. To address this issue, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase.

This resolves an Xcode build warning:

    Run script build phase 'Compile Kotlin Multiplatform' will be run during every build because it does not specify any outputs. To address this issue, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase.
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Summary of Changes

Hello @cartland, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an Xcode build warning related to the Kotlin Multiplatform compilation script. By marking the script phase as always needing to run, we ensure it executes consistently and eliminate the warning, improving the build process clarity.

Highlights

  • Xcode Build Warning Fix: Explicitly configured the 'Compile Kotlin Multiplatform' build phase in the Xcode project to always run, resolving a build warning about the script not specifying outputs.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in issue comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configureGemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

The pull request updates the Xcode project to ensure the shared Kotlin Multiplatform module is built on every Xcode build. This resolves a build warning. The review highlights a potential trade-off: while the warning is fixed, this change might increase incremental build times. It suggests exploring the alternative of specifying input/output files for the build script phase to allow Xcode's dependency analysis to optimize rebuilds, or documenting the decision if the current approach is preferred after consideration.

@@ -163,6 +163,7 @@
/* Begin PBXShellScriptBuildPhase section */
7555FFB5242A651A00829871 /* Compile Kotlin Multiplatform */ = {
isa = PBXShellScriptBuildPhase;
alwaysOutOfDate = 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

This change effectively silences the Xcode warning by forcing the 'Compile Kotlin Multiplatform' script to run on every build.

While this addresses the warning, it might lead to longer incremental build times because the shared module will recompile even if its source files or dependencies haven't changed. This could particularly impact developer productivity on larger projects or during frequent build cycles.

Have you considered the alternative approach of specifying input and output files for this script phase? This would allow Xcode to leverage its dependency analysis and potentially skip unnecessary recompilations. For instance:

  • Output Files: The path to the generated shared.framework (e.g., $(CONFIGURATION_BUILD_DIR)/$(FRAMEWORKS_FOLDER_PATH)/shared.framework).
  • Input Files: Key source directories of the shared module (e.g., $(SRCROOT)/../shared/src), the build.gradle.kts of the shared module, or a specific marker file that changes upon successful KMP compilation.

Defining these accurately can significantly optimize build times. If this approach was considered and deemed too complex or problematic for the current setup, it might be beneficial to document the rationale behind choosing alwaysOutOfDate = 1 for future maintainers, perhaps in a project README or a wiki page discussing build configurations.

@cartland
Copy link
Contributor Author

Xcode has a warning because the Build Phase "Compile Kotlin Multiplatform" is only supposed to run "Based on dependency analysis", but then the rest of the configuration doesn't specify any Input Files or Output Files. Xcode doesn't like that we tell it to conditionally run the script, but we don't give it any conditions.

Options:

  • Abandon this PR: Leave the warning as-is so developers can handle it on their own.
  • Accept this PR: Silence the warning. Declare that the XCFramework is expected to build every time (as it already does).
  • Add dependency detection logic: We could do something like this: main...cartland:github-android-kotlin-multiplatform-samples:ios-outputs
    • Adding the extra logic has several risks: Correctness (we might introduce a bug) & Complexity (increased mental load) & Limited Value (this sample code doesn't take long to build). This is why I think we should either decide to silence the warning or leave the warning as-is so developers can decide how to optimize on their own.

@cartland cartland changed the title Build shared module on every Xcode build Let Gradle handle KMP build caching on Xcode builds Jun 11, 2025
@cartland cartland merged commit 4fd84cc into android:main Jun 11, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants