HTTPDNS:Use HTTPDNS in WebView scenarios on iOS

1. Introduction

In Use HTTPDNS in native scenarios on iOS, you learned how to use HTTPDNS in native scenarios on the iOS platform to implement anti-hijacking, precise scheduling, and instant DNS resolution.

WKWebView is another scenario on iOS that frequently involves network requests. WKWebView is a modern web view provided by the WebKit framework for displaying web content in iOS applications. It replaces the legacy UIWebView and provides better performance, more features, and higher security. Using HTTPDNS when WKWebView loads web pages can improve network security and performance.

2. Current technology

As the iOS system evolves, technical solutions for integrating HTTPDNS with WKWebView are also evolving:

• Before iOS 17.0: Apple did not provide official hook interfaces for DNS resolution in WKWebView. It also did not directly provide interfaces for custom network request implementations. This required complex solutions that intercepted traffic by hooking private APIs.

• iOS 17.0 and later: Apple introduced the ProxyConfiguration API. This API provides official proxy configuration capabilities for WKWebView. It lets you reliably intercept all network requests, making it possible to seamlessly integrate HTTPDNS.

According to official Apple statistics (as of June 4, 2025), iOS 17 and later is installed on over 85% of all iPhone devices, and this number is growing. HTTPDNS provides non-functional improvements for WKWebView scenarios, such as anti-hijacking, precise scheduling, and instant resolution. Therefore, we recommend using this solution to integrate HTTPDNS. This approach covers most customers. Users on older system versions will gradually gain this capability as they upgrade.

3. Recommended solution: Local proxy-based solution for iOS 17+

source 'https://github.com/aliyun/aliyun-specs.git'

target 'yourAppTarget' do
    use_framework!
    
    pod 'AlicloudHTTPDNS', 'x.x.x'
    pod 'EMASLocalProxy', 'x.x.x'
end

#import <EMASLocalProxy/EMASLocalProxy.h>
#import <AlicloudHttpDNS/AlicloudHttpDNS.h>

// Create a WKWebViewConfiguration
WKWebViewConfiguration *config = [[WKWebViewConfiguration alloc] init];

// Configure the DNS resolver
[EMASLocalHttpProxy setDNSResolverBlock:^NSArray<NSString *> *(NSString *hostname) {
    // Get the HTTPDNS service instance
    HttpDnsService *httpdns = [HttpDnsService sharedInstance];
    HttpdnsResult *result = [httpdns resolveHostSyncNonBlocking:hostname byIpType:HttpdnsQueryIPTypeBoth];

    if (result && (result.hasIpv4Address || result.hasIpv6Address)) {
        NSMutableArray<NSString *> *allIPs = [NSMutableArray array];
        if (result.hasIpv4Address) {
            [allIPs addObjectsFromArray:result.ips];
        }
        if (result.hasIpv6Address) {
            [allIPs addObjectsFromArray:result.ipv6s];
        }
        NSLog(@"HTTPDNS resolution successful. Domain name: %@, IP: %@", hostname, allIPs);
        return allIPs;
    }

    NSLog(@"HTTPDNS resolution failed. Domain name: %@", hostname);
    return nil;
}];

// Set the log level
[EMASLocalHttpProxy setLogLevel:EMASLocalHttpProxyLogLevelDebug];

// Configure the WebView proxy
BOOL proxyConfigured = [EMASLocalHttpProxy installIntoWkWebViewConfiguration:config];
if (proxyConfigured) {
    NSLog(@"WebView proxy configuration successful.");
} else {
    NSLog(@"WebView proxy configuration failed. Using the system network.");
}

WKWebView *webView = [[WKWebView alloc] initWithFrame:self.view.bounds configuration:config];

4. Global NSURLProtocol interception solution

This solution was the earliest feasible option for integrating HTTPDNS with iOS WebView. It has a very high barrier to entry and is not very effective. However, it has persisted because iOS did not offer other choices in its early years. Its principle is based on NSURLProtocol, which can intercept network requests sent from upper-layer network libraries such as NSURLConnection/NSURLSession on iOS. Requests from WKWebView are also included. After intercepting the requests, the solution uses HTTPDNS for domain name resolution and subsequent processing. The steps are as follows:

1. You can register a custom NSURLProtocol through the following interface to intercept upper-layer network requests from WKWebView. You can then create a new network request to take over data sending, receiving, redirection, and other processing logic. The results are then fed back to the original request.

   [NSURLProtocol registerClass:[HttpDnsNSURLProtocolImpl class]];

2. The following is an overview of the custom NSURLProtocol processing procedure:

   • In canInitWithRequest, filter the requests that require HTTPDNS domain name resolution.

   • After the request is intercepted, perform HTTPDNS domain name resolution.

   • After resolution is complete, replace the URL.host field and the HTTP Header Host field, similar to a normal request. Then, take over the data sending, receiving, redirection, and other processing for this request.

   • Use the NSURLProtocol interface to feed the request processing results back to the original WebView request.

3. For more information about the implementation logic of the custom NSURLProtocol, see HttpDnsNSURLProtocolImpl.m in the provided demo.

5. Solution summary and comparison

This document introduces two main technical solutions for integrating HTTPDNS in WKWebView scenarios on iOS: the local proxy solution based on iOS 17 and later, and the global NSURLProtocol interception solution.

Each solution has its specific scenarios, advantages, disadvantages, and implementation complexity. To help you make a quick decision, the following table provides a side-by-side comparison of these two solutions:

Considering stability, development and maintenance costs, and future trends, we strongly recommend the local proxy solution based on iOS 17 and later.

With the rapid adoption of iOS 17 and later system versions, this solution provides stable and reliable HTTPDNS services to the vast majority of users at a minimal cost. It effectively solves domain hijacking and improves network performance. Its elegant implementation and official support ensure the long-term feasibility of the solution. For system versions earlier than iOS 17, a smooth fallback strategy is used. This means the system's default network requests are used. When users upgrade their systems, they automatically benefit from HTTPDNS.

The other solution has inherent complexity and uncertainty. Adopt it with caution. It is recommended only for teams with special requirements and deep technical expertise, after careful evaluation and thorough testing.