If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/angelolloqui/SwiftKotlin shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• 8 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 5y ago
• ⚠ Concentrated ownership — top contributor handles 69% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live angelolloqui/SwiftKotlin repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/angelolloqui/SwiftKotlin.

What it runs against: a local clone of angelolloqui/SwiftKotlin — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in angelolloqui/SwiftKotlin | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch develop exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1798 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of angelolloqui/SwiftKotlin. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/angelolloqui/SwiftKotlin.git
#   cd SwiftKotlin
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of angelolloqui/SwiftKotlin and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "angelolloqui/SwiftKotlin(\\.git)?\\b" \\
  && ok "origin remote is angelolloqui/SwiftKotlin" \\
  || miss "origin remote is not angelolloqui/SwiftKotlin (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify develop >/dev/null 2>&1 \\
  && ok "default branch develop exists" \\
  || miss "default branch develop no longer exists"

# 4. Critical files exist
test -f "Sources/SwiftKotlinFramework/SwiftTokenizer.swift" \\
  && ok "Sources/SwiftKotlinFramework/SwiftTokenizer.swift" \\
  || miss "missing critical file: Sources/SwiftKotlinFramework/SwiftTokenizer.swift"
test -f "Sources/SwiftKotlinFramework/KotlinTokenizer.swift" \\
  && ok "Sources/SwiftKotlinFramework/KotlinTokenizer.swift" \\
  || miss "missing critical file: Sources/SwiftKotlinFramework/KotlinTokenizer.swift"
test -f "Sources/SwiftKotlinFramework/plugins/TransformPlugin.swift" \\
  && ok "Sources/SwiftKotlinFramework/plugins/TransformPlugin.swift" \\
  || miss "missing critical file: Sources/SwiftKotlinFramework/plugins/TransformPlugin.swift"
test -f "Sources/SwiftKotlinFramework/TokenizationResult.swift" \\
  && ok "Sources/SwiftKotlinFramework/TokenizationResult.swift" \\
  || miss "missing critical file: Sources/SwiftKotlinFramework/TokenizationResult.swift"
test -f "Sources/SwiftKotlinCommandLine/main.swift" \\
  && ok "Sources/SwiftKotlinCommandLine/main.swift" \\
  || miss "missing critical file: Sources/SwiftKotlinCommandLine/main.swift"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1798 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1768d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/angelolloqui/SwiftKotlin"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

