Post not yet marked as solved
The crash log shows the exception type as SIGABRT and documentation.
indicates that the crash may arise from an uncaught exception.
Probably. Technically SIGABRT just means that some code within the process called abort, but the most common cause of that is an unhandled language exception.
Beyond that it’s hard to say what’s going on here based on the crash report snippet you posted. Can you post the full crash report? See Posting a Crash Report for advice on how to do that.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
So, there are two parts to this:
Why does it behave the way it does?
Why doesn’t Swift catch the problem?
The answer to the second is that the current Swift compiler only has limited concurrency checking and, even if you enable all the checks, it’s not very good about checking global variables (which is what App.counter is because it’s static).
If you compile your code with Xcode 14.0b3 and enable the Strict Concurrency Checking build setting (set SWIFT_STRICT_CONCURRENCY to complete), you’ll get a bunch of concurrency warnings.
As to why it works the way that it does, the key thing to note is that an async function can run in any context unless it’s explicitly isolated to an actor. Your increaseCounter() and decreaseCounter() functions are static, and so are effectively the same as free functions. These are not isolated to an actor and thus there’s nothing stopping them from running in parallel.
If you want to force them to run on the main actor, you can add the @MainActor attribute (which you’ve already tested) or move them, and counter, to an actor, removing the static for all three, and then annotate that with @MainActor.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
As documented in the open man page, open does pass along environment variables:
Opened applications inherit environment variables just as if you had
launched the application directly through its full path.
This isn’t working for you because Terminal is already running. By default open will reuse the existing instance of Terminal and there’s no way for open to set environment variables in already-running processes.
To see this work as you expect, start a second instance of Terminal by passing in the -n flag. However, that’s probably not what you want to do in your real setup because users get confused if multiple instances of Terminal are open (I got confused just testing this! :-).
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
There is no other difference we found. we just know that its fresh
partition where its failing.
OK. My advice on this front is that you test on a VM. You can then restore you VM to a ‘clean’ snapshot between each test. That ensures that you’re always starting from a fresh Mac, one that’s never seen your product before.
I go into this more in Testing a Notarised Product.
OS internally checks notarisation status of extension using Apple Server
Hitting the network is only necessary if you haven’t stapled the notarised ticket onto your product.
IMPORTANT I recommend that you notarise your outmost container and then staple to the outmost container that supports stapling. For specific advice, see Packaging Mac Software for Distribution.
so is there any server that we can check its ping-able/reachable
You can use stapler to do this, with the validate subcommand. If you add the -v option, stapler will show details about what it’s doing behind the scenes. See the stapler man page for more details.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
What API are you using for WebSocket? NSURLSession? Network framework? Or perhaps you’re doing this from within Safari? Or a web view?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
What could cause the deployment to fail like that?
Many things. You may find specific hints as to what’s going wrong in the system log. For advice on how to view that, see Your Friend the System Log.
If that doesn’t turn up anything useful, I have two further hints:
Check that the code is signed for deployment on modern systems. See Using the Latest Code Signature Format.
Check that your provisioning profile allows this exception. For details about what’s in a provisioning profile, see TN3125 Inside Code Signing: Provisioning Profiles.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
If you want to report a bug about this, please do that in Feedback Assistant, then post your bug number here, just for the record.
Taking a step back, why are you building a command-line tool without signing it? Unsigned code is pretty unusual on modern versions of macOS (notably, it’s not supported at all on Apple silicon). IMO the only good reason for building unsigned code is that you’re going to embed the code in some other code that is itself signed. Is that the case here?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
my application is allowed to open TCP listen sockets and send UDP
broadcast packets on the local wifi network WITHOUT any permission
requirement (not even "Local Network")!
Opening TCP listening sockets is not an operation protected by LNP. See LNP FAQ-2.
Sending UDP broadcast packets should trigger LNP, and it certainly did the last time I tried it [1]. Are you sure those packets are going out on the ‘wire’?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Which, admittedly, was a while ago, because LNP was a really hot issue back in the iOS 14 timeframe but has quietened down a lot recently.
Post not yet marked as solved
No Crash stack logs
There’s a variety of potential causes for this. Please post a complete crash report, per the instructions in Posting a Crash Report.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
Is that known issue or something that only happens to me? :)
Does that matter (-:
Seriously though, the purpose of testing on beta releases is to find weird problems like this, so it’s worth filing a bug about this regardless of the answer. Make sure to include a sysdiagnose log taken immediately after reproducing the problem, because it’s likely that multiple processes are involved in this deadlock.
Please post your bug number, just for the record.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
While Gualtier Malde is correct that this shouldn’t have changed during the iOS 16 beta upgrade, I want to caution you about this:
After users upgraded iOS16 beta, some users' sandbox database cannot
opening. After checking code logic, it is found that the encrypted key
of the database has changed after upgraded iOS 16.
Do not store valuable user data such that identifierForVendor is the only way to recover that data. The exact handling of identifierForVendor has changed in the past and it’s possible that it might change in the future. If you use it as the only encryption key for your user’s data, you open yourself up to problems like this.
I’ve worked with other developers in the past who’ve had exactly this problem, and the end result was that all their users lost all their data )-: I’m hoping that this won’t happen here, but your current design makes you extremely vulnerable to such problems and I strongly recommend that you change your design.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
One potential workaround is to add the -v flag, which causes otool to
print the property list as text.
I just discovered another potential workaround here, namely to use segedit with extract the __TEXT / __info_plist section. This is not without its complications though. See the segedit man page for the details.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
I agree with ssmith_c here: Life is a lot simpler, for you and your users, if you ship a universal app. This is especially important in managed environments, where the site manager may install the app in one place and then different users, some on Intel and some on Apple silicon, end up running it from there.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
or Bundle.main.bundlePath for execution path.
You have to be careful about this because Bundle contains a lot of complex logic and so the path you get back can change depending on the file system hierarchy in which your tool is placed.
My go-to API for this is _NSGetExecutablePath. Admittedly, this isn’t easy to call from Swift:
func mainExecutable() -> URL {
var buf = [CChar](repeating: 0, count: Int(MAXPATHLEN))
var bufSize = UInt32(buf.count)
let success = _NSGetExecutablePath(&buf, &bufSize) >= 0
if !success {
buf = [CChar](repeating: 0, count: Int(bufSize))
let success2 = _NSGetExecutablePath(&buf, &bufSize) >= 0
guard success2 else { fatalError() }
}
return URL(fileURLWithFileSystemRepresentation: buf, isDirectory: false, relativeTo: nil)
}
However, even this isn’t with its challenges. To quote the doc comment in <mach-o/dyld.h>:
Note that _NSGetExecutablePath will return "a path" to the
executable not a "real path" to the executable. That is the path may
be a symbolic link and not the real file.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Problems like this are almost always caused by a misunderstanding about how the keychain manages uniqueness. This varies by keychain item class. For the details, see the errSecDuplicateItem documentation.
For a generic password the key attributes are kSecAttrService and kSecAttrAccount. I generally recommend that you set both of these when you save an item to the keychain and only include these (oh, and kSecClass) when you query for that item.
The errSecDuplicateItem you’re geting from your storeItem(…) method is because an item exists with kSecAttrAccount for that user name and kSecAttrService empty. You then try to delete the item and that fails with errSecItemNotFound because one of the other attributes in the query dictionary returned by getDeletionDictionaryForTag(…) doesn’t match the item that’s currently in the keychain.
Does your app support multiple simultaneous accounts? If not, I typically hardcode kSecAttrService and kSecAttrAccount and store the user name elsewhere (in some other attribute). That means that the query dictionary is just:
let query: NSDictionary = [
kSecClass: kSecClassGenericPassword,
kSecAttrService: … fixed value …,
kSecAttrAccount: … fixed value …,
kSecReturnData: true,
]
and it’s hard to go wrong.
If your app supports multiple accounts then it makes sense to use kSecAttrAccount to store the account name. In that case your query dictionary would look like this:
let accountName: String = …
let query: NSDictionary = [
kSecClass: kSecClassGenericPassword,
kSecAttrService: … fixed value …,
kSecAttrAccount: accountName,
kSecReturnData: true,
]
if you know the account name in advance, or:
let query: NSDictionary = [
kSecClass: kSecClassGenericPassword,
kSecAttrService: … fixed value …,
kSecReturnAttributes: true,
]
when querying for all known accounts.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
