This post relates to FB13684924, which I submitted via Feedback Assistant on 12 March 2024. I regard the matter as urgent, so I thought I would ask if anyone here has had a similar problem and has advice or a workaround. (I have not yet filed a request for technical support: I expect I will do so if I cannot otherwise resolve the problem.) I will simply cut-and-paste in the text of FB13684924 here -- slightly reformatted, because Feedback Assistant seems not to like paragraphs ... ######## SNIP ######## I presently have an app for the Macintosh in the App Store. Its name is "Peter Pater". When I open the App Store application on a mac, and type "Peter Pater" in the "Search" window, the app does not show up. (I am taking care to make sure to search for Macintosh applications -- my app does not run on other platforms.) Thus there is no way for someone who has heard about my app -- perhaps by word of mouth -- to find it and purchase it. This behavior is new. The app first reached the app store on February 6, 2024, and for several weeks thereafter it showed up when I typed "Peter Pater" in the "Search" window. I know the app is still in the App Store, because when I type my own name (as developer) -- "Jay Freeman", or type one of the keywords that I provided when I submitted the app to the App Store, it does appear. (Suitable keywords include "astrogation", "quaternion" and "complex number".) ######## UNSNIP ######## Many thanks for any help or advice.

I am preparing a macOS app for the App Store, using the App Store Connect site on the web. I have successfully uploaded several screenshots with very fast uploads -- a few seconds -- but uploads of app previews are ending up stuck in processing (the message is "This file has been uploaded and is processing.") for many hours -- e.g., six hours for a 13 MByte preview. It is also frustrating that if I refresh the web page where I am attempting the upload, the upload fails immediately, and I have to start all over again. As I write these words I am waiting to see if the current attempt will succeed ...

I am having a problem configuring popup buttons for a macOS application, using the Interface Builder mechanisms of Xcode (14.3.1). I am prepared to report the issue as a bug, but I thought I would check here to see if I had overlooked something in my configuration efforts: Briefly, I wish to have a popup button in my app's main window (not in the menu bar), that has a bezel color of "System Orange Color" and that uses white lettering for its title. My app has a lot of buttons, and for all the other button types I have used, when I set the bezel color to System Orange or to some similarly dark-ish color, the title lettering automagically comes up white. That of course also happens for the popup buttons that are part of the menu bar -- their titles have white lettering -- but when I place a popup button in the main window of my app, its title comes up with black letters no matter what I do. This is solely an aesthetic problem -- the popup button works perfectly well, it just looks out of place because its lettering doesn't match the other buttons. The misbehaving popup button is configured via Xcode only -- no commands sent from code. Its Xcode configuration settings include Pull Down, No Arrow, Bevel, Momentary Push In, System Orange Color, System Regular (font), and No Image.

I recently lost a Freeform board due to syncing problems with iCloud, and tried to recover it by restoring Users//Library/Containers/Freeform from Time Machine, but Freeform could not read the restored data. Any suggestions on what to do? I mention this matter here because Freeform is potentially a very useful developer tool -- for interface design -- but it is certainly unacceptable if there is no way to back up its data in recoverable form. I did submit a report to Apple with Feedback Assistant.

