A Concise Guide to Remote Debugging on iOS, Android, and Windows Phone

remote_debugging_header

When I first started developing for mobile, my primary debugging tool was inserting alert() calls like it was 1999. It was nostalgic for about 30 seconds. My DevTools skills, honed during days of watching Paul Irish videos and years of memorizing keyboard shortcuts, were useless for mobile.

But things have come a long way since then. With the advent of remote debugging, I can now use the same developer tools I know and love from the desktop on mobile devices—even on Web views embedded within native apps.

Since there are already guides on remote debugging scattered around the Internet, my goal here is to consolidate that knowledge, and to present it in the context of hybrid application development (Web apps packaged in a native container).

In this article you’ll learn the best remote debugging approach for each of the three major mobile platforms: iOS, Android, and Windows Phone. You’ll see how to take a native-packaged Web app, and perform common debugging tasks such as inspecting elements and console logging.

For these examples I’m using a hybrid app I developed using Telerik AppBuilder: GifThself. GifThyself lets you build animated gifs with your device’s camera and share them. You can get the source to follow along at https://github.com/tjvantoll/GifThyself.

Contents

iOS

Apple added the ability to remote debug iOS applications in iOS6. To use it there are a few prerequisites. First, go to the Settings app on your iOS device. There, navigate to Safari –> Advanced, and toggle on the Web Inspector switch.

iphone-settings

In desktop Safari, go to the Safari –> Preferences… menu, select the Advanced tab, and ensure the Show Develop menu in menu bar check box is checked.

safari-show-develop

Because it requires Safari, remote iOS debugging is not available on Windows. For Windows users, your best option is weinre, which we’ll discuss momentarily.

Next, connect your iOS device to your development machine via USB and open the app you wish to debug. But be aware of one important restriction: iOS remote debugging is only available for apps built with a Development provisioning profile—not Ad Hoc, and not Distribution. If you use Telerik AppBuilder, you can import a Development profile and select it when performing a build, as the following screenshot shows:

select-profile

When you open an iOS app that was built using a development provisioning profile, it is immediately available as an inspectable application in Safari’s Develop menu.

safari-choice

At this point, you have the same Safari Web Inspector you use to debug Web applications on the desktop. You can select elements, tinker with CSS, debug JavaScript, profile your app, and more. In the following image, I inspect a paragraph in the Web Inspector, and see the paragraph highlighted on my device automatically:

ios-side-by-side

Android

Although Chrome for Android has had remote debugging for some time, remote debugging wasn’t available for PhoneGap/Cordova developers until quite recently, when Android 4.4 switched their WebView to use Chromium.

Like iOS, there are few prerequisites to use it. First, go to Settings –> About phone on your Android 4.4+ phone (Or Settings –> About tablet on your Android tablet). Next, as ridiculous as this sounds, tap the Build number seven times. You’ll get a tooltip message that congratulates you on becoming a developer. No, I’m not kidding.

android-about

Once you are a developer, head back to the main Settings page. There is a new Developer options menu option. Click it, and then check the USB debugging check box.

android-usb

Only apps that have a debuggable flag are candidates for remote debugging. If you’re using a Cordova version 3.3 or higher, you must add android:debuggable="true" to the <application> element in your AndroidManifest.xml file. If you’re using Cordova 3.2 or under, you must enable WebView debugging with some custom code.

If you are using Telerik AppBuilder, make sure that LiveSync is on when you perform your build. When it is, AppBuilder injects the necessary code to make remote debugging possible automatically.

android-build

Now connect your Android device via USB, and open the app you wish to debug. On your desktop, open Chrome and navigate to about:inspect. Check Discover USB Devices and you’ll see your application appear.

chrome-inspect-list

Click the Inspect link to open the Chrome DevTools for your app. From here you can use the DevTools functionality you know and love.

android-side-by-side

Need to debug older Android devices (< 4.4)? Check out jsHybugger; it provides most of the Chrome DevTools functionality for these older devices.

Windows Phone

