User Profile

I am using M1 & Xcode 15 and seeing the same... Using MacCatalyst If I submit to App Store for review in this condition what will happen? When I archive and distribute I only see the iOS application in AppStoreConnect... Do I need to submit a different binary to the Mac App Store? How will Mac users find my app

I am also experiencing this also in Xcode 15.0 (15A240d) on macOS Sonoma 14.0 (23A344) Running on M1Pro This a showstopper as I can no longer compile the app! Building for 'macCatalyst', but linking in dylib (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa.tbd) built for 'macOS' Building for 'macCatalyst', but linking in dylib (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL.tbd) built for 'macOS'

In the event that anyone else is interested in this matter: I have reached the conclusion that Action Extensions are limited to plain text. The Extension ActivationRule (supportsText) while not declarative is certainly suggestive. I found no means by which the extensionItemProviders would provide anything but plain-text. If anyone can supply evidence to contradict this conclusion PLEASE provide such in this thread.

Quinn; Thanks for your reply. Yeah Numbers works somewhat better but there are issues…. First I don’t have any need for the actual file to be returned via AppleScript.   I cannot predict how large a given file might be… So using Numbers file property of the document object, if I return only the POSIX path of the file object - I do get different behavior than with the returned path string from TextEdit.. My app takes the AppleScript result and constructs a custom attributedString that embeds the fileURL… When the user clicks on this attributedString (from Numbers) in the app’s main textView, I don’t get the error: [sandbox] Sandbox extension creation failed: client lacks entitlements? for path: Instead a Finder view opens to the enclosing folder without any complaining in the console - better yes, but not what I expect! I expected the file to actually open… But this ‘enclosing folder’ behavior is something I observe with a number of different ‘click on link’ actions - it seems that the ’System’ is forcing the user to perform the specific action to open a file rather that performing that open when the user only implies ‘open that file’… The user can build a collection of these text selection actions - the main attributes are stored in a custom CoreData repo. The use of CoreData is another reason why returning the file is not the correct result - I don’t want to store randomly large files in CoreData when all I want is a fileURL…. When I quit and relaunch the app, clicking on the attributedString results in the same Finder behavior but now the error mention above is shown in the Console. So the sandbox permission is very short lived - it only lasts for the current session…. From my perspective this is a limitation of the sandbox - If the user correctly asked me to access a file - why does that permission not persist if none of the security constraints have changed? Sure I do understand that there are issues -  but I am trying to articulate the limitations I experience in app development… So the whole POSIX thing above let to experimentation with the AppleScript in TextEdit. On the whole I don’t find a better solution than simply returning the path string and using it in the attributedString mentioned above. In this case, the click action will throw this error to the console but will also open the enclosing folder as above. The user’s experience is identical to what happens with the file object from the Numbers script….

Quinn; Thanks for this response. Also thank you for your long standing service to the developer community!! I wish there were a dozen of you. The URL is established by simply asking the active app for its current document. First recall that I have the app level entitlement: com.apple.security.files.user-selected.read-write On launch my app becomes an observer of 'externalApplicationDidActivate' et al - in this fashion my app is aware of the active app. When the service is invoked my app may fire a compiled AppleScript. These AppleScripts targets (~25) are each approved with an entitlement (com.apple.security.temporary-exception.apple-events) as well as each of these targets being approved by the user using the 'AEDeterminePermissionToAutomateTarget' mechanism These scripts are about as simple as can be; an example is shown below. I suppose that this fits the 'constructed internally' paradigm you reference above but I submit that it complies fully with the 'System' - I don't see how I can make it more fully comply with the 'System'. If you are aware of a better mechanism - I am all ears! So in essence the user has expressly asked my app to process a text string from a given app that my app has ensured that the system understands that my app will interact with.. Why under these circumstances are the results of a valid AppleScript from an approved app not considered as supplied by the 'System'? Any thoughts you might have will be fully considered! Thanks Again for your time and your patience over many years! Steve tell application "TextEdit" try set documentName to name of document 1 set documentPath to (path of document 1 as string) if ((documentPath is missing value) or (length of documentPath is 0)) then set documentPath to "unsaved document" end if set theResult to {|url|:documentPath, title:documentName} on error errMsg number errNum set theResult to {title:("Error" & errNum as text), |url|:errMsg} end try end tell return (theResult as record)

Done. FB9964644

the answer is embedded in the exception text "...Key path: count". I had somehow turned On a xib binding to "mutA2.count". Removing this cleared up the matter

Etresoft; Thanks for contributing to this discussion and filing a bug report. You said: "...If this is really a Safari problem, then my suggestion would be to add HTML to your data types. RTF is pretty ubiquitous on macOS, but isn't the future. There is no guarantee that new code is going to support RTF like it has in the past. It does still say "NeXT", after all...." So the answer is provided in my earlier log. Safari does NOT provide html to a service! For extra credit I DID enhance my app to acquire html data but unsurprisingly it is null. If you look at the log you will see that the "pboard.dataTypes" reported in the service entry point are: "public.rtf",     "NeXT Rich Text Format v1.0 pasteboard type",     "public.utf8-plain-text",     NSStringPboardType,     "com.apple.flat-rtfd",     "NeXT RTFD pasteboard type",     "public.utf16-external-plain-text",     "CorePasteboardFlavorType 0x75743136" So there is clearly a bug here. Safari reports "public.rtf" but does not provide that data to the service!

