Move WebView init to main thread.

[jsligh]

Closes #988

[weibel]

Since I initiated this issue myself I have reviewed the code. Here's my feedback

There are some potential areas where improvements can be made to ensure thread safety, efficiency, and better management of the user agent string. Here are my suggestions:

• Use a synchronization mechanism like DispatchSemaphore to manage concurrent access to the user agent string.
• Persist the user agent string, to minimize fetch time on subsequent app launches. The WKWebView init and javascript evaluation on app start can take several hundred ms depending on os and device.
• Introduce a delay when initializing the WKWebView to ensure it's ready before evaluating JavaScript. (EDIT: This is probably not necessary. The registering of the webviews suggested below, seems to have solved this issue)

I have made a solution in a branch in our own fork https://github.com/Vivino/prebid-mobile-ios/pull/1 tell me if you want a PR

IMO it's a lot of work to fetch the string. Have you ever considered reverse engineering the string format and accept that it might not always reflect the string from WKWebView?

[YuriyVelichkoPI]

Hi @weibel, thanks for the review!

I like the idea to persist the ua string. However, we still should update the value because the user can update the OS, and the actual string will be changed as well.

We want to avoid blocking operations since we had already faced deadlock solving this task with semaphores. So let @OlenaPostindustria propose the fix as well, and we will choose the most reliable variant.

[weibel]

@YuriyVelichkoPI We could e.g. persist the string with the OS version as key. I tried this in the solution I linked to. It's still in review on our side.

Did you consider the following?

IMO it's a lot of work to fetch the string. Have you ever considered reverse engineering the string format and accept that it might not always reflect the string from WKWebView?

[YuriyVelichkoPI]

We could e.g. persist the string with the OS version as key. I tried this in the solution I linked to. It's still in review on our side.

Did you consider the following?

IMO it's a lot of work to fetch the string. Have you ever considered reverse engineering the string format and accept that it might not always reflect the string from WKWebView?

It should be considered on the committee. I'm not sure how sensitive this info is. In some cases it should be precies.