I have a macOS app that I have been distributing for free outside the app store for more than 15 years, without notarization, without sandboxing, and without hardened runtime, all with no problems. If I understand correctly, macOS will soon be modified so that it will not launch any developer-distributed apps that are not notarized. Notarization will require both hardened runtime and sandboxing, and unhappily, my app will not run when notarized -- I have added sandboxing and hardened runtime, than gotten it notarized and tried -- and that is because it will not run when sandboxed. Thus I have two questions: Will there be some means, that I perhaps have missed, for my users to run my app as is, in un-notarized form with no sandboxing and no hardened runtime? (Assume that they are willing to click "Okay" on any macOS popups of the form "Abandon hope, all ye who enter here.") Perhaps I have missed something about the signing or distribution process ... ? If not, is there some entitlement I can obtain to allow my app to run when sandboxed? Perhaps the question is even "Should there be such an entitlement?" And to that end, I must now explain why it cannot run sandboxed: My app is a parallel processing system: To work properly it must open multiple copies of itself -- that's right, there will be multiple instances of the app window visible on the console, distinguished by tint, title and location so the user can tell which is which, and multiple app badges in the dock, similarly distinguished. Doing so is easy -- I use the c++ "system" function to call the Unix executable that is buried within the ".app" folder, passing it a command tail whereby the launched copy can tell how to distinguish itself. I build up the text string for the call piece by piece, but the result looks rather like this: system("<path-to-my-app>/MyApp.app/Contents/MacOS/MyApp -tail-item-1 -tail-item-2 ... &"); The app is written in mixed C++ and Objective C. The usual "Main.mm" file contains the entry point for the program, a "main()" function that does nothing but call "NSApplicationMain()", but I have added code to "main()" that runs before the call of NSApplicationMain(). That code uses C function "getopt()" to look for the extra command-tail items. If any are present, the app acts appropriately -- generally assigning non-default values to global variables that are used later in initialization. The first instance of the app that is called -- presumably by the user mousing on an icon somewhere -- knows by the absence of extra command-tail items that it is the first one launched, and thus knows to launch multiple additional instances of itself using this mechanism. The launched instances know by the presence of extra command-tail items that they are not the first one launched, and act differently, based on the command-tail items themselves. All this has been working fine for over a decade when the app is not sandboxed and does not have a hardened runtime. For what it is worth, the app will run with hardened runtime, provided the option "Disable Executable Memory Protection" is checked. Furthermore, when it is also sandboxed and I open it with no extra copies of itself launched (the number to launch is a preferences option), that single app instance runs fine. I have instrumented the code, and what seems to be happening is that the system call to launch another app returns zero -- implying it succeeded -- but has no effect: It is as if someone had special-cased "system" to do nothing, but to report success nonetheless. That is an entirely reasonable feature of a hardened runtime -- allowing arbitrary system calls would be a security disaster looking for a place to happen. The point is that my app would not be making an arbitrary system call -- it would be trying to open one specific app -- itself -- which would be sandboxed with a hardened runtime, and notarized. That is not likely to be a huge security problem. Incidentally, not all system calls fail this way -- I can do system("osascript -e 'tell app \"Safari\" to activate';"); or system( "open -a \"Safari\" <path to a help file located in MyApp's Resources>"); with impunity. Also incidentally, using AppleScript to launch another copy of MyApp from within itself doesn't do what I want: The system notices that MyApp is already running and just makes it active instead of launching a new copy, and there is no way to pass in a command tail anyway. I don't wish to appear to be advertising, so I won't identify my app, but a little more detail might be useful: It is a parallel program interpreter. The language implemented is the "Scheme" dialect of Lisp. Each instance running is a complete read/eval/print loop embedded in an application window where the user can read and type. The first instance of the app launched mmaps a large memory area for the Lisp system's main memory: That works kind of like a big heap in more conventional programs. It is not executable code, it contains Lisp data structures that an application instance can access. The other instances launched use the same mmapped area. The shared memory has lots of lock bits. I use low-level "lockless coding" -- hand-coded assembler with the Intel "lock" prefix or the more complicated arm64 stuff -- to keep simultaneous access by different app instances from corrupting the shared memory. Parallel Scheme has many uses, which include debugging and monitoring of running Scheme programs, and having multiple tail-recursive "actors" (Lisp jargon) operate on the same data at the same time. Enough said. I would like to be able to notarize this app so that users who obtained it outside the app store could understand that Apple had checked it for dangerous code. If that were possible, I might even try submitting it to the app store -- but that would be another story. Do I have any hope of keeping this product available?

I have been setting up MacOS color filters via "System Preferences" -> "Accessibility" -> "Display" -> "Color Filters". When I set it up, the filter effect only shows up on two of the four monitors I have attached to my Mac Pro. (The two that work are a Samsung LC49G95T and a Dell S3221QS; the two that do not are both HP2509s.) I have filed a bug report with Apple on this, but it occurs to me that it might be helpful to add to it any other users' experiences with monitors that do and do not "work" with color filters. Has anyone else seen this phenomenon? Alternatively, does anyone have any suggestions for getting the 2509s to show the filtering?

I need to know more about how macOS uses user-process virtual address space in ways not explicily requested by the user. In detail, I have a process that needs to mmap a file to a specific virtual address. I don't care what the address is, but I need to know it at compile-time. I know how to set up such a mapping, and how to specify in the executable that a particular chunk of virtual address space is reserved for it: Specifically, my Xcode build includes a .s file containing a .zerofill directive to create a named segment and section of the required size, and I use the -segaddr flag in the linker to specify the virtual address where that segment is to be loaded. I can then use the address and size that I have chosen, elsewhere in my source code, via mmap with MAP_FIXED. This method seems to protect the special segment from being used by macOS, which is of course what I want. My problem is, I don't know whether the location I have chosen for the new segment is inconveniencing macOS in some undesirable way: For example, staking out a big chunk of user memory in the wrong place might restrict the space available to the memory allocation system, or limit stack growth, or some such thing. At the moment, my empirical choice of location works on my own Macs, but it might not work on others, or on other versions of macOS. What I am looking for -- and haven't found -- is documentation about how macOS user-process virtual address space is used, in sufficient detail that I can choose the location of my special segment so that it does not get in the way. I need to know it for both the x86_64 architecture and the arm64 architecture, and I need to know how that usage might vary from machine to machine and from macOS version to macOS version. Can anyone help or advise? (For the curious, I need to mmap the file to a specific virtual address because it is binary data that contains absolute pointers to locations within itself. I can set up the pointers correctly for any given mmap loading address when I first mmap the file, but I need each subsequent process that mmaps the same file to be able to dereference pointers correctly -- thus I need a fixed load address that all processes can use when mmapping.)

I am porting a macOS Objective-C app from just Intel silicon to universal binary -- Intel and Apple silicon both -- using Xcode 13.2.1, building on a 2019 Mac Pro running macOS 11.6.4. I have followed all the instructions here: https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary. In particular, in Xcode's "build" settings, "Architectures" is set to "Standard Architectures (Apple Silicon, Intel) - $(ARCHS_STANDARD)", and "Build Active Architecture Only" is set to "No". Yet when I use Xcode to build either the release or the debug version of my app, the shell command: lipo -archs <path to MyApp.app>/Contents/MacOS/<MyApp> returns only "x86_64", and indeed, the app doesn't even start initialization when I test it on a Mac Mini with Apple silicon. What could I be doing wrong?