Unfortunately, there is no official way to use remote debugging on Windows Phone apps; you cannot connect Internet Explorer to Mobile Internet Explorer for instance. Therefore you must resort to a 3rd party solution, the most elegant of which is weinre.

Weinre

weinre is short for WEb INspector REmote. It’s built on the WebKit Web Inspector, and is specifically designed to work remotely; therefore it’s great for Windows Phone, as well as any platform where native remote debugging is not available (BlackBerry, iOS on a Windows development machine, and so forth).

weinre runs on top of Node.js. Assuming you already have Node.js installed, to get started, just install it from npm.

> npm install -g weinre

weinre works by creating a debug server that acts as an intermediary between the debug target (i.e. your app) and the debug client (i.e. your development machine). To start a debug server, run weinre with the --boundHost option set to your development machine’s IP address. My machine’s IP address is 10.0.0.13, so I run the following:

> weinre --boundHost 10.0.0.13
2014-04-04T16:44:28.723Z weinre: starting server at http://10.0.0.13:8080

Use ipconfig getifaddr en0 to get your IP address on Macs, and ipconfig to get it on Windows.

The output of running weinre tells you the URL to access the development server from. In my case, this was http://10.0.0.13:8080. Visit this page in your browser of choice, and scroll to the Target Script section. The debug targets need to use the <script> tag listed to communicate with the debug server. Copy the <script> tag.

weinre-dashboard

Paste the <script> into your app’s HTML. You can change the hash portion of the URL to give the target a meaningful name. Here I use “windows”:

weinre-html

Next, launch the app on your device. Then, back on your development machine, navigate to http://[ip-address]:8080/client/#[target-name]— in my case http://10.0.0.13:8080/client/#windows. You should see the app with the <script> tag inserted listed as a target.

weinre-client

Click the target, then use the menu at the top to view the functionality that weinre offers. The contents of the various tabs should look familiar. For instance, here I select a paragraph on the Elements tab, and see it reflected live on my Windows Phone device:

weinre-view

Although weinre is flexible, in that it runs across multiple platforms, it is also limited; you cannot debug JavaScript or profile your application for instance. Nevertheless, weinre provides a convenient way of performing common debugging tasks such as viewing JavaScript errors, tinkering with CSS, and running commands from the JavaScript console. It certainly beats alert() calls.

Additional Resources