Hey TyngJJ & Etresoft! Thank-you both for your help and thoughts here!! I REALLY appreciate it! So the NSService 3 SendTypes are: 'com.apple.flat-rtfd', 'public-rtf', and 'public.plain-text' These have not changed over the course of time but the service entry point results have changed. So I took the app to Big Sur to compare with Etresoft's findings. At this point it seems to be application related... Safari is NOT providing rtf in the service on either Calatina or Big Sur. Here's some Big Sur logging from the service entry point shown earlier when the text selection is RTF First you see Text Edit then Safari.... So, Etresoft if you are still listening and inclined please test with using Safari as the source application which is providing an rtf text selection.... TEXTEDIT * 2020-10-09 13:27:56.621448-0700  - BID:com.apple.TextEdit 2020-10-09 13:27:56.621599-0700  - pboard:(     "public.utf8-plain-text",     NSStringPboardType,     "public.rtf",     "NeXT Rich Text Format v1.0 pasteboard type",     "public.utf16-external-plain-text",     "CorePasteboardFlavorType 0x75743136" ) 2020-10-09 13:27:56.621651-0700  - pboard RTFD:(null) 2020-10-09 13:27:56.622996-0700  - pboard RTF:{length = 2131, bytes = 0x7b5c7274 66315c61 6e73695c 616e7369 ... 49207365 6e64207d } 2020-10-09 13:27:56.623128-0700  - pboard public.rtf:{length = 2131, bytes = 0x7b5c7274 66315c61 6e73695c 616e7369 ... 49207365 6e64207d } 2020-10-09 13:27:56.623595-0700  - pboard String:{length = 716, bytes = 0x0909596f 75206e65 65642074 6f206564 ... 20492073 656e6420 } 2020-10-09 13:27:56.623717-0700  - [pboard pasteboardItems]:(     "<NSPasteboardItem: 0x600000eb64c0>" ) 2020-10-09 13:27:56.623800-0700  - pasteboardItem[0]:(     "public.utf8-plain-text",     "public.rtf",     "public.utf16-external-plain-text" ) 2020-10-09 13:27:56.623901-0700  - pI RTFD:(null) 2020-10-09 13:27:56.624014-0700  - pI RTF:{length = 2131, bytes = 0x7b5c7274 66315c61 6e73695c 616e7369 ... 49207365 6e64207d } 2020-10-09 13:27:56.624094-0700  - pI public.rtf:{length = 2131, bytes = 0x7b5c7274 66315c61 6e73695c 616e7369 ... 49207365 6e64207d } 2020-10-09 13:27:56.624189-0700  - pI String:{length = 716, bytes = 0x0909596f 75206e65 65642074 6f206564 ... 20492073 656e6420 } 2020-10-09 13:27:56.624979-0700  - sender:com.apple.TextEdit NSPasteboardTypeRTF:2131 SAFARI * 2020-10-09 13:28:15.270898-0700  - BID:com.apple.Safari 2020-10-09 13:28:15.271097-0700  - pboard:(     "public.rtf",     "NeXT Rich Text Format v1.0 pasteboard type",     "public.utf8-plain-text",     NSStringPboardType,     "com.apple.flat-rtfd",     "NeXT RTFD pasteboard type",     "public.utf16-external-plain-text",     "CorePasteboardFlavorType 0x75743136" ) 2020-10-09 13:28:15.272557-0700  - pboard RTFD:{length = 0, bytes = 0x} 2020-10-09 13:28:15.273071-0700  - pboard RTF:{length = 0, bytes = 0x} 2020-10-09 13:28:15.273242-0700  - pboard public.rtf:{length = 0, bytes = 0x} 2020-10-09 13:28:15.273731-0700  - pboard String:{length = 621, bytes = 0x310a596f 75206e65 65642074 6f206564 ... 652c2074 68656e20 } 2020-10-09 13:28:15.273921-0700  - [pboard pasteboardItems]:(     "<NSPasteboardItem: 0x600000e10a80>" ) 2020-10-09 13:28:15.274031-0700  - pasteboardItem[0]:(     "public.rtf",     "public.utf8-plain-text",     "com.apple.flat-rtfd",     "public.utf16-external-plain-text" ) 2020-10-09 13:28:15.274170-0700  - pI RTFD:{length = 0, bytes = 0x} 2020-10-09 13:28:15.285873-0700  - pI RTF:{length = 0, bytes = 0x} 2020-10-09 13:28:15.286083-0700  - pI public.rtf:{length = 0, bytes = 0x} 2020-10-09 13:28:15.286269-0700  - pI String:{length = 621, bytes = 0x310a596f 75206e65 65642074 6f206564 ... 652c2074 68656e20 }

Etresoft; Try recompiling that old app using Xcode 12 on macOS 10.15 and run again. Using an old binary doesn't get to the issue.