WKWebView iOS 26 preventing javascript injections

I have an ASP.NET WebForm website application running under a WebView (WKWebView) developed with DotNet MAUI, and I've been experiencing problems since compiling with iOS 26. Specifically, there are two buttons on the webform. These buttons use some JavaScript code defined within the page via onClientClick from the ASPX page, while the button is also called from the server side using code like this:

string encodedMessage = System.Web.HttpUtility.JavaScriptStringEncode(diffLocationMessage, true); string scriptError = $"hideLoading(); showBootStrapStyleAlert({encodedMessage}, 'error');"; ScriptManager.RegisterStartupScript(this, GetType(), "Alert_Error_DiffLoc", scriptError, true);

Some of these JavaScript scripts work, while others don't.

At the same time, the OnClientClick button on the MAUI side uses a special handler to process a parameter (ENTRY or EXIT) received from these buttons and updates some hidden fields and labels on the webform side.

await myWebView.EvaluateJavaScriptAsync( $"if(document.getElementById('hfLatMaui')) document.getElementById('hfLatMaui').value = '{latitude}';"); await myWebView.EvaluateJavaScriptAsync( $"if(document.getElementById('hfLonMaui')) document.getElementById('hfLonMaui').value = '{longitude}';"); await myWebView.EvaluateJavaScriptAsync( $"if(document.getElementById('hiddenCurrentLat')) document.getElementById('hiddenCurrentLat').value = '{latitude}';"); await myWebView.EvaluateJavaScriptAsync( $"if(document.getElementById('hiddenCurrentLon')) document.getElementById('hiddenCurrentLon').value = '{longitude}';");

// Part 2: Update labels await myWebView.EvaluateJavaScriptAsync( $"if(document.getElementById('lblLatMaui')) document.getElementById('lblLatMaui').innerText = '{latitude}';"); await myWebView.EvaluateJavaScriptAsync( $"if(document.getElementById('lblLonMaui')) document.getElementById('lblLonMaui').innerText = '{longitude}';");

Server-side operations are performed with the values ​​received from here.

While the above problems did not occur up to iOS 18.x and Xcode 16.4, they are now occurring.

What should I do? What do you suggest?

NOTE-1: When my iPhone is connected to my M4 Pro PC via a Type-C Lightning cable, I saw that everything worked correctly when I ran the page under the Develop menu in Safari - I tested it.

NOTE-2: The problem is, as explained in NOTE-1, that the WebView executes some JavaScript behaviors while blocking others.

Answered by DTS Engineer in 888306022

Thanks for the careful diagnostic work. Two observations from your post jump out:

  • Same source code, two builds: the Xcode 16.4 / iOS 18 SDK build runs correctly in iOS 26, the Xcode 26 / iOS 26 SDK build does not.
  • The page itself runs correctly in Safari with Web Inspector attached.

Together, those localize the problem to how the WKWebView is being set up or driven inside your app at the iOS 26 SDK build, rather than the page or the device. The "some JavaScript executes while others don't" pattern is the most useful clue for narrowing further.

That pattern is consistent with WKContentWorld isolation in WKWebView. WKContentWorld separates JavaScript execution into distinct namespaces:

  • The page world (WKContentWorld.pageWorld) — JavaScript executed here can see page-defined globals, including functions defined in the page's <script> tags such as hideLoading() and showBootStrapStyleAlert().
  • A client world (WKContentWorld.defaultClientWorld or a named world) — JavaScript executed here can manipulate the DOM, but runs in an isolated JavaScript context that does not see page-defined globals or functions.

The simple two-argument evaluateJavaScript:completionHandler: is documented to evaluate in pageWorld. The fuller evaluateJavaScript:inFrame:inContentWorld: and callAsyncJavaScript: forms require the caller to specify the world explicitly.

If, somewhere in the path between your code and WKWebView, the calls go through the inContentWorld variant with a non-pageWorld value, the symptom fits exactly: DOM updates like document.getElementById('x').value = ... still work (the DOM is shared across worlds), but calls to page-defined functions silently fail (page globals are not visible from a client world).

To narrow this down, I'd suggest attaching Safari Web Inspector to the WKWebView inside your running app (not the same page loaded directly in Safari). With the device connected, in Safari on the Mac choose Develop → [Your iPhone] → [the WKWebView in your app]. With the Web Inspector attached while the failing operation runs, the JavaScript console will show what's actually happening:

  • A "function is not defined" error → JavaScript is running but in a world that can't see the page-defined function. That points at WKContentWorld isolation.
  • A CSP or cross-origin error → a content security policy is blocking the script.
  • An exception reading or writing a DOM node → the DOM-side call also failed and timing is the issue (the script ran before the element existed).
  • Nothing in the console at all → the script never reached WKWebView, which is a different class of issue (the call may be failing or being skipped earlier in the path).

