DebugSwift is a comprehensive debugging toolset designed to simplify the debugging process for iOS applications developed by Swift. It can monitor network requests, performance indicators (CPU usage, memory usage, frame rate FPS), crash reports, as well as application resources such as keychain and User defaults in real time; it also has built-in interface debugging tools, which can be visualized through grid overlay layers, touch indicators, and also supports memory leak detection and console log output.
The core advantage of this tool is that problems can be quickly located and repaired without exiting the application during the development process-you only need to shake the device to call up the debugging panel, which greatly improves the efficiency of problem troubleshooting.
When developing iOS, there is always a familiar sense of powerlessness: the problem is clearly there, but you just can’t see it. You wrote a bunch of print, cut to Xcode to read the log; you suspect it is an interface problem, so you open Charles to grab the package; you think the cache is unclear, so you go to UserDefaults; if there is a problem with the UI, you have to guess the layout layer by layer. The matter of debugging should have been “observation”, but it was forced to turn into “speculation.”
DebugSwift What you do is straightforward-you no longer leave the App to find problems, but put debugging capabilities directly into the app.
When the application is running, you don’t need to cut tools or add logs repeatedly. As long as the device is gently shaken, a debugging panel will pop up. This panel is not scattered in various places like traditional tools. It is more like a “console” that brings together the capabilities most commonly used in the development process. Network requests are clear here at a glance, and request parameters, response content, and error messages can be viewed directly; logs are no longer output line by line, but can be classified, filtered, and traced back; local data, such as UserDefaults or Keychain, is no longer Black boxes, you can directly see or even modify them.
More importantly, this debugging method changes not the tool itself, but the rhythm of debugging. The past process was: recurring the problem → logging → running again → looking at the results again. Now it’s more like: recurring problems → direct observation. The entire “guess + verification” process in the middle has been compressed.
You can even see some auxiliary information directly on the interface, such as layout grids and touch feedback, which are very intuitive when making UI adjustments. It will not be as complex as Instruments, nor will it be for in-depth performance analysis, but it will allow you to quickly discover “what’s wrong” during the development stage.
Of course, it would be a bit misleading to regard it as an all-round platform. It is not a tool dedicated to performance analysis, nor is it a complete crash monitoring system. It is more like a “daily debugging infrastructure.” Those really important things still have to be handed over to professional tools. But in most daily development scenarios, it is enough to stop people from relying on scattered and fragmented debugging methods.
So from a certain perspective, DebugSwift solves not the problem of “whether debugging can be performed”, but the problem of “whether debugging is smooth”. It turns debugging from a process that requires frequent switching of contexts to a continuous experience that always occurs within the application.
When you get used to this method and go back to using the combination of pure print + external tools, you will obviously feel a gap. Not because the tools are bad, but because they were not in the same space from the beginning. What debugSwift does is put this space together again.
Github：https://github.com/DebugSwift/DebugSwift
Oil tubing: