Hello, I am working on a research project focused on creating accessible interactions for visually impaired users. I need to verify some automated assistance processes in a real-world usage environment where VoiceOver is enabled. However, I have encountered a blocking issue: When I connect the device through Xcode UI Test / WebDriverAgent (or Appium + WDA) and perform operations, VoiceOver gets interrupted (sometimes it is even directly turned off), preventing blind users from continuing to use the narrator. Replication steps (stable replication)    On iPhone, enable VoiceOver (Settings → Accessibility → Narrator), and keep the device unlocked and the screen on. On Mac, start [Xcode UI Test / WebDriverAgentRunner / Appium+WDA] and establish a session with the device (XCTest session). Perform any operation: read the accessibility tree (/source), take screenshots, or click/slide. Observe the phenomenon: VoiceOver will [automatically turn off / reading interruption / focus jumping / unable to continue reading the new interface]. Expected behavior VoiceOver, as the core accessibility capability, should remain running and be able to continue reading the interface; the automation/assistance process should not "steal" and cause the narrator to fail. Actual behavior VoiceOver is [turned off / interrupted], and even after interface changes, it cannot read normally, affecting the use of blind users. I would like to ask: Non-jailbroken or external hardware-free methods Is this a known limitation (such as the mutual exclusion between XCTest and VoiceOver as Accessibility clients)? Is there an officially supported way to allow the automation/assistance program to safely read necessary information and trigger operations while VoiceOver is enabled, without disrupting the narrator (such as App Intents, Shortcuts, or other API/framework suggestions)? If it is necessary to avoid XCTest/WDA: In the research prototype stage, what is the recommended "reproducible, measurable" alternative technical route?

Apple provides sample code for compressing a single file here, but the "aa" command and Finder cannot decompress these files. I needed to write a custom decompresser using Apple's sample code here. Apple provides sample code for creating an "aar" file for directories here and a single string here, and the aa command and Finder can deal with these. However, I have struggled creating an ".aar" file for a single file. The file could be quite large, so reading it into memory and writing it as a blob is not an option. Does anyone have suggestions or can point me to Apple documentation that can create a ".aar" file for a single file?

We're trying to implement a backup/restore data feature in our business productivity iPad app using UIDocumentPickerViewController and AppleArchive, but discovered AppleArchive crashes instead of failing gracefully when decrypting a corrupt archive. As described in forum post 765101, UIDocumentPickerViewController can handoff a corrupt copy of an archive to UIDocumentPickerDelegate under specific circumstances. We've duplicated this behavior with iPadOS 16.6.1 and 17.7 when building our app with Xcode 15.4 targeting minimum deployment of iPadOS 16. We haven't tested this with the bleeding edge iPadOS 18. Our app is primarily Objective-C, but it utilizes the Swift-based AppleArchive 'EncryptingAndDecryptingDirectories' sample code associated with WWDC21 session: 10233: Bring Encrypted Archives and Performance Improvements to Your App with Accelerate. The WWDC21 'EncryptingAndDecryptingDirectories' Swift sample project crashes in a similar manner when a corrupt archive file created by UIDocumentPickerViewController is dropped into the sample app's window for decryption (see attached crash log). Does anyone know if there's a workaround for the 'EncryptingAndDecryptingDirectories' sample project to prevent AppleArchive from crashing when decrypting a corrupt archive? crash log.txt

I've been working on implementing alternate app icons for my iOS app, and everything works perfectly in debug builds on both the simulator and a physical device. However, when testing on TestFlight, I encounter the following error: The requested operation couldn’t be completed because the feature is not supported. Has anyone faced this issue before? Is there a specific TestFlight configuration or setup I might be missing to enable alternate app icon functionality?

Hello, I have integrated LZMA2 compression into my iOS app, Hogs, and successfully implemented compression. However, when attempting to upload the app for TestFlight, I encountered an error: "The app references non-public symbols in Payload/Hogs.app/Hogs: _lzma_code, _lzma_end." These functions are part of the LZMA compression library (specifically LZMA2). Here's a detailed description of the issue: What I Have Done: LZMA2 Integration: I integrated LZMA2 compression into the app and created a wrapper around the LZMA functions (_lzma_code, _lzma_end) to prevent direct references. App Build Configuration: I ensured the LZMA2 library is linked correctly with the -lzma flag in the linker settings. I wrapped the LZMA functions in custom functions (my_lzma_code, my_lzma_end) in an attempt to avoid using the non-public symbols directly. Error Message: During the app submission process, I received the following error: "The app references non-public symbols in Payload/Hogs.app/Hogs: _lzma_code, _lzma_end." Steps Taken to Resolve: Checked if any LZMA functions were exposed incorrectly. Ensured that all non-public symbols were properly encapsulated in a wrapper. Verified linker settings to ensure the proper inclusion of the LZMA2 library. Request: Could anyone provide suggestions or best practices to resolve this issue and avoid references to non-public symbols? Should I use a different method for linking LZMA2 or encapsulating these symbols? Thank You: I appreciate your help in resolving this issue so I can move forward with submitting the app for TestFlight.

