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/LinkedInAttic/LayoutKit 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

• 30+ active contributors
• Distributed ownership (top contributor 20% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 5y ago

_{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 LinkedInAttic/LayoutKit repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/LinkedInAttic/LayoutKit.

What it runs against: a local clone of LinkedInAttic/LayoutKit — 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 LinkedInAttic/LayoutKit | 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 master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1938 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "LinkedInAttic/LayoutKit(\\.git)?\\b" \\
  && ok "origin remote is LinkedInAttic/LayoutKit" \\
  || miss "origin remote is not LinkedInAttic/LayoutKit (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "LayoutKit.podspec" \\
  && ok "LayoutKit.podspec" \\
  || miss "missing critical file: LayoutKit.podspec"
test -f "LayoutKit.playground/Pages/Introduction.xcplaygroundpage/Contents.swift" \\
  && ok "LayoutKit.playground/Pages/Introduction.xcplaygroundpage/Contents.swift" \\
  || miss "missing critical file: LayoutKit.playground/Pages/Introduction.xcplaygroundpage/Contents.swift"
test -f "ExampleLayouts/HelloWorldLayout.swift" \\
  && ok "ExampleLayouts/HelloWorldLayout.swift" \\
  || miss "missing critical file: ExampleLayouts/HelloWorldLayout.swift"
test -f "LayoutKitSampleApp/AppDelegate.swift" \\
  && ok "LayoutKitSampleApp/AppDelegate.swift" \\
  || miss "missing critical file: LayoutKitSampleApp/AppDelegate.swift"
test -f "LayoutKitSampleApp/Benchmarks/BenchmarkViewController.swift" \\
  && ok "LayoutKitSampleApp/Benchmarks/BenchmarkViewController.swift" \\
  || miss "missing critical file: LayoutKitSampleApp/Benchmarks/BenchmarkViewController.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 1938 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1908d)"
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/LinkedInAttic/LayoutKit"
  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).

LayoutKit is a fast declarative view layout library for iOS, macOS, and tvOS that computes layouts imperatively in Swift/Objective-C instead of using Apple's Auto Layout engine. It solves the performance problem of Auto Layout by enabling synchronous layout computation on background threads and immutable, cacheable layout results—LinkedIn built it because Auto Layout was too slow for complex scrollable view hierarchies in their feed. Monorepo structure: /LayoutKit.xcodeproj is the core library (Swift + Objective-C), ExampleLayouts/ contains reference implementations (FeedItemLayout, ProfileCardLayout, SkillsCardLayout), LayoutKit.playground/Pages/ has interactive Swift Playground tutorials (Stack, Inset, Overlay, Animation, etc.), and LayoutKit.podspec defines the CocoaPods distribution.

iOS/macOS/tvOS engineers building high-performance scrollable feeds or complex layouts (especially at companies like LinkedIn) who need 60fps rendering and fast layout computation without Auto Layout's overhead, and who value declarative, testable layout code.

⚠️ UNMAINTAINED: The project is archived and no longer used by LinkedIn. It has comprehensive unit tests and shipped in production (LinkedIn app, LinkedIn Job Search app), Travis CI integration, and CocoaPods support, but has received no active maintenance—it is a snapshot of a mature codebase, not an actively developed project.

High risk for new projects: Project is explicitly unmaintained by LinkedIn and carries no future bug fixes or Swift/iOS version compatibility updates. No activity visible in recent commits. Suitable only for reference, education, or maintenance of legacy codebases already using LayoutKit. Swift version pinned to .swift-version file, creating potential compatibility issues with modern Xcode.

Nothing—project is archived. Last state shows example layouts for common UI patterns (feed items, profile cards, image piles), playground-based documentation, and completed iOS/macOS/tvOS support. No open development branches or PRs visible.

git clone https://github.com/LinkedInAttic/LayoutKit.git
cd LayoutKit
pod install
open LayoutKit.xcodeproj
# Or explore interactively: open LayoutKit.playground

Daily commands: Open LayoutKit.xcodeproj in Xcode and run the ExampleLayouts-iOS scheme, or open LayoutKit.playground in Xcode to explore layouts interactively. No server/CLI—this is a library, not an app.

• LayoutKit.podspec — Defines the LayoutKit library's public API surface, version, and platform support—essential for understanding the project's scope and dependencies.
• LayoutKit.playground/Pages/Introduction.xcplaygroundpage/Contents.swift — Entry point for learning the library; demonstrates core layout abstractions and patterns used throughout the codebase.
• ExampleLayouts/HelloWorldLayout.swift — Canonical minimal example showing how Layout types compose and render; reference implementation for new contributors.
• LayoutKitSampleApp/AppDelegate.swift — Application bootstrap; shows how LayoutKit integrates with iOS app lifecycle and common usage patterns.
• LayoutKitSampleApp/Benchmarks/BenchmarkViewController.swift — Performance measurement harness; critical for understanding LayoutKit's performance promise and how to validate changes.
• ExampleLayouts/FeedItemLayout.swift — Real-world complex layout example (feed card); demonstrates composition of multiple layout primitives.
• LayoutKit.xcodeproj/project.pbxproj — Build configuration for iOS, macOS, and tvOS targets; required to understand platform-specific code and build settings.

Create a New Primitive Layout Type

1. Create a new Swift file in LayoutKit/Layouts/ that conforms to the Layout protocol (LayoutKit/Layouts/[YourLayout].swift)
2. Implement the arrangement(maxSize:layoutDelegate:) method to compute child positions and return a LayoutArrangement (LayoutKit/Layouts/[YourLayout].swift)
3. Add your layout to the Example playgrounds or LayoutKitSampleApp to demonstrate usage (LayoutKit.playground/Pages/[YourPage].xcplaygroundpage/Contents.swift)
4. Update LayoutKit.podspec to expose your new layout in the public API (LayoutKit.podspec)

Add a New Sample App View Controller

1. Create a new UIViewController subclass in LayoutKitSampleApp/ (LayoutKitSampleApp/[YourViewController].swift)
2. Define your layout using LayoutKit primitives (StackLayout, LabelLayout, etc.) (LayoutKitSampleApp/[YourViewController].swift)
3. Integrate with UITableView or UICollectionView by calling layout.arrangement(maxSize:) in cellForRow or cellForItem (LayoutKitSampleApp/[YourViewController].swift)
4. Register your view controller in AppDelegate or a navigation menu (LayoutKitSampleApp/AppDelegate.swift)

Add a Benchmark Comparison

1. Create a new layout variant file (e.g., FeedItem[ImplementationName]View.swift) in LayoutKitSampleApp/Benchmarks/ (LayoutKitSampleApp/Benchmarks/FeedItem[ImplementationName]View.swift)
2. Implement the same visual layout using your target method (UIStackView, Auto Layout, manual frame, etc.) (LayoutKitSampleApp/Benchmarks/FeedItem[ImplementationName]View.swift)
3. Register the new view in BenchmarkViewController and add it to the comparison loop (LayoutKitSampleApp/Benchmarks/BenchmarkViewController.swift)
4. Run benchmarks on a real device and log Stopwatch timings (LayoutKitSampleApp/Benchmarks/Stopwatch.swift)

• Pure Swift Layout Computation (no Auto Layout) — Auto Layout constraint solving is O(n³) and becomes prohibitively slow for complex hierarchies in scrolling lists; LayoutKit uses single-pass linear layout computation instead.
• Layout Protocol Abstraction + Composition — Enables declarative, functional layout definitions where layouts can be recursively composed; encourages testable, reusable layout components.
• UIView Recycling + Reuse — Integrates with UITableView and UICollectionView cell reuse mechanisms to minimize memory allocation and GC pressure during scrolling.
• Playground-based Documentation — Live, interactive examples allow developers to see layout behavior instantly without running a full app; accelerates learning curve.

• Manual layout computation over Auto Layout

  • Why: Performance critical for LinkedIn's high-traffic feed; Auto Layout too slow for 60fps scrolling with complex cards.
  • Consequence: Developers must use LayoutKit-specific APIs rather than system frameworks; cannot leverage Auto Layout ecosystem tools.

• Immutable Layout definitions + computed LayoutArrangement results

  • Why: Enables caching of layout results and thread-safe composition without mutable state.
  • Consequence: Layout objects must be recreated on data changes (though lightweight); less familiar pattern for traditional iOS developers.

• Platform-specific implementations (iOS/macOS/tvOS with Objective-C wrapper)

  • Why: Leverage native view frameworks (UIKit, AppKit) for best platform integration.
  • Consequence: Platform-specific code paths; macOS/tvOS support requires separate LayoutKitObjC library.

• Limited to view hierarchy layout only; no text layout engine

  • Why: Focus on fast view positioning; reuse native text rendering (UILabel, NSTextField).
  • Consequence: Cannot customize text layout (line breaking, glyph placement) independently of LayoutKit.

• Does not replace Auto Layout constraint resolution entirely—no support for relative positioning (e.g., 'center relative to sibling')
• Does not provide responsive breakpoints for different device sizes (developers implement manually)
• Does not handle text layout or custom typography—delegates to native UILabel/NSTextField
• Not cross-platform (Android)—iOS/macOS/tvOS only
• Does not support dynamic type or accessibility text scaling natively—manual configuration required

Swift version pinned: .swift-version file enforces a specific Swift version; modern Xcode may warn or fail. No SPM support: Only CocoaPods distribution—Swift Package Manager not available. Right-to-left handling: Layout frames are auto-adjusted for RTL languages, but custom layouts must opt-in via LayoutProtocol conformance. Thread safety: Layouts are immutable but UIView updates happen on main thread—background computation is safe, but applying results requires main queue dispatch. No Storyboard support: LayoutKit is code-only; no Interface Builder integration.

• Immutable Value-Type Layouts — Core to LayoutKit's design—layouts are immutable structs that can be safely computed on background threads and cached, unlike mutable UIView hierarchies
• Declarative UI Composition — LayoutKit layouts describe structure via composition (StackLayout, InsetLayout) rather than imperative UIView manipulation, making code testable and maintainable
• Layout Measurement Protocol — LayoutKit measures view hierarchies via a protocol-based measurement pass (similar to React Native's Yoga), separate from frame assignment, enabling efficient caching
• Background Thread Layout Computation — Layouts can be computed off the main thread (no UIView access) and applied later, preventing jank in scrolling interfaces
• Right-to-Left (RTL) Language Support — LayoutKit automatically mirrors frames for Arabic/Hebrew; this is built into the layout system, not bolted on, making RTL 'just work'
• UITableView/UICollectionView Adapters — LayoutKit layouts integrate with system scrolling views via adapter patterns, letting you use fast layouts without rewriting your table/collection view code
• Layout Caching & Precomputation — Immutable layout results are serializable/storable; LinkedIn precomputed layouts on the server and cached them client-side to reduce user-perceived latency

• airbnb/epoxy-ios — Declarative composable component library for UICollectionView/UITableView, similar philosophy to LayoutKit but built on top of Auto Layout
• ReactiveX/RxSwift — Often paired with LayoutKit in production codebases for reactive data binding to layouts
• instagram/IGListKit — Facebook's high-performance list framework for iOS, addresses similar scrollable-view-performance problem as LayoutKit
• facebookincubator/ComponentKit — Facebook's C++ component library (LayoutKit spiritual predecessor), inspired declarative composable layout philosophy
• material-components/material-components-ios — Modern Material Design library; represents current generation of iOS layout solutions (successor to LayoutKit-era thinking)

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.

Migrate from Travis CI to GitHub Actions workflow

The repo uses .travis.yml for CI/CD, but GitHub Actions is now the standard for GitHub-hosted projects. This would modernize the build pipeline, improve integration with GitHub, and provide better visibility into test results. Given the multi-platform nature (iOS, macOS, tvOS), a GitHub Actions workflow could run tests across all schemes defined in LayoutKit.xcodeproj/xcshareddata/xcschemes/.

• [ ] Create .github/workflows/build-and-test.yml to replace .travis.yml functionality
• [ ] Configure workflow to build all schemes: LayoutKit-iOS, LayoutKit-macOS, LayoutKit-tvOS, ExampleLayouts-iOS
• [ ] Add codecov integration to the workflow (currently referenced in README but not configured in Travis)
• [ ] Test workflow locally and verify all test targets pass
• [ ] Document the new workflow in CONTRIBUTING.md

Add comprehensive unit tests for ExampleLayouts modules

The repo contains multiple example layout implementations (FeedItemLayout, ProfileCardLayout, CircleImagePileLayout, etc.) in ExampleLayouts/ directory, but there's no visible test coverage for these concrete layout examples. Adding tests would serve as both validation and documentation for how to properly use LayoutKit, and would be valuable for new contributors learning the framework.

• [ ] Create LayoutKitTests/ExampleLayoutsTests.swift or similar test file
• [ ] Add unit tests for each layout in ExampleLayouts/: FeedItemLayout.swift, ProfileCardLayout.swift, MiniProfileLayout.swift, SkillsCardLayout.swift, CircleImagePileLayout.swift
• [ ] Test layout calculations, size constraints, and view composition for each example
• [ ] Ensure tests run on all three platforms (iOS, macOS, tvOS) using platform-specific assertions
• [ ] Update .travis.yml or new CI workflow to run these tests as part of the standard test suite

Create platform-specific integration guides in documentation

The repo supports three platforms (iOS, macOS, tvOS) with separate targets and schemes, but there's limited guidance on platform-specific considerations. The LayoutKitObjC sample app suggests Objective-C interoperability, but this isn't documented. Adding platform-specific guides would help new contributors understand the codebase structure and platform differences.

• [ ] Create docs/PLATFORMS.md documenting iOS, macOS, and tvOS specific implementation details and known differences
• [ ] Create docs/OBJC_INTEROP.md explaining how to use LayoutKit from Objective-C (based on LayoutKitObjCSampleApp/)
• [ ] Add cross-references in CONTRIBUTING.md to these new guides
• [ ] Document which Layout classes have platform-specific code or limitations (e.g., search LayoutKit source for #if os(iOS) preprocessor directives)
• [ ] Include code examples for each platform from the respective sample apps (LayoutKitSampleApp vs LayoutKitObjCSampleApp)

• Add unit tests for ExampleLayouts/CircleImagePileLayout.swift—currently has no test coverage visible in repo structure
• Create a new Playground page (LayoutKit.playground/Pages/Gradient.xcplaygroundpage) demonstrating gradient backgrounds with SizeLayout + config closure
• Update the Introduction playground page to include a modern tvOS example (tvOS target exists but no playground reference)

The LayoutKit project presents a moderate security risk primarily due to its unmaintained status. The project is no longer actively developed or supported by LinkedIn, meaning security vulnerabilities will not be patched. While the codebase itself does not show obvious injection vulnerabilities or hardcoded credentials in the provided structure, the lack of dependency information prevents complete vulnerability assessment. The main concerns are: (1) no security updates will be provided, (2) third-party dependencies may contain unpatched vulnerabilities, and (3) Swift version may be outdated. For projects currently using LayoutKit, migration to maintained alternatives is strongly recommended. If continued use is necessary, implement robust dependency scanning and security monitoring practices.

• High · Unmaintained Project with Security Risks — README.md, project root. The project is explicitly marked as unmaintained and no longer used by LinkedIn. This means there will be no security patches, bug fixes, or updates for known vulnerabilities. Dependencies may contain unpatched security issues. Fix: Consider migrating to actively maintained layout libraries. If continued use is necessary, implement regular security audits and dependency scanning.
• Medium · Missing Package Dependency File — Dependency management configuration. The dependency information is not provided (empty). This prevents complete analysis of third-party library vulnerabilities. The project uses CocoaPods (based on .podspec files), but the Podfile.lock or Podfile is not visible in the provided structure. Fix: Provide Podfile and Podfile.lock for comprehensive dependency vulnerability scanning. Use tools like CocoaPods dependency check or dependency-check to identify vulnerable libraries.
• Medium · Outdated Swift Version Configuration — .swift-version. The .swift-version file exists but content is not shown. Swift versions can contain security vulnerabilities. Using outdated Swift versions exposes the codebase to known security issues. Fix: Update to the latest stable Swift version and verify all dependencies are compatible with modern Swift releases.
• Low · CI/CD Configuration Exposure — .travis.yml. The .travis.yml file is present in the repository, which may contain or reference sensitive configuration. While Travis CI is a public service, excessive details in CI configuration can expose build environment details. Fix: Ensure no credentials, API keys, or sensitive environment variables are hardcoded in .travis.yml. Use encrypted environment variables for any secrets.
• Low · Debug and Example Code in Production — LayoutKit.playground/, ExampleLayouts/, LayoutKitSampleApp/. The codebase contains playground files and example layouts that may include debug code or unsafe patterns. While examples are acceptable, they should not be included in production builds. Fix: Ensure debug and example code is excluded from production builds. Mark example code clearly and document security considerations.

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.