Debug UIWebView in your iOS app(idryman.org)
idryman.org
Debug UIWebView in your iOS app
http://www.idryman.org/blog/2012/06/17/debug-uiwebview-in-your-ios-app/
11 comments
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.
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.
Much easier just to use iWebInspector http://www.iwebinspector.com/
[deleted]
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).
This:
Another thing to note is that the inspector will use take the first webview in your application. There’s a common trick of creating an off-screen webview for checking the user agent string for whatever reason, and if you use a remote inspector you’ll get that one.
#if (TARGET_IPHONE_SIMULATOR)
Another thing to note is that the inspector will use take the first webview in your application. There’s a common trick of creating an off-screen webview for checking the user agent string for whatever reason, and if you use a remote inspector you’ll get that one.
According to this post in stack overflow http://stackoverflow.com/questions/1773615/apple-and-private... Apple can also detect `performSelctor:` that calls private APIs. Thus remember not to submit build with this code in it :)
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.
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.
You also don’t want it in the released app so that random guy in the coffee shop cannot connect to your app and mess with it while people use it.
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.)
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.'"
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.'"
This post is essentially just a compiler warning fix for the (much more interesting) one linked.