The AppleArchive module is pretty cool, but it relies almost entirely on two stream types, ArchiveByteStream and ArchiveStream, which don't really work well in a Swift Concurrency-based workflow since they all use thread-blocking mechanisms like pthread mutexes for synchronization, and threads in the cooperative pool should not be blocked. They also use their own thread pools for processing, independently of the cooperative thread pool, making it easy to end up with more threads than one has cores. (Perhaps even more so if you try to compress/decompress multiple files at once? The documentation isn't clear on whether separate archive operations share the same thread pool or not, but since it allows you to choose the size of the pool, it seems that these may be separate from each other as well.) Are there any plans for an interface to Apple Archive that would fit better with the structured concurrency model?

I've implemented Apple Archive in the app I'm working on and have implemented lzfse algorithm. The framework is extremely impressive in terms of the speed and compression ratios. I'm using the closure in ArchiveStream.writeDirectoryContents to indicate what the current file is being processed, but there doesn't seem to be a way to pull out progress % on each file. I've seen examples here [Accelerate].(https://developer.apple.com/documentation/accelerate/compressing_and_decompressing_files_with_stream_compression) but these aren't using the Apple Archive Framework... I'd really like to stick with the Apple Archive Framework if possible as it's simple and very fast.

I very much love the performance of AppleArchive and how approachable it is, and believe it to be one of the most underrated frameworks in the SDK. In a scenario quite typical, I need to compress files and submit them to a back end, where the server handling the files is not an Apple platform. Obviously, individual files compressed with AA will not be compatible with other systems out of the box, but there are compatible compression algorithms. ZLIB is recommended for cases where cross-platform compatibility is necessary. As I understand it, AA adds additional headers to files in order to support preservation of file attributes, ownership and other data. Following the steps outlined in the docs, I've written code to compress single files. I can easily compress and decompress using AA without issue. To create a proof-of-concept, I've written some code in python using its zlib module. In order to get to the compressed data, it's necessary to handle the AA header fields. The first 64 bytes of a compressed file appear as follows: AA documentation states that ZLIB Level 5 compression is used, and comes in the form of raw DEFLATE data prefixed with two header bytes. In this case, these bytes are 78 5e, which begin at the 28th byte and appear as x^ above. My hope was that seeking to the start of the compressed data, then passing what remains to a decompressor object initialized with the correct WBITS would work. It works fantastically for files 1MB or less in size. Files which are larger only decompress the first megabyte. The decompressor object is reaching EOF, and I've tried various ways of attempting to seek to and concatenate the other blocks, but to no avail. Using the older Compression framework and the method specified here, with the same algorithm, yields different results. I can decompress files of any size using python's zlib module. My assumption is that AppleArchive is doing something differently in order to support its multithreading capabilities, perhaps even with asymmetric encoding where the blocks are not ordered. Is there a solution to this problem? If not, why would one ever use ZLIB versus the much more efficient LZFSE? I could use the older Compression API, but it is significantly slower compressing synchronously, and performance is critical with the application I am adding this feature to.