Comments

  • Kent C. Dodds

    The author of Weinre recommends to not use Weinre these days. I’ve never done windows debugging so I don’t know what to recommend, but just thought I’d throw this out there: https://twitter.com/kentcdodds/status/448776824902803456

    • Hey @kentcdodds:disqus, thanks for commenting. In this case, Windows Phone falls into the same bucket as Android <= 4.3—there isn't a better remove debugging option.

      • Juan Carlos Alpizar Chinchilla

        not to mention remote debugging iOS apps in Windows, haven’t found a better option 🙁

      • Juan Carlos Alpizar Chinchilla

        not to mention remote debugging iOS apps in Windows, haven’t found a better option 🙁

  • Pingback: Bringing F5 (or Command+R) to Hybrid Mobile Apps | Telerik Developer Network()

  • Pingback: The State of Hybrid Mobile Development | Technology Blog()

  • Pingback: Supercharge Your App Development with Ionic and AppBuilder -Telerik Developer Network()

  • tds
  • Guest
  • You can now debug iOS through windows by using gapDebug. Check out http://www.genuitec.com/products/gapdebug/

  • Pingback: Thinking outside the Box – Making HFT Games | HappyFunTimes()

  • JonKragh

    TJ great article. If I have AppBuilder + Visual Studio (on windows) + a Connected iPad with the AppBuilder Companion App, is there a way to atleast see console.log() or soem other kind of debug output?

    I have that working in the same setup with Genymotion. Thanks!

    • Thanks Jon! JS If you deploy the app as an app package AppBuilder gives you access to the full iOS debugger in Visual Studio. But you’re right that you don’t have access to the logs from the companion app today; it’s something we’re considering adding in the future. For now JS Console is a good way to see the logs from the companion apps: http://jsconsole.com/.

      • JonKragh

        Wow really? So should I deploy and NOT use the companion app?

        I’m looking for guidance on quickly testing and debugging Cordova plugins. I can use the simulator for testing angular & the rest.

        What is the best setup? I have everything. AppBuilder, ios devices, android devices, genymotion, visual studio, sublime, etc.

        I run on windows as my powerhouse machine for dev.

        Any guidance on an ideal workflow? I’m currently trying to debug the Facebook login on actual devices with the facebook plugin from the Telerik Plugin Marketplace.

        But first I just have a blank appbuilder project and trying to get a workflow going. (Currently on the devices I was using companion, but I can deploy if that’s better).

        GREATLY APPRECIATE feedback here.

        • The companion app is great for quick testing, and I usually use it when I’m starting up my apps, but once you start getting into the complex stuff I indeed recommend deploying to physical Android and iOS devices.

          By deploying you can test all Cordova plugins and all configuration changes (Info.plist, AndroidManifest.xml, etc); you can use the full browser debugging tools within Visual Studio; and you can still use LiveSync to immediately see your changes.

          When I’m working in Visual Studio here’s my workflow: I start by connecting an iOS and Android device, both of which I’ve already setup for debugging so they appear within my “Devices List”. I then use the “Build and Deploy” option to install my app on both of those devices.

          Then I start developing. After I make changes I click “Synchronize {ProjectName} with Cloud” which I actually have mapped to a keyboard shortcut, and then I perform a LiveSync on each of my devices to see the change in action.

          After that I launch the browser’s developer tools by going to “Devices List” and clicking the “Debug” button for the device I want to debug from. Typically I only open one debugging console (usually iOS) and keep that open during development. I usually only open the other platform’s console for debugging if I run into issues specifically on that platform.

          And that’s it. I find that being able to both use LiveSync and view a developer console provides a really good development experience, which is why I recommend developing with app packages. If you have any other questions let me know. I have a very similar workflow that I like to use from the CLI too.

          • JonKragh

            TJ this is gold! Thank you. I cannot wait to try this workflow this weekend!

            This Visual Studio workflow would make for a great blog post!

          • JonKragh

            TJ I have this working now, it is AWESOME!!! Thank you.

            iOS and Android debugging right from VS!

            One more quick question. From an Android or iOS if you are hitting a development web api, what do you use to hit your local machine?

            I have been trying my local IP whcih I can hit from the device browser but angular’s $http is having an issue that I’m digging into.

            I’m wondering how you attack this. Thanks!

          • Awesome! I’ll have to get around to writing a blog post on this.

            I’m not sure I’ll be able to help with your HTTP issue though. I usually test using local IPs or virtual hosts as well, so I’m not sure what Angular’s $http module wouldn’t like about that.

  • Pingback: Hybrid Remote Salesforce Mobile SDK & Cordova Tips()

  • Vadim Ridosh

    You can use GapDebug for debugging iOS devices under Windows. It is free as a free beer, and you’re not forced to modify your app (like you should with weinre), and debug abilities are the same with Mac OS Safari debugger.

  • Pingback: How can I render .mtl for object on iPhone 5 using ThreeJS? - DexPage()

  • Pingback: Apple:Is there a web inspector available on iOS? – Apple Questions()

  • Pingback: Hybrid Mobile Development()

  • In your title “A Concise Guide to Remote Debugging on iOS, Android, and Windows Phone” -> ” Unfortunately, there is no official way to use remote debugging on Windows Phone apps”. Just remove it from your title then if you are not sure about yourself 😉

    As tds already said, using Visual Studio, under Debug > Windows > DOM Explorer, you can check html + css content. Visual Studio has also a dedicated Javascript console.

    https://msdn.microsoft.com/en-us/library/hh441474.aspx#InspectingDOM

  • Pingback: How to Estimate a Mobile App Project | AppPresser()

  • aj

    What an article! Thanks