Plugin API Change

Plugin API Change

Use this skill when adding, removing, or changing a Unity plugin API.

Goal

Make a safe API change across all plugin layers while preserving backward compatibility where possible.

Workflow

1. Identify the public C# API being changed in Assets/AppsFlyer/AppsFlyer.cs.
2. Trace the full path: C# API → AppsFlyerAndroid.cs (Android) | AppsFlyeriOS.cs (iOS) → Native bridge
3. Verify whether the API already exists in some form.
4. Check whether the change affects: method signatures, argument mapping, callback behavior, event payload shape, Android/iOS parity.
5. Implement changes in all required layers.
6. Check whether tests or example code must be updated.
7. Summarize compatibility risk and missing validation.

What to Check

C# layer

• AppsFlyer.cs — public API entry point
• AppsFlyerAndroid.cs — Android delegation (uses AndroidJavaClass/AndroidJavaObject)
• AppsFlyeriOS.cs — iOS delegation (uses [DllImport("__Internal")])
• #if UNITY_IOS / #if UNITY_ANDROID guards
• Assembly definition (.asmdef) boundaries — do not break
• Namespace AppsFlyerSDK — do not change

Android bridge

• AppsFlyerAndroidWrapper.java — Java bridge method
• Mapping to AppsFlyer Android SDK
• Threading safety

iOS bridge

• AppsFlyeriOSWrapper.mm — Objective-C++ bridge function
• Mapping to AppsFlyer iOS SDK
• Delegate/callback wiring

Output Format

Return:

• Summary
• C# API impact
• Android impact
• iOS impact
• Assembly definition impact
• Compatibility risk
• Tests to add or update
• Validation steps

Rules

• Keep Android and iOS behavior aligned unless a platform difference is intentional.
• Do not silently break the public C# API.
• Both billing library variants must remain buildable after the change.
• Do not stop at C#-only changes if native bridge work is required.