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/Ahmed-Ali/JSONExport 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.

WAIT — Stale — last commit 3y ago

• 24+ active contributors
• Distributed ownership (top contributor 45% of recent commits)
• Other licensed
• ⚠ Stale — last commit 3y ago
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected
• ⚠ No test directory detected

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

What it runs against: a local clone of Ahmed-Ali/JSONExport — 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 Ahmed-Ali/JSONExport | Confirms the artifact applies here, not a fork | | 2 | License is still Other | 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 ≤ 961 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other 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 "JSONExport/ViewController.swift" \\
  && ok "JSONExport/ViewController.swift" \\
  || miss "missing critical file: JSONExport/ViewController.swift"
test -f "JSONExport/FileContentBuilder.swift" \\
  && ok "JSONExport/FileContentBuilder.swift" \\
  || miss "missing critical file: JSONExport/FileContentBuilder.swift"
test -f "JSONExport/LangModel.swift" \\
  && ok "JSONExport/LangModel.swift" \\
  || miss "missing critical file: JSONExport/LangModel.swift"
test -f "JSONExport/Property.swift" \\
  && ok "JSONExport/Property.swift" \\
  || miss "missing critical file: JSONExport/Property.swift"
test -f "JSONExport/Supported Languages" \\
  && ok "JSONExport/Supported Languages" \\
  || miss "missing critical file: JSONExport/Supported Languages"

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

JSONExport is a macOS desktop application (written in Swift) that converts raw JSON objects into strongly-typed model classes with constructors, getters, setters, and utility methods in multiple languages including Java, Swift, Kotlin, and Objective-C variants. It solves the tedious problem of hand-coding data model classes by auto-generating boilerplate from JSON samples, supporting multiple backend frameworks like Realm, SwiftyJSON, ObjectMapper, and CoreData. Single Xcode project structure (JSONExport.xcodeproj) with source code in JSONExport/ directory. Core logic lives in model classes (DataType.swift, Constructor.swift, FileContentBuilder.swift) for schema representation and generation. FileRepresenter.swift and HeaderFileRepresenter.swift handle language-specific output. UI is driven by Main.storyboard and AppDelegate.swift. No separation of language backends is visible in the file list—generation logic likely monolithic.

iOS/Android developers and backend engineers who need to quickly scaffold model classes from API responses or sample JSON data. Specifically useful for teams working with multiple languages (Java for Android, Swift for iOS) who want to maintain consistent data structures without manual boilerplate coding.

The project is stable and feature-complete but effectively unmaintained as of the README statement—the original author is seeking new maintainers. The codebase is 120K+ lines of Swift with a multi-year history, but recent commit activity appears stalled. No visible CI/CD setup or automated tests in the file list suggest pre-release era practices. Verdict: production-ready but seeking active stewardship.

Single-maintainer burnout is explicit in the README; the project is not actively maintained. There is no visible test suite, CI pipeline, or dependency management file (no Package.swift or Podfile) in the listing, making it difficult to assess dependency health. The codebase targets macOS only and may have bitrot against newer Xcode/Swift versions. Contributors considering this should plan to own the modernization effort themselves.

The project is in maintenance-seeking mode. The README explicitly calls for new maintainers and contributors to take over. No active development roadmap or recent PR activity is evident from the file list. The codebase appears frozen pending community takeover.

Clone the repo: git clone https://github.com/Ahmed-Ali/JSONExport.git. Open the Xcode project: open JSONExport.xcodeproj. Build and run directly in Xcode (Cmd+R) or via xcodebuild -scheme JSONExport. No additional package manager setup is visible (no CocoaPods/SPM metadata in top-level files).

Daily commands: xcodebuild -scheme JSONExport build or open JSONExport.xcodeproj in Xcode and press Cmd+R to launch the app. The app is a desktop GUI; no CLI mode is evident from the structure.

• JSONExport/ViewController.swift — Main UI controller that orchestrates JSON input, model generation, and file export—entry point for all user interactions.
• JSONExport/FileContentBuilder.swift — Core abstraction that assembles generated model code from templates and language-specific configurations.
• JSONExport/LangModel.swift — Loads and manages language/framework templates from JSON configuration files; essential for multi-language support.
• JSONExport/Property.swift — Represents a JSON property in the data model; fundamental data structure that drives code generation.
• JSONExport/Supported Languages — Directory containing 15+ language template configurations (Swift, Java, Objective-C variants); defines all supported export targets.
• JSONExport/FileRepresenter.swift — Handles file writing and path management for exporting generated model files to the filesystem.
• JSONExport/AppDelegate.swift — Application lifecycle entry point and window management for macOS app.

