GO — Healthy across the board

• Last commit today
• 23+ active contributors
• Distributed ownership (top contributor 40% of recent commits)
• Apache-2.0 licensed
• CI configured
• ⚠ No test directory detected

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Lynx is a cross-platform native UI engine that compiles web-standard code (CSS + React-like JavaScript) to native Android, iOS, Harmony, Windows, and macOS apps from a single codebase. It provides a multithreaded C++ core engine (31.5M lines) that renders pixel-perfect UIs natively on each platform while maintaining web developer familiarity. Monorepo structure: core C++ engine in root with platform-specific bindings (platform/android/, platform/ios/, etc.). GitHub Actions workflows in .github/actions/ define build recipes for each platform (android-explorer-build, clay-macos-build, ios-explorer-build). npm packages published from this repo (lynx-core, lynx-types, tasm, type-config, type-element-api, css-defines). Lynx Explorer app provides reference implementations.

Web developers and frontend engineers who want to ship truly native mobile apps without learning platform-specific languages (Kotlin, Swift, Objective-C). Teams building cross-platform products who need performance at scale and consistent rendering across 5+ OS targets from React-like components.

Actively maintained with strong organizational infrastructure: 23+ automated GitHub Actions workflows (ci.yml, publish pipelines for iOS/Android/Harmony), detailed issue templates, multiple SDK release channels (lynx-core, lynx-types published via npm), and platform-specific explorers. Production-ready for mobile targeting iOS 10+ and Android 5.0+; web/desktop support is documented as available.

Large polyglot codebase (C++/Java/Objective-C/Kotlin/TypeScript) means ecosystem fragmentation risk and onboarding complexity. No visible open issue count in provided data, but 5+ platform targets (Android, iOS, Harmony, Windows, macOS) mean QA burden. Cross-platform rendering consistency is hard; pixel-perfect claims need testing per OS. Dependency on NDK/native toolchains adds setup friction vs. pure JS frameworks.

Multiple SDK release channels active: android-sdk-release, ios-sdk-publish, harmony-explorer-build workflows indicate ongoing platform expansion. Recent additions include Harmony OS support (harmony-explorer-build action) and Windows/macOS explorer builds (macos-explorer-build, windows-explorer-build actions). Type system tooling being published (lynx-types, type-config, type-element-api). Code quality scanning enabled (codeql.yml).

Clone with git clone https://github.com/lynx-family/lynx.git && cd lynx. Check .npmrc for npm config (likely private scopes). Platform-specific setup: see .github/actions/setup-android-env/action.yml for Android (NDK, SDK), .github/actions/ios-common-deps/action.yml for iOS (CocoaPods, Xcode). Run npm install to bootstrap monorepo dependencies. Reference lynxjs.org/guide/start/quick-start.html for hello-world template.

Daily commands: Android Explorer: ./gradlew :android:explorer:installDebugMode (requires Android SDK 21+, NDK per rootProject.ext.ndkVersion). iOS Explorer: use clay-macos-build action or xcodebuild -workspace ios/Lynx.xcworkspace -scheme LynxExplorer. See .github/workflows/ci.yml for full CI; it triggers on push to develop branch and tests all platforms. Web/dev: npm install && npm run build (inferred from lynx-types-publish, tasm-publish workflows).

• BUILD.gn — Root build configuration using GN build system; defines compilation flags, dependencies, and platform-specific targets across all platforms.
• base/include/base_public_headers.gni — Exposes core public headers from base layer; every platform-specific implementation depends on these fundamental utilities and abstractions.
• .github/workflows/ci.yml — Primary CI/CD pipeline; orchestrates builds for Android, iOS, macOS, Windows, and Harmony platforms—failures block all contributions.
• base/include/debug/lynx_assert.h — Core assertion and error handling macros used throughout the codebase; violations indicate serious architectural misuse.
• .github/PULL_REQUEST_TEMPLATE.md — PR submission expectations and review guidelines; sets tone for contribution quality and merge standards.
• CODE_OF_CONDUCT.md — Community governance and contributor behavior standards; foundational for healthy open-source ecosystem.
• CONTRIBUTING.md — Complete contribution workflow, branch strategy, and development environment setup; essential onboarding for all new contributors.

Add Support for a New Platform

1. Create platform-specific action file under .github/actions/{platform}-explorer-build/action.yml following existing patterns (e.g., android-explorer-build/action.yml) (.github/actions/android-explorer-build/action.yml)
2. Define platform build targets in root BUILD.gn with conditional logic for your platform (BUILD.gn)
3. Add platform-specific CI job to .github/workflows/ci.yml that calls your new action (.github/workflows/ci.yml)
4. Create platform SDK release workflow under .github/workflows following pattern of lynx-core-publish.yml (.github/workflows/lynx-core-publish.yml)
5. Add platform-native base layer implementations following base/include structure conventions (base/README.md)

