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.

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

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?