Creating WKWebView blocks the main thread for a long time at SDK initialization

[KeithBauerANZ]

Expected Behaviour

SDK initialization should be near-instantaneous

Actual Behaviour

SDK initialization blocks the main thread for 50+ms as it creates a WKWebView.

There's commented-out code in the codebase to use URLSession's native WebSocket support. Presuming that code works, you can probably just uncomment it and use if #available to use it at runtime on iOS 13+.

Platform and Version

iOS, 3.1.2

[cdhoffmann]

Hey @KeithBauerANZ. Can you share your initialization code a long with the startSession API call. We only create a web view on the creation of an assurance session, and that does not happen on SDK initialization by default.

[KeithBauerANZ]

I see what you mean, I need to investigate why this happens on every app launch for us.

However, whenever we do call this, it will still guarantee a significant main-thread hitch, and using the faster implementation would still be preferable.

[cdhoffmann]

Just taking a shot in the dark but if you are initializing the SDK "MobileCore.registerExtensions..." from the didFinishLaunchingWithOptions as recommended by us, and then calling startSession within the registerExtensions callback you will be creating a session on every launch.

As for your second point, we do have an item in our backlog to support the Native websocket implementation but we don't have a date for it at the moment. I will leave this open so that we notify you when we have included native websocket support.

[KeithBauerANZ]

We do call MobileCore.registerExtensions([..., AEPAssurance.Assurance.self], ...) at app launch. We don't call startSession though.

registerExtensions calls AEPCore's ExtensionContainer.init
That eventually calls Assurance.onRegistered, which creates an AssuranceSession
That eventually calls AssuranceSession.handleOutboundEvents
That eventually accesses self.socket, which (lazily) constructs a WKWebView.

So I still think this is outside our control?

[cdhoffmann]

@KeithBauerANZ Oh so this is a second...(n) launch scenario where you are reconnecting to a session which has been created before? In that case, then yes this is expected behavior as we create a session object once we find that a session existed before. Remember that this is something which should only be happening in debugging scenarios to begin with, so this 50 ms delay is not going to affect customers.

[KeithBauerANZ]

You're right, fresh installs of the app don't trigger this behavior, and I have no idea if it's actually happening to consumers in the wild. I can't explain why it was happening to me though, either.

[cdhoffmann]

Let me clarify, if a customer were to start an Assurance session, then they would see the same behavior you are seeing as it is intended behavior (reconnecting to an established session on consequent launches). But, I assume that your customers are not starting an Assurance session to begin with.

[KeithBauerANZ]

Yep, thanks. I'm just not sure how I started an assurance session; it certainly wasn't deliberate. But that's not a problem with your SDK!