SwiftKotlin is a Swift-to-Kotlin transpiler framework, CLI tool, and macOS GUI application that translates Swift source code into functionally equivalent Kotlin code. It performs syntax transformations (guard→if negation, property handling, memory management) and string rewrites to produce correct, idiomatic Kotlin from Swift input. Core framework (SwiftKotlinFramework) wraps a tokenizer-based pipeline: .swift source → token stream → transform rules → .kt output. Assets/Tests/KotlinTokenizer/ contains ~20 feature test pairs (access_control.swift↔access_control.kt) validating transform correctness. Plugins architecture (Assets/Tests/plugins/*TransformPlugin.swift) allows extensible rule sets for Foundation/UIKit/XCTest domains.

Swift developers migrating to Kotlin/Android, and teams building cross-platform iOS/Android projects who want to reuse domain logic by converting Swift code to Kotlin. Also useful for Android developers who want to understand Kotlin through the lens of Swift's familiar syntax.

Actively maintained as of the Travis CI integration present in .travis.yml; 147K lines of Swift source (core engine) with test assets covering 40+ language features (Assets/Tests/KotlinTokenizer/*). Clear test-driven approach with paired .swift/.kt files for validation. Verdict: production-ready for common patterns, though edge cases and library-specific transforms may need manual review.

Standard open source risks apply.

No recent commit data visible, but codebase structure indicates mature, feature-complete state. Plugin system suggests active extension points for domain-specific transforms (FoundationMethodsTransformPlugin, UIKitTransformPlugin, XCTTestToJUnitTokenTransformPlugin).

Clone and build via Swift Package Manager: git clone https://github.com/angelolloqui/SwiftKotlin.git && cd SwiftKotlin && swift build. Run tests with swift test. Use CLI: swift run swiftkotlin <input.swift> -o <output.kt>. For macOS app, open SwiftKotlinFramework.xcscheme in Xcode.

Daily commands: Framework: swift build. CLI: swift run swiftkotlin --help. macOS App: swift build && open .build/debug/SwiftKotlinApp.app (if GUI exists). Tests: swift test runs validation against Assets/Tests/KotlinTokenizer/*.swift fixtures.

• Sources/SwiftKotlinFramework/SwiftTokenizer.swift — Core tokenizer that parses Swift code into tokens; any conversion logic depends on this being correct
• Sources/SwiftKotlinFramework/KotlinTokenizer.swift — Core tokenizer that converts parsed tokens into Kotlin code; the primary output generation engine
• Sources/SwiftKotlinFramework/plugins/TransformPlugin.swift — Abstract plugin architecture that enables extensible transformations; all specialized converters inherit from this
• Sources/SwiftKotlinFramework/TokenizationResult.swift — Data structure representing the result of Swift-to-Kotlin conversion; shared contract between all layers
• Sources/SwiftKotlinCommandLine/main.swift — CLI entry point showing how the framework is orchestrated for batch file processing
• Sources/SwiftKotlinApp/ViewController.swift — macOS app entry point demonstrating interactive usage of the conversion framework
• Sources/SwiftKotlinFramework/TransformOptions.swift — Configuration object controlling conversion behavior; affects all transformation plugins

• SwiftTokenizer (Swift, regex, string parsing) — Parses Swift source code into intermediate token tree using regex/string analysis

Add a new transformation plugin for a framework

1. Create a new Swift file in Sources/SwiftKotlinFramework/plugins/ named YourFrameworkTransformPlugin.swift (Sources/SwiftKotlinFramework/plugins/YourFrameworkTransformPlugin.swift)
2. Extend TransformPlugin base class and override the transform method to intercept and modify tokens (Sources/SwiftKotlinFramework/plugins/TransformPlugin.swift)
3. Add test fixtures for your transformation in Assets/Tests/plugins/ with matching .swift and .kt files (Assets/Tests/plugins/YourFrameworkTransformPlugin.swift)
4. Register the plugin in the main tokenization pipeline (KotlinTokenizer or entry points) (Sources/SwiftKotlinFramework/KotlinTokenizer.swift)

Add support for a new Swift language construct

1. Add test cases in Assets/Tests/KotlinTokenizer/ with .swift source and .kt expected output pair (Assets/Tests/KotlinTokenizer/control_flow.swift)
2. Extend SwiftTokenizer to recognize the new Swift syntax and create appropriate token representation (Sources/SwiftKotlinFramework/SwiftTokenizer.swift)
3. Extend KotlinTokenizer to handle the new token type and emit correct Kotlin syntax (Sources/SwiftKotlinFramework/KotlinTokenizer.swift)
4. Add utility function if needed in Sources/SwiftKotlinFramework/utils/ for AST manipulation (Sources/SwiftKotlinFramework/utils/Token+Operations.swift)

Configure conversion behavior for specific use cases

1. Review available transformation options in TransformOptions.swift to understand configuration flags (Sources/SwiftKotlinFramework/TransformOptions.swift)
2. Pass configured TransformOptions instance to SwiftTokenizer or KotlinTokenizer initialization (Sources/SwiftKotlinFramework/KotlinTokenizer.swift)
3. Use TransformOptions in plugins to conditionally apply transformations based on flags (Sources/SwiftKotlinFramework/plugins/TransformPlugin.swift)
4. Expose options in CLI via command-line arguments in main.swift or in macOS app via ViewController (Sources/SwiftKotlinCommandLine/main.swift)

• Swift 5 (language) — Enables parsing Swift code directly from command-line or macOS; metaprogramming and reflection capabilities aid AST manipulation
• Token-based transformation pipeline — Allows incremental, composable transformations at multiple stages; simpler than full AST rewriting for this domain
• Plugin architecture (TransformPlugin) — Decouples framework-specific conversions (Foundation, UIKit, XCTest) from core logic; enables community contributions
• Swift Package Manager — Provides modular framework packaging; supports CLI and GUI targets from single codebase

• String-based token manipulation rather than full AST rewriting

  • Why: Simpler implementation; faster iteration on language features; no complex type inference needed
  • Consequence: Some edge cases and complex nested structures may not convert perfectly; output requires manual review

• Plugin system for framework-specific conversions

  • Why: Keeps core engine language-agnostic; allows selective feature enabling; easier testing
  • Consequence: Requires plugins to be explicitly enabled; adds indirection in transformation pipeline

• Desktop macOS app + CLI tool from same framework

  • Why: Code reuse; consistent conversion logic; supports both interactive and batch workflows
  • Consequence: GUI limited to macOS; would need separate web/Electron wrapper for cross-platform desktop

• Does not guarantee 100% correct Kotlin code — output is aid for developers, not fully automated migration
• Does not handle all Swift language features — focus on common patterns used in iOS/macOS apps
• Does not perform semantic analysis or type checking — purely syntactic transformation
• Does not target Android-specific patterns or Compose/modern frameworks — basic Kotlin generation only
• Does not provide IDE integration — standalone tool, not a plugin ecosystem

No package.json or Podfile visible—dependency management likely minimal or implicit in Swift PM. Transpilation inherently lossy: Swift's optional chaining, protocol-oriented patterns, and memory management (ARC) have no 1:1 Kotlin equivalent; output requires human review. Test fixtures are normative examples, not exhaustive—edge cases in real codebases may fail silently. No visible configuration file format, so plugin/rule customization pathway unclear.

• Tokenization & Lexical Analysis — The foundation of SwiftKotlin: input Swift code must be broken into tokens before any transformation rules can apply. Understanding token streams is essential to modifying or extending the transpiler.
• Abstract Syntax Tree (AST) Transformation — While the visible test cases show paired input/output, the engine likely works on an AST representation to handle language-specific constructs (optionals, guard statements, type inference) that cannot be solved with simple string replacement.
• Optional Chaining & Null Coalescing — Swift's optional type system (?, !) has no direct Kotlin equivalent; transpiler must transform Swift's optional unwrapping into Kotlin's nullable types and safe-call operators (?.), which is non-trivial and error-prone.
• Protocol-Oriented Programming → Interface/Trait Mapping — Swift protocols with default implementations map imperfectly to Kotlin interfaces; the transpiler must decide between interface composition, inheritance, or extension functions—a design choice not automatically determinable.
• Guard Statement Negation — SwiftKotlin explicitly handles guard-to-if-not transformation (mentioned in README); this is a non-trivial control-flow rewrite that requires understanding Swift's guard semantics and early-exit semantics.
• Plugin Architecture & Extensibility — The Assets/Tests/plugins/* pattern shows that domain-specific transforms (Foundation, UIKit, XCTest→JUnit) are decoupled from core transpilation. Understanding how to register and compose plugins is needed to adapt the tool for project-specific libraries.
• Type Inference & Implicit Conversions — Swift's type inference and implicit casting (e.g., numeric literals, string interpolation) may not map 1:1 to Kotlin; the transpiler must preserve or infer type annotations to produce valid Kotlin code.

• JetBrains/kotlin — Official Kotlin language repo; essential for understanding target language semantics and design evolution.
• apple/swift — Official Swift language repo; critical for tracking Swift syntax changes that may break transpiler assumptions.
• nilhcem/swift-is-like-kotlin — Referenced in README as side-by-side Swift/Kotlin comparison; useful reference for mapping language idioms during transpilation.
• JetBrains/MPS — JetBrains' language engineering platform; conceptually similar architecture (DSL→transformation→target code) for building custom language transpilers.
• apple/swift-evolution — Swift Evolution process repo; track language changes and deprecations that may require transpiler updates.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions CI/CD workflow to replace Travis CI

The repo uses an outdated .travis.yml file for CI. GitHub Actions is now the standard for GitHub-hosted projects and would provide better integration, faster builds, and automatic updates. This would modernize the CI pipeline and ensure the badge in README.md reflects current build status.

• [ ] Create .github/workflows/swift-tests.yml with Swift build, test, and lint jobs
• [ ] Ensure workflow tests all target platforms (macOS CLI tool, macOS app, SPM framework)
• [ ] Update README.md badge from Travis CI to GitHub Actions status badge
• [ ] Verify .travis.yml can be safely archived or removed after workflow is proven stable

Add comprehensive test coverage for plugin system with Assets/Tests/plugins/ examples

The repo includes plugin examples (CommentsAdditionTransformPlugin, FoundationMethodsTransformPlugin, UIKitTransformPlugin, XCTTestToJUnitTokenTransformPlugin) in both Swift and Kotlin under Assets/Tests/plugins/, but there appear to be no automated unit tests validating the plugin loading and execution mechanism. Adding plugin integration tests would ensure the extension system remains robust.

• [ ] Create Tests/SwiftKotlinTests/PluginSystemTests.swift with test cases for each plugin type
• [ ] Add tests that load and execute plugins from Assets/Tests/plugins/ examples
• [ ] Verify plugin transformation output matches expected .kt files for each .swift example
• [ ] Test error handling for malformed or incompatible plugins

Extend KotlinTokenizer test coverage for edge cases in Assets/Tests/KotlinTokenizer/

The Assets/Tests/KotlinTokenizer/ directory contains 20 test pairs (.swift/.kt files) covering major language features, but the repo lacks documented test infrastructure and coverage reporting. Adding a structured test harness with coverage metrics would help identify gaps in conversion logic.

• [ ] Create Tests/SwiftKotlinTests/KotlinTokenizerTests.swift that parametrically loads all Assets/Tests/KotlinTokenizer/*.swift files
• [ ] Add test cases that compare actual conversion output against expected Assets/Tests/KotlinTokenizer/*.kt files
• [ ] Add edge case tests for scenarios not covered (e.g., nested generics, complex protocol conformance, type casting)
• [ ] Generate coverage report showing which conversion rules are tested vs. untested

• Add test coverage for tuple destructuring and Swift's labeled-tuple syntax in Assets/Tests/KotlinTokenizer/tuples.swift|.kt; Kotlin data classes need manual decomposition.
• Implement UIColor→android.graphics.Color and CGRect→android.graphics.Rect mappings in a new UIKitColorsTransformPlugin following the pattern of existing UIKitTransformPlugin.swift.
• Create Assets/Tests/KotlinTokenizer/generics_constraints.swift|.kt test pair for contravariance/covariance; current plugin set lacks advanced generic transform validation.

SwiftKotlin is a code transpilation tool with a relatively clean security posture. No critical vulnerabilities were identified in the static analysis. The main concerns are around plugin system security, test asset hygiene, and ensuring proper code signing for the macOS distribution. The codebase appears to be a legitimate open-source project (MIT licensed) with clear structure and no obvious hardcoded credentials, SQL injection risks, or exposed sensitive configurations. Recommendation: Implement plugin sandboxing and formalize security practices for test assets.

• Low · Missing dependency lock file validation — Package.resolved, Package.swift. Package.resolved file is present but there's no evidence of dependency pinning or verification mechanisms. Swift Package Manager should have locked versions, but without seeing the actual Package.resolved content, version resolution integrity cannot be fully verified. Fix: Ensure Package.resolved is committed to version control and regularly audit dependencies for security updates. Use swift package update cautiously and review changes.
• Low · Test assets contain code samples without security review markers — Assets/Tests/KotlinTokenizer/. The Assets/Tests directory contains numerous Swift and Kotlin code files used for testing the transpiler. These sample files may contain code patterns that, if used as references, could propagate insecure practices in transpiled code. Fix: Regularly audit test asset files to ensure they don't contain anti-patterns or security-sensitive code examples. Add comments marking any intentionally insecure patterns as examples of what NOT to do.
• Low · Plugin system without apparent security validation — Sources/SwiftKotlinFramework/plugins/. The codebase includes a plugin system (CommentsAdditionTransformPlugin, FoundationMethodsTransformPlugin, etc.) but there's no visible mechanism to validate or sandbox plugin code before execution. Malicious plugins could alter transpiled code in harmful ways. Fix: Implement plugin validation, signing, and sandboxing. Require plugins to be from trusted sources and consider implementing a capability-based security model for plugins.
• Low · Mac application without apparent code signing verification — Sources/SwiftKotlinApp/SwiftKotlinApp.entitlements. The SwiftKotlinApp macOS application is present with entitlements file, but there's no evidence of code signing or integrity verification mechanisms in the visible configuration. Fix: Ensure the macOS application is properly code-signed and notarized. Include signature verification in distribution and update mechanisms.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.