Currently I am using HTML files for parts of my user interface. I display these files via WebView. This works as expected in debug mode in Xcode. Unfortunately, after having archived the app, the HTML resources are not being shown anymore.
That’s strange for many reasons: I can see the files are definitely in the correct resources folder within the app, the WebView doesn’t disappear or hide, it simply shows a white background as if it hasn’t loaded anything.
This observation is true for all HTML files within my project. Even if I don’t use them for UI but in order to export some data within a shareable HTML file, it doesn’t work (in release mode).
I did research on this issue but didn’t find anything of interest. I’m running out of ideas now…
Since you didn’t give your code in the question, it’s very hard to debug it… But from your own answer, I’m pretty sure I know the problem. You’re treating path strings and URL strings as interchangeable, and they’re not.
You suggest this:
(I added some newlines to make it readable.)
To call +[NSURL URLWithString:], you need a string representing a URL, not a string representing a path. But -[NSBundle pathForResource:ofType:inDirectory:] returns a path. There is a function to construct a URL from a path, +[NSURL fileURLWithPath:isDirectory:], if that’s what you want.
But, unless you need to support 10.5 and earlier, it’s much easier to just get a URL in the first place and not bother converting back and forth, by using -[NSBundle URLForResource:withExtension:subdirectory:] instead of -[NSBundle pathForResource:ofType:inDirectory:].
So:
In case you’re wondering why your code works in some cases but not others, consider what “/Applications/MyApp.app/Contents/” (I’m leaving off the “Resources/HTML/inspectorView/inspectorView.html” for brevity, because that’s not relevant here) means when read as a URL. It’s a relative URL; to interpret it, you take the current base, knock off the path portion, and replace it with the string. +[NSURL URLWithString:] happens to use “file://localhost” as the base, which means you end up with:
That happens to be a valid URL, and in fact the valid URL for exactly the file you wanted. That’s not documented to work, but it happens to. In this case. But what if you put a space in it? Then you get:
That’s not a valid URL; what you want is this:
And of course that’s exactly what you get if you call +[fileURLWithPath:isDirectory:] instead of +[URLWithString:].
(I’m cheating a bit here. Actually, NSURL internally keeps track of the relative URL and the base separately, and composes them when you try to access the URL. But you can ignore that for now.)