LogConsole Support

If you need help with the LogConsole app, we're here for you.

Email: mstone2112@gmail.com

Add the free, open-source LogConsoleKit SDK to your own app: [https://github.com/mstone2112/LogConsoleKit]

LogConsole User Guide

Thank you for your interest in LogConsole! It's built to let you check on your own apps' logs and crashes from any of your devices, without needing to plug into Xcode.

Sessions

This is the main screen, showing every session captured from an app using the LogConsoleKit SDK. On this page you can:

• See which app and device each session came from, and when it happened
• See an entry count for each session
• Spot crashed sessions immediately via the red "Crash" indicator

Session Detail

Tap any session to see its full log stream. On this screen you can:

• Filter log entries by tag
• See a crash banner with the failure reason, if that session crashed
• Export the session's logs and crash details to share or save elsewhere

Sync

Sessions sync automatically across your iPhone, iPad, and Mac through your own private iCloud account — open LogConsole on any of your signed-in devices and your full history is there.

Design Philosophy

LogConsole is built for solo and small-team iOS developers who want to check a TestFlight build's behavior without staying tethered to a cable. The architecture is deliberately simple: no server, no third-party backend, just your own iCloud account doing the syncing. That's a privacy choice as much as a technical one.

Privacy Policy

Last Updated: 2026

LogConsole respects your privacy. This app does not collect, store, transmit, or share any personal data with the developer or any third party. All session, log, and crash data is stored and synced exclusively through your own private iCloud account.

Information We Do Not Collect

The developer of LogConsole does not collect or have access to any of the following:

• Personal information (such as your name, email, phone number, or address)
• The contents of your synced sessions, logs, or crash data
• Usage data or analytics
• Location data
• Advertising identifiers
• Cookies or tracking technologies

The app does not use third-party analytics, advertising networks, or external data services.

Data Storage and Sync

All session, log, and crash data captured by apps using LogConsoleKit is stored in, and synced exclusively through, your own private CloudKit database tied to your iCloud account. This data is never transmitted to the developer or to any server operated by the developer. Apple's standard iCloud account security governs access to it, the same as any other app that stores data in your iCloud account.

The LogConsoleKit SDK

LogConsoleKit is the free, open-source companion SDK that other developers embed in their own apps to capture logs and crash details. Log message content is determined entirely by the developer of the app you're debugging — LogConsole and its developer never see or have access to this data; it flows only through your own iCloud account, the same as data created directly inside the LogConsole app itself.

Third-Party Services

LogConsole does not integrate with or send data to any third-party services. CloudKit sync is provided directly by Apple as part of your iCloud account, not by a third party engaged by the developer.

Children's Privacy

Because the developer does not collect any personal data, LogConsole is safe for users of all ages. No personal information is knowingly collected from children.

Changes to This Policy

If the app's functionality changes in the future in a way that affects data handling, this Privacy Policy will be updated accordingly. Any changes will be posted on this page.

Contact

If you have any questions about this Privacy Policy, you may contact:

Michael Stone
Email: mstone2112@gmail.com

LogConsoleKit — SDK Integration Guide

The capture SDK and crash-capture mechanism behind LogConsole, with CloudKit sync. This gets you to: your app's logs and crashes flowing into your own private CloudKit database, verifiable via Apple's own developer dashboard. It does not include a viewer app UI itself — that lives in the separate LogConsole app, not in this package.

Follow this guide in order. Every step exists because skipping it caused a specific, confirmed failure during real integration — they're listed here so you don't have to rediscover them. The full source is on GitHub: github.com/mstone2112/LogConsoleKit

What's in this package

• LogEntry, Session, CrashRecord — SwiftData models, written so they're valid for CloudKit mirroring (every stored property has a default, every relationship is declared on both sides with a matching inverse). A relationship declared on only one side builds and passes in-memory tests fine, but crashes at runtime the moment CloudKit is involved.
• LogConsoleContainer — builds the shared ModelContainer pointed at a CloudKit private database. Both the host app and the viewer app call this with the same container ID.
• LogConsole — the capture API. Only the HOST app (the app being debugged) calls this. Save failures print to the console rather than failing silently.

Prerequisites — check these before opening Xcode

1. A paid Apple Developer Program membership ($99/year), not just a free Apple ID. CloudKit specifically requires this to provision.
2. No pending agreement blocking your account. Sign in at appstoreconnect.apple.com and check for a banner asking you to accept an updated Program License Agreement. If one exists and you skip it, Xcode will fail to refresh your provisioning profile and report confusing, unrelated-looking capability errors.
3. Your test device(s) are signed into iCloud. Settings → top of the screen should show your name, not "Sign in to your iPhone/iPad."

Required end state — two folders, side by side

~/Developer/LogConsole/
  LogConsoleKit/          ← this package. Package.swift sits directly inside.
  LogConsoleApp/          ← the Xcode project you create in step 2 below.

The single most common mistake here is creating the new Xcode project and saving it inside the LogConsoleKit folder, so it becomes a child of the package instead of a sibling next to it:

NOT THIS:
~/Developer/LogConsole/
  LogConsoleKit/
    LogConsoleApp/        ← wrong — nested inside the package
    Package.swift

If you do this, Xcode's "Add Local Package" file picker will often default into that nested app folder, and since it has no Package.swift in it, you'll get "Cannot select this directory... contains a valid Package.swift file" — the package is fine, you're just pointed at the wrong folder.

Step 1 — place this package

Unzip or clone this package to ~/Developer/LogConsole/LogConsoleKit/. Confirm in Finder: opening that folder should show Package.swift directly inside it, not inside another folder.

Step 2 — create the app project

In Xcode: File → New → Project…. In the platform-category list on the left of that dialog, select Multiplatform — not "iOS" and not "macOS" individually; those tabs only offer single-platform templates. Under Multiplatform, choose App.

If your Xcode version doesn't show a Multiplatform option at all: create it as a plain iOS app instead, then add Mac afterward — select the project → select the target → General tab → find Supported Destinations → click + → add Mac.

Product Name: LogConsoleApp. Don't use spaces, and don't use anything close to "LogConsoleKit" — a name that's almost-but-not-quite the same as the package is exactly what causes folders to get dragged into the wrong place.

Uncheck "Use Core Data" if the dialog offers it. The template's Core Data boilerplate is unrelated to this package, which uses SwiftData instead, and it generates console noise once the app actually runs.

When Xcode asks where to save, navigate to ~/Developer/LogConsole/ itself — not into the LogConsoleKit folder — then save.

Step 3 — add the package dependency

Select the project file in the navigator → select the LogConsoleApp target → the General tab → scroll to Frameworks, Libraries, and Embedded Content → click + → Add Other… → Add Package Dependency… → click Add Local… → navigate to the LogConsoleKit folder.

A dialog titled "Choose Package Products for LogConsoleKit" will appear, showing "Add to Target" set to None — click that dropdown and select your LogConsoleApp target, then click Add Package.

Step 4 — enable CloudKit

Same target → Signing & Capabilities tab. (If you ended up with two separate iOS/macOS targets, repeat below for both.)

• Check the Team dropdown — needs your paid developer account selected.
• Click + Capability → add iCloud → check CloudKit → under Containers, click + and create a container, e.g. iCloud.com.yourname.logconsole.
• Click + Capability again → add Background Modes → check Remote notifications.

Write down the exact container ID string you just created. A placeholder or mistyped container ID is the single most common cause of a "BadContainer" error, and it won't show up until runtime.

Step 5 — smoke test

In LogConsoleAppApp.swift, add the import and an init():

import SwiftUI
import LogConsoleKit

@main
struct LogConsoleAppApp: App {
    init() {
        LogConsole.shared.start(containerID: "iCloud.com.yourname.logconsole", appVersion: "1.0")
    }

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

Replace the placeholder container ID with your exact string, copy-pasted rather than retyped.

Run on a Simulator first, not a physical device — physical-device runs can fail for unrelated reasons (e.g. a "developer disk image" pairing issue), and confirming on a Simulator first tells you whether a later device issue is hardware-related or not.

Step 6 — verify it actually synced

1. Go to icloud.developer.apple.com/dashboard, sign in with the same Apple ID, and select your container — it may default to a different one from a previous project.
2. Switch the database dropdown from Public Database to Private Database.
3. Click Record Type. You should see CD_Session and CD_LogEntry alongside the default Users entry.
4. Select CD_Session, then click Query Records.

If this returns "Field 'recordName' is not marked queryable," that's a dashboard quirk, not a sync failure — click Add filter or sort to query, add a sort on the system field Modified, and query again.

Phase 2 — crash capture

LogConsole.shared.start() also arms crash capture automatically. A fatal signal or uncaught exception writes a small file using only low-level system calls, and the next call to start() attaches it as a CrashRecord on whichever session was active when it happened.

To verify: run once normally, add a deliberate fatalError("manual crash test") and run again (it should crash), remove that line, then launch a third time from the device's home screen directly (not through Xcode's debugger, which intercepts the crash before the handler runs). Watch the console for a line starting with LogConsole attached a crash from the previous launch.

Troubleshooting — noise vs. real problems

These appear in the Xcode console and are expected, not bugs:

• BGSystemTaskSchedulerErrorDomain Code=3 and "updateTaskRequest called for an already running/updated task" — a known, Apple-acknowledged scheduling-contention message. It retries automatically.
• "Failed to send CA Event for app launch measurements" — unrelated Apple analytics telemetry.
• "Context in environment is not connected to a persistent store coordinator" — only appears if Core Data template boilerplate was kept instead of skipped in Step 2.

These are real and need the listed fix:

License

MIT — see the LICENSE file in the repository. Use this in your own apps, fork it, modify it, ship it.

Running the included tests

These run against an in-memory store, no CloudKit or network involved: Product → Test (⌘U) in Xcode, or swift test from the LogConsoleKit folder in Terminal. Note that these tests cannot catch CloudKit-specific schema issues like the missing-inverse-relationship bug described above — treat passing tests as confirmation of the capture logic, not of CloudKit compatibility.