One of our customers is having a problem finding our macOS app in the app store on an M1 system. It just doesn't show up, and if they use a direct link that I've sent them it shows a "not compatible with your system" message.
The app is currently compiled for Intel. We were missing some compatible CocoaPods & libraries for a universal build until just recently.
We know that it runs fine under Rosetta 2.
When they look at the list of compatible systems it says:
Requires
a Mac running macOS 10.15 or
later with an Intel 64-bit processor or
additional software not available in your
country or region.
They're on macOS Monterey, so I can't think of what the "additional software" could be except for Rosetta 2.
They also say that they already have Rosetta 2 installed, and I haven't seen the App Store block a download because of missing Rosetta 2.
How can I check to see that they do, in fact, have Rosetta 2 installed?
Has anyone seen the App Store block a download because of Rosetta 2?
Any ideas what could be causing this other than Rosetta 2?
The customer's region is New York, USA, so "not available in your
country or region." is unlikely.
When I do a search from my M1 mini the app shows up just fine.
Post
Replies
Boosts
Views
Activity
I'm using a Mac Mini as a Jenkins agent, which we use to run our Xcode tests on physical iOS devices. It's configured for remote access with SSH & screen sharing with VNC. Every few days they start failing completely. Sometimes one of them is up a bit longer, but more usually they're both down.
If I look in the GUI it says it's running. The correct ports are listening.
In Console I can see that the sshd process exits with 255 the instant it's started, but I haven't been able to get anything more specific.
I've found that I can get SSH & VNC access back with
launchctl bootout system/<svc name>
launchctl disable system/<svc name>
launchctl enable system/<svc name>
launchctl bootstrap system <plist file name>
The problem is that I can't tell from the remote device that it's not accessible by SSH/VNC. The different interfaces say that sure, everything's fine.
When I do a launchctl print there are some differences between the non-working and working versions. I don't know if these are actual indicators that it's down, or artifacts of the way I restarted them. The differences are consistent for both VNC & SSH:
Not working but apparently running:
path = (submitted by smd.215)
submitted job. ignore execute allowed.
system service = 0
Working after launchctl stop/restart:
path = /System/Library/LaunchDaemons/<plist file>
system service = 1
So, a few questions:
Has anyone else seen this?
Is there some way to get more error information about why sshd is exiting in the logs/console?
Is there a way to detect that sshd is failing, even though there's no system log entry for the failure, and the various interfaces show that everything's fine?
What's the cleanest way to tell the system to restart remote access every day just in case it can't be identified any other way?