skiptools / skiptools/skip

Configuration-aware bridge generation: honor `#if DEBUG` so debug-only Swift API can be excluded from release Kotlin bridges

Open
#715 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Swift
Stars
3.2k
Forks
106
Avg merge
6d 13h
Merged PRs (30d)
1

Description

Context: SkipFuse app, native mode with bridging. We keep mock factories for SwiftUI/Compose previews in shared Swift behind conditional compilation. On iOS, #if DEBUG strips them from release builds. On Android there is no equivalent: the bridge generator evaluates #if DEBUG as false in every configuration, including skip export --debug.

Repro: given a bridged entity with a debug-only mock factory:

// Sources/AppData/EEvent.swift
// SKIP @bridge
public struct EEvent {
    public let id: String
    public let title: String
}

#if DEBUG
// SKIP @bridge
extension EEvent {
    public static func mock(id: String = "mock_id") -> EEvent {
        EEvent(id: id, title: "Mock event")
    }
}
#endif 

the generated Kotlin facade omits the extension even in a debug export — the output under .build/plugins/outputs/.../skipstone/.../EEvent.kt contains the EEvent bridge but no mock(), so this Compose preview fails with Unresolved reference 'mock':

@Preview
@Composable
fun EventCellPreview() {
    CUIEventCell(event = EEvent.mock())   // e: Unresolved reference 'mock'
}

which works, but means every mock factory — implementations, fake-data string literals, and their Kotlin bridge classes — ships in release Android builds. R8 can strip the unreferenced bridge classes from the DEX, but the native implementations and strings still ship in the production .so. On iOS the same code is correctly stripped from release, so the two platforms can't be given parity here.

Request: a way for skip export --release to exclude blocks from bridge generation and native compilation that --debug includes. Either honoring DEBUG to match SwiftPM's debug-configuration behavior

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the bridged Swift example in Sources/AppData/EEvent.swift and reproduce the behavior with skip export --debug and skip export --release. Compare the generated EEvent.kt under .build/plugins/outputs/.../skipstone/ and verify that debug includes mock() while release excludes the bridge and native debug-only code.

Written by the indexing model from the issue text.

Assessment

Tech stack
kotlin, swift
Domain
build-system, mobile-dev
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.