Introduction of new skills

.claude-plugin/marketplace.json

@@ -27,6 +27,24 @@
 			"description": "React Native upgrade workflow covering updated templates, dependencies, and common pitfalls. Use when migrating a React Native app to a newer release.",
 			"source": "./",
 			"skills": ["./skills/upgrading-react-native"]
+		},
+		{
+			"name": "rn-new-architecture-migration",
+			"description": "React Native New Architecture migration guide focusing on XCFramework distribution for brownfield iOS apps. Covers bridge initialization, Hermes embedding, and Swift Package distribution.",
+			"source": "./",
+			"skills": ["./skills/rn-new-architecture-migration"]
+		},
+		{
+			"name": "rn-testing-and-debugging",
+			"description": "E2E testing framework comparison (Detox vs Maestro) and API failure simulation using MITMProxy. Covers CI setup, test authoring, and response overriding.",
+			"source": "./",
+			"skills": ["./skills/rn-testing-and-debugging"]
+		},
+		{
+			"name": "rn-native-ios-tooling",
+			"description": "iOS dependency manager comparison (SPM vs Carthage vs CocoaPods), OSS licensing tools for mobile apps, and Objective-C to Swift migration strategies.",
+			"source": "./",
+			"skills": ["./skills/rn-native-ios-tooling"]
 		}
 	]
 }

skills/rn-native-ios-tooling/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: rn-native-ios-tooling
+description: Covers iOS dependency manager comparison (SPM vs Carthage vs CocoaPods), OSS licensing tools for mobile apps, and Objective-C to Swift migration strategies. Use when evaluating iOS dependency managers, setting up license compliance, or planning an ObjC to Swift migration.
+license: MIT
+metadata:
+  author: Callstack
+  tags: react-native, ios, spm, cocoapods, carthage, licensing, objc, swift, migration
+---
+
+# React Native Native iOS Tooling
+
+## Overview
+
+Practical guidance for iOS dependency management, open-source license compliance, and Objective-C to Swift migration in React Native projects.
+
+## When to Apply
+
+Reference these guidelines when:
+- Choosing or switching iOS dependency managers (SPM, Carthage, CocoaPods)
+- Setting up OSS license compliance for iOS/Android apps
+- Planning a migration from Objective-C to Swift
+- Evaluating the cost of switching away from CocoaPods
+- Need cross-platform license notice generation
+
+## Quick Reference
+
+| File | Description |
+|------|-------------|
+| [ios-dependency-managers.md][ios-dependency-managers] | SPM vs Carthage vs CocoaPods comparison |
+| [oss-licensing-tools.md][oss-licensing-tools] | OSS license compliance tools for mobile |
+| [objc-to-swift-migration.md][objc-to-swift-migration] | ObjC → Swift migration checklist |
+
+## Problem → Skill Mapping
+
+| Problem | Start With |
+|---------|------------|
+| Choosing iOS dependency manager | [ios-dependency-managers.md][ios-dependency-managers] |
+| Migrating away from CocoaPods | [ios-dependency-managers.md][ios-dependency-managers] |
+| Setting up license notices in app | [oss-licensing-tools.md][oss-licensing-tools] |
+| Cross-platform license generation | [oss-licensing-tools.md][oss-licensing-tools] |
+| Planning ObjC to Swift migration | [objc-to-swift-migration.md][objc-to-swift-migration] |
+| Migrating native module to Swift | [objc-to-swift-migration.md][objc-to-swift-migration] |
+
+[ios-dependency-managers]: references/ios-dependency-managers.md
+[oss-licensing-tools]: references/oss-licensing-tools.md
+[objc-to-swift-migration]: references/objc-to-swift-migration.md

skills/rn-native-ios-tooling/references/ios-dependency-managers.md

