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/nickoneill/PermissionScope 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 9y ago

• 20 active contributors
• Distributed ownership (top contributor 42% of recent commits)
• MIT licensed
• ⚠ Stale — last commit 9y ago
• ⚠ 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 nickoneill/PermissionScope repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/nickoneill/PermissionScope.

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

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

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

# 4. Critical files exist
test -f "PermissionScope/PermissionScope.swift" \\
  && ok "PermissionScope/PermissionScope.swift" \\
  || miss "missing critical file: PermissionScope/PermissionScope.swift"
test -f "PermissionScope/Permissions.swift" \\
  && ok "PermissionScope/Permissions.swift" \\
  || miss "missing critical file: PermissionScope/Permissions.swift"
test -f "PermissionScope/Structs.swift" \\
  && ok "PermissionScope/Structs.swift" \\
  || miss "missing critical file: PermissionScope/Structs.swift"
test -f "PermissionScope-example/ViewController.swift" \\
  && ok "PermissionScope-example/ViewController.swift" \\
  || miss "missing critical file: PermissionScope-example/ViewController.swift"
test -f "PermissionScope/Constants.swift" \\
  && ok "PermissionScope/Constants.swift" \\
  || miss "missing critical file: PermissionScope/Constants.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 3143 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3113d)"
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/nickoneill/PermissionScope"
  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).

PermissionScope is a Swift framework that provides a unified API and intelligent UI for requesting iOS system permissions (location, contacts, camera, microphone, photos, etc.). Rather than triggering native permission dialogs immediately, it wraps multiple permission requests in a custom modal dialog that lets users understand why permissions are needed before granting them, and handles denied states by guiding users to Settings. Simple, focused library: PermissionScope/ contains the core Swift implementation (PermissionScope.swift is the main controller, Permissions.swift defines permission types, Constants.swift and Structs.swift provide configuration). Two example apps (PermissionScope-example/ in Swift and objc-example/ in Objective-C) demonstrate usage. Localization strings in files/ support 6 languages.

iOS app developers using Swift or Objective-C who need to request multiple system permissions and want to provide context and better UX around permission grants instead of relying solely on native system dialogs.

Abandoned as of iOS 10/11. The README explicitly states 'PermissionScope is no longer supported.' The codebase targets Swift 3 and iOS 8+, with no recent commits visible in the file structure. This was a mature, production-quality library for its time, but is outdated for modern iOS development.

High risk for new projects: the framework is unmaintained and explicitly unsupported for iOS 10+. It lacks compatibility with modern iOS permission APIs (Privacy framework, location accuracy consent in iOS 14+, etc.) and has zero protection against breaking changes in future iOS releases. Single-maintainer project with no active issue triage.

Nothing. The project is in maintenance-only mode with no active development. The README warning about lack of iOS 10/11 support was added but no updates to the codebase itself.

Clone the repo: git clone https://github.com/nickoneill/PermissionScope.git && cd PermissionScope. Open the Xcode project: open PermissionScope.xcodeproj. Build the example app using Xcode's Run button, or integrate via CocoaPods (pod 'PermissionScope') or Carthage (github "nickoneill/PermissionScope" ~> 1.0).

Daily commands: Open PermissionScope.xcodeproj in Xcode. Select the 'PermissionScope-example' scheme and press Cmd+R to build and run on simulator or device. Alternatively, open objc-example.xcodeproj for the Objective-C demo.

• PermissionScope/PermissionScope.swift — Core library class that manages permission requests and UI presentation; all contributors must understand the main API surface and permission handling flow
• PermissionScope/Permissions.swift — Defines all supported permission types (Location, Notifications, Contacts, etc.) and their status checking logic; essential for adding new permission support
• PermissionScope/Structs.swift — Data structures for permission items, scope requirements, and status results; foundational types used throughout the codebase
• PermissionScope-example/ViewController.swift — Demonstrates the primary usage pattern and API for requesting permissions; shows how the library integrates into a real app
• PermissionScope/Constants.swift — Configuration constants, UI strings, and localization setup; referenced globally for consistent behavior
• PermissionScope/Extensions.swift — Utility extensions for UIView, UIColor, and system frameworks; enables cleaner permission scope code

