# kean/Pulse: In-App Network Logging for Apple Platforms

> Pulse records URLSession traffic and SwiftLog events inside your own iOS, macOS, tvOS, watchOS or visionOS app and shows them in SwiftUI views you embed yourself. It is a framework, not a proxy, and the README is explicit about that boundary.

**kean/Pulse** — Network logger for Apple platforms

- Repository: https://github.com/kean/Pulse
- Website: https://pulselogger.com
- Stars: 7,231 · Forks: 379
- Language: Swift
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/kean-pulse

## A logging framework that ships inside your app

The problem Pulse addresses is the gap between a URLSession call that fails on a tester's device and the bug report that reaches you three days later with no request body. Pulse records events from URLSession, or from frameworks that sit on top of it such as Alamofire or Get, and renders them through PulseUI views that you add to your own app. The console therefore exists in every build you hand out, not in a separate tool the tester has to install and configure. The intended audience is iOS and macOS engineers plus the QA people who exercise their builds. Pulse Pro, a separate macOS application, is the other half of that workflow: it opens shared log files and can follow remote logging in real time. Logs stay on the device until someone chooses to share them, which the README states directly.

## How recording and display are split across three modules

The repository is a Swift package with a Sources directory, and the README describes three libraries with separate documentation sites. Pulse is the core framework that enables logging and stores events. PulseUI supplies the debug menu and console views you embed. PulseLogHandler connects Pulse as a backend for SwiftLog, Apple's logging API, so anything already emitting through SwiftLog lands in the same store. That split matters when you decide how much to ship: an app that only needs request capture can take the core framework, while the debug menu requires pulling in the UI layer. There is no daemon and no out-of-process component. The README states plainly that Pulse is not a network proxy and points readers who need one at Proxyman, which is a meaningful design statement rather than a marketing aside: this is in-process instrumentation, so it sees what your URLSession stack sees.

## Installing Pulse and seeing your first request

Pulse is distributed as a Swift package, so the entry point is Package.swift or the Xcode package dependency flow. The README does not print a version string for the dependency; it directs readers to the Getting Started guide on the documentation site, and the minimum requirements table is the reliable place to check compatibility. For Pulse 5.0 the table lists Swift 5.10, Xcode 15.4, and platform floors of iOS 15, tvOS 15, watchOS 8, macOS 12 and visionOS 1. A package dependency in a manifest looks like this:

## What Pulse cannot do, by design

The clearest limitation is the one the README volunteers: Pulse is not a network proxy. It cannot record traffic from an app you did not build, cannot see requests made by a system framework that bypasses your URLSession configuration, and cannot show you a packet-level view below TLS. If the bug lives in an app binary you do not control, or in traffic you cannot route through URLSession instrumentation, this is the wrong tool and the README says so. A second constraint is version coupling. The requirements table shows that moving from Pulse 4.0 to 5.0 raises the Swift floor from 5.7 to 5.10 and the Xcode floor from 14.1 to 15.4, with the minimum iOS version going from 14 to 15. Teams maintaining older deployment targets have a real upgrade cost here, not a cosmetic one. Finally, the README does not document rollback or a way to strip recording from release builds; that has to come from the integration guide, and the repository itself is silent on it.

## How Pulse differs from a proxy like Proxyman

Proxyman, named in the README as the alternative for people who need a proxy, sits between the device and the network and inspects traffic at the HTTP layer. That approach works on any app, including release builds and third-party software, and it needs a certificate installed on the device plus a desktop session. Pulse inverts the trade: nothing leaves the process, no certificate is involved, and the console travels with the build, but only instrumented code is visible. The two are not substitutes. A team debugging a server contract on their own app gets further with Pulse because the logs reach the tester without a proxy setup step. A team auditing an app they cannot rebuild has no Pulse path at all.

## Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-08-15, which is roughly five weeks before the current date. Recent releases are 5.2.3 on 2026-06-10, 5.2.2 on 2026-05-17 and 5.2.1 on 2026-04-20, so point releases have been arriving on a scale of weeks to a couple of months. That cadence is a cost as well as a signal: a framework embedded in your app inherits a dependency you should be willing to bump, and the 4.0 to 5.0 jump shows the project is comfortable raising platform floors between majors. The licence is MIT, stated in the README with a pointer to the LICENSE file, and the repository carries LICENSE.md at the top level. MIT is permissive and imposes no source disclosure on your app, but this is a description of the licence text, not legal advice. Pulse Pro is a separate commercial macOS application and is not covered by that licence.

## Conclusion

Adopt Pulse if your QA team or testers need to read network logs on the device and attach them to bug reports without a proxy certificate or a desktop machine in the loop. Do not adopt it if you need to intercept traffic from an app you cannot rebuild, or if you expect a packet-level view of TLS. Before integrating, check the minimum requirements table against your deployment targets: Pulse 5.0 needs Swift 5.10 and Xcode 15.4, and it raises the floor to iOS 15, tvOS 15, watchOS 8, macOS 12 and visionOS 1. Then confirm how you will get logs off the device, because the README points at Pulse Pro and remote logging without documenting either in the repository itself.

## FAQ

### Does kean/Pulse work on iOS and macOS?

Yes. The minimum requirements table lists iOS 15, tvOS 15, watchOS 8, macOS 12 and visionOS 1 for Pulse 5.0, and PulseUI provides the console views you embed in those apps.

### Is kean/Pulse a network proxy?

No. The README states that Pulse is not a network proxy and points readers who need one at Proxyman. Pulse records events from URLSession or from frameworks that use it, such as Alamofire or Get.

### What Swift and Xcode versions does kean/Pulse 5.0 require?

The requirements table lists Swift 5.10 and Xcode 15.4 for Pulse 5.0. Pulse 4.0 required Swift 5.7 and Xcode 14.1, so upgrading a major version can move your toolchain floor.

### How do I install kean/Pulse?

It is a Swift package, so you add it as a package dependency or through Xcode, then follow the Getting Started guide linked from the README. The README does not list a specific version string to pin.

### Can kean/Pulse record SwiftLog messages?

Yes. The PulseLogHandler module lets you use Pulse as a SwiftLog backend, and the README links to its own documentation site for the details.

### What licence does kean/Pulse use?

The README states that Pulse is available under the MIT license, with the LICENSE file in the repository for the full text. Pulse Pro is a separate macOS app and is not part of that licence.

## Sources

- [kean/Pulse on GitHub](https://github.com/kean/Pulse)
- [License: MIT](https://github.com/kean/Pulse/blob/main/LICENSE)
- [Project website](https://pulselogger.com)
- [README](https://github.com/kean/Pulse/blob/main/README.md)
- [Releases](https://github.com/kean/Pulse/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kean-pulse
