I have prepared a disk image with my application,which i want to install in Applications folder. When i copy the application from the disk image to the applications folder, i see that first it gets generic application icon (sometimes my application icon with a prohibitory sign (or broken folder) ). It becomes executable application after a couple of seconds (some 10 seconds)
I wonder if somebody has experienced something similar?
EDIT: On my customer computer with Snow Leopard the application stayed with a prohibitory sign (broken folder) . How do i fix it? It worked on Leopard
Yes this happens to me too. That is (supposed to be) the appearance of an app that cannot run on your particular platform, e.g. an Intel program on a PPC machine. Not sure why it does it to legit apps, but it seems to go away after a while (perhaps after it is run once?)
As I suspected it was a permissions problem. When build an installer with a Packager all items have to have a root as owner and wheel as group for permissions.
Why it stays that way is another question (perhaps related to caching?), but the reason for a copied application temporarily displaying as broken is simple: it is broken. That is, while it is being copied, it is incomplete, and therefore "broken". When the copy is complete, the application icon should update to indicate a good application.
If it doesn't this might be because the copy failed for some reason, or because the intermediate result is cached. In that case try refreshing by simple closing the Finder window and reopening it.
Related
every time I start or restart my MacBook, macOS verifies Xcode.
This is not a picture from me I took it from another post but its basically the same just with "Xcode" (the app) instead of the image file.
It takes a while and for the time macOS is verifying Xcode the fan of the MacBook goes like to 100%. While its verifying I can't really use other applications because they freeze and will unfreeze when the verification is finished.
I tried to remove the quarantine xattr from the Xcode.app and recursively from all package components but there never was one set xattr: /Applications/Xcode.app/: No such xattr
I also tried to to reinstall Xcode. When booting into safe mode the same verification window appears.
This happened after I updated my mac to macOS Catalina. If you have any idea what I can try next, let me know.
Ok so apparently in my case there was something messed up with my system. I couldn't find any solution and besides the Xcode problem Reminders always wanted to access a keychain of mine. Not the login, the system or iCloud Keychain but a keychain I created myself just to store and organise some password. And when I clicked on "Deny" Reminders would ask again so I only could close this window and be able to do other things when I allow access.
Anyway after I completely reinstalled macOS (first erase the whole Macintosh HD and then reinstall Catalina) everything works fine.
So if any of you doesn't have that much of data on their Mac just a few files to back up I'd definitely try a reinstall. Took my 3-4 hours and now it works again.
I am trying to delete an application in the /Applications folder on macOS High Sierra (I don't hink the exact OS really matters).
But I simply can not figure out, how to do so from a sandboxed app. In the Mac App Store there are a couple (in fact a lot) of apps that can do that.
When an app is selected, a prompt is shown where I can type in my password.
First I tried creating a helper utility and then calling SMJobBless. But after failing I noticed that this is not possible in a sandboxed app (kinda makes sense because you could completely bypass the sandbox?).
Then I tried to write an AppleScript. This really works fine, the prompt is shown and the file is either deleted or moved to the trash.
I had to add an entitlement:
com.apple.security.temporary-exception.apple-events
I have added co.apple.finder as a child node and like I said everything works fine. Unfortunately, this entitlement is not allowed in the Mac App Store (again, this makes sense).
Now my question is...how can I move a file to the trash (I do not need to delete it myself, it would be okay if the user had to empty the trash manually).
How do all those other apps do it?
Only way I can think of would be to open an NSOpenPanel, and get the user to select the application you want to delete. Not too many MAS-approved ways to poke through the sandbox beyond that.
For the next version of a NSDocument-based app, I am revising the document parameters, that is, the values in Info.plist > CFBundleDocumentTypes and UTExportedTypeDeclarations. Specifically, I am changing from a flat NSPersistentDocument to a document package (with the help of BSManagedDocument).
The revised app can create new documents, but they appear in Finder with a generic icon, and when I close such a new document and try to re-open it, -[NSDocumentController openDocumentWithContentsOfURL:display:completionHandler:]fails, creating an error in NSCocoaErrorDomain with code 256, description “newDoc.myExtension” could not be handled because MyApp cannot open files of this type, and failure reason MyApp cannot open files of this type.
I understand that there are several significant parameters CFBundleDocumentTypes and UTExportedTypeDeclarations, and these must all be correct or you get this error. In this case, they are correct. I've confirmed this by comparing the Info.plist in my built product with the Info.plist of a different but similar app that works.
I've also tried calling LSRegisterURL() with inUpdate = true from main(), but that did not help.
What might be wrong? I'm running in macOS 10.12.6, building with macOS 10.13 SDK and Xcode 9.
Apparently the problem is in updating the Launch Services database. I copied the new application, with the revised Info.plist, into /Applications, replacing an old version, then launched this copy once. After these two steps, document icons are now correct when I reopened a Finder window, and upon relaunching my new app, it can now reopen its own new documents without error.
UPDATE: Today (macOS 10.13 Beta 8) I had the same problem, but installing the corrected app into /Applications did not work. However, this time, rebuilding the Launch Services database by running the following command in Terminal, and then relaunching my app, did work:
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain u -domain s -domain l -v
A side effect of the above is that some apps will have generic icons in the dock and cmd-tab application switcher until relaunched.
I think that either Launch Services much prefers apps in /Applications over apps in Xcode's DerivedData folder, even if the latter is the only one currently running, or running apps from Xcode's DerivedData do not register at all, or both.
It seems from the documentation that calling LSRegisterURL() should have had the same effect, but apparently not.
I have an application bundle created with PyInstaller on OS X. If I double click the .app bundle in Finder, the application tries to launch, then terminates. No further information is given in the console, other than the application quit.
But if I launch the app executable from the terminal (i.e., ./Contents/MacOS/MyApplication, it works perfectly fine. This seems to be the same behavior experienced in this issue: OSX app built with python quits immediately if app bundle is executed from finder but runs fine from command line, but the marked solution there isn't particularly helpful.
I suspect this is indeed related to an environment or path issue. But I'm not sure how to fix it. Should something be specified in the info.plist file maybe? Any guidance would be greatly appreciated.
This is most likely due to a bad assumption about the working directory. When you launch from the Finder, the working directory may well be / (depends on OS X version), which is not writeable. If your app writes to the current working directory then you should probably set the working directory to somewhere sensible at startup.
Ok, so I am having a small problem. I have an .app file that was created by the Adobe Air converter. It works fine. However, when the .app file is zipped up on a CENT OS server the app no longer works. You can double click on the icon but the app just never launches.
The only weird thing that is being done by the server is that it is editing an xml file within the .app package, however, this .xml file doesn't even get loaded by the app until after it has launched so I can't see this being an issue?
I bet you (or the Adobe Air converter you used) code-signed your app package, in which case modifying the XML file (after it being built) would break things. I work on an app which requires frequent customization like this and the only way we're getting around it is to use a Macintosh (a MacMini) that's dedicated to building and code-signing unique versions.
The way to know what's going on is to look at your "Console.app" log, which should be logging some kind of error when you double click on your downloaded app.
Another thing you can do is (temporarily) disable the code on the web server that modifies the XML file and see if the downloaded app magically starts to work.