Swiftpack.co - dbukowski/DBDebugToolkit as Swift Package

Swiftpack.co is a collection of thousands of indexed Swift packages. Search packages.
See all packages published by dbukowski.
dbukowski/DBDebugToolkit 0.9.0
Set of easy to use debugging tools for iOS developers & QA engineers.
⭐️ 1,182
🕓 19 weeks ago
.package(url: "https://github.com/dbukowski/DBDebugToolkit.git", from: "0.9.0")


Swift version Xcode - Build Version Carthage compatible Swift Package Manager compatible License Platform

DBDebugToolkit is a debugging library written in Objective-C and Swift. It is meant to provide as many easily accessible tools as possible while keeping the integration process seamless.


  • ☑ Performance
    • ☑ CPU usage (current, max, chart)
    • ☑ Memory usage (current, max, chart)
    • ☑ FPS (current, min, chart)
    • ☑ Widget displaying current CPU usage, memory usage and FPS that stays on top of the screen
    • ☑ Simulating memory warning
  • ☑ User interface
    • ☑ Showing all view frames
    • ☑ Slowing down animations
    • ☑ Showing touches on screen (useful for recording and screen sharing)
    • ☑ Displaying customizable grid overlay on top of the screen
    • ☑ Autolayout trace
    • ☑ Current view description
    • ☑ View controllers hierarchy
    • ☑ List of available fonts with preview
    • ☑ Showing UIDebuggingInformationOverlay
  • ☑ Network
    • ☑ List of all the requests sent by the application
    • ☑ Request and response preview
  • ☑ Resources
    • ☑ File system: browsing and removing selected files
    • ☑ User defaults: browsing, removing selected item and clearing all the data
    • ☑ Keychain: browsing, removing selected item and clearing all the data
    • ☑ Core Data: browsing all the managed objects and their relationships with sorting and filtering options
    • ☑ Cookies: browsing, removing selected cookie and clearing all the data
  • ☑ Console
    • ☑ Displaying console output in text view
    • ☑ Sending console output by email with device and system information
  • ☑ Simulating location
  • ☑ Crash reports
    • ☑ List of all the crashes
    • ☑ Crash reports containing details, stack trace, console output and a screenshot
    • ☑ Sending crash reports by system actions
  • ☑ Modifying custom variable values from the menu
  • ☑ Adding custom actions to the menu
  • ☑ Opening application settings
  • ☑ Application shortcut item for clearing data
  • ☑ Showing version & build number
  • ☑ Showing device model & iOS version


To run the example project, clone the repo, and run pod install from the Example directory first. The example project is written in Objective-C. The code examples in this README are written in Swift 3.0.


DBDebugToolkit requires iOS 13.0 or later.



DBDebugToolkit was meant to provide as many useful debugging tools as possible. However, the second equally important goal was to keep the setup seamless for all the iOS projects. A good place for setting up DBDebugToolkit is in the AppDelegate, as it allows it to start as quickly as possible. The sisrc="https://raw.github.com/dbukowski/DBDebugToolkit/master/t setup consists of only one line:

import DBDebugToolkit

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
    return true

After such setup, simply shake the device to present the menu with all the debugging options:

Read more about triggers to find out how to customize menu presentation.


Triggers are the objects that tell DBDebugToolkit to present the menu. There are 3 predefined triggers:

  • DBShakeTrigger - reacts to shaking the device.
  • DBTapTrigger - reacts to tapping the screen.
  • DBLongPressTrigger - reacts to long pressing the screen.

By default, DBDebugToolkit is set up with DBShakeTrigger. You can also provide your own array of triggers:

import DBDebugToolkit

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
    let tapTrigger = DBTapTrigger(numberOfTouchesRequired: 3)
    let longPressTrigger = DBLongPressTrigger(minimumPressDuration: 1.0)
    let shakeTrigger = DBShakeTrigger()
    DBDebugToolkit.setup(with: [tapTrigger, longPressTrigger, shakeTrigger])
    return true

These are just examples. Both DBTapTrigger and DBLongPressTrigger have more customization options.

You can also create your own trigger. To do this, create a class that conforms to protocol DBDebugToolkitTrigger. Then create an instance of this class and pass it to the setup method.


The complete list of features with examples can now be found here: Features.



DBDebugToolkit is available through CocoaPods. To install it, simply add the following line to your Podfile:

pod "DBDebugToolkit"

However, to provide some of its features, DBDebugToolkit does use private API. The code that uses it is obfuscated to minimize the risk of rejecting your application on the App Store, but it can not be guaranteed that it is enough. That being said, here are some safer ways to install DBDebugToolkit:

  • Adding it only to debug builds

    It is now possible to specify the build configuration for a given pod:

    pod "DBDebugToolkit", :configurations => ['Debug']

    After such setup, all your code using DBDebugToolkit needs to be placed in preprocessor macros:

    #if DEBUG
        import DBDebugToolkit
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
        #if DEBUG
        return true

    The one major drawback of such setup is the fact that it won't include DBDebugToolkit in the builds that you send to the testers.

  • Creating a separate target for App Store releases

    After creating a separate target for App Store releases, your podfile could be defined this way:

    def common_pods
      # Here are all the pods that will be used in both targets.
    target 'YourApplication' do
    target 'YourApplicationAppStore' do
        pod "DBDebugToolkit"

    Then you will have to differentiate between the targets in code. To do this, you could add a custom flag to your App Store target build configuration. Assuming that you named the flag APPSTORE, all the code using DBDebugToolkit will be placed in preprocessor macros:

    #if !(APPSTORE)
        import DBDebugToolkit
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
        #if !(APPSTORE)
        return true

The setup with a separate target for App Store releases will help you prevent sending the build containing the private API calls included in DBDebugToolkit to the App Store review. However, you would have to remember about adding all the files to both targets during development. You will have to decide which way is the best for your project. Perhaps it will be easier to manually remove DBDebugToolkit from the podfile before each App Store release.


To integrate DBDebugToolkit into your Xcode project using Carthage, specify it in your Cartfile:

github "dbukowski/DBDebugToolkit" ~> 0.7.0

Run carthage update to build the framework and drag the built DBDebugToolkit.framework into your Xcode project.


Maintained by Gamada-d, debugtoolkit@outlook.de

Created by Dariusz Bukowski, dariusz.m.bukowski@gmail.com


DBDebugToolkit is available under the MIT license. See the LICENSE file for more info.


Stars: 1182
Last commit: 2 weeks ago
jonrohan Something's broken? Yell at me @ptrpavlik. Praise and feedback (and money) is also welcome.

Release Notes

19 weeks ago

What's Changed

Full Changelog: https://github.com/dbukowski/DBDebugToolkit/compare/0.8.0...0.9.0

Swiftpack is being maintained by Petr Pavlik | @ptrpavlik | @swiftpackco | API | Analytics