Thank you for the explanation. That clears-up some of my misunderstanding. After calming-down decided to rearrange the code and create a basic Linux .tar.gz with an embedded JRE for macOS. That will allow older Macs to use the software without building the project themselves, which will always work. IF enough users want a DMG so it can be installed on newer Macs, and donate the necessary funds or hardware, I may come back to this. And discovered another potential approach of using an Amazon EC2 Mac instance to build and test ELS on the latest macOS. Developing on this old Macbook Pro, then building on EC2 might keep it within their "free tier". Other than the certificate and DMG it looks and behaves like a real Mac app ... the Corionis ELS project: https://corionis.github.io/ELS

As I mentioned early-on in our discussions I have a Macbook Pro 13" Retina Late 2013. 2.8 GHz running Big Sur and added a Thundebolt dock and other goodies. Just read that Apple obsoleted the signing tools on 1 Nov 2023. The new tools require Monterey ... that is not supported on this Macbook Pro due to Apple's unethical forced obsolescence of hardware. I started this endeavor right when the tools were obsoleted. So I've wasted a lot of money and almost 2 months of work for NOTHING. I have absolutely NO intention of buying a new computer to give away software because of Apple's sheer greed. Sure wish you would have said something a few weeks ago. I will be deleting this developer account in a few days and attempting to sell this piece of shit. Will never have anything to do with Apple crap ever again, and will make sure my children, grandchildren, friends and anybody I talk to never touch any locked-in, Big Brother, planned obsolescence utter garbage from your company. EVER! Sorry for wasting your time. Apple doesn't deserve you.

After investing a good bit of money in a Mac and spending weeks getting my eight-year old application to look and behave like a "real" Mac app I have decided to back-burner the idea of supporting macOS. Thanks for those links. Guess I should have spent time investigating Apple's policies and procedures before delving into this. Had assumed it was a straight-forward proposition but I was woefully wrong. At this point I would have to rework my updater - that works everywhere else - because of Apple's procedures. And then pay to proceed. Correct me if I'm wrong but, from reading here and on other forums it seems that even after going through it all there is no guarantee my application would be "allowed". Apple reviews and evaluates applications before notarizing the required certificate. If Apple doesn't like the app for whatever reason they can deny it. Is that correct? Thanks again for your time.

Have gotten passed that 127.0.0.1 problem. Added the .app to Firewall Options. Now encountering the "Do you want the application to accept incoming network connections?" - every time it's run. Tried: codesign --force --deep --sign - /Applications/the.app but it still appears. Because I'm behind my own custom firewall have disabled the on-box firewall for now. Now this, from what I've read, does involve proper code signing. Is that correct?

Details: hostname returns correct name host using that name returns the correct IP address ping from another system using the name works - so that IP is being used by macOS However: Configuration of my software uses that IP address, not name Software in listener mode is forced to 127.0.0.1 Happens when installed and when executed from .class files in the IDE debugger What's the prescribed combination to make it work? This is the weirdest behavior I've ever seen in networking since I wrote assembly language device drivers for Intel Ethernet cards and developed software for Cisco switches.

Noted. This is a Java 11 application using java.net.* classes at the socket level for one protocol, and Apache Mina for sftp. The communications code has been working in production for years. How does one detect sandboxing? It fails because of 127.0.0.1 both in the IDE debugger and when installed. In the debugger it's running from .class files - would not think that would be sandboxed, unless the entire IDE is. Why is macOS doing this? What is the logic? How do I get past these issues that are not a problem with other operating systems? Have been working to determine whether an Apple implementation is viable. These things are quite discouraging and certainly make that difficult. Is this a matter of an Apple Developer ID, signing certificate, or other Apple policy or procedure that I need to perform so the IDE and my software are able to operate normally?? Was hoping to release a Beta of my version 4.0 yet this year. One last question: Does Apple evaluate (Open Source) applications to decide whether to allow them to be run? That is, if I sign-up, pay the fee and follow Apple procedures can it potentially be blocked? Is there anything written about how those decisions are made?? I'm sure you can understand not wanting to waste further time, effort or money. Once again, thank you for your time.

Still can't make it work outside the system. Guidance on what is required to proceed requested.

One last question if you please ... I'm using a Macbook Pro 13" Retina Late 2013 with Big Sur 11.7.10 which is losing support the end of this month. If I decide to proceed with the Developer program and paying the annual fee ... will the DMG builds from this computer become invalid, i.e. will I have to buy a newer Mac to continue building and signing deliverables? Thanks again for your time.

A related question -- upon further testing of the application I cannot reach it from another system to test cross-platform interoperability when run in client/server mode. It will only use 127.0.0.1 no matter which technique is used to executed it - even in the IDE debugger. And it changes the listener port. Why does macOS do that? Is there a setting or something to change that behavior? This makes testing cross-platform interoperability impossible.

Will do. Thanks for the link. So you agree, given the behavior of the code, that macOS security requirements must be met for this to work correctly, as opposed to there being a bug? Must admit I have difficulty with spending money for an application that is Open Source and free. Would guess that reduces the available free software for Apples. Thanks again for your time. Will come back to this once it's working and report.

