patchthecode/JTAppleCalendar

JTAppleCalendar is a Swift-based iOS and tvOS library that provides customizable calendar views, including month and year displays with support for range selection and international calendars like the Persian calendar. The system exposes a core API for configuring scrolling modes, cell sizes, and programmatic cell customization, while managing user interactions and delegate callbacks. It is distributed as a standalone framework compatible with modern dependency managers like Swift Package Manager and Carthage, targeting iOS 11+ and tvOS 11+.

7 changes.

The project underwent significant modernization by updating CI configurations, restructuring documentation, and dropping legacy iOS example assets. It introduced Swift Package Manager support, raised minimum deployment targets to iOS 11, and reorganized the project structure to facilitate framework distribution.

6 changes.

This period established the core JTAppleCalendar library with its foundational source components and API. It also introduced a comprehensive iOS sample application to demonstrate usage, alongside initial test suites for both Linux compatibility and UI verification.

The SampleJTAppleCalendar project has been added, providing a complete iOS application that demonstrates the JTAppleCalendar library. This sample includes a main interface for configuring month views (scrolling modes, cell sizes, date generation) and dedicated example screens for Persian calendar support, range selection, year views, and programmatic cell/header customization.

SampleJTAppleCalendar · high confidence

This change introduces the core source files for the JTAppleCalendar library, including the main view controllers (JTACMonthView, JTACYearView), cell implementations (JTACDayCell, JTACMonthCell), and the underlying data models and enums (CalendarEnums, CalendarStructs). It establishes the foundational API for configuring calendar parameters, handling user interactions like selection and scrolling, and managing delegate callbacks for cell customization and header views.

Sources · high confidence

The example project for JTAppleCalendar has removed its legacy iOS application structure, specifically deleting the \AppDelegate.swift\, \LaunchScreen.xib\, and \Main.storyboard\ files. This indicates a shift away from the traditional storyboard-based iOS example setup, likely to modernize the demo or align it with a different project configuration.

Example/JTAppleCalendar · high confidence

The placeholder files for the Pod module have been removed, specifically deleting the \.gitkeep\ files in \Assets\ and \Classes\, as well as the \ReplaceMe.swift\ source file. This cleanup eliminates the initial scaffolding artifacts from the project structure.

Pod · high confidence

The JTAppleCalendar example project file (project.pbxproj) has been deleted from the repository. This removes the Xcode project configuration for the example application and its associated test suite, which previously included source files, storyboards, and CocoaPods integration settings.

Example/JTAppleCalendar.xcodeproj · high confidence

The JTAppleCalendar project files have been restructured to support building the library as a standalone framework (JTAppleCalendar.framework). This includes adding the necessary Xcode project configuration, workspace settings, and build schemes, which facilitates integration via package managers like Carthage and ensures the framework is correctly assembled for consumers.

JTAppleCalendar.xcodeproj · high confidence

The sample application project has been reorganized and renamed from 'JTAppleCalendar\_Example' to 'SampleJTAppleCalendar'. This change includes migrating the project file to Xcode 11 (object version 52) and updating the build scheme to target the new application and UI test bundles. The project structure now explicitly groups example components such as range selection, year view, Persian calendar, and custom cell headers, providing a cleaner reference implementation for users.

SampleJTAppleCalendar.xcodeproj · high confidence

The Travis CI configuration has been updated to use Xcode 10 and explicitly build for both iOS and tvOS simulators, replacing the previous generic setup. The project documentation has been significantly restructured: the README now highlights key features like range selection and custom cells, includes badges for Carthage compatibility and sponsor support, and links to a new local documentation directory. Additionally, a CHANGELOG.md file has been added to track version history, and a .tailor.yml file has been introduced to configure code style linting rules.

(repo-wide) · high confidence

Added the necessary \.xcworkspace\ configuration files (\contents.xcworkspacedata\ and \IDEWorkspaceChecks.plist\) to the \.swiftpm\ directory. This ensures that the Swift Package Manager package is correctly recognized and configured within the Xcode workspace environment, resolving issues related to workspace setup.

.swiftpm · high confidence

Added UI test suite for the sample application; Added initial test suite for JTAppleCalendar on Linux; Removal of placeholder test suite in Example/Tests.

