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?

I've been uploading my app (Find Any File) to the App Store since its very first day, around 2010. It always worked. But now, after I the last successful release at the beginning of January, I am not able to get my app into the Store any more. Xcode 16.2 reports that it successfully uploaded my app, without warnings. Yet, it never appears in Connect's TestFlight builds. I just keep seeing this for the new version (2.5.6): And, after a while (less an hour), that entire 2.5.6 section disappears again as if there had never been an upload for 2.5.6. I don't get any emails about the submission or about an issue with it, either. It's like my submissions are suddenly blocked by Apple. Now I cannot submit a new version any more. What's going on there? I anyone else having a similar issue?

I need to detect the triggering of an auto-mount operation when accessing the path to a formerly unknown mount point at the file system (BSD, POSIX, NSURL) level, and how to wait for it to finish the operation. Network shares can have sub-volumes on them Consider a Windows server. Let's say there's a SMB sharepoint at C:\Shared. It has some folders, one of which is at C:\Shared\More. Furthermore, there's another partition (volume) on the PC, which is mounted at C:\Shared\More\OtherVol. If you mount the initial share on a Mac with a recent macOS, macOS initially only sees a single mount point at /Volumes/Shared, which can be checked with the "mount" command. Now, if you use Finder to dive into the Shared/More folder, Finder will trigger an auto-mount action on the containing OtherVol folder, and after that, the "mount" command will list two mount points from this server, the second being at /Volumes/Shared/More/OtherVol. (This was a bit surprising to me - I'd have thought that Windows or SMB would hide the fact that the share has sub-volumes, and simply show them as directories - and that's what it did in older macOS versions indeed, e.g. in High Sierra. But in Sequoia, these sub-volumes on the Windows side are mirrored on the Mac side, and they behave accordingly) Browse the volume, including its sub-volumes Now, I have a program that tries to dive into all the folders of this Shared volume, even if it was just freshly mounted and there's no mountpoint at /Volumes/Shared/More/OtherVol known yet (i.e. the user didn't use Finder to explore it). This means, that if my program, e.g. using a simple recursive directory scan, reaches /Volumes/Shared/More/OtherVol, the item will not appear as a volume but as an empty folder. E.g, if I get the NSURLIsVolumeKey value, it'll be false. Only once I try to enter the empty dir, listing its contents, which will return no items, an auto-mount action will get triggered, which will add the mountpoint at the path. So, in order to browse the actual contents of the OtherVol directory, I'd have to detect this auto-mount operation somehow, wait for it to finish mounting, and then re-enter the same directory so that I now see the mounted content. How do I do that? I.e. how do I tell that a dir is actually a auto-mount point and how do I wait for it to get auto-mounted before I continue to browse its contents? Note that newer macOS versions do not use fstab any more, so that's of no help here. Can the DA API help? Do I need to use the old Disk Arbitration functions for this, somehow? I have used the DA framework in the part to prevent auto-mounting, so I imagine I could hook into that handler, and if I get a callback for a mount operation, I could then queue the newly mounted volume for scanning. The problem, however, is that my scanning code may, having only seen an empty directory at the not-yet-mounted mountpoint, already decided that there's nothing there and finished its operation. I'd need some reliable method that lets my recursive scanning code know whether an auto-mount has been triggered and it therefore needs to wait for the DA callback. So, is there some signal that will let me know IMMEDIATELY after entering the empty mountpoint directory that an auto-mount op is on the way? Because I suspect that the DA callbacks come with a delay, and therefore would come too late if I used that as the notifier that I have to wait.

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.

For my app Find Any File, of which both releases and TestFlight betas were released many times, the TestFlight page tells me that several users have submitted crash reports. And I'm sure the same is true for the MAS releases: (Yes, this shows quite recent ones, but I've seen similar supposed crash report submits in this list before.) However, the actual "Crashes" listing on the appstoreconnect sites hasn't show any new crash reports for many months now: (This is the entirety of crash reports I can get listed, even when removing all filters.) Something appears to be stuck, on Apple's end. The same issue is with Xcode's Organanizer window, for "Crashes": It also used to list only the same very old reports and nothing since May 2024. And just now, when I retried this in Xcode, I'm shown a weird error message I never saw before: Error Downloading Crashes List An error occurred… Access Restricted with adam id: 1207815783 And yes, I'm logged in just fine, under Prefs / Accounts. How am I going to get this investigated? I had already sent an email about this to the Review team, who didn't react to it at all. DTS is only for Code level support, which this isn't. Any help?

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?

macOS 15 has added a new "Local Network" permission under Security & Privacy. I had a bug in my app that led to a crash when the user denied this permission. Now I've fixed it and would like to verify that it all works fine. The problem is: I need to remove my app from the settings so that macOS will show the prompt again (e.g. to verify that my custom message appears correctly). Usually, sudo tccutil reset All would do the trick. But not for this permission! The apps do not get cleared with this command. So, there's two issues: tccutil should remove it but doesn't. How can I remove this settings? Update I had a look at the "TCC.db" (see https://www.rainforestqa.com/blog/macos-tcc-db-deep-dive), and it seems to me that the Local Network permission isn't even managed by the TCC system, as it doesn't appear in it. This is odd.

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).

