Bugsee iOS SDK 7.0 — Now Generally Available
Bugsee iOS SDK 7.0 is now generally available. After seven betas since mid-September, it is ready for production.
Version 7 rebuilds the SDK on a new architecture: a new capture engine, a new crash handler, a set of detectors that goes well beyond crashes, and much finer control over what each report contains. We are also working to make the iOS and Android SDKs behave the same way, so Bugsee is easier to use for teams that ship on both platforms. Here is what is in it, and why it matters.
One SDK for iPhone, iPad, Apple TV and Apple Vision Pro
7.0 ships as a single Swift package for iOS and iPadOS 15+, tvOS 15+ and visionOS 1.0+. Apple TV and Apple Vision Pro apps now get Bugsee from the same package and with the same setup as an iPhone app.
A capture engine rebuilt from scratch
Less load on the video encoder. In 7.0 we took the load off the video encoder while a session is being recorded — a change that directly improves the SDK's performance in your app.
Adaptive capture is on by default. Introduced as an opt-in in iOS SDK 6.3, it drops to about one frame per second while the screen is still and returns to full rate the moment anything moves.
iPhone Duo and iPad multitasking. On iPhone Duo, the recording follows the app between the cover and inner displays as the device is folded and unfolded, and on iOS 27.1 and later fold traces record the posture and hinge angle. On iPad, in Split View and Stage Manager, every window of your app on screen is recorded into the same frame, with touches and the view hierarchy matching what the user actually saw. The video also follows window and screen size changes during the session.
Also new in capture:
- Mouse input — mouse buttons, modifier keys and scrolling are recorded alongside touches.
- More kinds of content — as opt-ins, the SDK can now capture
AVSampleBufferDisplayLayercontent, such as WebRTC calls and custom video players, and the camera preview. - Video quality presets — trade detail for size with a single option.
- Independent controls — session video and the report screenshot are now turned on and off separately.
Detection that goes beyond crashes
Bugsee has always caught crashes. 7.0 adds detectors for the problems that never throw an exception. Each one is independent, sits behind its own BugseeOptionDetect* option, and stays off until you turn it on:
- Hangs — the main thread not responding for 3, 5 or 10 seconds, reported with the main-thread stack captured while it was stuck.
- User frustration — rage taps, taps followed by an error, network requests stuck loading for too long, and a UI that freezes during interaction.
- HTTP errors — server errors (5xx), deduplicated so a single failing endpoint does not flood your issue list.
- Main-thread misuse — synchronous disk and network work on the main thread: the quiet causes of jank.
- Performance anomalies — building on the performance monitoring introduced in 6.2, Bugsee learns how long each kind of operation usually takes and flags the ones that take far longer.
Every detection arrives as a full Bugsee report — with the video, logs, network traffic and traces leading up to it — and is grouped like any other issue. The issue detection guide lists every detector and its option.
Crash reporting, hardened
- A hybrid crash handler. The new default catches both hardware faults, through Mach exceptions, and fatal signals raised by software — such as a Unity fatal error — which previously went unreported with Mach exceptions on. You can also choose exactly which signals Bugsee intercepts, which matters when another runtime in your app handles some of them itself.
- Out-of-memory terminations, now on by default. When the system kills the app for running out of memory, Bugsee reports it — with the video, logs and network events of the run that ended.
- Early-crash protection, now on by default. When a launch ends before the app becomes active, the next launch sends the reports waiting on the device right away — so a crash loop at startup can no longer keep its own reports from getting out.
- Swift async stacks. For a C++ exception thrown from Swift
asynccode, the report records the asynchronous callers of the throwing task, not just the bare thread stack.
Watchdog and memory-limit kills on iOS 27: the Crash Report Extension
Some terminations end an app before any in-process crash handler can run: the launch watchdog (0x8badf00d) and the memory limit (jetsam). Starting with iOS 27, the system hands the dead process to a crash reporter extension embedded in the app — and 7.0 ships one.
With Bugsee's extension, these terminations are reported with the stack of every thread at the moment of death — exactly what you need to see what the main thread was stuck on during launch, or what the app was doing when it hit the memory limit. After a few setup steps in Xcode, the extension's code is a single declaration. Your app keeps its own deployment target: only the extension needs iOS 27. The extension never sends anything itself; it leaves a small document on the device, and the SDK picks it up on the app's next launch.
Setup is described in the Crash Report Extension guide.
A fuller picture of the device
7.0 records more system traces, so every report shows not just what your app was doing, but what the device was doing around it. New traces cover frame rate, screen brightness, accessibility settings, the attached displays, fold state and hinge angle, and total RAM and low-memory state.
Breadcrumbs
New in 7.0, breadcrumbs annotate the session timeline with structured events. Once enabled, the SDK collects them automatically — app lifecycle, device events such as memory pressure, thermal state and Low Power Mode, screen changes, keyboard and focus, taps, swipes and scrolls, connectivity changes, and HTTP requests. addBreadcrumb records your own: navigation steps, feature-flag states, business checkpoints, or anything else that helps reconstruct what led to a bug. A breadcrumb filter can redact or drop any of them before they are recorded.
Breadcrumbs are off by default; the breadcrumbs guide covers the categories and the API.
Shape every report before it leaves the device
A new report handler receives every report the SDK creates — bug reports, errors and exceptions, and crashes recovered on the next launch — as a live, editable BugseeReport. Change the summary, description, severity, labels or attributes, or add attachments, before the report is assembled and uploaded. See the report handler guide.
Privacy, tightened
- Blackout mode. A new blackout mode suppresses everything that shows the screen — video, the report screenshot, touches and the view hierarchy — while logs, network events and traces keep recording. Protecting a sensitive flow no longer means losing the diagnostic context around it.
- Transitions are never recorded unprotected. While a protected view moves during an animated transition, those frames are blurred into unreadable blocks by default.
- Secure rectangles hide touches. Touches inside a secure rectangle are now dropped from the report, the same way secure views already worked.
The video privacy guide covers masking, secure areas and blackout in detail.
Lighter, and a better citizen
For all the new capability, 7.0 does less work where it matters. Beyond the lighter video encoding, capture now starts off the main thread, so launching the SDK does less synchronous work during your app's startup. Under memory pressure, the SDK releases its capture buffers, and reports waiting for upload are capped by size, count and age, so they never pile up on the device.
Feedback, now its own package
The in-app feedback chat — which lets your users talk directly to your team — has been rebuilt in SwiftUI and moved to its own Swift package, BugseeFeedback. Add it when you use it; apps that don't no longer carry it. A new listener callback tells you when the user sends a message. See the feedback guide.
Available now
Bugsee iOS SDK 7.0 is available now through Swift Package Manager, and the same XCFramework can be downloaded directly for builds that embed frameworks by hand. CocoaPods and Carthage stay on 6.x — see our CocoaPods post for the background.
Upgrading from 6.x? Note that 7.0 requires iOS 15 or later (6.x supported iOS 12). The new configuration and every API change are covered in the migration guide, and the release notes list everything that changed across the 7.0 betas. If you run into anything — or just want a hand planning the upgrade — reach out via the in-app chat or email support@bugsee.com.
