OpenPanel.initialize is not safe to call from either the main thread or a background thread due to a deadlock in the internal getiOSUserAgent implementation. This makes it impossible to initialize the SDK without causing either a crash or a ~1 second UI freeze.
Root cause
Inside DeviceInfo.getiOSUserAgent():
let webView = WKWebView(frame: .zero) // (1) must be on main thread
var userAgent = ""
let semaphore = DispatchSemaphore(value: 0)
DispatchQueue.main.async { // (2) queued on main thread
webView.evaluateJavaScript("navigator.userAgent") { (result, error) in
if let agent = result as? String { userAgent = agent }
semaphore.signal()
}
}
_ = semaphore.wait(timeout: .now() + 1.0) // (3) blocks calling thread
This creates two mutually exclusive failure scenarios:
Scenario A — Called from main thread:
Step (1) is fine.
Step (3) blocks the main thread via semaphore.wait.
Step (2)'s main.async block is queued but can never execute because the main thread is blocked.
The semaphore always times out after 1 full second, freezing the UI every time.
Scenario B — Called from a background thread:
Step (1) crashes immediately with Main Thread Checker: UI API called on a background thread: -[WKWebView .cxx_construct].
Observed crash (background thread):
Main Thread Checker: UI API called on a background thread: -[WKWebView .cxx_construct]
Queue name: com.apple.root.utility-qos
#5 OpenPanel.DeviceInfo.getiOSUserAgent()
#6 OpenPanel.DeviceInfo.getUserAgent()
#7 OpenPanel.OpenPanel.initialize(options:)
Observed freeze (main thread): OpenPanel.initialize always blocks the calling thread for exactly 1 second (the semaphore timeout), regardless of device speed, because the JS evaluation can never signal the semaphore while the thread is waiting on it.
Expected behavior
OpenPanel.initialize should be safe to call from the main thread without blocking it. The user agent should be fetched asynchronously and either:
Cached lazily on first use after a non-blocking async fetch, or
Fetched during initialize without blocking (e.g. completion-based), or
Simply use getBasicUserAgent() as the default and upgrade to the WKWebView-based UA once it becomes available asynchronously.
Suggested fix:
private static func getiOSUserAgent(completion: @escaping (String) -> Void) {
DispatchQueue.main.async {
let webView = WKWebView(frame: .zero)
webView.evaluateJavaScript("navigator.userAgent") { result, _ in
let agent = (result as? String) ?? getBasicUserAgent()
completion(agent + " OpenPanel/\(OpenPanel.sdkVersion)")
}
}
}
OpenPanel.initialize is not safe to call from either the main thread or a background thread due to a deadlock in the internal getiOSUserAgent implementation. This makes it impossible to initialize the SDK without causing either a crash or a ~1 second UI freeze.
Root cause
Inside DeviceInfo.getiOSUserAgent():
This creates two mutually exclusive failure scenarios:
Scenario A — Called from main thread:
Step (1) is fine.
Step (3) blocks the main thread via semaphore.wait.
Step (2)'s main.async block is queued but can never execute because the main thread is blocked.
The semaphore always times out after 1 full second, freezing the UI every time.
Scenario B — Called from a background thread:
Step (1) crashes immediately with Main Thread Checker: UI API called on a background thread: -[WKWebView .cxx_construct].
Observed crash (background thread):
Observed freeze (main thread): OpenPanel.initialize always blocks the calling thread for exactly 1 second (the semaphore timeout), regardless of device speed, because the JS evaluation can never signal the semaphore while the thread is waiting on it.
Expected behavior
OpenPanel.initialize should be safe to call from the main thread without blocking it. The user agent should be fetched asynchronously and either:
Cached lazily on first use after a non-blocking async fetch, or
Fetched during initialize without blocking (e.g. completion-based), or
Simply use getBasicUserAgent() as the default and upgrade to the WKWebView-based UA once it becomes available asynchronously.
Suggested fix: