Objective-C error tracking
Know when your Objective-C app breaks, before your users do
Captures an uncaught NSException or fatal signal automatically, then uploads the crash report on next launch. Self-hosted, so nothing about a Objective-C app's errors or its users' data ever leaves infrastructure you control.
Install
// Not yet packaged for CocoaPods/SPM -- add Sources/ForgeOpsTracker/ to your Xcode project
#import <ForgeOpsTracker/ForgeOpsTracker.h>
[ForgeOpsTracker configureWithBlock:^(FOTConfiguration *config) {
config.dsn = @"https://<api_key>@your-forgeops-host/api/v1/events";
}];
[ForgeOpsTracker installHandlers];
Uploads happen on the next app launch, not live during the crash itself, the same model every real mobile crash reporter uses.
Every client reports the same shape
Wherever it comes from, an event arrives with an exception class, a message, and a backtrace, plus whatever environment/release/server context that client can gather on its own. ForgeOps fingerprints and groups on the first three, so a Objective-C app's issues list works exactly the same way every other language's does: report the same bug a thousand times and it's still one row, not a thousand.
No agent, no sidecar: it's a plain HTTPS POST to your own ForgeOps instance's ingestion API, so nothing about a Objective-C app's traffic ever leaves infrastructure you control.
Works with your framework
The Objective-C client hooks in at the framework level, not by wrapping individual calls, so nothing about how you already write Objective-C code has to change.
Uncaught NSException
Installed via NSSetUncaughtExceptionHandler, chained onto any previously-installed handler rather than replacing it.
Fatal signals
SIGABRT, SIGSEGV, and the rest are caught via sigaction, writing a raw backtrace to disk before re-raising so the OS's own crash behavior still happens.
Caught exceptions
captureException:context: reports anything your own @catch block already handles, uploaded immediately rather than waiting for the next launch.
What it looks like
The issue list
Every Objective-C issue reported into a project shows up here: title, status, assignee, event count, and when it was last seen, the same columns as any other language's project.
The issue detail
Every occurrence keeps its own timestamp, environment, release, and server, plus the backtrace exactly as Objective-C reported it, expandable per occurrence rather than flattened into one generic stack.
Alerting
A new Objective-C issue, a regression, or a spike past a threshold you set can reach Slack, email, SMS, a voice call, or a generic webhook, configured per project, per trigger.
Heartbeats
For the failure mode error tracking can't see on its own: a Objective-C cron job or recurring task that's supposed to run but silently stopped. Each heartbeat gets its own ping URL and its own grace period before it alerts.
Questions
Do I need to change how I already handle errors?
No. Every client hooks the framework's own exception handling directly, the same way the install snippet above shows -- your own logs, error pages, and rescue blocks keep working exactly as they did before. ForgeOps just also finds out about it.
Where does the data actually go?
Straight to your own ForgeOps instance over plain HTTPS. No agent, no sidecar, no third-party ingestion service in between -- nothing about your app's traffic or its users' data ever leaves infrastructure you control.
What happens if the same bug fires a thousand times?
It's fingerprinted from its exception class, message, and backtrace, so a thousand reports of the same bug still show up as one issue with an event count of 1,000, not a thousand separate rows to dig through.
Is anything scrubbed before it's stored?
Yes. Emails, credit card numbers, and known API key/token formats are redacted out of every event before it's even written, on every plan, with room for per-project custom field names on top of the defaults.