What’s everyone’s take on this. If an app just needs to show specific web page(s), it will obviously look more integrated using the HTMLViewer.LoadURL() seems to work fine in my testing. It says any protocol besides HTML may or may not work depending on the OS, assuming this is not an issue, any other reasons not to use it?
Obviously, the other options is to just open a browser to the desired URL using GotoURL.
It really depends on several factors, but mainly what pages are you displaying.
If they’re say help pages on your site, a HTMLViewer is fine. If however it’s a third party site that needs cookies and passwords, use the default web browser with showURL.
I use both. HtmlViewer.LoadURL looks more integrated and I can display a special price for buying my app. But I also have a GoToURL.
It’s also important to note that HTMLViewer on Desktop doesn’t support hardware interaction with things like media devices, or the notification API.
The user is a factor too. I used to do my OAuth with HTMLViewer, but users were concerned about putting their passwords into my app. Of course, I know I’m not stealing their password and couldn’t if I wanted to, but the user doesn’t know how this stuff works. Having the user use their own browser helped user confidence greatly, plus they can use their password manager easier.
So again, it’s all about context. There isn’t one perfect answer.
I use an HTMLViewer in all areas, except when I cannot! For example, if the HTMLViewer WebPage has a Movie, it cannot go full screen.
You could use an HTMLViewer, but have a button to ‘View in Browser’.
As a user, I personally prefer seeing links in my preferred browser (so I can bookmark them, if I want). In apps coming with in-app browsers, I appreciate when there is an opt-out setting for that feature.
You already can bookmark your sites with HTMLViewer.
One need to add a Bookmark window and code to deal with (save to disk / read from disk).
Really easy to do. (of course takes a bit of time, but fun to have).
Nota: I love that Cookies are not supported on HTMLViewer 
Errr, can I bookmark them on desktop and open them on my mobile Safari later? 
I will still miss features from my browser.
Thanks all for the great feedback. Sam’s comment mentions exactly the type of thing of how I’d most likely be using it to open a URL to something like help.
I certainly understand and agree about opening a browser for all the features, passwords, cookies, bookmarks, etc, if sending the user to a website for something more than some content like help.
The only way I know of HTMLViewer not handling cookies is on Windows using the WebKit renderer and adding a CancelLoad event handler. Cookies are working just fine in every other situation here
If you are relying on this broken buggy behavior you should know it’s been marked as fixed.
Circling back on topic, I only use HTMLViewer in my updates window because of the simplicity of the content. I launch my help in the user’s web browser because the content is significantly more intricate and allows the user to bookmark pages.
IMO, content like help should not be displayed in an internal HTMLViewer.