Repository navigation
'mparticle-apple-integration-appboy' Improve SDK stability #371
Description
Hi team,
I hope you're doing well.
We're currently facing a crash in our app that's significantly affecting our crash-free score — we've seen approximately 24.8k occurrences since May 3rd.
The issue appears to be caused by an app hang on the main queue, related to the Braze SDK getting stuck inside an async function during initialization. We've already reached out to Braze support, and implementing background initialization on our side has successfully resolved the issue.
To do this, we used the Braze.prepareForDelayedInitialization() method, which allows you to initialize the SDK on a background queue. You can find the relevant documentation here.
For reference, this was the switch that we implemented in our side:
extension BrazeSdkWrapper {
func initialiseSdkInBackground() {
Braze.prepareForDelayedInitialization()
DispatchQueue.global(qos: .background).async { [weak self] in
guard let self else { return }
self.brazeSdk = Braze(...)
}
}
func initialiseSdkInForeground() {
self.brazeSdk = Braze(...)
}
}Also for more context on the crash, here's the stack trace:
CrashReporter Key: e950f79d5fc837a14e24ab3bc12090e36beea92d
Hardware Model: iPhone12,1
Process: Glovo
Identifier: com.myglovo
Version: 11.10.0
Role: Foreground
OS Version: iOS 18.3.2
App Hang: The app's main thread failed to respond to an event within 2000 milliseconds
0 libsystem_kernel.dylib +0x1700 _semaphore_wait_trap
1 libdispatch.dylib +0x4540 __dispatch_sema4_wait
2 libdispatch.dylib +0x4bf4 __dispatch_semaphore_wait_slow
3 Glovo +0x9205ac specialized AsyncViewStore.executeSync(_:)
4 Glovo +0x91f690 BrazeViewStore.start()
5 Glovo +0x9d54b8 specialized NSRecursiveLock.sync<A>(work:)
6 Glovo +0x91f05c BrazeViewStore.enabled.setter
7 Glovo +0x9d5444 specialized NSRecursiveLock.sync<A>(work:)
8 Glovo +0x90083c Braze.enabled.setter
9 Glovo +0x901e1c Braze.init(configuration:)
10 Glovo +0x902ae0 @objc Braze.init(configuration:)
11 Glovo +0x4faf7d0 -[MPKitAppboy start]
12 Glovo +0x5047a58 __54-[MPKitContainer handleApplicationDidFinishLaunching:]_block_invoke
13 libdispatch.dylib +0x2244 __dispatch_call_block_and_release
14 libdispatch.dylib +0x3fa4 __dispatch_client_callout
15 libdispatch.dylib +0x12a30 __dispatch_main_queue_drain
16 libdispatch.dylib +0x12648 __dispatch_main_queue_callback_4CF
17 CoreFoundation +0x79bc8 ___CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
18 CoreFoundation +0x761bc ___CFRunLoopRun
19 CoreFoundation +0xc8280 _CFRunLoopRunSpecific
20 GraphicsServices +0x14bc _GSEventRunModal
21 UIKitCore +0x3ee670 -[UIApplication _run]
22 UIKitCore +0x14e84 _UIApplicationMain
23 Glovo +0x270a8 main (AppDelegate.swift:65:7)
24 dyld +0x2fde4 start
We’d really appreciate your help in applying a similar fix on your end to address this crash and improve overall stability.
Activity
johannsa commentedon Aug 5, 2025
Hi @claudiomadureira! Due to some issues introduced in Braze SDK v9, we have been asking our customers for a while (documentation here) that they initialise the instance of the underlaying SDK (Braze) and they provide a reference to the instance to us.
Note: This is only for iOS and Braze SDK >= v9.
My understanding is that if you follow the above document, then the issue would not be present.
Do you have any comments on the above?
claudiomadureira commentedon Aug 5, 2025
Hi @johannsa ! Thank yoou for the reply. I'll perform the changes and I'll let you know about it. Is it ok to leave the issue opened yet till we have results?
nickolas-dimitrakas commentedon Sep 17, 2026
Closing — this is documented at https://docs.mparticle.com/integrations/braze/event/#ios-app-launch-tracking : for Braze SDK 9+ on iOS, initialize the Braze SDK yourself (e.g. via Braze.prepareForDelayedInitialization()) and provide the instance to mParticle, which avoids the main-thread hang during kit start. Let us know if that doesn't fully address it and we'll reopen.