Add Support for a New Language/Framework

1. Create a new JSON template file in JSONExport/Supported Languages/ named after the language (e.g., 'Kotlin-Android.json'). Define templates for class definition, property declarations, initializers, getters/setters, and imports. (JSONExport/Supported Languages/[NewLang].json)
2. Verify that LangModel.swift can parse the new template by ensuring your JSON follows the same key structure as existing templates (e.g., 'classDeclaration', 'property', 'constructor'). (JSONExport/LangModel.swift)
3. If the language requires type mappings not in DataType.swift, extend the DataType enum or the mapping logic to handle new type names. (JSONExport/DataType.swift)
4. Test by loading JSON in ViewController.swift, selecting your new language from the dropdown, and exporting a sample model to verify code generation.

Add a New Property Generation Feature (e.g., Validation Methods)

1. Define a new key in each language template JSON file (e.g., 'validationMethod') with template code that includes placeholders like {{propertyName}} and {{propertyType}}. (JSONExport/Supported Languages/*.json)
2. Extend Property.swift to include a method that retrieves and renders the validation template for each property. (JSONExport/Property.swift)
3. Update FileContentBuilder.swift to call the new property method and insert rendered validation code into the final generated file. (JSONExport/FileContentBuilder.swift)
4. Test by parsing sample JSON, selecting a language with the new template, and verifying validation methods appear in the output.

Add a New Export Destination Format (e.g., YAML Model Files)

1. Create a new representer class (e.g., YAMLFileRepresenter.swift) that implements model-to-YAML serialization logic. (JSONExport/[NewFormatName]FileRepresenter.swift)
2. Update ViewController.swift to add the new format to the export options UI and route export calls to your new representer. (JSONExport/ViewController.swift)
3. Optionally create a new LangModel variant or extend LangModel.swift to support YAML template syntax if needed. (JSONExport/LangModel.swift)
4. Test by parsing JSON, selecting your new format from the export dropdown, and verifying the output format.

Improve Type Inference for Complex JSON Structures

1. Enhance the JSON parsing logic in ViewController.swift to detect and classify nested objects, arrays, and custom types more intelligently. (JSONExport/ViewController.swift)
2. Update Property.swift to store and expose inferred type information (e.g., generic types like List<T>, Optional<T>). (JSONExport/Property.swift)
3. Extend DataType.swift to map complex inferred types to language-specific equivalents. (JSONExport/DataType.swift)
4. Verify templates in language files correctly render generics and nested types in generated code.

• Swift (primary) — Modern, statically-typed language with excellent macOS integration via Cocoa; allows safe JSON parsing and code generation.
• Objective-C (legacy components) — Objective-C components (NoodleLineNumberView) are historical; retained for text view line numbering but maintainable via bridging header.
• JSON configuration files — Template-driven approach allows adding new languages without code changes; Codable/JSONSerialization makes parsing straightforward.
• macOS Storyboard (Interface Builder) — Native macOS UI toolkit; simplifies UI layout and wiring; aligns with platform conventions.
• File I/O (Foundation framework) — Standard Apple APIs for writing generated code to disk; no third-party dependencies required.

• Template-driven code generation (vs. fully programmatic AST-based generation)

  • Why: Simpler to add new languages without code changes; reduces complexity and enables community contributions of language templates.
  • Consequence: Templates can become hard to maintain for complex languages; no type-safe generation, relying on string templates with placeholders.

• Monolithic ViewController for UI orchestration (vs. MVVM/MVC separation)

  • Why: Smaller codebase; faster to iterate on a single-window macOS app.
  • Consequence: ViewController grows large; harder to test business logic in isolation; UI state management is tightly coupled to generation logic.

• No persistence of user settings or export history

  • Why: Simpler state management; avoids schema migration complexity.
  • Consequence: User must re-select language and export path on each use; no history of previously exported models.

• Synchronous file I/O and code generation

  • Why: Simpler logic; export is typically fast (sub-second) for typical JSON payloads.
  • Consequence: UI blocks during large export operations; no progress indication for slow file writes.

• Does not provide real-time JSON validation or linting.
• Does not support Windows or Linux; macOS-only desktop application.
• Does not offer web-based or API-based code generation; strictly a desktop tool.
• Does not handle authentication or enterprise deployment; single-user personal tool.
• Does not generate unit tests or documentation alongside models.

No Package.swift or explicit dependency management visible—unclear if external dependencies exist or how to resolve them. Xcode version/Swift version compatibility not declared in the file list; likely requires recent Xcode (the README mentions Swift 3 ObjectMapper support, suggesting older codebase). The app is macOS-only; building on Linux or Windows is not possible. Multiple xcuserdata folders suggest local Xcode state pollution in the repo (should be gitignored but is checked in). No build artifacts or test directory visible; presence of tests unknown.

• Code generation from schema inference — JSONExport's core strategy—inferring type schemas from JSON samples and generating language-specific boilerplate; understanding this is critical to extending language support
• Type bridging across language ecosystems — The app maps JSON primitives to language-specific types (Swift Optional, Java null, Kotlin nullable); crucial for understanding FileRepresenter and DataType implementations
• Abstract syntax tree (AST) traversal for template rendering — FileContentBuilder likely constructs an AST-like representation of the model class before rendering; essential for adding new code generation features
• Cocoa/AppKit model-view controller (MVC) pattern — The UI is built on macOS MVC; understanding AppKit bindings and storyboard patterns is required for UI modifications
• Multi-target language code templating — JSONExport generates 10+ language variants from a single JSON input; the backend must use templates or polymorphic classes to avoid code duplication
• Optional type semantics across languages — Handling nil/null/Optional values differently across Java (nullable annotations), Swift (Optional), and Kotlin (nullable types) is a core complexity

• quicktype/quicktype — Cross-language JSON schema to code generator; more actively maintained and covers similar language targets (Swift, Java, Kotlin, TypeScript)
• SwiftyJSON/SwiftyJSON — Lightweight JSON parsing library for Swift; JSONExport generates code specifically for this library as one of its output options
• realm/realm-swift — Mobile database framework; JSONExport generates Realm-compatible model classes as one of its core supported languages
• Hearst-DD/ObjectMapper — Swift object mapping library; JSONExport generates ObjectMapper-compatible Mappable classes for model serialization
• RestKit/RestKit — Predecessor-era REST framework that inspired similar code generation workflows; relevant for understanding JSONExport's design philosophy in the pre-Codable era

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 for macOS builds and automated testing

The repo lacks automated build verification. Currently, there's no CI pipeline to validate that PRs compile correctly on macOS, which is critical for an Xcode project. This would catch regressions early and reduce manual testing burden on maintainers. The .xcodeproj structure is already in place; it just needs a workflow to build and test it automatically.

• [ ] Create .github/workflows/build.yml to run xcodebuild on macOS runner
• [ ] Configure the workflow to build JSONExport.xcodeproj with scheme JSONExport
• [ ] Add build validation for multiple macOS SDK versions to catch compatibility issues
• [ ] Document the CI setup in a new CONTRIBUTING.md file to help future contributors understand the build process

Add comprehensive unit tests for language template generation (DataType.swift, FileContentBuilder.swift, FileRepresenter.swift)

The core functionality of JSONExport is converting JSON to code in multiple languages. The repo contains language definitions in 'Supported Languages/' directory (Java-Android.json, ObjectiveC-Mac.json, etc.) but appears to lack unit tests validating that template rendering produces correct output. This is critical for ensuring language support quality and preventing regressions when adding new languages or modifying templates.

• [ ] Create Tests/ directory structure with JSONExportTests.xcodeproj target
• [ ] Add unit tests in JSONExportTests/FileContentBuilderTests.swift to validate output for each supported language
• [ ] Create JSONExportTests/DataTypeTests.swift to test DataType.swift enum handling and language-specific type mappings
• [ ] Add test fixtures (sample JSON inputs) and expected outputs for Java, ObjectiveC, and other supported languages
• [ ] Ensure FileRepresenter.swift correctly applies templates from the Supported Languages/*.json files

Refactor and document the language template system (Supported Languages/*.json files)

The language templates in 'Supported Languages/' are JSON config files that define how to generate code for each language, but there's no schema documentation or validation. Contributors adding new languages (Kotlin, Swift, C#, etc.) have no clear specification. Creating a formal schema and documentation would enable easier community contributions and prevent template syntax errors.

• [ ] Create JSONExport/LanguageTemplateSchema.json defining the expected structure for language template files
• [ ] Document each template property (classDefinition, imports, propertyDefinition, etc.) in a new LanguageTemplates.md file
• [ ] Add a validation script (e.g., in Swift) to verify new language templates conform to the schema before merging
• [ ] Refactor existing Supported Languages/*.json files to ensure consistency and add comments explaining each section
• [ ] Create a template for new contributors (e.g., NewLanguageTemplate.json.example) to make adding languages straightforward

• Add automated test coverage for FileContentBuilder.swift and DataType.swift parsing logic; currently no test files visible in the repo, making refactoring risky
• Modernize Swift syntax and update to latest Swift/Xcode version; the ObjectMapper example suggests Swift 3 era code that likely has deprecation warnings
• Add support for Swift 5.5+ async/await patterns in generated code for async-friendly model classes, building on the existing Swift code generation backend

JSONExport is a macOS desktop application with a moderate security posture. The primary concerns are related to development configuration management rather than application logic vulnerabilities. The main issues identified are: (1) User-specific Xcode configuration files committed to version control, which should be excluded via .gitignore; (2) Lack of visible security policy and responsible disclosure guidelines; (3) No apparent hardcoded secrets or credentials found in the file structure; (4) No SQLi/XSS risks evident given the nature of the application (JSON parsing and code generation); (5) No external dependency vulnerabilities visible as no package manager files (Podfile, Package.swift) were provided. As this is a mature macOS application seeking new maintainers, security review of the actual Swift and Objective-C code implementation would be recommended before deployment.

• Medium · User Data in Version Control — JSONExport.xcodeproj/project.xcworkspace/xcuserdata/ and JSONExport.xcodeproj/xcuserdata/ directories. Multiple Xcode user workspace files and user-specific configuration files are committed to the repository (.xcuserdatad directories, UserInterfaceState.xcuserstate files, xcschemes). These files may contain user-specific data, preferences, and potentially sensitive information about the development environment. Fix: Add these patterns to .gitignore: '.xcuserstate', 'xcuserdata/', '.xcworkspace/xcuserdata/'. Commit only the xcshareddata directory. Consider removing these files from git history using git filter-branch or similar tools.
• Low · Incomplete .gitignore Configuration — .gitignore (likely incomplete). The repository includes numerous auto-generated Xcode workspace files that should typically be excluded from version control. This increases repository size and can cause merge conflicts when multiple developers work on the project. Fix: Update .gitignore to exclude: *.xcuserstate, xcuserdata/, *.xcworkspace/xcuserdata/, .DS_Store, Pods/, and other common Xcode artifacts.
• Low · Lack of Code Signing Information — JSONExport.xcodeproj/project.pbxproj. No visible code signing certificates or provisioning profiles in the file structure, though Xcode projects typically require these. If signing credentials are stored elsewhere or in environment variables without proper documentation, this could pose security risks. Fix: Ensure code signing certificates and provisioning profiles are managed through secure channels (not committed to the repository). Use environment variables or secure CI/CD pipeline configurations for code signing.
• Low · No Security Policy Documentation — Repository root. No visible SECURITY.md or security policy file indicating how security issues should be reported. The README mentions the project is seeking maintainers but doesn't provide a responsible disclosure process. Fix: Create a SECURITY.md file with responsible disclosure guidelines, security contact information, and vulnerability reporting procedures.
• Low · Bridging Header Without Validation — JSONExport/JSONExport-Bridging-Header.h. JSONExport-Bridging-Header.h is used to interface between Swift and Objective-C code, but there's potential for unsafe interop if not properly managed. No visible sanitization of inputs from the Objective-C side. Fix: Review the bridging header to ensure all Objective-C code properly validates inputs before passing to Swift. Consider using Swift-native alternatives where possible to reduce interop surface area.

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.