Have run a series of tests with this updated Java 11 setup. It seems it now fails because the original software, the updater, and the update itself are being downloaded from GitHub. That is further supported by getting an error when it is first installed. Getting past that requires trying 2-3 times with right-click Open on the .app. Works end-to-end when DMG files are installed from local, and copied from local instead of downloaded during an "update". The downloaded updater cannot be mounted with exception: Cannot run program "/usr/bin/hdiutil": error=316, posix_spawn failed Found this explanation: error 316 smInitStatVErr: The InitStatusV field was negative after primary or secondary init Have no idea what that means. A copy of the mount command works when executed by hand. When updater is mounted by hand and executed it cannot mount the update after download, same exception. In both cases the updater cannot restart the .app with exception: java.io.IOException: Cannot run program "/usr/bin/open" (in directory "/Applications/ELS.app"): error=2, No such file or directory A copy of the open command works when executed by hand. Again, see #1. What is Gatekeeper's role in all of this? Seems it's sandboxing or something and not allowing system-level access to commands. Is there a better procedure for applying updates to an .app? Am I down to figuring-out how the get and use a signing certificate and whatever "notarize" is?

Updated everything to Java 11. Required minor code changes. hdiutil attach of the downloaded update still fails. Patterns and error codes are different. Will assemble a set of results and report tomorrow. (( btw - using ELS-Navigator, obviously not my name, because I'm old and hope to pass this project to others. So have the GitHub site, etc. setup to make the transition easier ))

If you temporarily modify your code to run hdiutil with no arguments, what do you see? Nothing at all with hdiutil help. I'm not capturing stderr so that may be why. No arguments returns a 1 error code whereas hdiutil help returns 0. That’s open source, right? Correct. See: https://openjdk.org/. I choose to not play Larry Elison's (Oracle) games. Status Your mention of Posix sent me down a different path. I neglected to mention I'm using JDK 8. That seems to be a problem with System.getRuntime().exec() that in JDK 8 uses fork() instead of posix_spawn(). After a great of deal testing and gyration I dropped JDK 11 into the Updater build and it appeared to work. However my build process originates in Linux. So to fully test this notion I have to upgrade Linux, Windows and Mac to JDK/JRE 11 and make some code changes related to Collection sorting. Am in the process of doing that now. Will report findings and solution if this works. A Note I will have further questions. In particular now, when going through the full process of building a deployment, uploading to GitHub. Then downloading and installing the base Main .app I receive a macOS dialog about not being able to verify the author and it not allowing the application to be executed. After 2-3 attempts it adds a button for "Run anyway". Being new to macOS is that common practice? Will I ultimately need to sign-up, pay, and get a certificate to sign this? I'm running Big Sur and am not familiar with the latest macOS conventions or security requirements. Would like to support all active macOS systems, again given the nature of this application (trying not to expound on that). Thank You! Once again, thank you for your time and effort. These are the last stumbling blocks to releasing a Beta of ELS after over 2 years of work on version 4.0 adding the desktop appliication and about 50K lines of code. (( I couldn't do your job that you are very good at, not enough patience :grin: Hazzah Mighty Quinn the Eskimo! Oddly, I was called that back in the '60s-'70s when I was a lead player in (you never heard of) Mid-West rock bands. Respects. ))

Thank you for the reply. ERROR 12/10/2023 11:11:05.362 Process failed: /usr/bin/hdiutil attach /var/folders/jv/bf5sm5951ylg9wts7tvpzhvh0000gp/T/ELS_Updater/ELS-4.0.0-development-2312081735.dmg -mountroot /var/folders/jv/bf5sm5951ylg9wts7tvpzhvh0000gp/T/ELS_Updater java.io.IOException: Cannot run program "/usr/bin/hdiutil": error=316, spawn failed Have not been able to find a detailed description of error 316. The process uses the system temp directory retrieved with Java System.getProperty("java.io.tmpdir") Both the Main .app and updater have an embedded OpenJDK JRE. The DMGs are built with DMG Canvas, https://www.araelium.com/dmgcanvas. Both programs are launched using a binary Java launcher from DMG Canvas. This is happening in the updater that was just downloaded and attached, after it downloads the update. The thread waits 2.5 seconds for the download to settle. Then it attempts to attach the update DMG. Three attempts are made separated by 1.5 seconds Also happens if the updater is executed manually. The hdiutil attach command line works when executed by hand. It also fails to restart the Main .app with an error=2 No such file or directory. That error is incorrect, the file and directory exist. The open command line works when executed by hand. The entire updater process works when executed locally in a debugger (IntelliJ) executing the commands one line at a time. That is why diagnosing this has been particularly difficult. My only guess is there are nuances to macOS I do not know yet. What is macOS doing in this mix, e.g. scanning the DMG? Are there security issues? Thank you for your time and effort. This one isn't easy.

Thank you for the great information. Just installed the Xcode CommandLineTools. The signing and notarization raises another question: If done with Xcode 14 tools is the result backward compatible with older macOS versions? Or will I need to produce different builds for different eras of macOS? As mentioned I am supporting older systems deliberately due to the nature of this application. Have discovered a potential combination. Test on this macOS 11, and sign and notarize here for as long as that's supported. When the tech changes beyond macOS 11 use a free account on Amazon AWS EC2 that offers the latest macOS, e.g. Sonoma 14. Test and do the signing and notarization there. Do not want to buy a Mac to give away free software. The "after the end-of-support in December 2023" comment shows my lack of familiarity with Apple. Updates for macOS 11 end in Dec. '23, next month. Didn't know if that would invalidate anything signed and notarized on this box. Thanks again for your time.