macOS Tahoe 26.5.1: Mac Catalyst App Crashes at Launch with EXC_BREAKPOINT in libsystem_secinit due to Container Integrity Check Failure

After updating the application following an upgrade from a previous macOS version to macOS Tahoe 26.5.1 (25F80), the sandboxed app immediately crashes on launch. The crash occurs during dyld library initialization, before any application code (including main()) is executed.

The crash report identifies that libsystem_secinit.dylib rejects the existing app sandbox container with the following signature: "failed integrity checks for container at /Users/apptest/Library/Containers/77C6DBAA-6E54-4ED4-947C-5C5648BE280B/Data: Invalid argumen"

Clearing out the old sandbox container data (e.g., rm -rf ~/Library/Containers/77C6DBAA-6E54-4ED4-947C-5C5648BE280B/Data) resolves the crash.

Please help analyze the possible causes of this issue: 1.Could this be a compatibility issue between the new macOS 26.5.1 system and Mac Catalyst apps? 2.Could this be caused by certain APIs used by the app or specific project configuration settings? If so, please provide some relevant hints to help narrow down the scope of analysis.

Is this affecting an app that you’ve built? Or are you seeing this with apps built by other developers?


For context, the immediate cause of this crash is an app container ownership check. When a sandboxed app first launches, the system creates its app container and records information about the app’s identity into that container. The next time the app launches it checks that that this is the same app. This prevents a malicious app from impersonating some popular app and snarfing up its data. This “same app” check is based on code signing requirements. See TN3127 Inside Code Signing: Requirements.

Something has gone wrong with that check in your case. I’m not aware of any specific reason why this check would suddenly start failing for your app. To understand what’s going on I’ll need a bunch of information from you, and hence the question above is the first of many (-:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

At present, this issue is known to affect only this one app and it impacts users.

OK.

I’ve collected many identical crash logs from users in Organizer

OK, so that confirms that this is an app that you created.

Are you able to reproduce this in your office? If so, what were the specific steps?

I’m looking for more details here because you wrote:

following an upgrade from a previous macOS version to macOS Tahoe 26.5.1

and I’m not sure how to interpret that. Taken literally it suggests that an upgrade from macOS 26.5 to 26.5.1 will trigger the problem. Is that right?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for your reply.

We're not sure if upgrading from macOS 26.5 to 26.5.1 triggers this issue. Our steps to reproduce are: upgrade from macOS 15.7 or 26.2 (very sorry, I'm not sure exactly which one) to Tahoe 26.5.1, and then update the app version.

OK. So lemme see if I understand this properly. You’re seeing this crash if you:

  1. Install macOS 15.7 or 26.2 (not sure which one).
  2. Install version N of your app from the App Store.
  3. Upgrade to macOS 26.5.1.
  4. Install version N+1 of your app from the App Store (or version N+2 of your app from TestFlight).

Is that right?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes, it is right.

Thanks for confirming.

I had a look at the source of this failed integrity checks for container error and it’s not as complicated as I first thought. Moreover, each of the integrity checks that it runs has an accompanying log point, so you should be able to learn more from the system log.

Try this:

  1. Run Console and start stream log entries.
  2. Reproduce the problem.
  3. Switch to Console and pause the log.
  4. Search the log for log entries from the secinitd process (past process:secinitd into the search field) where the Subsystem column is blank and the Category column says <Missing Description> [1].

What do you see?

For example, in my tests I did this:

  1. I created a sandboxed test app.

  2. I ran it.

  3. I quit it.

  4. I replaced its Data/Library/Images directory with a file (mwa ha ha!).

    % rm -r ~/Library/Containers/com.example.apple-samplecode.Test836638/Data/Library/Images
    % touch ~/Library/Containers/com.example.apple-samplecode.Test836638/Data/Library/Images
    
  5. I ran the app.

It crashed, with the crash report saying:

failed integrity checks for container at /Users/quinn/Library/Containers/com.example.apple-samplecode.Test836638/Data: Invalid argumen

and in the system log I see this:

type: error
time: 2026-07-09 13:21:33.577600 +0100
process: secinitd
subsystem: 
category: <Missing Description>
message: <private>: Library/Images is not a directory

type: error
time: 2026-07-09 13:21:33.577620 +0100
process: secinitd
subsystem: 
category: <Missing Description>
message: <private>: Invalid argument

The second log entry is a mirror of the error from the crash report, but the first log entry actually tells me what failed.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] It’s annoying that these log entries don’t have a meaningful subsystem and category, and I filed a bug requesting that (r. 181803147).

macOS Tahoe 26.5.1: Mac Catalyst App Crashes at Launch with EXC_BREAKPOINT in libsystem_secinit due to Container Integrity Check Failure
 
 
Q