@@ -0,0 +1,119 @@
+---
+title: iOS Dependency Managers
+impact: HIGH
+tags: spm, cocoapods, carthage, ios, dependency-management, xcode
+---
+
+# Skill: iOS Dependency Managers
+
+Compare and choose between SPM, Carthage, and CocoaPods for iOS dependency management.
+
+## Quick Reference
+
+**Recommended ranking**: SPM > Carthage > CocoaPods
+
+| Feature | SPM | Carthage | CocoaPods |
+|---------|-----|----------|-----------|
+| Swift support | Full (native) | Full | Full |
+| ObjC support | Limited | Full | Full |
+| Installation | Built into Xcode | `brew install carthage` | `gem install cocoapods` |
+| Project impact | **None** | Almost none | **Heavy** (wraps into workspace, modifies xcodeproj) |
+| Removal complexity | Trivial | Easy | Very complex |
+| Build speed | Fast (Apple's caching) | Slow initial (prebuilds once) | Rebuilds deps every time |
+| Market share | ~46% | ~11% | ~61% |
+| Apple maintained | Yes | Community | Community |
+| Binary distribution | Supported (XCFramework) | Supported | Limited |
+
+## When to Use
+
+- Starting a new iOS/React Native project and choosing a dependency manager
+- Evaluating whether to migrate away from CocoaPods
+- Need to understand trade-offs between available options
+
+## Comparison Details
+
+### Swift Package Manager (SPM)
+
+**Strengths:**
+- Built into Xcode — no external tools needed
+- Minimal project file changes
+- Fast dependency resolution with caching
+- Apple-maintained, long-term investment
+- Easy to add/remove packages
+- First-class binary target (XCFramework) support
+
+**Weaknesses:**
+- Limited Objective-C library support
+- Some RN dependencies still require CocoaPods
+- Resource bundle handling can be tricky
+- Cannot mix with CocoaPods for the same target easily
+
+**Best for**: New Swift-first projects, libraries with SPM support.
+
+### Carthage
+
+**Strengths:**
+- Decentralized — no central spec repo
+- Prebuilds frameworks (faster CI if cached)
+- Minimal project file intrusion
+- Easy to remove
+- Good ObjC and Swift support
+
+**Weaknesses:**
+- Slow initial build (compiles all dependencies from source)
+- Requires manual framework linking
+- Smaller ecosystem than CocoaPods
+- Some libraries don't support Carthage
+
+**Best for**: Projects wanting prebuilt binaries without project file modification.
+
+### CocoaPods
+
+**Strengths:**
+- Largest library ecosystem
+- Excellent Objective-C support
+- React Native's default dependency manager
+- Well-documented integration
+- Handles complex dependency graphs
+
+**Weaknesses:**
+- **Extremely hard to switch away from** — modifies xcodeproj, creates workspace, adds build phases
+- Slow `pod install` on large projects
+- Ruby dependency management adds complexity
+- Central spec repo can be slow
+- Xcode 16 compatibility issues (frequently)
+
+**Best for**: React Native projects (required by most RN libraries), large ObjC codebases.
+
+## Key Insight: CocoaPods Lock-In
+
+CocoaPods is extremely hard to switch away from because it:
+1. Creates and manages a `.xcworkspace`
+2. Modifies the `.xcodeproj` with custom build phases
+3. Manages header search paths and framework search paths
+4. Many React Native libraries only provide Podspecs
+
+**Migration effort from CocoaPods**: Weeks to months for a medium-sized RN project. Requires rewriting build configuration and potentially forking libraries.
+
+## Decision Matrix
+
+| Scenario | Recommendation |
+|----------|---------------|
+| New RN project | CocoaPods (required by RN ecosystem) |
+| Pure Swift project, no RN | SPM |
+| Need easy dependency removal | SPM or Carthage |
+| Large ObjC codebase | CocoaPods |
+| Want prebuilt frameworks | Carthage or SPM (binary targets) |
+| Evaluating migration from CocoaPods | Only if strong business case justifies the effort |
+
+## Common Pitfalls
+
+- **Attempting to remove CocoaPods casually**: Understand the full scope of project file changes before starting
+- **Mixing SPM and CocoaPods for same dependency**: Can cause duplicate symbol errors
+- **Not caching Carthage builds**: Initial builds are slow; cache `Carthage/Build` in CI
+- **Assuming all RN libraries support SPM**: Most still require CocoaPods
+
+## Related Skills
+
+- [oss-licensing-tools.md](./oss-licensing-tools.md) — License compliance for dependencies
+- [objc-to-swift-migration.md](./objc-to-swift-migration.md) — ObjC → Swift migration strategies

skills/rn-native-ios-tooling/references/objc-to-swift-migration.md

@@ -0,0 +1,197 @@
+---
+title: Objective-C to Swift Migration
+impact: HIGH
+tags: objc, swift, migration, ios, bridging-header, refactoring, native
+---
+
+# Skill: Objective-C to Swift Migration
+
+Plan and execute an Objective-C to Swift migration for iOS native code in React Native projects.
+
+## Quick Reference
+
+| Phase | Key Actions |
+|-------|------------|
+| Before | Investigate code, understand flows, simplify ObjC first |
+| During | Migrate by module, use bridging headers, rewrite when needed |
+| After | Migrate unit tests, update docs, apply SOLID principles |
+
+## When to Use
+
+- Planning migration of native iOS modules from ObjC to Swift
+- React Native native module needs Swift rewrite
+- Brownfield app has legacy ObjC code
+- Team wants to leverage Swift-only features (async/await, structured concurrency)
+
+## Prerequisites
+
+- Xcode 15+ with Swift 5.9+
+- Understanding of both Objective-C and Swift
+- Existing unit test coverage (or willingness to add it)
+- Bridging header knowledge
+
+## Before Migration
+
+### 1. Investigate the Code
+
+- Map all ObjC files and their dependencies
+- Identify interconnected modules and isolated components
+- Document threading model, queuing, and dispatch patterns
+- Note any C/C++ interop (Swift's C interop is more limited)
+
+### 2. Understand Flows and Threading
+
+- Trace execution paths through ObjC code
+- Document GCD/NSOperationQueue usage patterns
+- Identify main thread vs background thread boundaries
+- Note any `@synchronized` blocks or locking mechanisms
+
+### 3. Simplify First
+
+Before migrating, clean up the ObjC:
+- Remove dead code
+- Break large classes into smaller ones
+- Reduce coupling between modules
+- Fix existing bugs (don't carry them into Swift)
+
+### 4. Plan the Migration Order
+
+Start with the **smallest-impact, most-isolated** module:
+- Utility classes with no dependencies
+- Data models / value objects
+- Standalone helpers
+
+Work outward toward more connected code.
+
+## During Migration
+
+### 5. Migrate Module by Module
+
+**Do not attempt a "big bang" rewrite.** Migrate one module at a time:
+
+1. Create Swift file(s) for the module
+2. Set up bridging header for ObjC → Swift interop
+3. Migrate the implementation
+4. Update callers to use the Swift version
+5. Remove old ObjC files
+6. Verify tests pass
+
+### 6. Use Bridging Headers
+
+**ObjC calling Swift:**
+```objc
+// Import the auto-generated Swift header
+#import "MyApp-Swift.h"
+
+// Use Swift class
+MySwiftClass *obj = [[MySwiftClass alloc] init];
+```
+
+**Swift calling ObjC:**
+```swift
+// In MyApp-Bridging-Header.h, add:
+// #import "MyObjCClass.h"
+
+// Then use directly in Swift
+let obj = MyObjCClass()
+```
+
+**Tip**: Expose only what's needed via `@objc` and `@objcMembers`. Don't make everything visible.
+
+### 7. Don't Hesitate to Rewrite
+
+- Translating ObjC patterns 1:1 into Swift often produces poor Swift code
+- Use Swift idioms: optionals instead of nil checks, enums with associated values, structs for value types
+- Rewrite delegate patterns as closures where appropriate
+- Replace NSNotificationCenter with Combine or async/await where practical
+
+### 8. Leverage Swift Features
+
+| ObjC Pattern | Swift Replacement |
+|-------------|-------------------|
+| Delegate + protocol | Closure / async-await |
+| NSError** | throws / Result type |
+| GCD dispatch_async | Task { } / structured concurrency |
+| KVO | @Published + Combine |
+| NSMutableArray | [Element] (value type) |
+| Category | Extension |
+| typedef enum | enum with raw values |
+
+### 9. Migrate Unit Tests Early
+
+- Migrate tests for a module **alongside** the module itself
+- Swift tests can call both ObjC and Swift code
+- Use XCTest's Swift API directly
+- Don't leave test migration for "later" — it rarely happens
+
+### 10. Apply SOLID Principles
+
+Migration is an opportunity to improve architecture:
+- **Single Responsibility**: Split classes that do too much
+- **Open/Closed**: Use protocols for extensibility
+- **Liskov Substitution**: Ensure protocol conformances are correct
+- **Interface Segregation**: Prefer small, focused protocols
+- **Dependency Inversion**: Inject dependencies rather than hard-coding
+
+## Documentation
+
+Keep documentation updated throughout:
+- Update API docs as interfaces change
+- Document any behavior changes (even if intentional improvements)
+- Note breaking changes for consumers of the migrated code
+- Update README with new Swift requirements
+
+## React Native Specific Considerations
+
+### Native Modules
+
+When migrating a RN native module from ObjC to Swift:
+
+```swift
+import React
+
+@objc(MyModule)
+class MyModule: NSObject {
+    @objc static func requiresMainQueueSetup() -> Bool {
+        return false
+    }
+
+    @objc func doSomething(
+        _ resolve: @escaping RCTPromiseResolveBlock,
+        reject: @escaping RCTPromiseRejectBlock
+    ) {
+        resolve(["result": "success"])
+    }
+}
+```
+
+The `RCT_EXTERN_MODULE` macro still requires an ObjC file:
+
+```objc
+// MyModule.m
+#import <React/RCTBridgeModule.h>
+
+@interface RCT_EXTERN_MODULE(MyModule, NSObject)
+RCT_EXTERN_METHOD(doSomething:
+                  (RCTPromiseResolveBlock)resolve
+                  reject:(RCTPromiseRejectBlock)reject)
+@end
+```
+
+### Turbo Modules
+
+For New Architecture Turbo Modules, prefer Swift with `@objc` annotations. The codegen bridge handles the interop layer.
+
+## Common Pitfalls
+
+- **"Big bang" migration**: Migrating everything at once introduces too many bugs simultaneously
+- **1:1 translation**: Produces un-idiomatic Swift code. Rewrite to use Swift patterns.
+- **Ignoring threading differences**: Swift concurrency model differs from GCD patterns
+- **Skipping test migration**: Leads to untested Swift code
+- **Making everything @objcMembers**: Only expose what ObjC callers actually need
+- **Not simplifying ObjC first**: Migrating messy ObjC produces messy Swift
+
+## Related Skills
+
+- [ios-dependency-managers.md](./ios-dependency-managers.md) — Dependencies may change during migration
+- [oss-licensing-tools.md](./oss-licensing-tools.md) — Verify license compliance after dependency changes