Add a New Base Utility Module

1. Create header file under base/include/ (e.g., base/include/my_utility.h) with clear public interface (base/include/algorithm.h)
2. Export new header in base/include/base_public_headers.gni so dependents can access it (base/include/base_public_headers.gni)
3. Add implementation and unit tests, ensuring compliance with CPPLINT rules (base/CPPLINT.cfg)
4. Document with examples in base/README.md for discoverability by other platform teams (base/README.md)

Release a New Version to npm/SDK Registries

1. Push tag matching semver format to develop branch (e.g., v1.2.3) (.github/workflows/publish-release.yml)
2. Merge to develop; automated publish-release.yml triggers, calling individual package workflows (.github/workflows/lynx-core-publish.yml)
3. Verify platform-specific SDKs publish correctly via ios-sdk-publish and android-sdk-release actions (.github/actions/ios-sdk-publish/action.yml)
4. Generated changelog appears in GitHub releases via generate-changelog action (.github/actions/generate-changelog/action.yml)

Enforce Code Quality Standards in a PR

1. Follow C++ formatting rules defined in .clang-format; run formatter on all changes (.clang-format)
2. Ensure code passes CPPLINT via CPPLINT.cfg and base/CPPLINT.cfg rules (CPPLINT.cfg)
3. Use assertion framework from base/include/debug/lynx_assert.h for error handling (base/include/debug/lynx_assert.h)
4. Complete PR checklist in .github/PULL_REQUEST_TEMPLATE.md before submitting (.github/PULL_REQUEST_TEMPLATE.md)

• GN Build System — Enables fast, platform-agnostic multi-target compilation; used by Chromium for managing complex cross-platform builds (Android, iOS, macOS, Windows, Harmony).
• C++ with FML (Flutter Message Layer) — Core runtime performance critical for web-on-native rendering; FML provides proven async messaging and threading primitives proven at scale.
• GitHub Actions CI/CD — Native integration with repository; supports matrix builds across platforms and automated release pipelines without external infrastructure.
• npm + CocoaPods + Gradle — Multi-language distribution strategy: npm for JS/TS developers, CocoaPods for iOS, Gradle for Android—reaches each platform's native developers in their ecosystem.

• Single C++ codebase with platform-specific SDKs (not cross-platform abstraction layer like React Native)

  • Why: Maximizes performance and native feature access; avoids overhead of JS bridge or intermediate layer.
  • Consequence: Requires platform-specific explorer apps and testing per OS; higher maintenance burden but better runtime characteristics.

• Multi-package publishing (lynx-core, lynx-types, css-defines, tasm, type-config, type-element-api)

  • Why: Allows fine-grained dependency management and independent versioning per domain (runtime vs. types vs. tooling).
  • Consequence: More complex release coordination; breaking changes in one package can affect downstream; requires

1. Android: minSdkVersion in build.gradle is 16 (API 16 = Android 4.1) but repo README claims 'Android 5.0 (API 21) or newer' — verify which is enforced. 2) multiDexEnabled true required; apps must handle 65K method limit. 3) NDK version pinned via rootProject.ext.ndkVersion — if undefined, gradle sync fails silently. 4) iOS CocoaPods may require pod cache clean --all on clean CI runners. 5) Harmony OS builds use custom GN toolchain (rare); no gradle, Xcode, or CMake — learning curve steep. 6) Platform flavor variants (debugMode/asan/noasan) affect binary size/perf drastically; wrong flavor in release causes crashes.

