Do .dmg files need to be signed? - macos

I've packaged my mac application into a .dmg file, but when I mount the file and double click on the app I get this warning "MyApp is an application downloaded from the Internet. Are you sure you want to open it."
I don't want my app to look suspicious. I know that in Windows you need to sign your installer so the OS doesn't display the scary red stop icon and the "Unverified"/"Unknown" label, is it the same for OS X?

No, you will always get that notification the first time you start anything you downloaded. It's a flag set onto the files extended attributes.

Related

How to prevent the "XYZ would like to access files in your Downloads folder" message when an app opens files inside its own bundle?

I have an installer app that gets distributed inside of a notarized disk image. The app is a simple program that performs a few checks on the system and then launches the macOS installer to install a pkg that is contained with the app's bundle.
However, even though this app is inside a mounted disk image, and even though the file it's trying to open is inside its own signed and notarized bundle, it still triggers the "App would like to access files in your Downloads folder" if the dmg is located in the user's Downloads folder, which it almost always will be.
Is there any way to get this app to launch the installer without triggering this message? The entire point of the app is to try and make the installation process as smooth and seamless as possible. The explicit goal is that opening it will go directly into the mac installer with no warning messages, interruptions, or any other sort of dialog box that risks confusing or alarming the user.
Note: just distributing the pkg on its own is not an option, because the purpose of this app is to work around a bug in macOS's installer on Apple Silicon macs. The pkg is Intel only, and if I add a script to it that executes when the pkg opens, then it will confusingly display a warning message to the user twice, once when Installer.app opens as an arm64 process, and then again when it relaunches as an x86_64 process.
This is an annoyingly roundabout workaround, but I managed to do it using launchd.
The gist of the method is to create a plist file in the user's temporary folder specifying a launchd job that starts on demand and just calls /usr/bin/open to open the pkg file inside the application bundle, and then call launchctl to load it. Once the installer is open, remove the launchd job.

Why "macOS folder archive" doesn't get signed with install4j

I can't figure out why archive/macOS folder archive doesn't get signed by install4j even when it's instructed to "Sign macOS media files" in general settings. Looking into the logs during the build I do see that DMG gets signed.
The signing certificate is good because I've got another app signed without problems, the only difference is that media is installer/macOS folder. So it signs the DMG and doesn't sign the app folder inside? What's the point? I must be missing something.
I am trying to achieve a very simple flow for the user - click on dmg, drag the app archive to the Applications and click to run. No installers needed. It works great until the dmg gets downloaded from the internet, Mac decides that it's dangerous because there is no developer signature and fun begins... How do I make this signature with install4j?
Any help is greatly appreciated.
(install4j version is 6.1.6)
I am trying to achieve a very simple flow for the user - click on dmg, drag the >app archive to the Applications and click to run.
Then use the macOS single bundle archive and not the macOS folder installer.
So it signs the DMG and doesn't sign the app folder inside?
No, both the DMG and all generated launchers are signed by install4j for the macOS folder installer.
Note: For macOS 10.14, you will need install4j 7.0.6+ otherwise the signature is reported as invalid.
Update after discussion in the comments:
In your case, the executable is a shell script. For mach-o binaries, the codesign tool on macOS saves the signature directly inside the binary, for non-mach-o binaries, it saves extended HFS+ attributes of the file Info.plist. These extended attributes would not be picked up by install4j even if you build on macOS, they will be lost at runtime and the signature will be invalid.
I'm afraid that the only way forward is to use a generated launcher.

Mac .app file no longer working after being served by a webserver

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.

Why does my Firemonkey app open a terminal window on OSX but not on Win32?

