Bridge pod pattern and kn gc fix

[jinweihan93-ops]

No description provided.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request introduces a comprehensive research project and proof-of-concept for a Kotlin Multiplatform (KMP) V3 split-delivery architecture, specifically addressing the 'dual runtime' problem in iOS XCFrameworks. It includes new Gradle modules for Foundation and Business logic, ObjC bridge implementations, and a suite of diagnostic tools and verification scripts. Feedback focuses on improving the portability of shell scripts and documentation by removing hardcoded paths and device IDs, correcting relative paths in the Podfile to ensure clean builds, and refactoring Gradle build scripts to reduce configuration duplication across iOS targets. Additionally, it is recommended that the Business module adopts the more robust C-based bridge storage pattern used in the Foundation module.

[gemini-code-assist]

The script contains hardcoded values for the device UDID and the workspace path. This makes the script non-portable and will cause it to fail on other developers' machines. These should be made dynamic, for example by using arguments or environment variables, or by deriving them relative to the script's location.

Suggested change

	DEVICE=93C1CE99-BB65-4FB8-874C-48BD1056E350
	BUNDLE=com.exampe.kmp.getstarted.KMPGetStartedCodelab
	WORKSPACE=/Users/bytedance/codelab-android-kmp/get-started/iosApp/KMPGetStartedCodelab.xcworkspace
	DEVICE=${1:-$(xcrun simctl list devices booted | grep -o '[A-F0-9]\\{8\\}-[A-F0-9]\\{4\\}-[A-F0-9]\\{4\\}-[A-F0-9]\\{4\\}-[A-F0-9]\\{12\\}' | head -n 1)}
	BUNDLE=com.exampe.kmp.getstarted.KMPGetStartedCodelab
	WORKSPACE="$(dirname "$0")/iosApp/KMPGetStartedCodelab.xcworkspace"

[gemini-code-assist]

The framework search paths in the post_install hook use a relative path $(PODS_ROOT)/../.. which resolves to the get-started directory. Based on the project structure and Gradle scripts, the kmp-local-repo directory is a sibling of get-started, not a child. This will cause build failures on a clean checkout. The path should be corrected to point three levels up from PODS_ROOT to reach the parent of get-started.

        "\"$(PODS_ROOT)/../../../kmp-local-repo/foundationKit/foundationKit.xcframework/ios-arm64-simulator\"",
        "\"$(PODS_ROOT)/../../../kmp-local-repo/foundationKit/foundationKit.xcframework/ios-arm64\"",
        "\"$(PODS_ROOT)/../../../kmp-local-repo/businessKit/businessKit.xcframework/ios-arm64-simulator\"",
        "\"$(PODS_ROOT)/../../../kmp-local-repo/businessKit/businessKit.xcframework/ios-arm64\""

[gemini-code-assist]

The documentation contains a hardcoded absolute file path. This is specific to one developer's machine and reduces the portability and usefulness of the documentation for others. It should be replaced with a relative path or a placeholder to make it universally applicable.

Suggested change

	*项目路径：`/Users/bytedance/codelab-android-kmp/get-started`*
	*项目路径：`./get-started` (项目根目录)*

[gemini-code-assist]

The configurations for iosArm64 and iosSimulatorArm64 are nearly identical. This duplication can be reduced by iterating over a list of targets, which would make the script more concise and easier to maintain.

    listOf(
        iosArm64(),
        iosSimulatorArm64()
    ).forEach { target ->
        target.compilations["main"].cinterops.create("businessBridge") {
            defFile(project.file("../business-bridge/businessBridge.def"))
            includeDirs(project.file("../business-bridge/headers"))
        }
        target.binaries.framework {
            baseName = xcfName
            xcf.add(this)
            // KMT-2364: Do NOT re-export Foundation types — their ObjC bridge lives in
            // foundationKit.framework only. Re-exporting causes duplicate ObjC class
            // registration, corrupting the BackRef→ObjHeader* mapping.
            binaryOption("embedRuntime", "false")
            binaryOption("externalKlibs", "com.example.kmp.foundation")
            val suffix = if (buildType == NativeBuildType.DEBUG) "debug" else "release"
            linkerOpts(
                "-framework", "foundationKit",
                // foundationKit.framework is produced by foundationCommon (not KMPFoundation).
                "-F", "${projectDir}/../../foundation/foundationCommon/build/bin/${target.targetName}/${suffix}Framework"
            )
        }
    }

[gemini-code-assist]

The bridge delegates _authDelegate and _networkDelegate are stored in mutable Kotlin internal vars. This pattern is less robust than the one used in the foundation module, which uses C functions and static Obj-C variables for storage. The foundation module's approach is safer against cross-dylib linking issues and provides better encapsulation. For consistency and future-proofing, the business module should adopt the same pattern.

[gemini-code-assist]

The configurations for iosArm64 and iosSimulatorArm64 are nearly identical. This duplication can be reduced by iterating over a list of targets, making the script more concise and easier to maintain.

    listOf(
        iosArm64(),
        iosSimulatorArm64()
    ).forEach { target ->
        target.compilations["main"].cinterops.create("foundationBridge") {
            defFile(project.file("../foundation-bridge/foundationBridge.def"))
            includeDirs(project.file("../foundation-bridge/headers"))
        }
        target.binaries.framework {
            baseName = xcfName
            xcf.add(this)
            // Split-framework: foundationKit embeds the runtime so businessKit doesn't have to.
            binaryOption("exportRuntimeSymbols", "true")
            binaryOption("exportKlibSymbols", "com.example.kmp.foundation")
        }
    }

[gemini-code-assist]

The script hardcodes a specific simulator device UDID. This makes it brittle and not portable to other development environments. Consider making the device UDID configurable via an argument or automatically detecting a booted simulator.

Suggested change

	DEVICE=93C1CE99-BB65-4FB8-874C-48BD1056E350
	DEVICE=${1:-$(xcrun simctl list devices booted | grep -o '[A-F0-9]\\{8\\}-[A-F0-9]\\{4\\}-[A-F0-9]\\{4\\}-[A-F0-9]\\{4\\}-[A-F0-9]\\{12\\}' | head -n 1)}

[gemini-code-assist]

The _run helper function suppresses errors from subprocess calls by returning an empty string. This can hide important issues during analysis, making debugging difficult. It would be more robust to log the error to stderr before returning.

Suggested change

	try:
	return subprocess.check_output(cmd, stderr=subprocess.DEVNULL, text=True)
	except subprocess.CalledProcessError:
	return ""
	def _run(self, cmd: List[str]) -> str:
	try:
	return subprocess.check_output(cmd, stderr=subprocess.PIPE, text=True)
	except subprocess.CalledProcessError as e:
	print(f"Warning: Command '{' '.join(cmd)}' failed with exit code {e.returncode}:\n{e.stderr}", file=sys.stderr)
	return ""