• Multithreaded Rendering Engine — Lynx's core differentiator is off-main-thread rendering (C++ engine runs on dedicated threads); explains minSdkVersion=16 requirement and why CI tests multiple architectures (arm, x86). Critical to understand for any performance debugging.
• JNI (Java Native Interface) — Android bindings (platform/android/src/main/java/*) call C++ engine via JNI; any Android-specific bug often traces to JNI marshalling boundaries, memory layout mismatches, or GC interaction.
• Flavor-based Build Variants — Android flavors (debugMode/asan/noasan) in build.gradle are NOT just cosmetic; asan (AddressSanitizer) flavor produces different binary with runtime checks, breaking binary-only dependencies. Critical for CI/CD correctness.
• CSS-in-Native Rendering — Unlike React Native (which uses Yoga flex layout), Lynx claims 'CSS + React' design; core engine must parse/evaluate CSS and map to platform-native views (UIView on iOS, View on Android). This is novel vs competitors.
• Cross-Platform ABI (Application Binary Interface) Compatibility — 5 platforms (Android/iOS/Harmony/Windows/macOS) means C++ ABI must be stable across compilers (clang, MSVC, gcc), architectures (arm, arm64, x86, x86_64), and ABIs. .clang-format enforces style but ABI breaks are silent at compile time.
• GN Build System — Presence of .gn file indicates Chromium/Chrome's GN metabuild tool (not CMake or gradle); used for Harmony/Windows/macOS builds and indicates architectural decision to diverge from Android/iOS gradle/Xcode setup.
• AddressSanitizer (ASAN) — Separate build flavor ('-fsanitize=address' in asan flavor) catches memory bugs at runtime; critical for C++ engine stability. CI likely runs asan flavor separately to catch leaks before release.

• facebook/react-native — Direct competitor: also compiles JS to native iOS/Android via JNI/Objective-C bridge, but Lynx emphasizes CSS + web standard rendering vs React Native's component model
• NativeScript/NativeScript — Similar web-to-native approach using TypeScript/JavaScript, targets iOS/Android; Lynx differentiates with multithreaded C++ renderer and claimed performance advantages
• flutter/flutter — Competing cross-platform engine (Dart-based); Lynx targets web developers specifically, Flutter targets language-agnostic teams; both claim pixel-perfect rendering
• lynx-family/lynx-types — TypeScript type definitions companion repo; published via lynx-types-publish.yml workflow in this monorepo; developers need both core engine and type stubs
• lynx-family/reactlynx — Official React-compatible DSL layer for Lynx (mentioned in Lynx Explorer section); developers use this to write components instead of raw C++

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 comprehensive CI workflow for cross-platform SDK builds and testing

The repo has multiple platform-specific build actions (android-explorer-build, ios-explorer-build, macos-explorer-build, windows-explorer-build) but the main ci.yml workflow is not visible. There's no clear evidence of automated testing across all supported platforms (Android, iOS, macOS, Windows, HarmonyOS) on every PR. This is critical for a cross-platform web framework claiming to 'build across platforms.'

• [ ] Review .github/workflows/ci.yml to identify gaps in platform coverage
• [ ] Ensure ci.yml triggers platform-specific builds for Android, iOS, macOS, Windows, and HarmonyOS on each PR
• [ ] Add test reporting steps that aggregate results from .rtf/native-ut-lynx.template and .rtf/android-ut-lynx.template
• [ ] Configure matrix builds to test against minSdkVersion 16 (Android) and equivalent minimum versions for other platforms

Create integration tests for multi-flavor Android builds (debugMode, asan, noasan, dev)

The Android build.gradle defines 4 product flavors with different CMake configurations and sanitizer flags, but there's no visible test coverage validating that each flavor builds correctly and produces expected binary outputs. This is essential for maintaining build consistency across debug and release variants.

• [ ] Create .github/actions/android-flavor-test action that builds each flavor sequentially
• [ ] Add verification steps to confirm expected artifacts exist (libc++_shared.so exclusion, sanitizer builds, etc.)
• [ ] Add unit tests in .rtf/android-ut-lynx.template or new file to validate native code compilation with ASAN/TSAN flags
• [ ] Document expected flavor outputs in CONTRIBUTING.md under Android build section

Add pre-commit linting hooks and validation for .clang-format and .prettierrc compliance

The repo has .clang-format, .prettierrc, and CPPLINT.cfg configuration files but no automated enforcement in CI or pre-commit hooks. This creates inconsistent code style contributions and increases review burden. New contributors won't know formatting expectations until CI fails.

• [ ] Create .githooks/pre-commit script that runs clang-format on C++ files and prettier on JS/TS files before commit
• [ ] Add GitHub Action step in ci.yml to run 'clang-format --dry-run' and 'prettier --check' on all staged files
• [ ] Document setup instructions in CONTRIBUTING.md with: git config core.hooksPath .githooks
• [ ] Add validation that CPPLINT.cfg is respected and output blocking warnings in CI

• Add unit tests for type definitions in lynx-types package: the TypeScript package is published (lynx-types-publish.yml workflow exists) but no test files visible in file list; write Jest tests for API surface consistency across platforms.
• Document CMake build flags in CONTRIBUTING.md: .gn and platform/android/build.gradle show -DFLAVOR_NAME, -fsanitize=address, -fPIE flags but no explanation for new C++ contributors; add inline comments or docs/cmake-flags.md.
• Create platform-specific setup guide for Windows/Linux devs: .github/actions/windows-common-deps/action.yml exists but no Windows section in README; extract action.yml logic into docs/setup/windows.md with verified commands.
• Add Harmony OS example in Lynx Explorer: harmony-explorer-build action exists but no reference app shown in .github/ISSUE_TEMPLATE or docs; create a 'hello-world' Harmony screen in explorer/ to match Android/iOS examples.

The codebase shows several significant security concerns, primarily around outdated Android API levels (minSdkVersion 16, targetSdkVersion 22) which lack modern security features and patches. The native build configuration includes potentially unsafe dynamic linking flags. While infrastructure (GitHub Actions, CI/CD) appears well-established, the actual build configurations lack hardened security settings. The project has a responsible security disclosure policy (SECURITY.md). Overall security posture is below industry standards due to legacy Android API targets and incomplete visibility into cross-platform security hardening.

• High · Low Minimum SDK Version for Android — build.gradle - defaultConfig section. The Android build configuration specifies minSdkVersion 16, which is extremely outdated (released in 2011). This exposes the application to numerous known vulnerabilities in older Android versions that have not received security patches. Fix: Update minSdkVersion to at least 21 (API level 21, Android 5.0+). Consider targeting minSdkVersion 24 or higher for better security coverage.
• High · Outdated Target SDK Version — build.gradle - defaultConfig section. targetSdkVersion is set to 22 (Android 5.1, released 2015). Modern Android requires targeting recent API levels. This misses critical security features and privacy protections introduced in newer Android versions. Fix: Update targetSdkVersion to the latest available API level (currently 35+). This is required by Google Play Store for new app submissions.
• Medium · Address Sanitizer (ASAN) Flavor Configuration — build.gradle - asan productFlavor configuration. The 'asan' product flavor is configured with Address Sanitizer flags, which is useful for development but should never be used in production builds. If this flavor is accidentally released, it would impact performance and could expose internal memory addresses. Fix: Ensure strict build controls prevent ASAN-enabled builds from being released to production. Add documentation and CI/CD checks to validate only 'noasan' or 'debugMode' flavors are released.
• Medium · Missing ProGuard/R8 Configuration Clarity — build.gradle - consumerProguardFiles configuration. While 'consumer-rules.pro' is referenced, there is no visibility into the actual obfuscation and minification rules. Incomplete ProGuard rules could leak sensitive code structure or allow reverse engineering of critical functionality. Fix: Review and harden consumer-rules.pro to ensure all sensitive classes and methods are properly obfuscated. Enable optimization and use non-shrinkable rules carefully.
• Medium · Unsafe Native Flags Configuration — build.gradle - debugMode and asan CMake configuration. CMake arguments include '-Wl,-ldl' and '-Wl,-llog' which may allow dynamic library loading. Combined with outdated Android versions, this increases risk of arbitrary code execution if vulnerabilities are present in native code. Fix: Review native code for proper input validation and bounds checking. Use security compile flags like -fstack-protector-strong, -D_FORTIFY_SOURCE=2, and -Wformat -Wformat-security.
• Low · Incomplete Multiplatform Security Configuration — .github/actions/* and build.gradle. The build configuration shows multiple platform build scripts (.github/actions) for Android, iOS, Windows, and macOS, but only Android configuration is visible. Security configurations may be inconsistent across platforms. Fix: Audit security configurations across all platform-specific build scripts (iOS, Windows, macOS) to ensure consistency in minimum SDK versions, secure compilation flags, and dependency management.

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

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

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/lynx-family/lynx 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.

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

What it runs against: a local clone of lynx-family/lynx — 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 lynx-family/lynx | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | 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 ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of lynx-family/lynx. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/lynx-family/lynx.git
#   cd lynx
#
# 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 lynx-family/lynx and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 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 "BUILD.gn" \\
  && ok "BUILD.gn" \\
  || miss "missing critical file: BUILD.gn"
test -f "base/include/base_public_headers.gni" \\
  && ok "base/include/base_public_headers.gni" \\
  || miss "missing critical file: base/include/base_public_headers.gni"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"
test -f "base/include/debug/lynx_assert.h" \\
  && ok "base/include/debug/lynx_assert.h" \\
  || miss "missing critical file: base/include/debug/lynx_assert.h"
test -f ".github/PULL_REQUEST_TEMPLATE.md" \\
  && ok ".github/PULL_REQUEST_TEMPLATE.md" \\
  || miss "missing critical file: .github/PULL_REQUEST_TEMPLATE.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
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/lynx-family/lynx"
  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).

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