Seeing Crash while initilizing the sdk

[PSinha1202]

We have an app in Production that is crashing in iOS 18.0, which uses the 4.1.2 SDK. In order to resolve the issue we also updated the SDK to 4.3.3, and a few of the developers using Xcode 16.0 and Swift 6 complete and iOS 18.0 simulator are seeing the crash.

The crash is seen the moment the app launch.
App Delegate --> calls a function that initiates the SDK, and it crashes.

Is this is known or being worked on? This is affecting our user base so a quick resolution would be appreciated.

Here are the crash logs

thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x10a82ced4)
    frame #0: 0x000000010a82ced4 MyClass`(1) suspend resume partial function for closure #2 @Swift.MainActor @Sendable () async -> () in closure #1 @Sendable () async -> () in static DeviceRisk.SigmaDevice.processDevice(context: DeviceRisk.SigmaDeviceContext, callback: (Swift.Optional<Swift.String>, Swift.Optional<DeviceRisk.SigmaDeviceError>) -> ()) -> () + 328
    frame #1: 0x000000010a82e8fc MyClass `(1) await resume partial function for partial apply forwarder for closure #2 @Swift.MainActor @Sendable () async -> () in closure #1 @Sendable () async -> () in static DeviceRisk.SigmaDevice.initializeSDK(_: Swift.String, options: Swift.Optional<DeviceRisk.SigmaDeviceOptions>, callback: (Swift.Optional<Swift.String>, Swift.Optional<DeviceRisk.SigmaDeviceError>) -> ()) -> ()

frame #2: 0x000000010a82e8d0 MyClass `(1) await resume partial function for reabstraction thunk helper from @escaping @callee_guaranteed @Sendable @async () -> () to @escaping @callee_guaranteed @Sendable @async () -> (@out ())
    frame #3: 0x000000010a82e900 MyClass `reabstraction thunk helper from @escaping @callee_guaranteed @Sendable @async () -> () to @escaping @callee_guaranteed @Sendable @async () -> (@out ())partial apply forwarder with unmangled suffix ".96TQ0_"
    frame #4: 0x000000010a82d80c MyClass `(1) await resume partial function for generic specialization <()> of reabstraction thunk helper <τ_0_0, τ_0_1 where τ_0_0: Swift.Sendable, τ_0_1 == Swift.Never> from @escaping @callee_guaranteed @Sendable @async () -> (@out τ_0_0) to @escaping @callee_guaranteed @async () -> (@out τ_0_0, @error @owned Swift.Error)
  * frame #5: 0x000000010a82e6a8 MyClass `reabstraction thunk helper <τ_0_0, τ_0_1 where τ_0_0: Swift.Sendable, τ_0_1 == Swift.Never> from @escaping @callee_guaranteed @Sendable @async () -> (@out τ_0_0) to @escaping @callee_guaranteed @async () -> (@out τ_0_0, @error @owned Swift.Error)generic specialization <()> of partial apply forwarder with unmangled suffix ".101TQ0_

[rburunkayaSocure]

Hi @PSinha1202,

Thanks for contacting us. Is this crash report is from the SDK v4.1.2 or v4.3.3? If the issue is from the v4.1.2 then upgrading SDK version to 4.3.3 may help but if it is from v4.3.3 then we may need little bit more information.

Can you let us know more about you code integration looks like?

Kind regards,

[PSinha1202]

@rburunkayaSocure thanks for a quick follow up.

The crash logs is from sdk 4.3.4, we saw the notes of fix in 4.3.0, so tried to upgrade it with the hope it would fix it.

Here is the sample code

@main @MainActor
class AppDelegate() {

func application(_ application: UIApplication,
                   didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

....
   myclassObject.initializeSocureSigma()
  ....
}
}


class MyClass {

  
   func initializeSocureSigma() {

      SigmaDevice.initializeSDK(sdkKey) { token, error in
            if error {
              ....
            }

       }
   }
}

[PSinha1202]

update:

We use Bitrise to make our builds, and even there, it's crashing. We tried Xcode 16.0, and even with Swift 5.0 and with latest sdk 4.3.3.

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x0000000107fe1080
Triggered by Thread:  0

Thread 0 Crashed:
0   MyApp           	       0x107fe1080 closure #2 in closure #1 in static SigmaDevice.processDevice(context:callback:) + 328
1   MyApp           	       0x107fe2aa9 partial apply for closure #2 in closure #1 in static SigmaDevice.initializeSDK(_:options:callback:) + 1
2   MyApp           	       0x107fe2a7d thunk for @escaping @callee_guaranteed @Sendable @async () -> () + 1
3   MyApp           	       0x107fe2aad thunk for @escaping @callee_guaranteed @Sendable @async () -> ()partial apply + 1
4   MyApp           	       0x107fe19b9 specialized thunk for @escaping @callee_guaranteed @Sendable @async () -> (@out A) + 1
5   MyApp           	       0x107fe2855 thunk for @escaping @callee_guaranteed @Sendable @async () -> (@out A)specialized partial apply + 1
6   libswift_Concurrency.dylib    	       0x2448d3829 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1```

[rburunkayaSocure]

Hey @PSinha1202

Can you let us know about code in your closure. The crash is happening in the callback closure so it could be related to something there.

Thanks

[DJohnsonGusto]

Hi @rburunkayaSocure

Inside the intializeSDK closure, we either log an error or update UserDefaults. Even if we remove all logic from the closure, the same error is being hit.

SigmaDevice.initializeSDK(sdkKey, options: nil) { _, _ in } // Same crash noted above

[rburunkayaSocure]

Hi @DJohnsonGusto

I have one more question. Do you see that on any specific device or all devices on iOS 18?

Thanks

[PSinha1202]

Few of the iOS devices (we have six users so far complained) are seeing crashes. A few developers are also seeing crashes in the simulator as well.

[rburunkayaSocure]

Hey @PSinha1202

We are going to work on reproducing the issue on our end and get back to you. Also can you please send an email to support@socure.com email to continue communication through support channel.

Thanks,

[PSinha1202]

sent the email to the support group.

[PSinha1202]

Hi Team,

Checking to see if the team is able to reproduce the issue and have any clue for the crash.

[rburunkayaSocure]

Hi @PSinha1202

We are still working on reproducing the issue but no luck so far. Our engineering team is eager to schedule a call with your team to debug issue. We can continue our conversation on support thread which your team is already opened.

Thanks