I support Mac code signing and notarisation for DTS and, as part of that work, I often need to look inside various Apple-specific archive file formats. This post explains how I do this. It’s mostly for the benefit of Future Quinn™, but I figured other folks would appreciate it as well. IMPORTANT This post explains low-level techniques for inspecting archives. Do not use them to create archives. Instead, create your archives using the highest-level tool that will get the job done [1]. Flat Installer Package A flat installer package — appropriate for uploading to the Mac App Store or the notary service — is actually a xar archive. Unpack it using the xar tool. For example: % # List the contents: % % xar -tf InstallTest-1.0d1.pkg com.example.apple-samplecode.InstallTest.pkg com.example.apple-samplecode.InstallTest.pkg/Bom com.example.apple-samplecode.InstallTest.pkg/Payload com.example.apple-samplecode.InstallTest.pkg/PackageInfo Distribution % % # Actually unpack: # % mkdir tmp % cd tmp % xar -xf ../InstallTest-1.0d1.pkg % find . . ./Distribution ./com.example.apple-samplecode.InstallTest.pkg ./com.example.apple-samplecode.InstallTest.pkg/Bom ./com.example.apple-samplecode.InstallTest.pkg/Payload ./com.example.apple-samplecode.InstallTest.pkg/PackageInfo See the xar man page for more info on that tool. The resulting Bom file is a ‘bill of materials’. For more on this, see the bom man page for details. Use lsbom to dump this: % lsbom ./com.example.apple-samplecode.InstallTest.pkg/Bom . 0 0/0 ./InstallTest.app … ./InstallTest.app/Contents … ./InstallTest.app/Contents/Info.plist … ./InstallTest.app/Contents/MacOS … ./InstallTest.app/Contents/MacOS/InstallTest … … The Payload file contains… you guessed it… the installer’s payload. This is a gzipped cpio archive. To unpack it, pipe the file through cpio: % cpio -i < com.example.apple-samplecode.InstallTest.pkg/Payload 5072 blocks % find InstallTest.app InstallTest.app InstallTest.app/Contents InstallTest.app/Contents/Info.plist InstallTest.app/Contents/MacOS InstallTest.app/Contents/MacOS/InstallTest … See the cpio man page for more info on that tool. Note This is a bit of a hassle so most of the time I use a third-party app to unpack installer packages. Which one? Well, I can’t give away all my secrets (-: Xip Archives To extract a xip archive (pronounced, I believe, as chip archive), run the xip tool with the --expand argument: % xip --expand XipTest.xip However, if that doesn’t work you’ll need to dig into the archive. First, undo the outer xar wrapper: % xar -xf XipTest.xip This produces two files, Content and Metadata: % ls -l total 7552 -rw-r--r-- 1 quinn staff 1683391 10 Jun 17:05 Content -rw-r--r-- 1 quinn staff 287 10 Jun 17:08 Metadata -rw-r--r-- 1 quinn staff 1697157 10 Jun 17:05 XipTest.xip The Metadata file is an XML property list: % cat Metadata … <dict> <key>UncompressedSize</key> <integer>2598653</integer> <key>Version</key> <integer>1</integer> </dict> </plist> The Content file is an Apple Archive. Unpack this using the aa tool: % aa extract -ignore-eperm -i Content -d tmp % find tmp tmp tmp/XipTest tmp/XipTest/XipTest.app tmp/XipTest/XipTest.app/Contents tmp/XipTest/XipTest.app/Contents/Info.plist tmp/XipTest/XipTest.app/Contents/MacOS tmp/XipTest/XipTest.app/Contents/MacOS/QCodeIndex tmp/XipTest/XipTest.app/Contents/MacOS/XipTest … See the aa man page for more info on that tool. Note aa was previously known as yaa. iOS App Archives iOS apps are stored in an .ipa file. This is actually a zip archive under the covers. To unpack it, change the file name extension to .zip and then double click it it in the Finder (or use your favourite unzipping tool, like unzip or ditto). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] For installer package specifically, productbuild is your friend, but you can also use the lower-level tools like productsign, pkgbuild, and pkgutil. Revision History 2024-02-20 Added the iOS App Archives section. Added a note about third-party apps to the end of the Flat Installer Package section. 2022-09-30 Changed yaa to aa and added a reference to the Apple Archive framework. 2021-02-26 Fixed the formatting. 2020-06-10 First posted.

VS 2022 .net MAUI Error : Process cannot be executed on XMA server. There was an error unzipping the file : The given path's format is not supported. Please Help!

Dear Developer, We identified one or more issues with a recent delivery for your app, "WF Studio" 1.1.58 (269). Please correct the following issues, then upload again. ITMS-90338: Non-public API usage - The app references non-public symbols in WF Studio: _CMTimebaseCreateWithMasterClock, _CMTimebaseCreateWithMasterTimebase. If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. For further information, visit the Technical Support Information at http://developer.apple.com/support/technical/ Best regards, The App Store Team

Has anyone recently updated their Xcode, iOS and MacOS and is perhaps having the same issue as me? I have updated Xcode to latest version and after trying to Archive the app so I could upload a new build version to app store I keep getting this error: Command PhaseScriptExecution failed with a nonzero exit code and this: PhaseScriptExecution [CP]\ Embed\ Pods\ Frameworks /Users/blazw/Library/Developer/Xcode/DerivedData/App-cjlyvstgewichsheopwjaqqfczpa/Build/Intermediates.noindex/ArchiveIntermediates/Svet\ gastronimije/IntermediateBuildFilesPath/App.build/Release-iphoneos/Svet\ gastronimije.build/Script-421B80DAB9083632D2B6ED13.sh (in target 'Svet gastronimije' from project 'App') cd /Users/blazw/Documents/Personal/Angular/vigros-app/ios/App /bin/sh -c /Users/blazw/Library/Developer/Xcode/DerivedData/App-cjlyvstgewichsheopwjaqqfczpa/Build/Intermediates.noindex/ArchiveIntermediates/Svet\\\ gastronimije/IntermediateBuildFilesPath/App.build/Release-iphoneos/Svet\\\ gastronimije.build/Script-421B80DAB9083632D2B6ED13.sh mkdir -p /Users/blazw/Library/Developer/Xcode/DerivedData/App-cjlyvstgewichsheopwjaqqfczpa/Build/Intermediates.noindex/ArchiveIntermediates/Svet gastronimije/BuildProductsPath/Release-iphoneos/Svet gastronimije.app/Frameworks Symlinked... rsync --delete -av --filter P .*.?????? --links --filter "- CVS/" --filter "- .svn/" --filter "- .git/" --filter "- .hg/" --filter "- Headers" --filter "- PrivateHeaders" --filter "- Modules" "../../../IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Capacitor.framework" "/Users/blazw/Library/Developer/Xcode/DerivedData/App-cjlyvstgewichsheopwjaqqfczpa/Build/Intermediates.noindex/ArchiveIntermediates/Svet gastronimije/InstallationBuildProductsLocation/Applications/Svet gastronimije.app/Frameworks" building file list ... rsync: link_stat "/Users/blazw/Documents/Personal/Angular/vigros-app/ios/App/../../../IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Capacitor.framework" failed: No such file or directory (2) done sent 29 bytes received 20 bytes 98.00 bytes/sec total size is 0 speedup is 0.00 rsync error: some files could not be transferred (code 23) at /AppleInternal/Library/BuildRoots/97f6331a-ba75-11ed-a4bc-863efbbaf80d/Library/Caches/com.apple.xbs/Sources/rsync/rsync/main.c(996) [sender=2.6.9] Command PhaseScriptExecution failed with a nonzero exit code I get this error only when Archiving the app… it builds normally if I connect my iPhone to my Mac and run it on the phone…