• PermissionScope (main class) (UIViewController, NSNotification, custom delegate pattern) — Orchestrates permission requests, manages UI state, and fires callbacks on completion or cancellation
  • Failure mode: Missing permission status updates if system frameworks return incorrect state; unclear error reporting
• Permissions (enum + status logic) (EventKit, Contacts, CoreLocation, UserNotifications, AVFoundation, Photos) — Encapsulates permission type definitions and provides status-checking logic for each iOS permission framework
  • Failure mode: Status check fails if system framework not imported or device lacks permission support; new iOS versions break unsupported permission types
• Structs (Permission items & responses) (Swift structs, enums) — Defines immutable data structures for permission requests, results, and scope requirements
  • Failure mode: Mismatches between request and response structures; no validation of permission type compatibility
• UI & Dialog Management (UIView, UIButton, UILabel, CALayer animations) — Renders modal dialog with permission items, buttons, and localized text; manages user interactions
  • Failure mode: Dialog rendering issues on small/large devices; gesture conflicts with parent view controller

• App ViewController → PermissionScope — App instantiates PermissionScope with permission array and callbacks
• PermissionScope → Permissions (enum) — Queries current status of each permission type via status property
• Permissions (enum) → iOS System Frameworks — Checks permission status via EventKit, Contacts, CoreLocation, etc.
• iOS System Frameworks → PermissionScope — Returns permission status (authorized, denied, undetermined)
• PermissionScope → UIViewController (parent) — Presents modal dialog with permission items and buttons
• User → PermissionScope UI — User taps 'Allow' or 'Cancel' button
• PermissionScope → iOS System — Triggers native system permission prompts (e.g.,

Add Support for a New iOS Permission Type

1. Define a new permission case in the Permission enum (e.g., .fooPermission) with its status property (PermissionScope/Permissions.swift)
2. Add status checking logic to the computed property that queries the system (e.g., using EventKit for Calendar) (PermissionScope/Permissions.swift)
3. Create a PermissionItem in the main PermissionScope class to register the new permission (PermissionScope/PermissionScope.swift)
4. Add localized strings for the permission label and description (files/English.strings)
5. Update the example app to demonstrate requesting the new permission type (PermissionScope-example/ViewController.swift)

Customize Permission Scope UI Appearance

1. Modify color constants in the Constants section or override colors on the PermissionScope instance (PermissionScope/Constants.swift)
2. Adjust font sizes and spacing via Constants or set custom view properties before presenting (PermissionScope/PermissionScope.swift)
3. Update localization strings for custom labels and descriptions (files/English.strings)

Integrate PermissionScope into a New App

1. Install via CocoaPods (add to Podfile) or Carthage (PermissionScope.podspec)
2. Import PermissionScope and instantiate with required permissions (PermissionScope-example/ViewController.swift)
3. Set onAuthChange or onCancel callbacks to handle permission results (PermissionScope/PermissionScope.swift)
4. Call .show() when you need to request permissions (PermissionScope-example/ViewController.swift)

• Swift 3 — Modern Apple language with strong type safety; better integration with iOS frameworks than Objective-C
• UIKit — Standard iOS UI framework; required for presenting permission request dialogs and managing view hierarchy
• CocoaPods & Carthage — Enable easy distribution and dependency management for iOS developers integrating the library

• Unified API across diverse iOS permissions (Location, Notifications, Contacts, etc.)

  • Why: Each permission type has different APIs and system frameworks; unifying them reduces consumer complexity
  • Consequence: Must maintain status-checking logic for each permission type separately; harder to add new permission types

• Modal dialog UI for all permission requests

  • Why: Provides consistent UX and clear visual hierarchy for users to understand why permissions are needed
  • Consequence: Less flexibility for apps wanting inline or background permission flows; modal can interrupt user flow

• Callback-based async handling (onAuthChange, onCancel)

  • Why: Aligns with iOS system callbacks and is idiomatic for the era (pre-async/await Swift)
  • Consequence: Can lead to callback nesting; no structured concurrency support for modern Swift

• Support for iOS 9 and below (targets iOS 8+ but README deprecation note indicates iOS 10/11 incompatibility)
• Real-time permission monitoring across app lifecycle
• Custom permission types beyond system iOS permissions
• Background permission requests without user interaction
• Android or cross-platform support

This framework is unmaintained and incompatible with iOS 10+. Using it in a new project targeting modern iOS will fail silently or crash on newer permission APIs. Info.plist files in example apps lack required privacy keys (NSLocationWhenInUseUsageDescription, etc.), so examples won't run on recent iOS without manual editing. The PermissionScope.h header exists but bridging may break in Xcode versions after Swift 3 era.

• iOS System Permissions & Privacy — PermissionScope wraps native iOS permission requests (CoreLocation, Contacts, AVFoundation, etc.); understanding which frameworks trigger which dialogs is essential for using this library correctly.
• UIViewController Modal Presentation — The core of PermissionScope.swift is a custom UIViewController presented modally; understanding view controller lifecycle and presentation contexts is required to understand or modify the UI.
• Swift-Objective-C Bridging — PermissionScope is Swift but must work in Objective-C codebases; the bridging header pattern (objc-example/objc-example-Bridging-Header.h) shows how the framework exports to legacy code.
• [AVFoundation & CoreLocation Frameworks](https://developer.apple.com/documentation/avfoundation and https://developer.apple.com/documentation/corelocation) — Permission status checking in Permissions.swift directly calls AVCaptureDevice, CLLocationManager, and Contacts APIs; you need to know these frameworks to understand permission state logic.
• Localization with String Resources — PermissionScope includes localized strings in files/ directory (English.strings, German.strings, etc.) using iOS .strings file format; modifying or adding languages requires understanding this pattern.
• CocoaPods & Carthage Dependency Management — PermissionScope.podspec defines how the library is packaged and distributed; understanding pod structure is needed if you fork or maintain your own version.

• IvanVorobei/SPPermissions — Modern maintained Swift alternative with iOS 14+ support, provides similar unified API and custom permission dialog UI
• Piotr1215/PermissionKit — Another Swift permission wrapper library offering reactive-style permission handling, actively maintained alternative
• apple/swift-foundation — Apple's modern Privacy framework and Permission APIs in recent iOS; what PermissionScope should target if revived
• onevcat/Kingfisher — Similar era well-maintained Swift library pattern showing how iOS frameworks evolved past PermissionScope's design

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 Swift Package Manager support to PermissionScope.podspec and create Package.swift

The repo currently supports CocoaPods and Carthage but lacks SPM support, which is now the preferred dependency manager for modern iOS projects. Adding a Package.swift file would make the library accessible to developers using Swift Package Manager, significantly improving adoption for iOS 13+ projects.

• [ ] Create a Package.swift file at the root defining the library target and its dependencies
• [ ] Reference PermissionScope/ directory as the main library source
• [ ] Test local integration by adding the repo as an SPM dependency in the example apps
• [ ] Update README.md with SPM installation instructions alongside CocoaPods and Carthage sections

Fix localization string typo and add missing localization files

The files/Russian.string file has incorrect naming (should be .strings plural). Additionally, several common languages are missing localization files. Fixing the typo and adding more translations improves UX for international users and demonstrates maintenance attention to detail.

• [ ] Rename files/Russian.string to files/Russian.strings
• [ ] Create missing locale files: files/French.strings, files/Japanese.strings, files/Chinese-Simplified.strings
• [ ] Verify all .strings files are properly referenced in PermissionScope.xcodeproj build settings
• [ ] Test that localized permission descriptions appear correctly when device language changes

Add unit tests for Permissions.swift and PermissionScope.swift permission status detection

The repo currently has no visible test targets or test files. Adding unit tests for the core permission detection logic in Permissions.swift would catch regressions and provide confidence for future maintenance. Tests should cover permission request status checking and callback handling.

• [ ] Create PermissionScopeTests target in PermissionScope.xcodeproj with XCTest framework
• [ ] Write tests for permission status detection methods in Permissions.swift (e.g., permission denied, authorized, not determined states)
• [ ] Write tests for PermissionScope.swift callback handling when users grant/deny permissions
• [ ] Add test coverage for both iOS 8-12 and modern iOS 13+ permission behavior differences
• [ ] Update .github/ISSUE_TEMPLATE.md to reference test coverage expectations for future PRs

• Add unit tests for permission status checking logic in Permissions.swift (currently untested); create Tests/ folder and write XCTest cases for permissionStatus() methods for each permission type.
• Update documentation for iOS 14+ location accuracy consent (Apple added CLAccuracyAuthorization); add a new LocationAccuracy permission type to Permissions.swift and document the breaking behavior change.
• Create a migration guide in README.md pointing users to maintained alternatives (PermissionKit, SPPermissions, or native PermissionKit in iOS 17+) with side-by-side API comparison.

The PermissionScope library presents significant security concerns due to its unmaintained status and outdated technology stack. The project explicitly states it is no longer supported, targets iOS 8+ with Swift 3, and lacks modern security features. There is no visible vulnerability disclosure process. The library should not be used in production applications targeting current iOS versions. Organizations currently using this library should prioritize migration to actively maintained alternatives. The low security score reflects the critical nature of using unsupported, unpatched code in security-sensitive areas (permissions handling).

• High · Unmaintained Library with Deprecated iOS APIs — README.md, .swift-version, PermissionScope.swift. The README explicitly states 'PermissionScope is no longer supported. Please use an alternative if you need updates for newer iOS 10 and 11 APIs!' This indicates the library is no longer maintained and may contain unpatched security vulnerabilities. The codebase targets iOS 8+ and Swift 3, which are significantly outdated and lack security updates. Fix: Migrate to a actively maintained permissions library or Apple's native RequestUserNotificationPermission and equivalent modern APIs. If continued use is necessary, conduct a thorough security audit and apply custom patches.
• Medium · Swift 3 Runtime Security Concerns — .swift-version, PermissionScope/PermissionScope.swift. The project uses Swift 3 (as indicated by .swift-version and badges), which reached end-of-support years ago. Swift 3 lacks modern memory safety features, concurrency safety improvements, and security patches present in current Swift versions. This increases vulnerability to memory corruption attacks and race conditions. Fix: Upgrade to Swift 5.9+ to benefit from modern memory safety, Concurrency framework, and security improvements. Refactor code to use current Swift APIs and best practices.
• Medium · Potential Hardcoded Localization Data — files/English.strings, files/German.strings, files/Italian.strings, files/Korean.strings, files/Russian.string, files/Spanish.strings. Multiple localization string files exist in the 'files/' directory (English.strings, German.strings, Italian.strings, Korean.strings, Russian.strings, Spanish.strings). Without reviewing file contents, hardcoded strings could potentially leak sensitive information or contain unvalidated user-facing content. One file appears misnamed (Russian.string instead of Russian.strings) suggesting inconsistent maintenance. Fix: Review all localization files to ensure no sensitive information is hardcoded. Implement proper string validation. Fix the naming inconsistency for Russian.strings. Consider externalized localization management for sensitive strings.
• Low · Missing Dependency Lock File — Root directory (CocoaPods/Carthage/SPM configuration). No package lock file (Podfile.lock, Cartfile.resolved, or Package.resolved) is visible in the file structure. This means dependency versions are not pinned, potentially leading to unexpected updates with breaking changes or security issues when installing the library. Fix: Commit lock files to version control (Podfile.lock for CocoaPods or Cartfile.resolved for Carthage) to ensure reproducible builds and prevent unexpected dependency updates.
• Low · No Visible Security Policy or Security Headers — .github directory structure. No SECURITY.md file, security policy, or vulnerability disclosure guidelines are present in the repository. There is no clear process for reporting security issues, which could delay patching of vulnerabilities. Fix: Create a SECURITY.md file documenting how to responsibly report security vulnerabilities. Include a security policy and expected response timeframes.

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.