iOS — recurring App Store hang in IMSilentSwitch createAudioFile (InMobiSDK 11.1.1, AdMob mediation)

[AnyMindG]

Hello InMobi Support support@inmobi.com ,

We are seeing a recurring App Store hang attributed to the InMobi SDK in our
iOS app (please fill in app name) (App Store ID: please fill in your app's
ID). The hang signature involves IMSilentSwitch createAudioFile on the main
thread during ad mediation initialization, and we need your help confirming
the upstream status and identifying a fixed SDK / adapter version.

This is reported on our live App Store build running InMobiSDK 11.1.1 with
GoogleMobileAdsMediationInMobi 11.1.1.0 and Google-Mobile-Ads-SDK 12.14.0. We
have separately built and validated GoogleMobileAdsMediationInMobi 11.4.1.0
(with InMobiSDK 11.4.1) in our development workspace, but have not rolled it
to production yet because we want to confirm with your team whether 11.4.x
actually addresses this hang before changing the SDK on the live app.

---

1. Integration context

• App: (please fill in app name — currently iOS)
• iOS deployment target: 16.0 and above
• Mediation stack: Google Mobile Ads SDK (AdMob) with InMobi as a third-party
  mediation adapter
• Pods installed on the live App Store build (CocoaPods 1.17.0):
  • Google-Mobile-Ads-SDK 12.14.0
  • GoogleMobileAdsMediationInMobi 11.1.1.0
  • InMobiSDK 11.1.1
• Adapter location (device build): Pods/GoogleMobileAdsMediationInMobi/InMobiA
  dapter-11.1.1.0/InMobiAdapter.xcframework/ios-arm64/
• SDK location (device build): Pods/InMobiSDK/InMobiSDK.xcframework/ios-arm64/
• Mediation init pattern on the live app:
  // Off main, before AdMob init completes
  dispatch_async(dispatch_get_global_queue(QOS_CLASS_USER_INITIATED, 0), ^{
  [IMSdk initWithAccountID:kInMobiAccountID];
  });
  [GADMobileAds.sharedInstance startWithCompletionHandler:nil];
• AdMob unit IDs: (please fill in your rewarded video / interstitial / banner
  unit IDs that route through InMobi)
• InMobi placement IDs involved: (please fill in)
• Frequency: triggered both on cold start and on first rewarded/interstitial
  load after launch.
• Internal validation status: GoogleMobileAdsMediationInMobi 11.4.1.0 +
  InMobiSDK 11.4.1 builds and runs cleanly in our dev workspace (GAMDemo). We
  have not yet confirmed via production telemetry whether the hang signature
  disappears with that upgrade.

---

2. Hang signature (symbolicated)

Hang Type: App Store hang (main thread blocked)
Attributed To: InMobiSDK
Hang Signature: -[IMSilentSwitch createAudioFile] + 616
(IMSilentSwitch.m:176)
Hang Contribution: 10% of total hang time in app
Occurrences: 5,803
Duration: 6–7 s (range up to 10 s)
Affected iOS: (please fill in — typically iOS 16/17/18 mix from App Store
reports)

Full stack (symbolicated):
_dispatch_async_and_wait
→ IMAudienceBiddingToken / IMBaseAdRequestModel
→ -[IMDeviceVolumeManager getDeviceVolumeWithPublisherVolumeControl:]
→ +[IMSilentSwitch shared] (dispatch_once)
→ -[IMSilentSwitch setupAudioServices]
→ -[IMSilentSwitch createAudioFile] + 616 (IMSilentSwitch.m:176)
→ -[AVAudioFile initForWriting:settings:commonFormat:interleaved:]
→ AudioComponentFindNext / registerInternalAudioUnits
→ dyld dlopen_from
→ main thread blocked ~6–10s

Historical comparison (same code path persists across major versions):

• InMobiSDK 5.97.0 showed the same AVAudioFile → AudioToolbox → dlopen path at
  unsymbolicated offset +415436.
• InMobiSDK 6.01.0 confirmed the symbol as createAudioFile.
• InMobiSDK 11.1.1 (current production) still shows the same signature in App
  Store hang reports.

---

3. Interpretation

+[IMSilentSwitch shared] is being entered via dispatch_once from
IMDeviceVolumeManager.getDeviceVolumeWithPublisherVolumeControl: during the
audience-bidding-token collection path. The first-time dispatch_once triggers
setupAudioServices → createAudioFile, which initializes an AVAudioFile for
writing. On a cold start this forces AudioToolbox + ExtAudioFile unit
registration and a dyld dlopen_from of system audio components — all executed
on the main thread because IMAudienceBiddingToken synchronously waits
(_dispatch_async_and_wait) for the result.

The result is a 6–10 s main-thread freeze on the first ad request after
launch, which App Store is classifying as a hang and surfacing to users.

This is consistent with a known class of issues in IMSilentSwitch first-time
initialization and the publisher-volume-control code path being reachable from
synchronous mediation-init callers.

---

4. Questions for InMobi support

Please confirm or clarify the following so we can take the correct action:

(a) Confirmation. Is InMobiSDK 11.1.1 known to execute
IMSilentSwitch.createAudioFile (via dispatch_once → setupAudioServices)
synchronously on the calling thread when
IMDeviceVolumeManager.getDeviceVolumeWithPublisherVolumeControl: is invoked
from IMAudienceBiddingToken? If yes, is this behavior expected, or is it a
regression introduced in the 11.x line relative to 10.x?

(b) Fixed SDK / adapter version. Which InMobi iOS SDK version (and
corresponding GoogleMobileAdsMediationInMobi adapter version) definitively
moves the audience-bidding-token / device-volume probe off the synchronous
main-thread path? Please reference the specific build or changelog entry that
confirms the fix, so we can correlate with our hang telemetry before and after
the upgrade.

(c) Configuration flag. Is there a documented iOS-side configuration to
disable the silent-switch audio file creation when not used (similar to
Android's InMobiSdk.setMediaSessionEnabled(false))? We do not currently use
InMobi for audio creatives — only display / video — and would prefer to skip
this code path entirely if a flag exists. (Note: we have already evaluated
IMSdk.shouldAutoManageAVAudioSession: and MraidConfig.enableSDKAVAudioSession
— both appear scoped to HTML-video playback only, not to IMSilentSwitch
first-time init.)

(d) Recommended mediation-init guidance. Please share the recommended sequence
and threading for IMSdk initWithAccountID: and AdMob's
startWithCompletionHandler: so that the AdMob mediation-init path
(requestAudienceBiddingToken / prepareToken) does not synchronously reach
IMSilentSwitch on the main thread. If there is a specific init flag, async
API, or pre-warm sequence, please document it.

(e) Adapter-only update path. If the fix is adapter-side (in
GoogleMobileAdsMediationInMobi), please indicate the exact minimum adapter
version that no longer triggers getDeviceVolumeWithPublisherVolumeControl:
synchronously during token collection. We can then pin to that adapter version
independently of the underlying InMobiSDK release.

(f) Escalation path. If this is an unfixed regression in 11.1.1 rather than a
duplicate of the 10.x bug, please escalate to the SDK engineering team and
provide a target fix version. We can provide additional telemetry
(unsymbolicated stack dumps, device mix, occurrence timestamps, App Store hang
dashboard export) on request.

---

Thank you for your help. We want to keep InMobi in our mediation stack but we
cannot ship a 6–10 s main-thread freeze on first ad load. A clear answer to
questions (b) and (d) is the most important for us — once we know the correct
pinned version and init pattern, we can roll it out and re-measure against the
current 11.1.1 baseline.