Post not yet marked as solved
I ran across the following crash while using one of our apps.
The app crashes since the recent iOS 17 beta builds.
The code crashes when using valueForKey on an NSArray with objects that implement NSCopying.
like: [@[[Sample new]] valueForKey:@"copy"];
or: [[Sample new] valueForKey:@"copy"];
header:
@interface Sample : NSObject<NSCopying>
- (Sample *)copy;
- (Sample *)copyWithZone:(nullable NSZone *)zone;
@end
implementation:
@implementation Sample
- (Sample *)copy {
return [super copy];
}
- (Sample *)copyWithZone:(nullable NSZone *)zone {
return self;
}
@end
Any idea why this might be happening?
I have created a feedback too: FB12819891
Post not yet marked as solved
Hello!I have an app with a Safari app extension (not in the app store), signed with a Developer ID certificate and all works fine on macOS Mojave.When switching to macOS Catalina, the app now needs to be notarized to avoid the gatekeeper alert when starting the app.But when the app is successfully notarized, the Safari app extension does not show up any more in the Preferences page of Safari or when executing "pluginkit -mAvvv -p com.apple.Safari.extension".When using the version of the app without notarization, the extension shows up in Safari and works as expected (apart from the gatekeeper warning).I have tried some check on the notarized app without any errors:codesign --verify --verbose /Applications/___.app/Applications/___.app/: valid on disk/Applications/___.app/: satisfies its Designated Requirementcodesign -test-requirement="=notarized" --verify --verbose /Applications/___.app/Applications/___.app/: valid on disk/Applications/___.app/: satisfies its Designated Requirement/Applications/___.app/: explicit requirement satisfiedcodesign -test-requirement="=notarized" --verify --verbose /Applications/___.app/Contents/PlugIns/SafariExtension.appex/Applications/___.app/Contents/PlugIns/SafariExtension.appex: valid on disk/Applications/___.app/Contents/PlugIns/SafariExtension.appex: satisfies its Designated Requirement/Applications/___.app/: explicit requirement satisfiedxcrun stapler validate /Applications/___.appProcessing: /Applications/___.appThe validate action worked!spctl -a -vv /Applications/___.appsource=Notarized Developer IDorigin=Developer ID Application: ___ (___)I have no idea how to analyze/debug why the extension is not shown. Any help would be appreciated.The notarization log output shows some warnings that some executables part of the app have "hardened runtime" not enabled (as they are not built with Xcode). May this be a reason for this?Getting a log output for why the extension is not accepted would be very nice. But so far I have not found any documentation how to do this.Thank you and regards,Dominik
Post not yet marked as solved
Hello!I am using the accessibility API (AXUIElementCreateApplication, ...) to watch all opened documents within an application.For this I obtain the root element of the application via AXUIElementCreateApplication, iterating recursively through it's child windows (reading kAXChildrenAttribute, kAXWindowsAttribute and kAXMainWindowAttribute) and checking the unique path of the opened documents by reading the kAXDocumentAttribute of each window element (elements having the kAXRoleAttribute "AXWindow").This works pretty reliable and is supported by all document based applications (can simply be tested with TextEdit), however if I want to scan the application for a document window which has multiple documents opened in full screen mode (e.g. by clicking the green full screen icon in the document window's title bar, shifting the full screen window beside by pressing Ctrl + right arrow key and making another document window of that application full screen) not all document windows appear in the accessibility tree now.With the kAXMainWindowAttribute I can access the top level window, but if the application has multiple full screen windows, they are no more accessible. The kAXChildrenAttribute and kAXWindowsAttribute do not contain any full screen window. Even if the full screen windows are not "hidden", underlying documents which are not the main window are not accessible.If the observing application has still a retained handle (AXUIElementRef) to a window which is turned into full screen and then covered by another full screen document window of that application, the handle remains still valid and the window and it's kAXDocumentAttribute can still be accessed, but when starting a fresh iteration with AXUIElementCreateApplication (e.g. this is required when the observing application is restarted), there is no access.Furthermore if a document is opened in a tab (This can be done by e.g. opening multiple documents with TextEdit and then selecting "Window -> Merge All Windows" from the menu or opening a document with TextEdit, putting this window to full screen, and opening a second document with TextEdit, and now TextEdit will open the second document within a tab of the full screen window), the kAXDocumentAttribute cannot be accessed from documents which are not the main window but only tabbed. Only the label of the tab (kAXTitleAttribute of elements with "AXTabButton" sub role) can be obtained, but this is not unique, as multiple documents from different locations can have the same file name.As with full screen windows all retained AXUIElementRef handles remain still valid.A list of all documents could be obtained through the dock menu of the application, but there is no kAXDocumentAttribute which would identify a document distinctly and a distinction between open documents and suggestions from recently opened documents is difficult. And different applications use the doc menu in a different way.Using the AccessibilityInspector from Xcode reflects this observations.Has there anybody any ideas how to access the kAXDocumentAttribute in this cases?Or should this be seen as a bug of the accessibility API?Used macOS version: 10.14.6 MojaveThe problems are also existing in earlier versions of macOS.Regards,Dominik
Fabasoft.