Introduction

On-device logging is useful when a bug only appears on a real phone, tablet, or edge device and you cannot rely on a debugger being attached. The key is to log enough information to diagnose the issue, store it somewhere retrievable, and avoid turning the log system itself into a performance or privacy problem.

Decide What Should Be Logged

Useful device logs usually include:

• App lifecycle events
• Network failures and retries
• Error messages with timestamps
• Important user actions around a bug
• Version and build information

What you usually should not log is raw secrets, passwords, or sensitive personal data. Logging is a diagnostics feature, not a second database.

Write Logs to a File on the Device

For persistent retrieval, file logging is often easier than relying only on console output.

Swift example:

1import Foundation
2
3final class FileLogger {
4    private let fileURL: URL
5
6    init(filename: String = "app.log") {
7        let directory = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)[0]
8        self.fileURL = directory.appendingPathComponent(filename)
9    }
10
11    func log(_ message: String) {
12        let line = "\(Date()) \(message)\n"
13        let data = Data(line.utf8)
14
15        if FileManager.default.fileExists(atPath: fileURL.path) {
16            if let handle = try? FileHandle(forWritingTo: fileURL) {
17                try? handle.seekToEnd()
18                try? handle.write(contentsOf: data)
19                try? handle.close()
20            }
21        } else {
22            try? data.write(to: fileURL)
23        }
24    }
25}

This gives you a real file that can later be shared, uploaded, or inspected from the app sandbox.

Retrieve Logs From the Device

There are several practical retrieval paths:

• Pull them during development with platform tools
• Export them from inside the app
• Upload them to a backend when the user reports a problem

For Android, adb logcat or app-specific files are common. For iOS, console logs are visible in Xcode, but app-managed log files are easier to export reliably from production builds.

An iOS export flow might attach the log file to a share sheet:

1import UIKit
2
3func presentLogExport(from viewController: UIViewController, fileURL: URL) {
4    let activity = UIActivityViewController(activityItems: [fileURL], applicationActivities: nil)
5    viewController.present(activity, animated: true)
6}

That is often enough for beta testing and support workflows.

Add Rotation and Size Limits

Device storage is limited, so logs should not grow forever. A simple strategy is:

• Keep one active log file
• Rotate when it exceeds a size limit
• Retain only the most recent few files

Even a basic cap, such as five files of a few megabytes each, is far safer than unbounded logging on a user device.

Prefer Structured Messages

A log line such as network failed is much less useful than:

2025-03-07T18:30:00Z requestId=123 endpoint=/sync status=500 retry=2

Structured or semi-structured logs are easier to search, filter, and upload into later diagnostics tooling. If you already have event IDs or correlation IDs in your app, include them in the log output.

Common Pitfalls

• Logging sensitive data creates a security and privacy problem that can be worse than the original bug.
• Relying only on console logs makes retrieval difficult when the device is in the field rather than attached to a developer machine.
• Letting the log file grow without rotation wastes storage and can hurt performance.
• Writing logs synchronously on hot paths can slow the app if the logger is not buffered carefully.

Summary

• Store diagnostic logs on the device when you need post-failure visibility.
• Use file logging if the logs must be retrievable after the moment they were emitted.
• Add export or upload paths so the logs can actually be collected.
• Keep logs structured, size-limited, and free of sensitive data.