MBLoggerCoreDataManager: `fatalError` in `FileManager.storeURL` crashes the host app when App Group container is unavailable on iOS Simulator first-launch — should throw and let `bootstrap()` degrade gracefully

[eugene-lisovskiy]

Summary

When the host app's App Group entitlement is correctly configured but the container isn't yet mounted (clean iOS Simulator install after simctl uninstall / simctl install), FileManager.storeURL(for:databaseName:) calls fatalError which crashes the host process.

The bootstrap() method that ultimately consumes this URL is already wrapped in do/catch (MBLoggerCoreDataManager.swift:93-117) and would degrade storageState to .disabled if loadContainer threw — but fatalError short-circuits the catch and brings down the entire host app.

Reproduction

1. Host app with valid group.cloud.Mindbox.<bundle-id> entitlement (verified embedded via codesign -d --entitlements - Runner.app).
2. Cycle the install on iOS Simulator:

   xcrun simctl uninstall booted <bundle-id>
   xcrun simctl install booted Runner.app
   xcrun simctl launch booted <bundle-id>

3. App crashes with EXC_BREAKPOINT (SIGTRAP).

Stack trace from the .ips report:

FileManager.storeURL(for:databaseName:)        — FileManager+Extensions.swift:13
  closure #1 in MBLoggerCoreDataManager.init   — MBLoggerCoreDataManager.swift:18-23
    MBLoggerCoreDataManager.bootstrap()        — line 93
  ← Mindbox.assembly()
    Mindbox.shared.unsafeMutableAddressor      — first access of the lazy singleton
      AppDelegate.initializeMindboxSdk()       — our host code calling Mindbox.shared.initialization(configuration:)

Reproduces 100% on Xcode 26.x / iOS 26.5 Simulator with Mindbox and MindboxLogger both at 2.15.0.

Why this matters

• Blocks automated UI testing on iOS Simulator (Maestro / XCUITest with clearState: true / simctl uninstall between runs).
• Affects every first-launch on a CI runner that wipes the simulator between builds.
• Related to Thread 1: Fatal error: containerURL not found for group:  #124 (closed as a host misconfiguration) and Crash at MBLoggerCoreDataManager #585 (fixed a different fatalError in persistentContainer in 2.14.2). The pattern of using fatalError from within the SDK's init path is the deeper issue — an SDK should never bring down its host app just because one of its capabilities can't be initialized.

The host app's entitlement is correctly configured. The container is simply not yet available because the OS hasn't finished setting up the App Group sandbox on a brand-new install. Subsequent launches succeed (which is why this only shows up under automation, not under hand-driven QA).

Proposed fix

FileManager+Extensions.swift:

extension FileManager {
    enum StoreURLError: Error {
        case containerUnavailable(appGroup: String)
    }

    static func storeURL(for appGroup: String, databaseName: String) throws -> URL {
        guard let fileContainer = FileManager.default
            .containerURL(forSecurityApplicationGroupIdentifier: appGroup) else {
            throw StoreURLError.containerUnavailable(appGroup: appGroup)
        }
        return fileContainer.appendingPathComponent("\(databaseName).sqlite")
    }
}

Update callers (currently a single call site inside LoggerDatabaseLoader) to propagate the throws. MBLoggerCoreDataManager.bootstrap() already has a catch branch that sets storageState = .disabled and logs the failure — the new throw lands there cleanly. No behavior change in the happy path.

This keeps the original semantic guidance for misconfigured hosts (the host's logging is silently disabled and the developer sees an [MBLoggerCDManager] bootstrap failed: containerUnavailable(appGroup: ...) line in the console) while removing the crash.

If you want a louder signal for misconfigured hosts in DEBUG, an assertionFailure instead of fatalError would also keep the bootstrap path crash-free in release builds while still flagging the issue during development.

Environment

• Mindbox 2.15.0
• MindboxLogger 2.15.0
• MindboxNotifications 2.15.0
• mindbox_ios (Flutter plugin) 2.15.0
• Xcode 26.x / iOS 26.5 Simulator (iPhone 17 Pro)
• Host: Flutter 3.x app, native AppDelegate.swift calling Mindbox.shared.initialization(configuration:) from didFinishLaunchingWithOptions before GeneratedPluginRegistrant.register(with: self)
• App Group: group.cloud.Mindbox.<bundle-id> (verified embedded in the .app's entitlements)

Happy to provide the full .ips crash log on request.

[justSmK]

@eugene-lisovskiy

Thanks for the detailed report — reproduction steps, stack trace, and the proposed fix were extremely helpful. The proposed fix is correct: replacing fatalError with a thrown error lets the existing catch in bootstrap() degrade the logger to a disabled state instead of taking down the host process. We'll pick this up and update the issue once the PR is open.

One honest caveat before we move on: we've confirmed the crash path locally (by forcing containerURL to return nil via a non-existent AppGroup), but we haven't been able to reproduce your specific timing scenario ("sandbox not yet mounted on a brand-new install") on our side — even with simctl erase + boot + install + launch × 5 against the same Mindbox 2.15.0 release, on Xcode 26.5 / iOS 26.5 Simulator, with an identical early-init pattern (Mindbox.shared.initialization(...) in didFinishLaunchingWithOptions before plugin registration).

The fix lands either way, but to write a regression test that actually reflects your reality (rather than a synthetic misconfiguration), it would help to know:

1. CI environment: self-hosted vs cloud runner (GitHub Actions / GitLab / etc.), macOS version (sw_vers), and the exact Xcode build (xcodebuild -version).
2. How the simulator is wiped between runs — is it simctl erase , simctl create of a fresh device, Maestro's clearState: true, or something else?
3. Reproduces locally too? Does the crash happen on a developer machine outside CI, or strictly on the CI runner?
4. os_log from launch to crash if not too much trouble:

xcrun simctl spawn booted log show \
  --predicate 'subsystem == "com.apple.containermanager" OR subsystem CONTAINS "Mindbox" OR process == "Runner"' \
  --info --debug --last 2m

Anything around containermanagerd / mobile_container_manager during launch would let us confirm the actual signal.

Not blocking the fix on any of this — we'll ship the patch as soon as the PR is ready. The above is just for the regression test. Thanks again!