Essentially, yes. To elaborate on the linked bug a bit:

You can use UIWebView, the older interface. The biggest problem is that its JavaScript engine is slower than Safari's, and does not JIT compile code (according to Apple, this is for security reasons). I've also seen complaints about scrolling performance.

You can use WKWebView, the newer interface. Its JavaScript engine does JIT, and it boasts 60fps scrolling. Unfortunately, it's missing several features detailed in the bug, including a way to clear and manage cookies, custom URL handlers, POST request bodies missing in certain cases, etc.

One would hope that the WkWebView bugs and omissions will be addressed in future iOS versions, but today is not possible to make an iOS browser that works as well as Safari.

Last I checked, iOS's third-party app policies forbid the implementation of anything akin to a JIT compiler, and even third-party usage of the standard WebView component disables the Nitro JIT. I'm not an iOS dev though, I have no idea if there's been any progress in this space recently.

Yeah, it's seemingly changed since you last checked. Now they allow you to use the Nitroj JIT. I'm not an iOS developer as well, just heard it.

Its changed now with IOS 8, JIT is enabled for WKWebkit

To be precise, it's not that JIT is now allowed in iOS; that would be a security issue because it would basically allow sandboxed apps to create executable memory area, which is considered very bad. On the contrary, what just happens is that WKWebView is piggy-backing on the new extension system to run in a different process, with a different relaxed sandbox, and communicates to the host app with an IPC channel (similar to eg. Chrome extensions). It looks like there are not enough features exposed over this IPC channel to make a fully featured browser, yet.