I have a MacOS app which has its own documents. The documents are supposed to have custom icons, so that they are easily identifiable on -- e.g. -- the Desktop. They used to be visible, but they aren't now. In more detail ... I have been upgrading and old app that was last built (in Objective C, using Xcode) under MacOS 10.13 (High Sierra). I have gotten the upgrade to build and run under Big Sur (still Objective C and Xcode). Both the old and the new versions of the app successfully write usable documents. The documents created by both the old and the new app do show up on the Desktop with the correct icons when I copy the documents to an old Mac running High Sierra. They also show when I copy them to a Mac running Mojave. (I don't happen to have a Catalina partition handy, so I can't say about Catalina.) The exact same documents do not show up with the correct icons when I copy them to a newer Mac running Big Sur -- they show up with generic document icons. I have both the old and the new versions of the app installed on all these machines, so the Finder can do whatever it does to both versions to find out about document icons. Obviously (I think), something has changed about how the Finder gets information about document icons, between Mojave and Big Sur, or possibly between Catalina and Big Sur. Does anyone know what it is? In particular, are there some new key/value pairs I should add to my Info.plist or to the Custom macOS Application Properties panel in Xcode, to make my custom document icons show up?

I am developing with Objective C. In Xcode, I have a single .nib file with several NSWindows in it besides the app's main window. I wish to use addChildWindow:, etc., to attach the extra windows to the main window and (e.g.) move them around. Thus in the .nib editor, I have used the Connections Inspector to make connections ("drag lines") to the windows from IBOutlets in a central controller (special class, not an NSWindowController or an NSViewController) where I have put code to run addChildWindow:, etc. The problem is, that the connections aren't getting created. When I check in my central controller's "awakeFromNib" method, I find that the IBOutlets to my windows are all null at that time. There is a whole lot on the net about people having this kind of problem with NSViews, and the recommended solutions involve NSViewControllers: Let me stress that my connections are not to NSViews, but to NSWindows. I am not sure how to apply the advice for NSViews to my problem. My "extra" windows are in essence static -- I just use their views to display things to the user (via, e.g. NSTextFields) or to get input from the user (via, e.g., NSButtons), so I haven't any need for the content-altering functions of window or view controllers. Besides, I am not sure how I would go about connecting my windows or their content views to an NSWindowController or an NSViewController, because the IBOutlets haven't been loaded when I need them. Thus I am stuck in a loop: I can't use null IBOutlets to connect windows and views to window or view controllers, but I seem to need controllers with the windows or views already connected in order to load things and thereby get the IBOutlets to be non-null. Is there a way out?

I am developing in C++ and Objective C using Xcode 13.1, running on a 2019 Mac Pro with Big Sur 11.6.1. I am working on an app to run on (only) Macintoshes with Intel silicon. (Apple silicon will involve a port, later.) In Xcode, my compiler is set to Apple CLang, with defaults across the board. I need to embed some Intel assembly-language code in some of the C++ code for my application. I can't find any manuals or examples for how to do that. I have written Intel assembler before, but not for a long time, and never embedded in a MacOS app. Can someone recommend any books or links to documentation or examples? Apple's own documentation seems in great part no longer maintained.

It looks like I will eventually have to reverse-engineer and replace NSDrawer for one of my MacOs apps. There has been talk here and there about doing that, and I wondered if anyone had done so and would be willing to share or give hints. For the record: (1) My use of NSDrawer is appropriate under the original human interface guidelines for it, which were "[u]se drawers only for controls that need to be accessed fairly frequently but that don't need to be visible all the time." (2) NSSplitView is not appropriate because (a) my app is text-based, and it is very disconcerting to have the text re-flowed when the extra view opens and closes, and (b) I need more than one drawer (for different sets of controls, useful in different circumstances). (3) Various other kind of view don't work because of one or more of (a) they block content in the main view, (b) they do not automatically appear at the same position relative to the main view, or (c) they do not follow the main view when the user moves  or resizes it. (Note that requirements (b) and (c) follow from Fitt's law.) My app is a program-development environment for the Scheme programming language, called "Wraith Scheme".

I am running a MacPro7,1 with Big Sur 11.6 and Xcode 13.0. When I open the main nib file for my application, the editor is completely blank -- nothing shows up. The app builds and runs as expected, so it is not like the nib has vanished. The nib has been visible recently, but I am not aware of anything unusual that I might have done to it to cause damage. The behavior repeats after a project clean, and also after closing Xcode and reopening it. Does anyone have any ideas of what might be going on, and how to fix the problem?

Ten years or so ago I had an iPad app called ***** Scheme III on the app store. I stopped upgrading it, and it is no longer there, and indeed, it does not run on current devices. I recently received email from someone who has an original iPad, which would run the app, and who wants it. Is there any way I can get a copy to that person?