
Debug UIWebView in your iOS app - dryman
http://www.idryman.org/blog/2012/06/17/debug-uiwebview-in-your-ios-app/
======
Xuzz
The real article you want is (as linked):
[http://atnan.com/blog/2011/11/17/enabling-remote-
debugging-v...](http://atnan.com/blog/2011/11/17/enabling-remote-debugging-
via-private-apis-in-mobile-safari/)

This post is essentially just a compiler warning fix for the (much more
interesting) one linked.

------
brainlock
If you absolutely need to debug something _on the device_ in iOS 5, I wrote
this a few weeks ago: <https://github.com/brainlock/ios-remote-inspector>

I had a rendering bug that only happened on the device, not in the simulator.

This opens the web inspector locally, and exposes a proxy on port 55555 for
you to access from your working machine.

Not really useful on iOS 6 anymore :-) but still, useful on iOS 5.

------
jfhollingworth
Much easier just to use iWebInspector <http://www.iwebinspector.com/>

------
shaggyfrog
Debugging? That's cool. Just don't submit a build with this code in it to
Apple -- it will get rejected for using a private API (the underscore in
_enableRemoteInspector is a dead giveaway).

~~~
dryman
According to this post in stack overflow
[http://stackoverflow.com/questions/1773615/apple-and-
private...](http://stackoverflow.com/questions/1773615/apple-and-private-apis)
Apple can also detect `performSelctor:` that calls private APIs. Thus remember
not to submit build with this code in it :)

~~~
gauravk92
So just infer the method name at runtime.

The static analyzer could alert a human of a dynamic performSelector call but
they're still a myriad of ways to get around that as well. With just a tiny
bit of obfuscation any human is simply going to dismiss analyzing the
disassembly to figure out what's going on since performSelector is a valid API
call. They can't remove you from being able to do things at runtime either or
make only make static calls to objc_message.

Literally the only technical solution would be for them to run the app through
some sort of dynamic analyze,r where it runs the code and figures out
everything that's going on. There are obvious issues with such a system though
even theoretically.

For example, let's say you have a variable x which has a value determined at
runtime:

x = figureOutXBasedOnSomeRuntimeStuff()

if (x) { InferPrivateMethodNameAndPerform() } else { DoSomethingElse() }

The analyzer has to traverse all paths to actually know if a private method is
being called but it can't just run the code once with x as true, and once with
x as false. It's a dynamic environment so those actions may have radically
different actions based on other variables or the user's preferences at
runtime, etc. And if it simply runs the app then many code paths get missed.
Maybe in the distant future the analyzer could actually play around with your
app enough and possibly go through every code path that way. But by simply
having it tied to a page on the Internet, you can just wait till its approved
and then enable it.

So one obvious conclusion might be to have a human disassemble the app and
figure out what's going on. But that's simply not economically feasible and
even experienced security analysts can have a hard time figuring out what code
is doing, even if you have the source code.

It's more likely overtime they will dull the sharp edges of objective c,
especially for iOS. At which point the entire SDK will be structured in such a
way as to not allow you to do things you aren't supposed to. But they can't
prevent you from ripping llvm off of opensource.apple.com and compiling
without the restrictions. In terms of a technical solution, it itself is not
economically feasible. Definitely easier to just ban infringing people when
they get caught, old fashioned way.

In summary it's more likely that they just don't care. Apple knows being on
the app store is more valuable then using the minus button illegally (hah
camera+). So they simply won't do anything about it, you can slip your app
onto the app store taking full advantage of the private APIs with a bit of
obfuscation and they'll most likely just let it through. They are smart enough
to know realistically their efforts to enforce this rule is futile, so they
probably just don't care and will simply ban you from the store (unless your
app is making shit tons of money, then they'll just tell you to fix it).

I don't recommend it either but from a technical standpoint it's a very
interesting puzzle of sorts.

------
SeoxyS
Uh, shouldn't the class be `UIWebView`, not `NSClassFromString(@"WebView")`?
(Specifically, the class name would be missing the UI prefix, and the string-
class conversion is redundant.)

~~~
dryman
The `_enableRemoteInspector` is a private method to the private class
`WebView`. If you use `UIWebView` it will cause runtime exception
'NSInvalidArgumentException', reason: '+[UIWebView _enableRemoteInspector]:
unrecognized selector sent to class 0x6df1ec'

If Automatic reference counting (ARC) feature was enabled, the compiler would
raise an error for the code `[NSClassFromString(@"WebView")
_enableRemoteInspector];` : "No known class method for selector
'_enableRemoteInspector.'"

