Add Extensive Logging

[kean]

Description

• Integrate Pulse and set it up using SwiftLog Logging System
• Add a "bolt" button to "Experimental Features". Tap it five times, and it'll show a new "Super Experimental Features" section.
• Show "Extensive Logging" flag in the new section. When you enable it, it'll show a warning alert.
• Add "Logger" section in "App Settings" (if enabled)

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.

	App Name	WordPress
	Configuration	Release-Alpha
	Build Number	30558
	Version	PR #25005
	Bundle ID	org.wordpress.alpha
	Commit	4a4a631
	Installation URL	4fi7b4rofcg48

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.

	App Name	Jetpack
	Configuration	Release-Alpha
	Build Number	30558
	Version	PR #25005
	Bundle ID	com.jetpack.alpha
	Commit	4a4a631
	Installation URL	1h4c1jlc6jotg

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

Version 26.5 has now entered code-freeze, so the milestone of this PR has been updated to 26.6.

[kean]

Renamed it to "Developer Tools"

[crazytonyli]

Does onTapGesture(count: 5) { isDeveloperModeEnabled = true } work?

[kean]

Feel free to change it and try it.
I generated all the original code.

[crazytonyli]

If I understand correctly, with the changes in this PR, the app now always uses Pulse to log HTTP requests and responses, and the feature toggle controls whether the user can see those logs. Considering 99% of the users won't turn on the feature toggle and view the logs, to avoid running code and taking up the app's memory for nothing, should we change the model to only log HTTP requests when the feature toggle is on?

[kean]

should we change the model to only log HTTP requests when the feature toggle is on?

There is a significant impact on performance and app on-disk see. If has to be a debug-only feature.

[crazytonyli]

@kean @jkmassel I have made quite a few changes. Do you mind having another look?

[crazytonyli]

The new cards look like this:

[wpmobilebot]

🤖 Build Failure Analysis

This build has failures. Claude has analyzed them - check the build annotations for details.

[dcalhoun]

The new cards look like this:

I recognize the current layout mimics the Prompts card, but the mixture of left- and center-aligned text feels odd to me. Also, the majority of the Jetpack cards seem to only use left-aligned text.

I suggest we use a single alignment rather than mixing them. As an example, the iOS Settings app showcases both layouts.

Left-aligned	Center-aligned

[kean]

I'm not sure you want to see the card on the most prime spot on the dashboard all the time you have logging enabled. It can be pretty annoying.

Claude recommends the following as an ideal option:

• Set a reasonable TTL when enabling it, e.g. 24h, 7 days, or give user an option
• When the time is up, show an interactive alert on app launch: "Extensive logging has been running for . Turn it off?" [Turn Logging Off] [Extend For 24 hours] [Extend for 7 days].

[crazytonyli]

@dcalhoun Good call. I'll align the content to the left to see how it looks.

---

We shouldn't have an auto-timeout on it though – it'd be super annoying if it turned itself off right before an issue happened and we missed it.

@kean I agree with Jeremy's comment here ⬆️. I imagine users would only keep the extensive logging flag on for a short amount of time when they try to reproduce an issue. Maybe we can add an "Ignore" button to the card, which dismisses the card while keeping the extensive logging flag on? I think we should still warn users about it, though. We can make the "ignore" action take effect for a week or so, so users can still see the warning if they keep the flag on.

[kean]

Jeremy's concern was that it would turn itself off automatically, which is fair. With an alert, however, it won't. It will simply ask if you still need it.

[kean]

A persistent indicator also seems a OK, but I'd suggest showing it as a small badge with an info button instead of a large card. It only needs to say "Extensive Logging On".

[crazytonyli]

@kean Maybe something like this?

Simulator.Screen.Recording.-.iPhone.17.-.2026-01-22.at.11.45.22.mov

[kean]

Here's another potential option, which I liked the most out of the ones I tried.

• Orange to indicate that this is "not normal"
• Info icon to show that it's tappable

It should work well if the goal is to ensure you turn it off as soon as possible. I think we should let you hide it though like other cards. Look for how personalization service it used. It has the storage and the APIs for that.

struct CompactLoggingBadge: View {
    var body: some View {
        HStack(spacing: 12) {
            Circle()
                .fill(.orange)
                .frame(width: 8, height: 8)

            VStack(alignment: .leading) {
                Text("Extensive Logging Enabled")
                    .font(.subheadline)
                    .fontWeight(.medium)
                Text("This feature may impact performance")
                    .font(.caption)
                    .foregroundStyle(.secondary)
            }

            Spacer()

            Image(systemName: "info.circle.fill")
                .foregroundStyle(.tertiary)
        }
        .padding(.vertical, 4)
    }
}

I'd show it under "Prompts" card so it doesn't draw as much attention, but is still visible.

[crazytonyli]

@kean Thanks for the suggestion! I have taken your code, with a small adjustment to the spacings to match the dashboard UI.

[sonarqubecloud]

Quality Gate passed

Issues
13 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud