With RemoteDebug iOS WebKit Adapter, you can use the RemoteDebug iOS WebKit Adapter Use Chrome DevTools, VS Code, Firefox debugger.html to debug Safari and iOS WebViews

Today, we’re excited to introduce our new project, RemoteDebug iOS Webkit Adapter, Use VS Code, Chrome DevTools, Firefox debugger.html and other tools to debug Safari and iOS WebViews.

RemoteDebug iOS WebKit Adapter overview

RemoteDebug iOS Webkit Adapter Purpose

  1. Some tools based on Chrome Debugging Protocol (CDP) can also debug iOS Safari/Webkit.

  2. It can provide protocol adapters, and by the way, The Protocol adapter is used to handle the API differences between Chrome Debugging Protocol and Webkit Remote Debugging Protocol.

  3. Secondary development on ios-Webkit-debug-proxy. Why? This is because the RemoteDebug iOS Webkit Adapter project is actually built based on the ios-WebKit-Debug-proxy project, You can also think of the RemoteDebug iOS Webkit Adapter project as an extension of the ios-WebKit-Debug-proxy project

Goal

I’ve always wanted an open source protocol adapter, why? This is because, with open source protocol adapters, we don’t have to reinvent the wheel and can then allocate our efforts and resources wisely. Until now, protocol adapters have enabled a variety of tools and clients to debug Apache Cordova and iOS WebKit/Safari. In addition, the Central protocol adapter makes responsibility very clear (the above tools can focus only on API implementation, the protocol adapter only deals with compatibility issues).

Architecture

Although the protocol adapter itself is implemented in TypeScript, there are scenarios where you rely on Node CLI tools. This is because the protocol adapter requires ios-webkit-Debug-proxy. Ios-webkit-debug-proxy relies on Node), so the protocol adapter execution process is changed. The Node CLI tool first starts the ios-webkit-Debug-proxy instance, which then detects the connected ios device. Finally, start the corresponding protocol adapter according to the iOS version number.

RemoteDebug iOS WebKit Adapter architecture

Checking the iOS version number relies on the IdeviceInfo provided by LibiMobileDevice, which is (seriously) necessary. This is because the API exposed through WebKit Remote Debugging Protocol changes slightly between WebKit versions. The idea of using API differentiation as a starting point for iOS 10’s demotion to iOS 8 has already been implemented. See more implementation details.

Finally, the protocol adapter exposes the WebSocket server as well as the HTTP server, both of which support CDP. This means that it doesn’t seem to make much of a difference whether external tools (such as VS Code) connect to a Chromium-based runtime or a protocol adapter.

Describe The Adapter in a nutshell.

The protocol adapter gives a broad range of features that hasn’t been working for a long time between the apis exposed by the Chromium kernel and the WebKit kernel, You can also find your own growing delta.

  • DOM and CSS (DOM/CSS)

    Implements a range of basic DOM/CSS APIS that allow developers not only to review DOM elements, but also to modify the CSS of DOM elements.

  • Console

    As expected, the Console API implements the Console function, but this is done by mapping the Webkit Remote Debugging Protocol API to the new Chrome Debugging Protocol API.

  • Network Request Viewer (Network Tool)

    As expected, Network tool also implements functions for Network tool, and cookies can be activated by setting or deleting cookies.

  • Script debugging

    During script debugging, developers can become familiar with the usage of debugger-Statement in tools such as VS Code, debugger.html, and Chrome DevTools.

  • Screencasting

    As a little extra thing, the protocol adapter can also be used for a basic version of Screencasting with the help of Chrome developer tools. Of course, we also found that the WebKit kernel supports viewport screenshots by using the Page.SnapshotrectAPI. All of these mentioned above will help us simulate the screen recording features of Chromium. As for the performance warning feature, we will implement it in the caveat of performance is sub-pair with the native implementation. In addition, the touch behavior simulation is not thorough enough. It can be a very limited experience, but conceptually it works from a protocol adapter point of view.