The JTAppleCalendar library has been updated to version 8.0.5, introducing official Swift Package Manager (SPM) support via a new Package.swift file and dropping the Example/Podfile in favor of this modern dependency manager. For users, this update raises the minimum deployment target to iOS 11.0 and tvOS 11.0, and requires Swift 5, while also adding a privacy manifest (PrivacyInfo.xcprivacy) to the resource bundles.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 49 → 58 (+8.4)
• Rubric changed (rubric-2026.08.15 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 89 (-11.0)
• Architecture 93 (new)
• Maturity 48 → 48 (-0.8)
• Readiness 26 → 45 (+19.2)
• Security 100 → 90 (-10.0)

• Dimension evaluation failed
• LLM evaluation failed
• No automated tests
• No exposed public API
• No tests found
• Test reliability not included
• early-stage repository — too little history to judge knowledge freshness
• single-commit history — no usable git history window to measure hotspots
• single-maintainer — knowledge-concentration (bus factor) risk

• Assertions commented out: testExample (SampleJTAppleCalendarUITests/SampleJTAppleCalendarUITests.swift)
• Assertions commented out: testExample (Tests/JTAppleCalendarTests/JTAppleCalendarTests.swift)
• Coverage not measured — Swift suite
• Dependency hygiene PARTLY measured — SwiftPM pinning read, dependency currency NOT established
• Dormant codebase
• Duplicated block (12–13 lines × 2) (Sources/JTAppleCalendar/JTACMonthLayoutHorizontalCalendar.swift)
• Duplicated block (9 lines × 2) (SampleJTAppleCalendar/ExampleSectionHeaders/HeaderAsClass/CodePinkSectionHeaderView.swift)
• Inconsistent method naming for selection operations. selectDates has two overloads: one taking a range (from:to:) and one taking an array. deselectDates has a range overload, but deselect (singular verb) takes an array. This breaks the parallel structure between select and deselect operations.
• Inconsistent naming for reload operations. One method is reloadData (standard UIKit pattern), but the other is also reloadData with different parameters. While overloading is acceptable, the presence of reloadDates([Date]) suggests a distinction between full reloads and partial updates. However, reloadData is ambiguous about whether it resets the entire calendar or just refreshes current data. The naming doesn't clearly distinguish between 'refresh current view' and 'reset calendar state'.
• Inconsistent naming for scroll operations. scrollToDate and scrollToHeaderForDate are specific, but scrollToSegment is vague. SegmentDestination is an enum, but the method name doesn't reflect that it's scrolling to a specific segment type (e.g., header, footer, specific month). Also, scrollToHeaderForDate is a very specific operation that might be better named scrollToMonthHeader(for:) for clarity.
• Inconsistent pattern for asynchronous/synchronous operations. One overload returns the value directly, the other uses a completion handler. While this is a common pattern, it is inconsistent with cellStatus(for:) which also has this duality. More importantly, visibleDates implies a simple getter, but the async version suggests potential latency. It is better to be consistent: either always async or provide a synchronous version only if it's guaranteed to be fast.
• Inverted test pyramid
• JTACMonthLayout.configureHorizontalLayout (cognitive 53) (Sources/JTAppleCalendar/JTACMonthLayout.swift)
• JTACMonthLayout.configureVerticalLayout (cognitive 56) (Sources/JTAppleCalendar/JTACMonthLayout.swift)
• JTACMonthLayout.layoutAttributesForElements (cognitive 28) (Sources/JTAppleCalendar/JTACMonthLayout.swift)
• JTACMonthLayout.sizeForitemAtIndexPath (cognitive 32) (Sources/JTAppleCalendar/JTACMonthLayout.swift)
• JTACMonthView.handleSelectionValueChanged (cognitive 22) (Sources/JTAppleCalendar/JTACMonthView.swift)
• JTACMonthView.handleSelectionValueChanged (cyclomatic 16) (Sources/JTAppleCalendar/JTACMonthView.swift)
• JTACMonthView.indexPathOfdateCellCounterPath (cognitive 42) (Sources/JTAppleCalendar/JTACMonthView.swift)
• JTACMonthView.indexPathOfdateCellCounterPath (cyclomatic 22) (Sources/JTAppleCalendar/JTACMonthView.swift)
• …and 23 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

patchthecode/JTAppleCalendar was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.