This happened for me with Xcode 15.3 beta 1 and beta 2, and I've just tested and it's still happening with Xcode 15.3 beta 3. I've reported this as FB13620516.
Thanks, Quinn! That's very informative.
For CI, someone also suggested separately that using ephemeral CI environments would also prevent this situation from triggering.
Post not yet marked as solved
It's all done via a script, but the basic gist is:
xcrun xcodebuild archive -archivePath MyFramework.xcarchive -scheme MyFramework
xcrun xcodebuild -create-xcframework \
-framework MyFramework.xcarchive/Products/@rpath/MyFramework.framework \
-debug-symbols MyFramework.xcarchive/dSYMs/MyFramework.framework \
-output MyFramework.xcframework
ditto -c -k --rsrc --keepParent MyFramework.xcframework MyFramework.xcframework.zip
The zip file is attached to a GitHub release, and I download it in the app project, expand it and link to it as normal.
I can see looking at this how the signing might be a bit "off" by reaching into the xcarchive directly, rather than exporting the framework first. I might try using xcodebuild -exportArchive prior to creating the XCFramework, and see if that helps.
Post not yet marked as solved
You'll need to annotate any methods from NSTableViewDataSource that you implement with @objc.
For what it's worth, I don't believe any of the drag and drop protocol methods are implemented in the base NSTableViewDiffableDataSource type.
Post not yet marked as solved
Thanks for the suggestions, folks!
@John+Daniel, unfortunately I need to leave the files where they are. Part of the appeal of this app is that it will work with external resources without having to move them around, but that's a solid suggestion under different circumstances.
@eskimo I may end up having to do this, thanks for the suggestion about authorising a common parent. Not sure how that would play out in the user's experience, mind you ("why does this app need to access my entire home directory?!").
I think I need to file some feedback asking for enhancements to the user experience here — perhaps if the files I wanted to create security scoped bookmarks for could be collated into a single, easily reviewable dialog somehow that would be a much better experience, ie: I'm only asking the end user for access to what I actually need, and the user isn't bombarded with a bunch of same-same dialogs asking for access to each individual file (which would consequently cause the Vista effect and they'll just click through them without checking).
I've filed this as FB7247261 - please let me know if there's more information I can add that would be helpful. Thanks for your time, Quinn!
Sadly, it's not the team identifier. Mine is a "weird" value, just like yours - and the only way I could get it was via Xcode 10.x. I'll file some feedback - if there's no way to get this value in an Xcode 11+ world, that's a big problem.
Are there any other methods to get this information, Quinn? Application Loader.app isn't part of Xcode as of version 11.
Post not yet marked as solved
We chose to spin out to an external XPC service that won't be a requirement to run our app and (eventually) won't be shipped as part of the binary that users download from our website, but can be downloaded to augment the app's features/experience it if the user chooses to.This external XPC service does not use the App Sandbox (but has a very narrowly defined and documented set of features so our users know what it's capable of doing, and actually is doing), and thus can perform limited interactions with things like simctl. You can see a similar approach with apps like Paste.app, which prompts to download a helper app when the user enables specific features in-app: http://pasteapp.me/helperIn Reveal's case, this means we'll need to ship some example documents (or the facililty to download sample documents from our website), which I think will be an improvement for our users anyway.
Post not yet marked as solved
Thanks, Quinn - I appreciate that. I've found a workaround for now, but will log a DTS incident if it becomes necessary.
Post not yet marked as solved
Hi Quinn - thanks for replying!For my use, yes, I think it does cause a problem. I'm one of the developers working on Reveal and the filesystem items I'm writing out from our sandboxed app are:An iOS framework that contains our runtime supportAn iOS simulator application bundle that I use simctl to install and launchThe installation via simctl works fine, but the Simulator refuses to load the app it seems because of that quarantine bit. I'm expecting I'll face similar problems when I try to dyld inject our framework into that app same app via launch args/environment variables. At this stage, I think we'll need to offer a post-install download containing these items in order to support sandboxing. Do you have any ideas? I'm keen to work within the rules, but I understand that my use case here isn't run-of-the-mill.