I created a simple testbed app in Delphi XE2, and compiled both a Win32 and OSX version of the application.
I zipped up the OSX version, along with a copy of the libcgunwind dylib runtime file and copied this files to a Mac i have access to.
When I unzipped the file, the mac recognized my OSX application and I double clicked it.
This, in turn, opened up a terminal window for some unknown reason along with my simple app's form.
The application itself ran and behaved just fine, but I'm curious why a terminal window would open up on the Mac?
There is a free tool available for Delphi XE2 that will create the OSX deployment app bundle for you, from Windows, without the need for PAServer.
http://enesce.com/delphiosx_bundler
Check the readme for instructions.
IIRC this happens if you execute the binary directly instead via a bundle
Lazarus/FPC apps had the same problem. IIRC the directly executed binary also didn't get events under those circumstances, but those apps were Carbon based. That problem also went away when running via a bundle setup (which is pretty much a manifest, a few dirs and a symlink)
Your application needs to be run from the application bundle. If you run it directly, you'll get the side effect of seeing the terminal window with the command line that is running the application.
You'll want to read more about Application Bundles.
If you're using PAServer, after you run the program for the first time on the Mac, look in the following folder on the Mac for the application bundle:
/Users/[username]/Applications/Embarcadero/PAServer/scratch-dir/[profilename]
If your project is named Project1, you'll see an application bundle in that folder named Project1.
If you read the above wiki article, you'll know that Project1 has a "hidden" extension of .app, and the whole thing is really a folder with all of the required files to run the application.
To the Mac OS user, the application bundle appears as a single program file, complete with an icon. The user can double-click the application bundle to run the application, drag it to their dock, etc.
The application bundle will have the Delphi icon by default, but you can replace it with your own icon. On the Mac, simply right-click on the application bundle in Finder, and select Show Package Contents. In there, look in the Contents/Resources folder for the .icns file.
Use the Icon Composer application that was installed with XCode to create your .icns icon file from existing image files.
Peek around inside at the rest of the contents. You'll see the required dylib, your program file, and the Info.plist file, which is a text file with things like application IDs, signatures, and other important things.

Sharing iPhone Apps for the Simulator

iPhone Apps built for the simulator are stored here:
/Users/<username>/Library/Application Support/iPhone Simulator/User/Applications
Is it possible to copy the <GUID>.sb and <GUID> directory and install them on a different computer (with Development tools installed)?
This would be very useful for testing/demoing with out having to buy iPhones for all the managers and external clients.
I found a way that requires just a little more setup, but is much easier for non-developers:
Instructions for your users/testers:
Install Xcode following Apple's instructions
Double-click the attached application - the iPhone simulator will launch, install the app and start it automatically.
How to set it up:
Download and unzip (to a folder on your desktop or wherever) 'Simulator Bundler' from: http://github.com/landonf/simlaunch/downloads
Set your XCode build target to the required Simulator configuration (iPad/iPhone/which iOS version)
Do a 'Build and archive'
Find it: select 'Archived applications' in the Organizer, right click the relevant build, select "Reveal archived application in Finder"
Drag the application (yourAppName, no extension) onto the Simulator Bundler app
Done. This will create a self-contained Mac OS X yourAppDisplayName.app file in the same folder (with your app's icon as the icon) that you can stick up on an FTP server or email to your users/testers.
--
I think it's much neater/slicker than having to explain where to copy files, how to launch the simulator and so on.. And if anything gets messed up they can just uninstall via the familiar tap-and-hold + (x) gesture in the simulator UI, then double-click the app you sent them again.
You can also produce several of these packages changing the bundle identifier between builds, allowing them to be installed side by side in your testers' simulators; say for getting some user feedback on different UI designs, or configure one for Production and one for Staging/QA servers, so your content editors can check their changes before they go live or whatever..
The ability to reinstall the app from a desktop icon is also very convenient for localisation testing: launch the simulator, uninstall the app if present, set the required region format and language, double click the icon on your desktop, test; repeat for each required locale. (guarantees a fresh install each time, I've found that switching language with the app installed can result in all sorts of strange behaviour)
Yes, if you send those files to another person, and they put them into that directory, they can test the applications in the iPhone Simulator as well :)

Resources