Console + Network · 6 minutes
View JavaScript console errors on iPad
When a button does nothing, collect what happens at the moment you tap it. A console error is evidence, but it is not automatically the cause. This walkthrough first proves that capture is working, then produces an intentional error you can inspect.
Before you start
Install Codable on an iPad running iPadOS 26.4 or later. Enable it in Settings → Apps → Safari → Extensions. From Codable’s Extension screen, open the local demo in Safari and allow the extension on the page. These steps also work on iPhone.
Codable on the App Store ↗Start capture before reproducing the problem
Open Codable from Safari’s extensions menu and choose Console. Use Clear to start with an empty view. Close the popover, tap Log button event on the demo page, then reopen Codable → Console.
Look for Button clicked. Opening the extension after a problem has already happened cannot reliably recover earlier console output. After a navigation or reload, open Console again before repeating the action.
Check: Button clicked appears with the demo’s action and timestamp.
Produce an intentional error
Open Network once before making the next request, then return to Console and Clear. Close the popover and tap Fetch error in the demo’s Network section. Reopen Console and find Fetched demo error.
This example is an explicit console.error message from the demo after an error response. It is not an uncaught JavaScript exception. On your own site, an uncaught error or rejected promise may include a source location and stack; preserve that detail when it is available.
Check: You see a deliberate demo error, and the page remains usable.
Check the page you are debugging
Enter the following expression in Console and tap Run. It reads the current page’s button label without changing the page.
For a real broken button, compare the visible error with the handler you expected to run. Follow the first relevant frame in your app’s code, and note whether the same error repeats with the same action. Avoid blaming an unrelated background error.
document.querySelector("#fetchError")?.textContentCheck: The result is Fetch error on the bundled demo.
Compare the request with the error
Choose Network, tap Refresh, and select the /api/error request. Read the status and the available response preview. A failed response can explain an error path; a successful request can help rule one out. The order of two entries alone does not prove that one caused the other.
When handing this to a teammate or coding agent, include the exact action, expected result, observed error, relevant source location, and request status. Remove tokens, personal data, and private page content before sharing.
If you get stuck
Console is empty
Confirm access to the current tab, open Console first, and reproduce the action again. Try document.title with Run to confirm that evaluation reaches the page. Page restrictions or a missing bridge can prevent capture.
Network has no matching request
Open Network before repeating the action. Detailed fetch and XMLHttpRequest capture begins when that panel is initialized; older resource-timing rows cannot reconstruct missing bodies or headers.
An error has no useful stack
A plain console.error string does not contain a thrown Error’s stack. Browser restrictions, minification, and cross-origin scripts can also reduce detail. Use a development build with useful error handling or desktop remote inspection when you need breakpoints.
What this can tell you
- Console values are bounded snapshots. They are not the live, expandable object handles, debugger pauses, or complete execution history of desktop developer tools.
- Capture may miss early startup output, workers, inaccessible frames, and browser-internal messages. No output does not prove that no error occurred.
- Network combines instrumented fetch/XHR activity with resource timing. It cannot expose every browser request, and response previews, headers, and timing details can be unavailable or truncated.
- The companion app’s Scratchpad runs in a separate browser runtime. It does not share the inspected Safari page’s variables or authenticated session.
For a full debugger connected to a Mac, Apple documents remote inspection of iOS and iPadOS. For extension setup, see Apple’s Safari extensions guide.