Post not yet marked as solved
I mainly just want to avoid accidentally violating the ToS or
something
Again, whose terms of service are you worried about here? AFAICT there are four parties involved:
Apple
You, the app developer
Your user
Their credit card
All (except the user) have terms of service.
As an engineer, not a lawyer, I can’t help you with any of these, other than to point out that the Apple side of this is covered by your legal agreements with Apple and the App Store Review Guidelines
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
This is how to activate app using AppleScript.
OK. Does that leak if you test it in isolation? That is, substituting it for step 2 in the steps 1 through 7 of my earlier post.
ps Using string substitution to build an AppleScript is extremely risky. For example, if the application name contains a weird character, like a " or a \, bad things will happen. I recommend that you pass these parameters to your script using an Apple event. You do this with the -executeAppleEvent:error: method. For an example of this, see the appendix in BSD Privilege Escalation on macOS (it’s in Swift but it’s not too hard to translate it to Objective-C).
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
I recommend that you disable your third-party crash reporter and attempt to get an Apple crash report for this. When debugging gnarly problems, you really need a crash report that you can rely on [1].
But how do I figure out which line actually causes this?
By symbolicating your crash report.
I cannot simply symbolicate the crash (I assume) since this address is
from the heap where the closure was allocated for that specific call.
Your logic is flawed here. A closure is allocated from the heap but all the code executed by the closure is in your executable’s __TEXT segment [2]. Thus, you should be able to symbolicate this. With an Apple crash report the standard symbolication methods should deal with this. If they don’t, I’m happy to help you out with that.
If your third-party crash report isn’t symbolicating properly, you need to escalate this with its vendor. Alternatively, you can manually symbolicate using the process described in the Symbolicate the Crash Report with the Command Line section of Adding Identifiable Symbol Names to a Crash Report. This assumes that your third-party crash report contains an equivalent to the Binary Images section of an Apple crash report.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] For an explanation as to why you can’t rely on third-party crash reports, see Implementing Your Own Crash Reporter.
[2] Allocating code in the heap is not possible on iOS due to security restrictions.
Post not yet marked as solved
I’d like to clarify what’s going on here. Reading your post it seems like:
You have built and notarised an app containing an Endpoint Security system extension.
On some macOS 12.4 systems your ES sysex fails to load with OSSystemExtensionErrorCodeSignatureInvalid.
On other systems it loads just fine.
Is that right? If so, how do the failing systems differ from the working systems? You’ve already said that the failing systems include both Intel and Apple silicon machines. Are these other differences? Are the working systems also running macOS 12.4? Do all the systems have SIP enabled?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
I checked yesterday(07.18) and it doesn't reproduce.
Cool.
If it is reproduced again, we will report back.
Thanks.
The best thing to do in that case is to reproduce the problem with verbose logging enabled (via --verbose) and then file a bug with that log. Once you do that, post your bug number here so that I see it.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
On the iOS side, working on local networks requires the Local Network privilege. For more background on that, see the Local Network Privacy FAQ.
macOS does not support the Local Network privilege, and neither does the iOS simulator. So I wouldn’t expect to see a local network prompt there. However, macOS does support the application firewall (System Preferences > Security & Privacy > Firewall), which may present authorisation prompts if your app attempts to listen for incoming connections.
Are you perhaps mixing these things up?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
I would still need something to support continuous observation of any
KVO from a background thread.
KVO works fine from a background thread. The fundamental issue here is that you’re trying to use AppKit from a background thread, and that won’t end well. My general advice is that you run your script runtime (Python in this case) on the background thread and run AppKit on the main thread. My experience is that script runtimes require that all access be confined to a single thread but don’t require that this be the main thread. In contrast, AppKit really wants to be run on the main thread.
Another option here is to fork a child process, start AppKit on its main thread, and then pass notifications back to the parent process.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
here is crash report
That’s not the full crash report )-:
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
but from the answer it is unclear to me whether Apple is planning to
fix this
This is definitely our bug to fix. That status means that we know what’s gone wrong but the fix isn’t in any currently seeded release. You should be notified when that changes, that is, when the fix makes it into a seed.
How should we handle IPv6 link-local addresses in iOS 16?
Use Bonjour? (-:
Seriously though, Bonjour makes this all much better because the remote peer has a mDNS host name, and you can pass that to URL rather than monkey around with IP addresses.
But, yeah, I realise that you’re hands are tied by the accessory only supporting SSDP )-:
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
I couldn't test it before not having an iPhone or a mac!
Realistically, this is not a valid development strategy. While you may be able to get past this problem, you will eventually run into some issue that requires you to test on real hardware. I recommend that you raise this issue with whoever is paying the bills here.
Can someone symbolicate it forme me please ?
No, sorry.
At looked at one of your crash reports and it appears to be slightly munged. Specifically, a JSON-style crash report typically contains two JSON dictionaries:
A header, which is flattened to a single line
The main crash report payload
In your case the header is split across multiple lines. Once I joined that back into a single line, I was able to parse the crash report in Xcode. It shows this:
Exception Type: EXC_CRASH (SIGABRT)
which indicates that your app crashed itself by calling abort, and this:
Last Exception Backtrace:
0 CoreFoundation … __exceptionPreprocess + 216
1 libobjc.A.dylib … objc_exception_throw + 56
2 CoreFoundation … __CFDictionaryCreateGeneric + 0
3 FirebaseAuth … +[FIRAuth auth] + 92
4 Runner … 0x102670000 + 803712
5 Flutter … 0x103d18000 + 127904
6 GoogleUtilities … -[GULAppDelegateSwizzler application:donor_didRegisterForRemoteNotificationsWithDeviceToken:] + 264
7 UIKitCore … __63-[UIApplication pushRegistry:didUpdatePushCredentials:forType:]_block_invoke + 108
8 libdispatch.dylib … _dispatch_call_block_and_release + 24
which might offer some hints as to why it did that.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
Exception Type: EXC_CRASH (SIGABRT)
This indicates that your app crashed itself by calling abort. Now look at the backtrace of the crashing thread:
Thread 0 Crashed:
0 libsystem_kernel.dylib … __pthread_kill + 8 (:-1)
1 libsystem_pthread.dylib … pthread_kill + 208 (pthread.c:1668)
2 libsystem_c.dylib … __abort + 124 (abort.c:155)
3 libsystem_c.dylib … vsnprintf_l + 0 (vsnprintf.c:89)
4 QrApp.iOS … xamarin_find_protocol_wrapper_type + 0
5 QrApp.iOS … 0x102eac000 + 31322216
…
18 QrApp.iOS … 0x102eac000 + 25268
19 Foundation … __NSThreadPerformPerform + 164 (NSThread.m:1058)
It looks like your code (frame 5) called a method in your third-party runtime (frame 4) that caused it to call abort.
It’s hard to say what it’s complaining about. I recommend that you escalate this via the support channel for your third-party runtime. Specifically, you should try to see if there’s a way to:
Symbolicate frames 18 through 5 in your backtrace
Capture the error associated with this failure
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
Allowed by who?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
the file to be moved into the folder gets a "copy" extension to the
filename
That behaviour is built in to the Finder and there’s no way to override it. What you can do is to check to see if a file with that name exists and then move it out of the way.
tell application "Finder"
exists folder "Documents" of home
-- true
exists folder "Blibble" of home
-- false
end tell
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
This is how to activate app using AppleScript.
I’m sorry but I can’t read your post. Please put the code in a code block. For this and other tips, see Quinn’s Top Ten DevForums Tips.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
Your app can talk to your ES client sysex using XPC. See the EndpointSecurity man page (in section 7) for the details. If your app opens an XPC connection to the ES client sysex and sends at least one request over that connection, the connection will fail with the interrupted status if your ES client terminates.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"