User Profile

This is a new one on me. My built app works great on all my systems. But when I send it off to testers to run, if they launch it from Finder they get an alert that says "<appname> is damaged and can't be opened. You should move it to the Trash."There's no information in Console about what might be wrong, other than that the app was sent a SIGKILL.Does anyone have thoughts on what could be causing this? I have confirmed that the app runs fine for me even on a machine that has no Apple ID set up, so it's not about being tied to my Apple account from a signing perspective or whatever (and the alert message is wrong for that to be the issue anyway).Alternatively (or in addition) -- is there a tool that can analyze my application to tell me about any issues with the way it's packaged, its metadata, etc to help me understand issues like this? Haven't been able to find one.Thanks,Eric Shepherd

I have a Mac Carbon project that currently exists as a monolithic application that fhas a single main window that is primarily an OpenGL view into which 2D content is being drawn. Obviously, I'm eager to get this converted into a modern 64-bit application. I would also like to transition to allowing multiple windows to be open, each running an instance of the code that the existing application is based on, so that multiple ongoing sessions can be running at the same time.My plan is to remove all the UI code from the existing application, and to eradicate all Carbon dependencies so I can convert the code to 64-bit. Then I will create a wrapper application which handles the UI: the menus, the creation and management of the session windows, and so forth. Each time a new session is created or restored from a save file, I want the wrapper app to instantiate a copy of the main program, using an IOSurface and a shared memory object to allow the wrapper and the main program to share a memory buffer which is used as a texture for Metal to draw the graphics into the session's window.The main program is more than just a "helper" in that it can't be allowed to be terminated automatically or anything like that. It needs to stay running until the wrapper is quit or the wrapper tells a given session to exit.Right now, my main concern is figuring out the right way to create and manage the session processes. It sounds like in theory converting the main session program into an XPC service would be the right approach, except for a few concerns I have due to things I've read:It sounds like a given XPC service can only be run once. That would not suffice for my needs, since the whole point is to spawn multiple copies of it.It sounds like XPC services are really intended for processes that live a very short time, and for which there are limits on how much control you have over how long the service is permitted to run.If XPC isn't the right choice, what is? I know I'm not the first person to think of doing things this way...The basic model is something like this:┌──────────────────────────────────────────────────┐ ┌───────────────────┐ │ │ │ │ │ Main Program │ ┌ ─ ─ ─ ─ ─>│ SessionApp │ │ •••••••••••••••••••••••••••••••••••••••••••••••• │ │ │ │ │ │ └───────────────────┘ │ ┌───────────────────┐ ┌───────────────┐ │ │ │ │ ┌────>│ SessionWindow │<│─ ─ ─ ─ ┘ ┌───────────────────┐ │ │ │ │ └───────────────┘ │ │ │ │ │ │ │ │ ┌ ─ ─ ─ ─ ─>│ SessionApp │ │ │ Main Menus │ │ ┌───────────────┐ │ │ │ │ │ Window Management │────┼────>│ SessionWindow │<│─ ─ ─ ─ ┘ └───────────────────┘ │ │ │ │ └───────────────┘ │ │ │ │ │ │ ┌───────────────────┐ │ │ │ │ ┌───────────────┐ │ │ │ │ │ │ └────>│ SessionWindow │<│─ ─ ─ ─ ─ ─ ─ ─ ─ ─>│ SessionApp │ │ └───────────────────┘ └───────────────┘ │ │ │ └──────────────────────────────────────────────────┘ └───────────────────┘ messages back and forth; shared memory for each SessionWindow's MTKView's window-sized texture buffer Any suggestions or advice? Thanks!

I am working on updating an existing single-window OpenGL Mac application to support multiple open windows. Each window would be running the same code but with different data. There are a lot of global variables and structures involved in managing the state of the original application, so if I can keep each window's memory space separate, I can avoid having to basically rewrite all the original code practically from scratch. Bonus points if I can find a solution that lets the windows be grouped and ungrouped using the window tab APIs.In addition to the instance windows, there will need to be a preference window and assorted other UX features, along with the main menu bar (which would need a list of the instances as well, of course).To that end, I'd like to do something more or less like the following:Create an encapsulating application that provides the main menu bar, global preferences, and UX for creating, loading, saving, and otherwise managing the individual windows that contain instances of the main application.Revise the existing application to migrate all its UX code out to the new encapsulating app, leaving just the core code that processes the data and draws the graphics using OpenGL into its view.Doesn't matter to me whether the instance windows are created by the encapsulating app and the instances send their frames to the window buffer using shared memory or the like, or the instances create their own windows. I would think the latter is the easiest and smartest way to go. The only reason I leave open the possibility of having the encapsulating app create the instances' windows is that it might make the interactions between the instances and the Cocoa UI code easier.While this could be done by just having each instance have its own menu bar and dispatching messages back and forth to keep menus in sync and such, but it would not look very clean and seems like a pretty messy solution. I'm hoping there's a better way. Any ideas?

SInce updating to 10.13.5 beta 4 (17F59b), the neither option key on my keyboard doesn't work in any of my apps. I'm using a Logitech G510 gaming keyboard, with the Alt and Windows keys swapped so that the option and command keys wind up in the expected places.It's important to note that if I switch them back, the option key works but the command key doesn't, so something about the key located two to the left of the space bar (between Ctrl and Alt) is not working correctly in this beta. It was definitely working since before the beta was installed and I've checked and none of my apps appear to be swiping it somehow.