In WWDC21 session 10233: Bring Encrypted Archives and Performance Improvements to Your App with Accelerate, there is an example of encrypting a directory using the AppleArchive framework. There is also accompanying sample code. However, that sample code uses a SymmetricKey and the hkdf_sha256_aesctr_hmac__symmetric__none profile. The key is set by calling context.setSymmetricKey(encryptionKey). How can you perform the same operation of encrypting a directory using AppleArchive but with a "human" password? (i.e.: A password provided by the user from a prompt?) Simply changing the profile to hkdf_sha256_aesctr_hmac__scrypt__none and then calling `context.setPassword("MyPassword") producing the following output "Error setting password (invalidValue)." I also tried using the command line aea application, but received the output Password is too short. Prompt: > aea encrypt -v -password-value "password" -profile 5 -i MyDirectory -o MyDirectory.aea Operation: encrypt input: FOO output: FOO.aea profile: hkdf_sha256_aesctr_hmac__scrypt__none worker threads: 10 auth data (raw): 0 B compression: lzfse 1 MB Error 0xb9075800 Password is too short Main key derivation failed (-2) Main key derivation Invalid encryption parameters Finally, in the file AEAContext.h, there is a comment associated with the method AEAContextSetPassword() that states: Set context password Stores a copy of password in context. Required to encrypt / decrypt a stream when encryption mode is SCRYPT. An internal size range is enforced for the password. The caller is expected to enforce password strength policies. @param context target object @param password password (raw data) @param password_size password size (bytes) @return 0 on success, a negative error code on failure I cannot find any other documentation that states what the password policy. And if there is a password policy for AppleEncryptedArchives, does that mean AEA is not a good fit for encrypting personal directories where the user just wants to use "any old password", regardless of the password's strength?

I need to implement ZIP file and directory compression without using any third party libraries and Apple Archive looks like it would do the trick. Unfortunately, whenever I try to make use of it (yes, I did import it), I get out of scope errors. The Swift import headers are all essentially empty in the Xcode 12.2 beta. The Objective C headers exist, though. Before I put any more time into this, does anyone know if/when Apple Archive will be implemented as documented? Has it been pulled from the SDK but the documentation not updated? I'm a little worried about trying to use the Objective C variant because I cannot find anything on the status of the framework in general. Thanks, Kevin

Running an app that uses AppleArchive with Xcode 14.0/14.1 on simulators with iOS/tvOS 14.x/15.x fails with a dyld linker error: Library not loaded: /usr/lib/swift/libswiftAppleArchive.dylib Referenced from: /Users/tom/Library/Developer/CoreSimulator/Devices/A35CB8BA-9ABF-4E4D-B985-FEF35091FB88/data/Containers/Bundle/Application/5A504371-0F53-4E06-9F46-81D73835E906/MyApp.app/MyApp Reason: tried: '/Users/tom/Library/Developer/Xcode/DerivedData/MyApp-ffndhzhjdbfrvuhkxftdfqudypxx/Build/Products/Debug-iphonesimulator/libswiftAppleArchive.dylib' (no such file), '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/introspection/libswiftAppleArchive.dylib' (no such file), '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswiftAppleArchive.dylib' (no such file), '/usr/lib/swift/libswiftAppleArchive.dylib' (no such file), '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libswiftAppleArchive.dylib' (no such file) Running the app on iOS/tvOS 14.x/15.x devices works. Also release builds run fine on those devices. I'm unable to test if this issues was already present in Xcode 13, because running apps with AppleArchive on simulators fails because of another bug: https://developer.apple.com/forums/thread/665465 Feedback: FB11703995

Hello, I want to archive a folder containing files into a single file using Apple Archive. So far so good, it works as it should. Now, the documentation says: The zlib compression algorithm, which is recommended for cross-platform compression. The encoded format is the raw DEFLATE format as described in IETF RFC 1951, the following obtains the equivalent configuration of the encoder: deflateInit2(zstream,5,Z_DEFLATED,-15,8,Z_DEFAULT_STRATEGY) Thus, I'm using .zlib, because I want the archive to be unarchivable on macOS as well as other, non-Apple platforms. The thing is, I don't know what file extension to use so it is unarchivable / openable on both macOS and, say, Windows. Using .aar ("Apple Archive"), or .aea ("Apple Encrypted Archive"), it works on macOS, but I doubt those can be opened on Windows (since it's the Apple-proprietary file format). Using .zip doesn't work on macOS, so I doubt it'll work on Windows. Using .zlib doesn't work (can't be opened on macOS) Usng .z doesn't work (can't be opened on macOS) So my question is, with a folder compressed using .zlib for cross-platform, what file extension must I use for the resulting archived file so it can be opened with an unarchiving app on macOS and non-Apple platforms? Thank you for any insights, Matthias

I built a MacOs app, and it works fine, but the problem happens when I achieve the project. When I tried from an old Xcode version (12.3) Macbook Pro late 13 it works But when I run from Macbook pro-2020 (M1 chip), the issue happened while archiving, and works fine while running, I use Xcode 14 beta. The app is written in objective-c I get this error: /Users/usamafouad/Downloads/Oil Paint - Mac/Oil Paint App/frameworks/Source/Mac/GPUImageMac-Prefix.pch error build: Build input file cannot be found: '/Users/usamafouad/Library/Developer/Xcode/DerivedData/Oil_Paint-dywawlmfpsulhqapvsuiigxhgkrs/Build/Intermediates.noindex/ArchiveIntermediates/Oil Paint/InstallationBuildProductsLocation/@loader_path/../Frameworks/GPUImage.framework/Versions/A/Modules/module.modulemap' Could you please help me, it's an urgent issue?

3 questions on the AppleArchive.h APIs: Are there Obj-C APIs? I see Swift APIs but I'm not looking forward to using them. Is there sample code showing how to use the C APIs? Is there any plan to fix the documentation on Apple Developer web page for this library? It's not really useful right now and the CSS is broken for sample code (the sample code frame is clipping code on the right). Same problem with the Compression documentation.

There are files that fail to decompress on Mac or iOS. Even using open source for iOS, they all fail. Clicking on the MacBook to open it fails. However, some compression programs on Mac or PC will successfully decompress it. Is there any way to forcefully open or decompress such a compressed file (Zip)? I tried the Apple Archive method, but that method also fails with an error now. (Personally, I would like to be able to force such a file through the Apple archive.)

Running the latest Mac OS beta. I have downloaded the image twice but same result. The error from the command line is: xip: error: The archive “Xcode_13_Release_Candidate.xip” is damaged and can’t be expanded. The error when using the Archive Utility is about not enough space but I have more than 100GB available. Restarting the Mac doesn't help.