Sharing what the console shows during the failing operation would let me narrow this further.

One additional debugging note: the Network panel in Web Inspector will show whether any required script files or page resources fail to load on the new build but loaded on the old one. A late-loading <script> can produce intermittent "function not defined" symptoms that look like the page is partly working.

NOTE-3 : The same IPA compiled with Xcode 16.4 / iOS 18.x works correctly on the same iPhone 13 device

NOTE-4 : iOS 26.4.1 beta, iOS 26.5 beta, Xcode 26.x EAP, Rider macOS 2026.1.1 (not listing iOS device list ) & 2026.1.1 EAP (listed iOS device list)

Thanks for the careful diagnostic work. Two observations from your post jump out:

  • Same source code, two builds: the Xcode 16.4 / iOS 18 SDK build runs correctly in iOS 26, the Xcode 26 / iOS 26 SDK build does not.
  • The page itself runs correctly in Safari with Web Inspector attached.

Together, those localize the problem to how the WKWebView is being set up or driven inside your app at the iOS 26 SDK build, rather than the page or the device. The "some JavaScript executes while others don't" pattern is the most useful clue for narrowing further.

That pattern is consistent with WKContentWorld isolation in WKWebView. WKContentWorld separates JavaScript execution into distinct namespaces:

  • The page world (WKContentWorld.pageWorld) — JavaScript executed here can see page-defined globals, including functions defined in the page's <script> tags such as hideLoading() and showBootStrapStyleAlert().
  • A client world (WKContentWorld.defaultClientWorld or a named world) — JavaScript executed here can manipulate the DOM, but runs in an isolated JavaScript context that does not see page-defined globals or functions.

The simple two-argument evaluateJavaScript:completionHandler: is documented to evaluate in pageWorld. The fuller evaluateJavaScript:inFrame:inContentWorld: and callAsyncJavaScript: forms require the caller to specify the world explicitly.

If, somewhere in the path between your code and WKWebView, the calls go through the inContentWorld variant with a non-pageWorld value, the symptom fits exactly: DOM updates like document.getElementById('x').value = ... still work (the DOM is shared across worlds), but calls to page-defined functions silently fail (page globals are not visible from a client world).

To narrow this down, I'd suggest attaching Safari Web Inspector to the WKWebView inside your running app (not the same page loaded directly in Safari). With the device connected, in Safari on the Mac choose Develop → [Your iPhone] → [the WKWebView in your app]. With the Web Inspector attached while the failing operation runs, the JavaScript console will show what's actually happening:

  • A "function is not defined" error → JavaScript is running but in a world that can't see the page-defined function. That points at WKContentWorld isolation.
  • A CSP or cross-origin error → a content security policy is blocking the script.
  • An exception reading or writing a DOM node → the DOM-side call also failed and timing is the issue (the script ran before the element existed).
  • Nothing in the console at all → the script never reached WKWebView, which is a different class of issue (the call may be failing or being skipped earlier in the path).

Sharing what the console shows during the failing operation would let me narrow this further.

One additional debugging note: the Network panel in Web Inspector will show whether any required script files or page resources fail to load on the new build but loaded on the old one. A late-loading <script> can produce intermittent "function not defined" symptoms that look like the page is partly working.

Thanks for the reply but when deploy to the simulator its crashing so that i can't test anything

( my setup is macOS 26, xCode 26.4.1, 26.5 simulators, macOS Rider 26.1.2 )

here ise crash report


Translated Report (Full Report Below)


Process: XsentiusMaui [37730]

Path: /Users/USER/Library/Developer/CoreSimulator/Devices/F24D336A-217A-4B3C-9D86-B11FF5A3C57C/data/Containers/Bundle/Application/054985D3-AA75-4CCE-A103-35EC0BE523B0/XsentiusMaui.app/XsentiusMaui

Identifier: com.cozbim.xsentiusmobile

Version: 1.0.1 (101)

Code Type: ARM-64 (Native)

Role: Foreground

Parent Process: launchd_sim [37350]

Coalition: com.apple.CoreSimulator.SimDevice.F24D336A-217A-4B3C-9D86-B11FF5A3C57C [7708]

Responsible Process: SimulatorTrampoline [1010]

User ID: 501

Date/Time: 2026-05-19 20:09:33.7484 +0300