Has anyone else seen this happen with their macOS apps in TestFlight? The situation: When I launch my app that's been downloading via TestFlight.app, it often comes up with its main window deactivated. Also, when I have open more than one window and close one, the other window doesn't come to front either. In either case, activating the app or clicking into a window will activate it properly. It feels as if there's another window that's not visible but somehow keeps getting activated. I have this happen on two Macs running both Sonoma and Monterey. Also, if I take the very same build that I had uploaded to TestFlight and run it directly, it works correctly. So I suspect that TestFlight somehow messes with my app's windows. If you want to test this yourself: Get the app thru this link: https://findanyfile.app/TestFlight/ Then launch it. Often, the Find window will already come up without being active. Activate it, then open the Preferences window by typing cmd-comma. Then close the Prefs window with cmd-W. This should re-activate the Find window but will instead leave it deactivated, and none of the menu shortcuts (such as cmd-comma, cmd-N or cmd-Q) work. That's the bug. I wonder how I can debug this to find a work-around for this odd behavior. E.g, I'd like to see if there is indeed a semi-hidden window causing this. How would I do this? I could probably make a new TestFlight build that queries the app's windows array and logs it. But are there other ways to query an app's windows? I tried AppleScript, but since my app isn't scriptable, I only get an error -1728 for tell app "Find Any File" to get windows.

Imagine you accidentally made a build of your app with version 2 and uploaded that to App Store Connect for TestFlight even though you're still working on version 1.x and continue to do so with your public releases. Here's an example: The build 55 is the accidental 2.0 version, but the current releases are 209 and 210 with a lower string version. So, that one build of version 2 was a mistake. Sadly, you cannot remove it, even it has expired, even if it has never seen the outside of TestFlight. And it's a bit annoying too, because it stays up there at the top of your builds, and always presents the outdated version when you visit that page on App Store Connect. But worse is the fact that because of this, any version 1.x you release since then will not get you any crash reports or feedback that the user may have submitted to you. This is clearly a bug, and I was able to verify this just recently. I suspect this happens because Apple wants to avoid storing and forwarding reports for outdated versions, maybe to save space on their servers. That makes somewhat sense, though I've also had people finding crashes in older versions that were not fixed in the latest version, so I'd still like to get those reports from older versions. However, if Apple really only wants to keep crash reports and feedback msgs from the latest release, then Apple's mistake is that they use the unreliable string version to check which is the latest version instead of using the build number, which is ENFORCED by Apple to always be incrementing for each upload. If you are in the same boat, please comment so that we can make it clear to Apple that this is not an isolated issue.

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 two apps that are exempt from the need to be sandboxed. One has been in the MAS since the first day in 2010, and the other was added only a bit later, when there still was no sandboxing in place. When Apple added requirements for sandboxing, they exempted existing apps like mine under certain conditions. For years, this was no problem, but lately, nearly every other time I submit an update or a TestFlight beta, I get the app rejected for not being sandboxed, even though I explain the situation in the app's Review Notes. It's always a tedious fight convincing the reviewer to let the app pass. And, of course, it delays my releases each time. It's frustrating and exhausting. Sadly, I cannot find any public documents that confirm my claim of this exemption. So, it's always possible that the reviewer may read my note but still not believe me. Are there others here who still have such non-sandboxed in the MAS? How do you deal with this? Or do you know of documents or websites that I can refer the reviewer to?

When using the mount command on macOS, I can see mounted network servers like this: //tt@mynas.local/NAS on /Volumes/NAS (smbfs, nodev, nosuid, mounted by thomas) In this example "thomas" is my macOS user name, under which I mounted the "NAS" volume. But there's also the "tt" name before the "@" - and that's what I'm interested in getting - that's the user name known to the server, i.e. the name I logged in on the server when the connection prompt appeared. How do I get this name (tt) via macOS APIs? I can get it via "mount", but that requires parsing and is inefficient, and so I like to avoid that if possible. man mount mentions getfsent(), but in my testing it only lists internal volumes, not network volumes.

On macOS, if I mount two volumes whose name is the same, the second one gets renamed, by appending "-1" to its name. I need a method to determine the original volume name, i.e. without such a suffix. (Of course, I cannot blindly remove any "-" plus digits because the volume may actually be named like this.) I can find the original name when using the mount command in Terminal: //tt@192.168.61.121/NAS2 on /Volumes/NAS2 (smbfs, nodev, nosuid, mounted by tt) //tt@QNAS%28AFP%29._afpovertcp._tcp.local/NAS2 on /Volumes/NAS2-1 (afpfs, nodev, nosuid, mounted by tt) Here, I can tell that "/Volumes/NAS2-1" was originally named "NAS2" on the network. How do I determine the share's name without invoking such tools, but via CF or other macOS functions, with providing the path or URL of the mounted volume (such as "/Volumes/NAS2-1")?

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?