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!