Launch Time: 2026-05-19 20:09:33.6347 +0300

Hardware Model: Mac16,1

OS Version: macOS 26.5 (25F71)

Release Type: User

Crash Reporter Key: 307E060A-0B57-9A0D-D769-4CCF07BED703

Incident Identifier: DDDD5089-C8EA-4AD0-BD3B-539845EBA70D

Sleep/Wake UUID: 9513F2DA-21DC-45FA-AD7A-E168F1211B79

Time Awake Since Boot: 77000 seconds

Time Since Wake: 3520 seconds

System Integrity Protection: enabled

Triggered by Thread: 0

Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))

Exception Subtype: UNKNOWN_0x32 at 0x00000001014c4000

Exception Codes: 0x0000000000000032, 0x00000001014c4000

Termination Reason: Namespace CODESIGNING, Code 2, Invalid Page

VM Region Info: 0x1014c4000 is in 0x1014c4000-0x101564000; bytes after start: 0 bytes before end: 655359

  REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL

  mapped file                 1014a4000-1014c4000    [  128K] r--/rwx SM=COW  Object_id=c68cd9f9

---> mapped file 1014c4000-101564000 [ 640K] r--/rwx SM=COW Object_id=580d2308

  GAP OF 0x2d4000 BYTES

  mapped file                 101838000-101aec000    [ 2768K] r-x/rwx SM=COW  Object_id=e9bd83c8

Thread 0 Crashed:

0 dyld_sim 0x1011be980 mach_o::UnsafeHeader::forEachLoadCommand(void (load_command const*, bool&) block_pointer) const + 44