Screencasting from iOS Simulator to Chrome DevTools

Getting started

First, keep in mind that the RemoteDebug iOS WebKit adapter runs on Windows and MacOS platforms. Next, you can start installing the adapter by using the NPM installation package:

npm install remotedebug-ios-webkit-adapter -g

Depending on your system, you may need to install some special dependencies during the installation process. For more installation details, follow the dependency installation tutorial provided in the README file.

In the process of using the adapter, Use the Adapter with Chrome DevTools, VS Code, and Firefox debugger.html. VS Code and Firefox Debugger.html)

First, you need to start the adapter from the command line of your preference:

remotedebug_ios_webkit_adapter --port=9000

Once the adapter is running, you can follow the guide to configure Chrome DevTools. This will show “discover network targets” on Chrome ://inspect#devices page. Alternatively, you can run the adapter on port 9222. IOS Targets can also be displayed on the Firefox debugger.html page.

Alternatively, you can Alternatively configure VS Code using the launch.json configuration file given below while opening the 9000 port. Once configured, you can easily debug Safari and iOS WebViews using VS Code.


{

    "version": "0.2.0"."configurations": [{"name": "iOS Web"."type": "chrome"."request": "attach"."port:": 9000."url": "https://kenenth.io/*"."webRoot": "${workspaceRoot}/src"}}]Copy the code

Thanks to Microsoft for sponsoring the work

The RemoteDebug iOS Webkit Adapter project started as a Microsoft internal experiment and wanted to connect the process with different runtime environments. Transparent to Visual Studio, VS Code, and other tools. Why? This is because our existing debugging tools are based on CDP and are mainly for Node and Chrome environments.

Today, the RemoteDebug iOS Webkit Adapter project has been donated to the RemoteDebug GitHub organization, which is also open source based on the MIT protocol. By making the RemoteDebug iOS Webkit Adapter project open source, the Microsoft team has made good on its promise, but this means that the Microsoft team will no longer maintain the project.

Many thanks to my current employer, Microsoft, for letting me be the project manager for the RemoteDebug iOS Webkit Adapter project, as well as to the rest of the team who worked so hard to get this project done. Special thanks to James Lissiak for providing the technical architecture diagram for the project due to his in-depth study of different protocol apis and his solution to the Screencasting bits problem. (Translator’s Note: There should be applause)

Going forward

The next task for the RemoteDebug iOS WebKit Adapter project is to implement the 32 apis that have yet to be developed. The adapter is fully covered with Chrome’s Debugging Protocol (CDP) API, but I’d like to see the community get involved as well.

While RemoteDebug iOS WebKit Adapter is still in its early days, the project has taken over the ios-WebKit-Debug-proxy project, And making WebKit debugging on iOS available to more tools is great! Profiling is still one of the bigger things that needs to get tackled but it can be difficult to think about, This is because Webkit Remote Debugging Protocol and Chrome Debugging Protocol differ greatly in the implementation of the underlaying data model. That said, if possible, performance analytics will allow some tools to be used, such as Lighthouse and CalibreApp to analyze the performance of WebKit kernel browsers.

What’s next for RemoteDebug? (What’s next for RemoteDebug)

  1. RemoteDebug’s focus will continue to be on Amway Standardized Core Debugging Protocol. Instead of being owned by browser vendors with mature open governance Model experience, more browser vendors can participate.
  2. RemoteDebug should include the RemoteDebug Test Suite so that when running across runtime, We can verify for ourselves that RemoteDebug has compatibility issues to make sure tools like VS Code are working properly. We haven’t started RemoteDebug yet, but I don’t think that should prevent you from using the RemoteDebug iOS WebKit Adapter in some scenarios. In addition to Chrome’s own implementation of RemoteDebug test targets, we already have one for RemoteDebug.

Finally, please try the RemoteDebug iOS WebKit Adapter. During the process of using it, you are welcome to issue it to us, and you are welcome to make suggestions on what needs to be improved on GitHub.