Dev/delivery 124647/rpc implementation

[af-obodovskyi]

Summary

Migrates the AppsFlyer Unity plugin's core API from the legacy AndroidJavaClass/DllImport native bridges to a unified, schema-driven RPC transport. Every public method and parameter is now aligned to a canonical JSON schema (appsflyer-plugins-rpc-schema.json) shared across platforms, replacing ad-hoc per-platform bridging code with a single dispatch path (AppsFlyerRPCClient → Fire/Query).

What changed

C# plugin API (Assets/AppsFlyer/AppsFlyer.cs)

• Every public method now routes through the RPC transport instead of AndroidJavaClass/P/Invoke calls; removed the old native bridge interfaces (IAppsFlyerAndroidBridge, IAppsFlyerIOSBridge, IAppsFlyerNativeBridge) and platform delegation classes (AppsFlyerAndroid.cs, AppsFlyeriOS.cs).
• Fixed a set of schema-alignment bugs found during a Unity-vs-schema-vs-RN audit:
  • isSessionReady() now performs a live RPC query instead of returning a stale client-cached flag.
  • enableDebug/setDisableNetworkData parameter names renamed to match the schema's canonical public contract (enabled / isDisable).
  • setLogLevel now accepts case-insensitive input (schema's canonical values are lowercase) and uppercases before firing the wire RPC.
  • generateInviteLink now remaps the canonical referrerCustomerId key to Android's wire key customerId internally, instead of requiring callers to know the platform-specific key.
  • updateServerUninstallToken (iOS) now hex-encodes the device token instead of Base64, matching the schema's required wire format.

Android native bridge

• Migrated AppsFlyerRPCBridge and PurchaseRevenueBridge from Java to Kotlin.
• Dependency/gradle updates: added play-services-ads-identifier (fixes a ClassNotFoundException reading GAID), and temporarily disabled purchase-connector due to an AGP8 manifest-namespace conflict with af-android-sdk (needs an upstream repackage before re-enabling).

iOS native bridge

• Added a Swift RPC wrapper (AppsFlyerRPCWrapper.swift) replacing the old Obj-C++ RPC wrapper.

Sample/test app

• Added AppsFlyerAPITester.cs — a UI-driven manual test harness covering the full RPC API surface.
• Added ATTPermissionRequest.mm for iOS App Tracking Transparency prompts; removed the old AppsFlyerOpenURL.mm.
• Updated Android manifest/gradle templates and QATestScript.cs for the new bridge.

Removed

• Stale prebuilt binaries that shouldn't have been in source control: the macOS bundle (test-app/Assets/AppsFlyer/Mac/...) and unitywrapper.aar.

Out of scope / explicitly excluded

• appsflyer-plugins-rpc-schema.json is intentionally not included in this MR.
• handleOpenUrl, handleLaunchOptions, continueUserActivity were audited against the schema (which flags them internal-only) but are kept public and unchanged — they're documented, tested, and tied to the native AppsFlyerAttribution handling; removing them would be a breaking change with no clear benefit.
• Build/run-generated artifacts (Xcode export, APKs, Editor-version churn, EDM4U-resolver-generated settings, backup files) were kept out of version control.

Testing

• Assets/AppsFlyer/Tests/Tests_Suite.cs updated for the new RPC-layer assertions.
• Manual verification recommended via the new AppsFlyerAPITester harness in the sample app on both platforms, particularly: isSessionReady (live query behavior), generateInviteLink (Android key remap), and updateServerUninstallToken (iOS hex encoding).
• No native SDK behavior changes required — confirmed via RPC mapping docs that both Android and iOS already implement the relevant RPC methods correctly.

[pazlavi]

No test exercises ParseResponse's new expectedId mismatch check at all — no test that a matching id succeeds, none that a mismatched id throws AppsFlyerRPCException, and no end-to-end test driving the real DefaultInstance (all existing contract tests use a mock IAppsFlyerRPCClient and bypass this code path entirely). This is exactly the mechanism the CRITICAL Android id-echo bug above slipped through — a real ParseResponse/StubResponse round-trip test would have caught it.

References:

• Microsoft: Unit testing best practices

[pazlavi]

Replacing the synchronous MainActor.assumeIsolated with DispatchQueue.main.async avoids a crash if this @_cdecl entry point is called off-main, but it trades that for a real ordering bug: AppsFlyer.init calls InitIOSBridge then synchronously runs the blocking init RPC and registerSessionReadyListener/start on the same stack frame. DispatchQueue.main.async from the main thread only runs after control returns to the run loop, so the event handler is now installed after init/start already ran — exactly the ordering the comment above says must be preserved ("before registerSessionReadyListener, so sessionReady can reach Unity"). Any sessionReady/conversion-data/deep-link event fired during init is silently dropped.

// Good — install synchronously when already on main, hop (sync) otherwise
let install = { MainActor.assumeIsolated { AppsFlyerRPCBridge.shared.setEventHandler { ... } } }
if Thread.isMainThread { install() } else { DispatchQueue.main.sync(execute: install) }

References:

• Apple — DispatchQueue.async vs. sync and main-queue reentrancy

[pazlavi]

AndroidTargetArchitectures narrows from 10 (ARM64 | X86_64) to 2 (ARM64-only), and AndroidAllowedArchitectures: -1 is dropped entirely. .github/workflows/rc-e2e-android.yml runs the RC E2E gate on an arch: x86_64 emulator, which generally has no ARM translation layer — a test-app APK with only arm64-v8a libs will fail to install (INSTALL_FAILED_NO_MATCHING_ABIS) or crash on native paths there, silently breaking the E2E gate this same PR's release pipeline depends on for sign-off. This looks like incidental churn from opening the project in a newer editor — ProjectVersion.txt jumps 6000.3.5f1→6000.5.6f1 in the same commit, and AndroidMinSdkVersion/iPhoneSdkVersion also shift in the same hunk — which makes a functional regression easy to miss in a "review fixes" commit.

# fix — keep x86_64 alongside arm64 for the test app CI builds against
AndroidTargetArchitectures: 10
AndroidAllowedArchitectures: -1

References:

• reactivecircus/android-emulator-runner — arch/target compatibility

[pazlavi]

StubResponse re-parses the request JSON purely to recover the id that Execute already holds two stack frames up — a layering smell, since Dispatch(string) is meant to be an opaque string→string transport. Prefer passing the id down explicitly (Dispatch(string jsonRequest, string id)) or having Execute synthesize the fallback response itself; this also removes a redundant JSON deserialize the play-mode test suite pays on every call.

References:

• Martin Fowler — Layering and keeping responsibilities in the owning layer

[pazlavi]

Execute/ExecuteFire go through the injectable IAppsFlyerRPCClient instance, but InitAndroidBridge/InitIOSBridge are static methods on the concrete class, not on the interface — forcing AppsFlyer.cs itself to branch on UNITY_ANDROID/UNITY_IOS to pick an initializer, platform knowledge the RPC client exists to encapsulate. It also means bridge initialization (including the ordering bug flagged above in AppsFlyerRPCWrapper.swift) can't be mocked or asserted in the play-mode suite. Add a single InitBridge(string callbackObjectName) to the interface and let each implementation own its #if split.

References:

• Microsoft — Dependency inversion / designing for testability

[pazlavi]

[assembly: InternalsVisibleTo("Tests")] grants access to a simple-named assembly, and Tests is the name Unity generates by default for a test asmdef in a Tests/ folder — so any integrator project with its own Tests.asmdef silently gains access to AppsFlyer internals, including the newly-non-public internal static IAppsFlyerRPCClient instance transport seam. Rename the test assembly to something namespaced (e.g. AppsFlyerSDK.Tests, matching the existing namespace AppsFlyerSDK.Tests) and reference that instead.

References:

• .NET — InternalsVisibleToAttribute

[pazlavi]

This commit shifts deep-link delivery from UnityAppController subclassing/swizzling to NSNotificationCenter observers, leaving only continueUserActivity (Universal Links) swizzled in AppsFlyer+AppController.m since classic UnityAppController posts no notification for it. That's an asymmetric, partially-migrated design with two concrete gaps: (1) the old didFinishLaunching: handler explicitly forwarded a cold-start custom-URL-scheme launch — the new observers only listen for kUnityOnOpenURL/remote-notification, so a cold launch from a URL-scheme deep link is silently dropped; (2) when UnityAppController.h isn't available (Unity's Swift Xcode project type — the type test-app's xcodeProjectType: 0 doesn't exercise in E2E), the swizzle file compiles out entirely via #if __has_include, so Universal Links have no delivery path at all on that export type, with no compile error or runtime warning. This mixed-architecture decision plus its known gaps is significant enough to warrant an ADR and a release-notes/README callout, not just an inline comment.

For gap (1): the restored cold-start handler should not just extract userInfo[@"url"] and forward a bare URL to handleOpenUrl:sourceApplication:annotation: the way the old pre-RPC handler did. The plugin already has a dedicated, schema-aligned API for this — AppsFlyer.handleLaunchOptions(Dictionary<string, object> launchOptions) (Assets/AppsFlyer/AppsFlyer.cs:428), which fires the whole launchOptions map as a single RPC payload. The cold-start observer should forward the entire launch-options dictionary to that method's native counterpart, not a URL extracted out of it — matching how the RPC schema models this case rather than reviving the old ad-hoc URL-only path. Note the native iOS side of handleLaunchOptions isn't wired up anywhere in this diff yet, so that needs to exist before this observer can call it.

References:

• Apple — Supporting Universal Links (continueUserActivity)
• ADR template / when to write one

[pazlavi]

Two smaller test gaps from this commit: (1) the new collectDataFromLauncherActivity() API (Android-only Fire call) has no contract test pinning the RPC method name or the #if UNITY_ANDROID guard, unlike every sibling Fire-based method; (2) CallBackObjectName is a mutable static now read by a second consumer (generateInviteLink's GameObject.Find), but no fixture resets it in [TearDown] — a later test with an anonymously-named GameObject could accidentally match a leftover name from a previous test (NewAppsFlyerComponent() spawns default-named GameObjects), a classic order-dependent flakiness hazard.

[TearDown]
public void TearDown()
{
    foreach (var go in _spawned) UnityEngine.Object.DestroyImmediate(go);
    _spawned.Clear();
    AppsFlyer.CallBackObjectName = null; // avoid leaking static state into other tests
}

References:

• Martin Fowler: Eradicating Non-Determinism in Tests

[pazlavi]

Switching to applicationContext correctly avoids pinning a destroyed Activity, but UnityPlayer.currentActivity?.applicationContext ?: return makes init() fail silently if currentActivity happens to be null at that moment. Since sHandler is a process-lifetime singleton, that leaves the bridge permanently uninitialized for the rest of the process — every fireJson silently drops, every executeJson returns a generic "not initialized" error — with no log signal. Previously, direct currentActivity access would have thrown an NPE at the same point, at least surfacing the problem immediately.

Fix at the dependency level rather than patching around it here: com.appsflyer:af-android-plugin-bridge is currently pinned to 7.0.12 (android-unity-wrapper/unitywrapper/build.gradle:42, mirrored in Assets/AppsFlyer/Editor/AppsFlyerDependencies.xml:5); a newer release of that dependency introduces a context-provider pattern specifically to address this currentActivity-may-be-null timing problem. Bump af-android-plugin-bridge to the version that ships the context provider and have AppsFlyerRPCBridge.kt consume it instead of reaching into UnityPlayer.currentActivity directly — that removes the race at its source rather than just logging when it happens.

References:

• Android — Context types and avoiding Activity leaks

[pazlavi]

Five independent reviewers converged on this, and it's confirmed directly against the code: the new FireAsync helper — now the transport for essentially every "fire and forget" setter/action method in the public API (init, start, stop, logEvent, setCustomerUserId, anonymizeUser, ~70 methods in total) — calls AppsFlyerRPCClient.instance.Execute(...) instead of ExecuteFire(...). These are not interchangeable: Execute() (AppsFlyerRPCClient.cs:150, documented "Synchronous execute — use only for getter methods that return data") blocks the calling thread on a semaphore with a 5s timeout on iOS (AppsFlyerRPCWrapper.swift:86) and a blocking JNI CallStatic<string> call with no timeout on Android, and it throws AppsFlyerRPCException on any error response. ExecuteFire() (AppsFlyerRPCClient.cs:143, "Fire-and-forget for setter methods — no return value needed, no main-thread block") is the true non-blocking path the old Fire() used. Since FireAsync has no await before this call, it executes synchronously in place regardless of whether the caller awaits the outer Awaitable — so every previously-instant fire-and-forget call (including the ones invoked directly from OnApplicationPause, and the several chained calls inside init()) now blocks Unity's main thread for a full native RPC round trip on every single invocation. This is confirmed to be an unintentional regression, not a deliberate design change: at the prior commit (5115385) this same helper called ExecuteFire, and Tests_Suite.cs asserted Received(1).ExecuteFire(...); this diff changed the implementation and the test assertions to Execute(...) in lockstep (see the paired HIGH finding on Tests_Suite.cs below), which is why the test suite stayed green through the regression instead of catching it. ExecuteFire is now dead code in production. Given the scale of this decision (converting the entire fire-and-forget API surface), consider also writing an ADR for the FireAsync/Awaitable migration akin to docs/adr/0001-ios-deep-link-delivery-architecture.md, documenting the intended blocking/non-blocking contract so this class of regression is easier to catch in review.

// Current (regression) — blocks the calling thread for a full native round trip on every call
private static async Awaitable FireAsync(string method, Dictionary<string, object> parameters = null)
{
    AppsFlyerRPCClient.instance.Execute(method, parameters);
}

// Fix — restore the non-blocking, fire-and-forget transport
private static async Awaitable FireAsync(string method, Dictionary<string, object> parameters = null)
{
    AppsFlyerRPCClient.instance.ExecuteFire(method, parameters);
}

References:

• Unity Awaitable API
• Apple: DispatchSemaphore

[pazlavi]

Independent of the Execute/ExecuteFire transport bug above, FireAsync also drops the try/catch (AppsFlyerRPCException) that Fire() used to have — the old helper always logged failures via AFLog, regardless of whether the caller cared. Since none of the ~70 converted methods' real call sites in this repo were updated to await them (Assets/AppsFlyer/AppsFlyerObjectScript.cs — the script wired to the shipped AppsFlyerObject prefab — calls init, enableDebug, registerConversionListener, start fire-and-forget; test-app/Assets/Scripts/QATestScript.cs and AppsFlyerAPITester.cs do the same), an RPC failure that used to produce a log line now disappears completely — worse than the swallowed-but-logged behavior it replaced, and the opposite of the commit's stated goal ("so callers can observe completion/errors instead of exceptions being silently swallowed"). There is also no test anywhere in this diff asserting the new propagation behavior for any FireAsync-based method (only the pre-existing QueryAsync-based getters got exception-path coverage).

// Fix — keep an internal log-on-fault fallback so unawaited callers don't regress to total silence
private static async Awaitable FireAsync(string method, Dictionary<string, object> parameters = null)
{
    try { AppsFlyerRPCClient.instance.ExecuteFire(method, parameters); }
    catch (AppsFlyerRPCException e) { AFLog(method, "RPC error: " + e.Message); throw; }
}

References:

• Microsoft: Exceptions in async methods

[pazlavi]

The new doc comment claims call-site ordering "is preserved exactly like the fire-and-forget Fire() this replaced." That's true for ordering, but glosses over the more consequential difference: per the CRITICAL finding above, FireAsync currently blocks on every call instead of firing and forgetting. Once that's fixed, revisit this comment so it accurately describes the resulting behavior rather than implying full equivalence with the old helper.

[pazlavi]

This comment asserts flatly that calling the synchronous getters "no longer deadlocks" and is "now also safe to call from the main thread." That rests on an unverified assumption about the closed-source AppsFlyerRPCBridge.executeJson's internal threading behavior — the corresponding Swift file's own comment calls that behavior "undocumented." Combined with the HIGH finding below about rpcQueue.sync having no timeout of its own, a slow or stuck executeJson call could still block the calling thread for an unbounded time, or deadlock outright if it ever needs the main thread back. Soften this comment to state the assumption explicitly rather than asserting safety as settled fact.

References:

• Apple: Avoiding deadlocks with DispatchQueue.sync

[pazlavi]

As a direct consequence of the FireAsync/Execute mixup, every test that previously asserted mockRpc.Received(1).ExecuteFire(...) was mechanically rewritten in this diff to assert mockRpc.Received(1).Execute(...) instead (this line plus roughly a dozen more — Stop_FiresStopWithShouldStop, LogEvent_FiresLogEventWithNameAndValues, Init_Android_SendsInitWithDevKeyOnly, etc.). This keeps the suite green but means it now actively asserts the regressed (blocking) behavior instead of catching it. Once FireAsync is fixed to call ExecuteFire, these assertions need to revert, and ideally a test should assert Execute is never used for pure setter/logger methods.

References:

• NSubstitute — verifying calls

[pazlavi]

rpcQueue.sync here only guarantees serialized entry into AppsFlyerRPCBridge.executeJson — it has no timeout of its own, and it doesn't guarantee the underlying RPC round trip is serialized if executeJson is internally asynchronous (dispatches work and returns before its completion handler fires, which is plausible for a closed-source, completion-handler-based API). Two compounding risks: (1) if a queued executeJson call ever blocks synchronously longer than expected before returning, every other call sharing this one global serial queue — including a concurrent call from a different thread — blocks indefinitely with no cancellation, silently defeating the 5s SLA the semaphore/timeout pattern was designed to guarantee; (2) since FireAsync's bug (see CRITICAL finding) currently routes virtually all API calls through this same blocking path from Unity's main thread, this is now a real deadlock path, not just a stall, if that blocked call ever needs to synchronize back onto the main thread internally. Recommend verifying with the AppsFlyerRPC framework vendor that executeJson/setEventHandler never block synchronously beyond a bounded time and never hop back to the calling thread, or restructure so the queue submission itself (rpcQueue.async instead of .sync) is never blocking, relying solely on the semaphore's timeout for the bound.

// Current — unbounded wait for queue entry if executeJson ever blocks synchronously
rpcQueue.sync {
    AppsFlyerRPCBridge.shared.executeJson(requestStr) { jsonResponse in
        response = jsonResponse
        semaphore.signal()
    }
}
_ = semaphore.wait(timeout: .now() + 5)

// Safer — submission itself is never blocking; the 5s timeout is the only wait
rpcQueue.async {
    AppsFlyerRPCBridge.shared.executeJson(requestStr) { jsonResponse in
        response = jsonResponse
        semaphore.signal()
    }
}
_ = semaphore.wait(timeout: .now() + 5)

References:

• Apple: Avoiding deadlocks with DispatchQueue.sync
• WWDC: Combating deadlocks in concurrent code

[pazlavi]

_afFireJson is fire-and-forget and discards its completion result ({ _ in }), yet it's wrapped in rpcQueue.sync, which still blocks the calling thread for the duration of entering executeJson(...) for no benefit — since nothing is awaited, rpcQueue.async would serialize entry identically without ever blocking the caller. This is a needless-blocking anti-pattern for a call whose entire purpose is to not block.

// Better — true fire-and-forget, still serialized
rpcQueue.async {
    AppsFlyerRPCBridge.shared.executeJson(requestStr) { _ in }
}

References:

• Apple: DispatchQueue — sync vs async

[pazlavi]

The new TryGetConnector/TryCallStatic/WarnConnectorUnavailable guard correctly converts the disabled Android purchase-connector dependency from an unguarded NoClassDefFoundError crash into a logged warning, but has three residual gaps: (1) only the warning is deduplicated via _connectorUnavailableWarned — the new AndroidJavaClass(...) lookup itself is retried and re-fails on every subsequent call, paying needless JNI/exception overhead each time; consider caching the failure state, not just the warned flag. (2) _connectorUnavailableWarned is a static with no reset hook, a latent test-isolation hazard for whoever adds coverage next (there is currently none for this guard at all, and it can't be exercised by the Editor-based playmode suite since it's gated on UNITY_ANDROID && !UNITY_EDITOR). (3) since the entire Purchase Connector Android surface becomes a silent runtime no-op with no compile-time signal, consider marking the Android-facing entry points [Obsolete] (pointing at the AGP8 namespace-collision tracking issue) so integrators get a build-time warning instead of discovering the regression only when a purchase event never reports.

[Obsolete("Android Purchase Connector is temporarily non-functional (AGP8 namespace collision " +
          "with af-android-sdk, see AppsFlyerDependencies.xml). Track upstream fix before relying on this.")]
public static void init(MonoBehaviour unityObject, Store s) { ... }

References:

• Microsoft: ObsoleteAttribute
• NUnit test isolation guidance

[pazlavi]

Per the native SDK's own docs for the onPause RPC method: "For Cocos2dx platform only — Cocos2dx has its own applicationDidEnterBackground event. Therefore onPause will be called from C++ by JNI." This is a Cocos2dx-specific bridging requirement, not a Unity one — Unity already has its own reliable OnApplicationPause MonoBehaviour callback, so there is no engine-level gap for this RPC call to work around on the Unity side. The existing doc comment on this method (in AppsFlyer.cs, unchanged by this diff) misattributes the reason for keeping it, claiming Unity itself doesn't reliably deliver Android Activity foreground/background transitions — that justification belongs to Cocos2dx, not Unity. Recommend deleting OnApplicationPause/the onPause FireAsync call from this Unity plugin entirely rather than carrying over Cocos2dx-oriented boilerplate; confirm with the native SDK team that Unity's own Activity lifecycle already reports foreground/background correctly without this call before removing it.

[pazlavi]

AppsFlyerRPCClient.instance.InitBridge(...) is only ever called from inside init() (here and at line 92 for iOS/macOS), which means any RPC call made before AppsFlyer.init(...) has actually run has no native→Unity callback route wired yet. Confirmed this isn't a theoretical gap: _rpcBridge (AppsFlyerRPCClient.cs:167) is a static readonly field loaded via TryLoadAndroidBridge() at class-load time, independent of InitBridge — so the RPC dispatch machinery (Execute/ExecuteFire → fireJson/executeJson) is already available before init() ever runs, but responses/events routed back through the callbackObjectName channel InitBridge wires (_rpcBridge.CallStatic("init", callbackObjectName) on Android, _setRPCEventHandler on iOS) have nowhere to go until init() calls it. InitBridge should be called unconditionally as early as possible — e.g. from a static constructor or a [RuntimeInitializeOnLoadMethod] hook — rather than being gated behind init(), so the callback route exists as soon as the plugin loads regardless of call order.

[pazlavi]

The SDK mixes callback-delivery mechanisms and, in two cases, uses the wrong kind of mechanism for what the callback actually represents. Correct split per product intent (see the Flutter plugin's registerConversionListener for the reference shape: https://github.com/AppsFlyerSDK/appsflyer-flutter-plugin/blob/master/lib/src/appsflyer_sdk.dart): long-lived/recurring results — conversion data (onConversionDataSuccess/onConversionDataFail), deep link (OnDeepLinkReceived), session ready (OnSessionReady) — should be delivered via the register-function/event pattern; one-time results — request response, in-app/purchase-validation response, and generate-invite-link — should be delivered via an awaitable return value.

Current state against that split:

• OnDeepLinkReceived (line 991) is long-lived but wired backwards: it's a plain C# event whose add accessor (line 993, add { onDeepLinkReceived += value; registerDeepLinkListener(); }) triggers the RPC subscription as a side effect of subscribing via +=. Per the Flutter reference, the listener should instead be supplied directly as a parameter to registerDeepLinkListener(callback) — the register function itself is the API surface, not a += event with a hidden side effect in its accessor.
• OnSessionReady (line 997) is a plain C# event (add/remove, no side-effecting accessor) — likely fine as-is since session-ready has no separate native "subscribe" RPC call to trigger, but worth confirming with the same register-function shape for consistency if one gets added later.
• onConversionDataSuccess/onConversionDataFail (routed inside onRPCEvent, line ~1053) are long-lived by nature but still delivered via the legacy GameObject.SendMessage(eventType, dataStr, ...) idiom, and registerConversionListener() (line 409) takes no callback parameter at all — should be migrated to a single register function that takes the success/fail listeners as parameters, matching Flutter's registerConversionListener({onConversionDataSuccess, onConversionDataFail}).
• OnRequestResponse (line 979) and OnInAppResponse (line 985) are one-time results (an ack for a single track/request call, and a single purchase-validation response) but are currently implemented as long-lived C# events — this is backwards; they should instead be delivered as the awaitable return value of the call that triggers them (e.g. validateAndLogInAppPurchase at line 940/960 already returns Awaitable — OnInAppResponse firing alongside it as a second, separately-subscribed delivery path is redundant/conflicting).
• generateInviteLink (this line) is a one-time result but still uses the legacy GameObject.SendMessage("onInviteLinkGenerated"/"onInviteLinkGeneratedFailure", ...) wrapper instead of its already-correct awaitable twin, generateInviteLinkAsync (line 564).

Recommend: for deep link and conversion data, make the register function itself accept the listener(s) as parameters (registerDeepLinkListener(callback), registerConversionListener(onSuccess, onFail)) rather than exposing a separate += event; remove OnRequestResponse/OnInAppResponse as public events and instead surface their payloads as awaitable return values from the triggering calls; drop the SendMessage-based generateInviteLink wrapper in favor of generateInviteLinkAsync.

[pazlavi]

FireAsync is declared async Awaitable but its body is a single synchronous call (AppsFlyerRPCClient.instance.ExecuteFire(...)) with no await — the compiler synthesizes an already-completed-or-faulted Awaitable with nothing actually asynchronous happening. The doc comment above it (lines 23–30) correctly explains the consequence: an exception is only visible to a caller who awaits the result; a caller who doesn't gets the old "unobserved exception" silence. Every call site inside AppsFlyer.cs does await FireAsync(...), but nothing in the public API prevents an integrator from calling AppsFlyer.init(...)/AppsFlyer.start()/any other Awaitable-returning method without await — a very easy mistake coming from the pre-migration void-returning API — and on a bridge-load failure (e.g. IsBridgeAvailable == false) or any other RPC exception, that caller would get silent failure with only the new Debug.LogError path (which only covers the bridge-missing case, not a general RPC exception) to notice anything went wrong.

Recommend: catch and log inside FireAsync itself, the same way the old Fire() helper it replaced did, so the safety net doesn't depend on the caller choosing to await. The async Awaitable signature can stay (for call-site consistency with the other RPC methods) — the fix is just to not let an unobserved fault be the only failure path:

private static async Awaitable FireAsync(string method, Dictionary<string, object> parameters = null)
{
    try
    {
        AppsFlyerRPCClient.instance.ExecuteFire(method, parameters);
    }
    catch (Exception e)
    {
        AFLog(method, "RPC error: " + e.Message);
    }
}

References:

• C# async/await — exceptions in async void vs Task

[pazlavi]

getAppsFlyerUID()'s doc comment is the only synchronous getter still warning that calling it "deadlocks" on iOS's main thread. isSessionReady() and getSdkVersion() were already updated (in this diff) to the accurate "may block up to 5s" wording, reflecting that AppsFlyerRPCWrapper.swift's _afExecuteJson no longer hops through MainActor — it's a bounded rpcQueue-serialized semaphore wait now, not a deadlock. Leaving this one getter's comment stale will send integrators looking for a workaround to a problem that was fixed in this same commit.

References:

• Keep documentation in sync with source of truth

[pazlavi]

unregisterConversionListener() and the equivalent unregisterDeeplinkListener() (line 494) only fire the native RPC unregister call — neither one nulls the corresponding static callback field (onConversionDataSuccessCallback/onConversionDataFailCallback/onDeepLinkListenerCallback). After calling either, native stops delivering events, but the C# lambda reference stays alive in a static field for the lifetime of the process, keeping alive whatever it closes over (a MonoBehaviour, a scene object, a UI element) well past scene teardown — a static-lifetime delegate leak. Contrast with onSessionReady, which correctly clears its subscription via remove { onSessionReady -= value; }.

public static async Awaitable unregisterConversionListener()
{
#if UNITY_ANDROID
    await FireAsync("unregisterConversionListener");
#endif
    onConversionDataSuccessCallback = null;
    onConversionDataFailCallback = null;
}

References:

• .NET: static fields and GC roots

[pazlavi]

generateInviteLinkAsync's catch block only catches the base Exception type, so when native returns an RPC-level error, the structured AppsFlyerRPCException.Code/.Details are discarded — the caller only ever sees null back plus a log line. QueryValidateAndLogAsync (added in this same diff, for validateAndLogInAppPurchase) does this correctly: it catches AppsFlyerRPCException first to preserve .Details/.Message, then falls back to bare Exception. Callers of generateInviteLinkAsync can't distinguish a missing OneLink template from a network timeout from a malformed parameters dictionary — all three collapse to the same null.

Separately: generateInviteLinkAsync should be renamed to generateInviteLink now that the old fire-and-forget SendMessage-based generateInviteLink is gone and there's only one method left for this call.

References:

• Exception handling: catch specific types before general ones

[pazlavi]

fireJson's not-initialized path logs the full, unredacted $jsonRequest via Log.w. This is the serialized RPC request body — for methods like setCustomerUserId, logEvent/logAdRevenue (with purchase values), or setPhoneNumber/PII-bearing setters, that payload can contain customer identifiers and revenue data. Logcat output on a production device is not a safe sink for this — persisted device logs, bug-report captures, or a rooted/ADB-connected device can all read it. Redact or omit the payload from this log line (log the RPC method name only, not the full params).

References:

• OWASP MASVS: Sensitive data should not be logged

[pazlavi]

validateAndLogInAppPurchase is split into two method overloads distinguished only by parameter type — (AFPurchaseDetailsAndroid details, ...) (line 960) and (AFSDKPurchaseDetailsIOS details, ...) (line 982) — each independently gated by its own #if UNITY_ANDROID / #if UNITY_IOS || UNITY_STANDALONE_OSX block, and each returning null on the "wrong" platform. This is overloading standing in for what should be a single abstraction: AFPurchaseDetailsAndroid and AFSDKPurchaseDetailsIOS describe the same domain concept (a purchase to validate) but share no common type, so adding a third platform means adding a third overload rather than a third implementation of an existing contract — a SOLID (Open/Closed) violation. AFSDKValidateAndLogResult (the shared return type both overloads already converge on via QueryValidateAndLogAsync) should likewise be defined against an interface rather than as a single concrete class, so the result contract is explicit and not just an accident of both overloads happening to call the same private helper today.

Recommend: introduce a common purchase-details interface (e.g. IAFPurchaseDetails) implemented by AFPurchaseDetailsAndroid and AFSDKPurchaseDetailsIOS, and collapse the two overloads into one validateAndLogInAppPurchase(IAFPurchaseDetails details, Dictionary<string, string> additionalParameters) that dispatches to the platform-specific payload-building logic internally (or via a small per-platform strategy), rather than via overload resolution on the caller's static type. Define AFSDKValidateAndLogResult against a corresponding result interface for the same reason.

References:

• SOLID: Open/Closed Principle