sample.ips.txt Xcode, MacSymbolicator and QuickLook all fail to consider the symbols from the lastExceptionBacktrace of a modern .ips crash report. I have attached a full report as an example (I had to change its extension to txt or I wouldn't be able to upload it - change it back to ips and then use Quicklook to see its contents, which will be missing the backtrace). Here's the excerpt that matters: "lastExceptionBacktrace": [ { "imageOffset": 992564, "symbol": "__exceptionPreprocess", "symbolLocation": 164, "imageIndex": 13 }, { "imageOffset": 106164, "symbol": "objc_exception_throw", "symbolLocation": 60, "imageIndex": 25 }, { "imageOffset": 274836, "symbol": "-[__NSDictionaryM setObject:forKeyedSubscript:]", "symbolLocation": 1176, "imageIndex": 13 }, This trace is missing from a symbolicated report - I only get to see the main threads. Here's the start of that report: ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: Find Any File [2616] Path: /Applications/Find Any File.app/Contents/MacOS/Find Any File Identifier: org.tempel.findanyfile Version: 2.4.1 (355) Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 0 Date/Time: 2024-01-09 11:31:33.8066 -0600 OS Version: macOS 14.3 (23D5043d) Report Version: 12 Anonymous UUID: E3DD5ECE-F28C-31BA-A2EA-DE39D4284163 Time Awake Since Boot: 990 seconds System Integrity Protection: enabled Crashed Thread: 11 Dispatch queue: Folder size calc (Macintosh HD) (QOS: UNSPECIFIED) Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6 Terminating Process: Find Any File [2616] Application Specific Information: abort() called Thread 0:: Dispatch queue: com.apple.main-thread 0 CoreAutoLayout 0x18cecbdd8 -[NSISEngine hasValue:forEngineVar:] + 284 1 AppKit 0x187f51894 NSViewActuallyUpdateFrameFromLayoutEngine + 128 2 AppKit 0x187f11790 -[NSView layout] + 636 Contrary to this, when I get a similar crash report from an older macOS version where it still uses the older .crash instead of .ips files, I get to see the backtrace and can symbolicate it as expected. This seems to be a major bug in the symbolicator for ips files, and it's been around for years. I'm surprised that this is still not taken care of. Am I the only one who's noticing this?

Update: Turns out it works for others, apparently, and I also found one of my Macs where it does work, too. So it must be something pertinent to my systems. Oddly, though, the same ones where it now fails used to work because I had TestFlight enabled there before. I have TestFlight set up on App Store Connect, and I have already about 50 testers subscribed. Today, I found that the Public Link does not work any more: Once TestFlight.app is installed, and one clicks the link to add my app to TestFlight, it always shows the error ""Unable to Open Link" in TestFlight.app: I've tried this on several Macs (Ventura and Sonoma), and with different Accounts, both where the app was already added or not. Is something generally broken, i.e. do others see the same issue with their TestFlight links, or is it just me? How do you suggest I get this resolved? Here's an example link I set up for this purpose - it only allows a handful of subscribers, so please do not actually subscribe but just see if you even get allowed to, or if you get the same error if you must try: https://testflight.apple.com/join/oV8NNojg And here's how it's set up:

I have an app in the App Store that doesn't need to be sandboxed (it's been in the MAS since 2010, before sandboxing became mandatory for new apps). I have run into an obscure bug that ONLY appears when the app was installed by TestFlight, but not when I run the same executable from before the upload (taken from the very same archive). I suspect it's a bug around the installed receipt or is codesign related, because that's the only things I am aware of that would be changed between my upload and the re-download via TestFlight. To debug this, I have built a small test project that I want to submit to DTS, demonstrating the bug in a clear and direct manner. But when I try to upload it, even for "internal testing" only, the upload gets rejected automatically because it's missing the App Sandbox entitlement. However, if I add the entitlement, then my app won't work, so I cannot enable it. Hence I need to get an exception from App Review so that they allow me test app being uploaded without the sandbox entitlement. I know that's possible because otherwise I'd not be able to upload my regular application, which I did just the other day. How do I get this resolved? Would a member of the App Store team please contact me? The Apple ID for the test project is: 410006334. Or, alternatively, you can also use the newer 6503298614 (I tried the other in hopes it would be allowed not to be sandboxed because I had created it long ago, but that didn't work out).

My app (Find Any File) behaves strangely on Sequoia: When the code calls the window's makeFirstResponder on the NSSearchField item in the window's toolbar, and if the toolbar is currently showing the small loupe icon, it should: Switch to showing an NSTextView in place of the loupe icon Make the text view the first responder so that the user can type in it. This used to work reliably before macOS 15, but in 15.0.1 and also the current 15.1 beta it often misses step 1 or or step 2. When it misses step 1, then the window's first responder reports back to it's set to the text field, but its frame is very narrow (width is 4 isntead of 192). And when it misses step 2, then the textview is visible but hasn't gained focus - instead, the main window is the first responder. This happening is quite random. I find no pattern. Even worse, after calling makeFirstResponder, if I check the window's first responder, it's always the expected NSTextView, even if I delay the check with dispatch_async(dispatch_get_main_queue(), ^{ …. So I cannot even reliably detect when this goes wrong in order to act on it. Has anyone else noticed this to happen in their apps?

I have several ObjC based apps in the App Store and used to validate the receipt file inside the app in my code, and then reject it with exit(173) if it's invalid, which did trigger macOS to update the receipt if possible. This isn't working any more in recent macOS versions, where the user is instead just told that the app is damaged, and they need to re-install it manually. Which sucks. So I wanted to update my code. I read about SKReceiptRefreshRequest, which is supposed to re-download and install the receipt file, if I understand it correctly. I implemented the code but now have trouble verifying that it works as intended, and does this in a user friendly way. I found in my tests that macOS now caches the receipt in ~/Library/Caches/com.apple.appstoreagent/fsCachedData and then hardlinks the file into the app. BTW: Sadly, this also requires that the app is located on the startup volume or the system will refuse to install the receipt, which wasn't a requirement in past times. Now, if the receipt is already present in the cache folder, then my code works - the receipt gets re-linked. But what if the cached receipt isn't there, yet? Such as that the user had copied the app from another Mac over to a freshly installed Mac? In the past, when the user then launched the app on the new Mac, he'd be prompted to login to the MAS and if that worked, the receipt would get installed and the app launched. Basically, the question is: What if the receipt validation fails in my app and I request a new receipt, but the user has not yet logged into MAS (e.g. new computer)? To simulate this, I logging out of the MAS and TestFlight, deleting all copies of the app and then run the app that I had copied from another Mac where it was authorized with a valid receipt for that device. If I do this with the old version that uses exit(173), I get these two messages in macOS 15.2: The second one is especially terrible because it shows the translocated path, which the average user surely get quite confused, and then maybe even search in vain for the app in there and get frustrated. But that's out of my hands. Sigh. Now, that was proving that the old method with exit(173) isn't working any more and needs to be changed in my apps. Since I'm still developing (testing) this new behavior, the app is therefore not in the MAS yet - the only way for me to test this is to use TestFlight. However, running a Testflight app copied from another Mac leads to this error: That is not helpful in simulating what would happen if this app was released in the MAS. This won't let me find out what happens if my app is run on a Mac where the receipt fails and I ask it to load it via SKReceiptRefreshRequest and if the user is NOT yet logged into the MAS account for this purchased app of his/hers. That leaves only one option: Release the app with untested code and hope for the best. Contrary to this new behavior, the old method did let me test this easily because I would just use the special App Store tester account with the MAS app, i.e. the built MAS app would, when I launched it locally, request for a login and I'd provide my tester's account. But this isn't available any more, apparently. What a mess.

I have a macOS app that contains multiple additional executables. One is a full app bundle, the others are single-file tools with an embedded plist. So far, I have used Xcode 13 to upload the app to the MAS. This had not (and still does not) report any warnings. But today, when i tried to upload (or Verify) with Xcode 16.2, I am getting this warning: I cannot make sense of this. Clearly, the placeholders are not properly filled out, but even if I remove any one of the items from the app, the verification keeps report the same warning. Only if I remove ALL of the embedded app and executables, the warning goes away. Now, the problem is that I can't see what I need to do. My Xcode signing setting are set to "Automatic", and it shows "Provisioning Profile: None required" for the main and all involved sub projects. And I never needed one (the app is not sandboxed and doesn't have to be - it's exempt), and the app was always accepted this way and runs on 10000s of Macs like this, with all executables doing their job as intended. So, what's this warning about and is that a false flag (e.g. should only be posted for sandboxed apps) or what?

My app (FindAnyFile) provides a Finder-like interface in which it also offers a QuickLook preview command, which invokes [[QLPreviewPanel sharedPreviewPanel] makeKeyAndOrderFront:nil]; Now, if it shows .abcdp files, it often, but not always, crashes. This has been happening for many macOS versions, at least since 10.15, up to 26.1. Also, it does not seem to matter which SDK/Xcode I build with, as I used several and all versions lead to the crash. The issue rather appears to be inside the QLplugin for the AB file (ABCardCollectionView etc.). I am able to trace this crash in Xcode. There are a LOT of errors and warnings coming up, and eventually the qlplugin throws an ObjC exception which in turn brings down my entire app (and here I thought that the XPC system was designed to expressly avoid such crashes). Possibly significant errors are: CNAccountCollectionUpdateWatcher 0x6000025cf800: Update event received, but store registration failed. This event will be handled, but the behavior is undefined. Error using remote object proxy when fetchAnonymousXPCEndpoint: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.telephonyutilities.callservicesdaemon.callstatecontroller" UserInfo={NSDebugDescription=connection to service named com.apple.telephonyutilities.callservicesdaemon.callstatecontroller} connection to service named com.apple.coreduetd.people … CNPropertyNotFetchedException: A property was not requested when contact was fetched. I've attached the (mostly) complete console output from such a debug run. I have also an open bug report regarding this kind of crash (back then I was not able to reproduce it myself): FB15553847 Also, when I "Quick Look" the same file in Finder, I get a "Preview not permitted" for the same items that crash in my app. If I copy the same items to the Desktop, then Finder can QL them and my app doesn't crash when viewing the item on the Desktop. So, the crash only happens with the items inside ~/Library/Application Support/AddressBook/Sources/…/Metadata/. Now, here is the weirdest part: You might think: So, if the Finder shows "Preview not permitted", then my app trying to view those items is the result of that condition (even if that's not supposed to crash). However: I have a clean 26.1 install (in an Apple ARM VM) where Finder also says "Preview not permitted" for these items in the user's Library/AB/Metadata folder, but my app can QL those items without crashing! Also, I have one user who uses 26.1 and gets the crash with files in the same location. So, the "Preview not permitted" is probably not the cause of this crash, though it's suspicious that a user gets this at all - why can't a user QL the abcdp files in the Metadata folder but when copied to the Desktop, QL works? You'd think that Finder has the necessary entitlements to access the AB, or doesn't it? Of course, my app has permission enabled under Privacy & Security / Contacts (if it's disabled, then the app can't show anything but will also not crash). And it has the "Address Book" entitlement. Would be nice if this could be looked into and eventually be fixed. Alternatively, I'd welcome any suggestions on how to prevent my app from crashing if the qlplugin throws. But if you look at the stack trace you'll see that there's no method of my own app involved where I could insert an exception catcher. I added code to my previewItemURL delegate method to make sure the NSURL item is readable, and it is, even Of course, apart from the issue with .abcdp files, the QL operation in my app works flawlessly, i.e. I have never received any other crash reports relating to any other QL plugins. QuickLook for AddressBook crash messages

My app that's been around since the dawn of the Mac App Store, and which uses its own receipt validation code for 15 years now, recently sometimes triggers a "does not support the latest receipt validation requirements" error message with my app's users. But I cannot reproduce it, even if I freshly install the app on a M4 Mac running macOS 26.2. So I have a hard time testing my fix. Does someone have a sample receipt file they could share with me (including the MAC from "en0" / GUID device ID), or do you know where I can find one that uses the new SHA-256 hash? In fact - when reading https://developer.apple.com/documentation/appstorereceipts/validating-receipts-on-the-device it seems that there's only a SHA-1 after all. So why do some users get the "receipt validation requirements" message at all? I'm only reading the receipt, decoding the ASN.1 fields and then validate the hash from the receipt (field 5) against the SHA-1 from the GUID+receipt, as always, calling libCrypto's SHA1() function. So, what would even trigger the message, as I'm not invoking any higher-level APIs that would verify the receipt for me, and thus would know when something is wrong?!?

I have a program that installs an NSStatusItem button in the Menubar. It registers for both the right and left click events. Before Tahoe, clicking into the statusitem with the mouse at the very top of the menubar would also invoke the Action handler, be it a right or a left click. Now, with Tahoe, where the menubar height was changed from 24 to 30, left clicks at the top edge still trigger the Action event, but right clicks do not - they only work if moving the mouse a few pixels down. This is quite inconvenient - the idea of the menubar being at the edge of the screen was always that one can just push the mouse to the edge and then click to interact. Tahoe has broken this basic GUI concept now partially. And since left clicks still work, it suggests that I don't do anything wrong - the clicks are controlled by the framework, and I'm never asked to provide a frame in which the clicks shall be accepted. It's that Apple's code apparently now uses the smaller statusitem's bounds instead of the full menu bar height for hit-testing. Is that on purpose or a bug? And does someone know a work-around, i.e. can I hook into the click-handler at a deeper level and do the hit testing myself? I've tried adding a subview to the statusitem's window's contentView, but that also only reacts to clicks in the smaller area.