1 dyld_sim 0x1011c1460 mach_o::UnsafeHeader::forEachSegment(void

....

Thanks for sending the crash report. The simulator launch crash is a different issue from the JavaScript-injection problem we were tracking, and the good news is it doesn't have to block the JS debugging — more on that at the end.

The simulator crash is a code-signing failure at dynamic load

The most informative parts of the crash report:

  • Termination Reason: Namespace CODESIGNING, Code 2, Invalid Page
  • Crashing thread: dyld_sim, in mach_o::UnsafeHeader::forEachLoadCommand / forEachSegment
  • The crash happens about 3 ms after launch — the dynamic linker is still loading binaries from the .app bundle and your code never runs.

What this means: as dyld maps pages of a binary into memory, the kernel verifies each page against the binary's code signature. One page doesn't match, the kernel terminates the process, and the crash report points at the mapped-file region that failed. The address (0x1014c4000) with "Invalid Page" wording typically indicates a page-hash mismatch — either the binary was modified after signing, or it was signed in a way the simulator runtime doesn't accept.

This is unrelated to WKWebView and to the JavaScript-injection issue we were discussing. The app isn't reaching any code that uses WKWebView.

A few directions to investigate:

  • Run codesign -dv --verbose=4 on the main executable and on each .dylib, .framework, or other embedded binary inside your .app bundle. That tells you what's signed, by which identity, and whether the signature is intact.
  • Try matching the simulator runtime to the SDK. You mentioned Xcode 26.4.1 with an iOS 26.5 simulator — running an iOS 26.4 simulator (matching the SDK version) is a quick experiment that confirms or rules out a runtime/SDK mismatch.
  • Make sure your .NET iOS workload is current. dotnet workload list shows what's installed; dotnet workload update updates it. The .NET toolchain produces and signs the embedded runtime binaries in a MAUI app, so the workload version is the most likely place a signing-related change for Xcode 26 would land.
  • For a launch crash like this, the fastest progress is usually a report to the .NET MAUI / Xamarin issue tracker, with the codesign -dv output for the bundled binaries and your exact tool versions attached. The crash happens before any of your code runs, so the question is how the toolchain produced the bundle.

The on-device path for the JavaScript debugging is still open

Even while the simulator situation is being sorted out, you can investigate the JS-injection issue on device. The iOS 26 SDK build runs on your iPhone 13 — that's the configuration where JS partially works, which is exactly what we want to debug. Web Inspector attaches to your running app on a real device the same way it would attach to the simulator.

The flow is:

  1. Run your Xcode 26 / iOS 26 SDK build on the iPhone 13 connected via USB.
  2. In Safari on the Mac, choose Develop → [Your iPhone] → [the entry for the WKWebView inside your app]. The entry will be labeled with your app's name or with the URL the WKWebView is currently showing — not "Safari", which is a separate process.
  3. With the JavaScript console open, trigger the operation in your app that's failing.
  4. The errors (or silence) on the console will tell us which of the four scenarios from my previous message you're in.

The test you described in NOTE-1 was the page loaded directly in Safari on iPhone, which is a different process from your app's WKWebView and doesn't go through any of the EvaluateJavaScriptAsync paths. Attaching Web Inspector to the WKWebView inside your running app is the test that will give us the diagnostic information we need.

This is unrelated to WKWebView and to the JavaScript-injection issue we were discussing. The app isn't reaching any code that uses WKWebView.

yes i know but when its occured wanted to share with you

For a launch crash like this, the fastest progress is usually a report to the .NET MAUI / Xamarin issue tracker,

what is your suggestion? should i I clean install Rider macOS 26.1.2 (latest and simulator problem solved version) and Xcode & emulators?

Run your Xcode 26 / iOS 26 SDK build on the iPhone 13 connected via USB.

In Safari on the Mac, choose Develop → [Your iPhone] → [the entry for the WKWebView inside your app]. The entry will be labeled with your app's name or with the URL the WKWebView is currently showing — not "Safari", which is a separate process. With the JavaScript console open, trigger the operation in your app that's failing. The errors (or silence) on the console will tell us which of the four scenarios from my previous message you're in. The test you described in NOTE-1 was the page loaded directly in Safari on iPhone, which is a different process from your app's WKWebView and doesn't go through any of the EvaluateJavaScriptAsync paths. Attaching Web Inspector to the WKWebView inside your running app is the test that will give us the diagnostic information we need.

Yes I know and as I said before which mentioned NOTE-1 i tried to run and everything was fine

main is problem is when run it under webview

hope to explain clearly and we will find the solution both of for device deploy and webview problem

regards

Hi soykanozcelik,

A few things on your follow-up.

On a clean install: updating Rider to the version that fixes the iOS-device-listing issue is reasonable — that's a JetBrains-side question and using their latest stable is the standard advice there. The dyld code-signing crash on the simulator is a separate issue: that crash originates in how the bundle is signed, which the .NET iOS workload is responsible for — not Rider or Xcode. A clean reinstall of Xcode and the simulator runtimes is unlikely to fix the crash by itself. Updating the .NET iOS workload is more likely to address the signing failure (use dotnet workload list to check the current version, then dotnet workload update).

On the WebView debugging: yes, the JavaScript is failing inside your app's WebView, and that's where the diagnostic information needs to come from. The NOTE-1 test you described — opening the page in Safari on the iPhone via the Develop menu — loads the page in Safari's own process, separately from your MAUI app's WebView. The EvaluateJavaScriptAsync paths your app uses don't run when the page is loaded that way, so that test doesn't reach the failing code path.

What I'm asking for is a different test: attach Web Inspector to your app's WebView while the app is running.

Before this works, three things need to be enabled. Two of them you likely already have from your NOTE-1 test:

  1. iPhone: Settings → Apps → Safari → Advanced → "Web Inspector" toggle on.
  2. Mac: Safari → Settings → Advanced → "Show features for web developers" enabled.
  3. In your app: WKWebView.isInspectable must be set to true on your app's WebView. Starting in iOS 16.4, WKWebView is not inspectable from Web Inspector by default — apps must opt in. This is the prerequisite most likely not yet in place for a MAUI app, since it requires a platform-specific customization on iOS that reaches the underlying WKWebView and sets Inspectable = true (typically guarded by an iOS 16.4+ availability check). Without this, the WebView inside your app will not appear in Safari's Develop submenu no matter what else is configured.

Steps:

  1. Run your MAUI app on the iPhone (the iOS 26 SDK build that has the JavaScript problem).
  2. In the running app, navigate to your ASPX page so the WebView is showing the page with the buttons.
  3. With the iPhone connected by USB, on the Mac choose Safari → Develop → [Your iPhone] →. The submenu will contain two entries: one labeled Safari (the Safari app on the iPhone), and another labeled with your app's name or the page's URL — that second entry is the WebView inside your running app. Pick that one.
  4. With the JavaScript console open, trigger the failing operation in your app.
  5. The console will show what actually happens at the moment the JavaScript runs (or fails to run).

A small but important detail: open the JavaScript console first, then trigger the operation. Web Inspector captures messages starting when it attaches, not before. If you've already triggered the failing operation before attaching, reload the page in your app and trigger again so the console can capture what happens.

The console output from step 5 is what would let me narrow this further. Without it I can't yet tell which of the four scenarios I described in my earlier response is happening (function-not-defined, CSP block, DOM exception, or no execution at all).

Let me know what the console shows when you can run that test.

WKWebView iOS 26 preventing javascript injections
 
 
Q