Hi everyone, Has this every happened to you? If so, how did you resolve it? Submitting my app for review, I got the following rejection: Guideline 2.4.5(ii) - Performance The package currently available in App Store Connect cannot be installed and may be corrupted. Next Steps Please rebuild your application and upload a new version. If this issue continues, please contact Apple Developer Technical Support for help investigating the issue. DTS referred me back to app review: We are unable to help you resolve this matter. Please circle back with the App Review team for assistance. I'm building the .pkg with productbuild: xcrun productbuild --product WFH\ Phone\ Webcam.app/Contents/Info.plist --component WFH\ Phone\ Webcam.app /Applications --sign "3rd Party Mac Developer Installer: Mansour Moufid (42A2D88R9U)" --timestamp WFH\ Phone\ Webcam.pkg and uploading it with altool: xcrun altool --username "..." --password "..." --validate-app --file WFH\ Phone\ Webcam.pkg --type osx xcrun altool --username "..." --password "..." --upload-app --file WFH\ Phone\ Webcam.pkg --type osx The .pkg signature looks fine: xcrun pkgutil --check-signature WFH\ Phone\ Webcam.pkg Package "WFH Phone Webcam.pkg": Status: signed by a developer certificate issued by Apple (Development) Signed with a trusted timestamp on: 2024-04-29 14:11:27 +0000 Certificate Chain: 1. 3rd Party Mac Developer Installer: Mansour Moufid (42A2D88R9U) Expires: 2025-03-13 20:11:55 +0000 SHA256 Fingerprint: CB 8A 12 1D 4D 16 29 27 08 30 07 1C 6C F6 1C F4 85 6E AE F1 B1 34 68 F7 81 6D C3 3B 1B 8C 5D 32 ------------------------------------------------------------------------ 2. Apple Worldwide Developer Relations Certification Authority Expires: 2030-02-20 00:00:00 +0000 SHA256 Fingerprint: DC F2 18 78 C7 7F 41 98 E4 B4 61 4F 03 D6 96 D8 9C 66 C6 60 08 D4 24 4E 1B 99 16 1A AC 91 60 1F ------------------------------------------------------------------------ 3. Apple Root CA Expires: 2035-02-09 21:40:36 +0000 SHA256 Fingerprint: B0 B1 73 0E CB C7 FF 45 05 14 2C 49 F1 29 5E 6E DA 6B CA ED 7E 2C 68 C5 BE 91 B5 A1 10 01 F0 24 The app's signature also checks out: codesign --strict --deep --verbose --verify WFH\ Phone\ Webcam.app WFH Phone Webcam.app: valid on disk WFH Phone Webcam.app: satisfies its Designated Requirement I have no idea what "cannot be installed and may be corrupted" means and app review is not responding to my request for more information...

Hello. I'm working on a Core Media IO camera extension, including a source and sink stream. My application sends sample buffers to the sink stream, which are passed to the source stream. The sample buffers' pixel format is 420v. This format is determined in the application (not the camera extension) by a VTDecompressionSession, which has the image buffer attribute requested: kCVPixelBufferIOSurfaceCoreAnimationCompatibilityKey; and a decoder specification that requests the key kVTVideoDecoderSpecification_EnableHardwareAcceleratedVideoDecoder. However, no client can connect to the extension's source stream. Photo Booth shows a blank screen. I noticed the second argument to the function CMVideoFormatDescriptionCreate, which has type CMVideoCodecType, doesn't explicitly support 420v. In fact there is no 4:2:0 format in the list at all. Comparing the headers, the only format in common between CoreVideo and CoreMedia is 422YpCbCr8... % sed -n -e 's/.*\(kCMVideoCodecType_[a-zA-Z0-9_]*\).*/\1/p' < /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreMedia.framework/Versions/A/Headers/CMFormatDescription.h | sort | uniq > kCMVideoCodecType.txt % sed -n -e 's/.*\(kCVPixelFormatType_[a-zA-Z0-9_]*\).*/\1/p' < /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Versions/A/Headers/CVPixelBuffer.h | sort | uniq > kCVPixelFormatType.txt % comm <(sed -e 's/kCMVideoCodecType_//' < kCMVideoCodecType.txt) <(sed -e 's/kCVPixelFormatType_//' < kCVPixelFormatType.txt) What is the guidance for pixel formats in camera extensions? The sample camera extension code produced by Xcode uses kCVPixelFormatType_32BGRA. Should camera extensions all be using this format? That's an extra step of YUV→RGB conversion that I'd rather avoid if possible.

Hello everyone. I'm decoding an H264 elementary stream with VideoToolbox. The VTDecompressionSession's output callback returns a CVImageBuffer successfully. While attempting to convert this YUV image to RGB, I prepare a luma vImage_Buffer and chroma vImage_Buffer, but I get strange values from CVPixelBufferGetBytesPerRowOfPlane: CVPixelBufferGetBaseAddressOfPlane(0) 0x10e98c000 CVPixelBufferGetHeightOfPlane(0) 1080 CVPixelBufferGetWidthOfPlane(0) 1440 CVPixelBufferGetBytesPerRowOfPlane(0) 46080 CVPixelBufferGetBaseAddressOfPlane(1) 0x10eb2b000 CVPixelBufferGetHeightOfPlane(1) 540 CVPixelBufferGetWidthOfPlane(1) 720 CVPixelBufferGetBytesPerRowOfPlane(1) 23040 If I use this value (46080) in initializing the vImage_Buffer's rowBytes field, vImageConvert_420Yp8_CbCr8ToARGB8888 crashes. If I simply set rowBytes=width, the conversion is successful. Has anyone seen this before? Notice the value returned is 32 × width. Why?

Hello, On macOS, I can include a second executable in the app bundle, which the main executable can launch and communicate with via pipes (standard input/output). I've done this before (with app sandbox inheritance). I've read on other forums that this is not possible on iOS. Is that correct? I tried popen() and it always fails with the error "Operation not permitted." 😔 I just wanted to confirm before I move on to using frameworks. Thanks for your time.

Hello, I've always used a package manager (pkgsrc), it installs to my home directory (~/pkg). I noticed today that if I manually copy a binary (not build by the package manager) to that location (~/pkg/bin), it gets terminated by EXC_BAD_ACCESS (Code Signature Invalid), but runs fine in its original location. I was confused because I don't remember signing anything in there. So Xcode clang is signing everything by default: % codesign --display --verbose ~/pkg/bin/python ... Format=Mach-O thin (arm64) CodeDirectory v=20400 size=514 flags=0x20002(adhoc,linker-signed) hashes=13+0 location=embedded Signature=adhoc ... "linker-signed"..? I guess I have to "re-link" binaries every time they get moved? Since the linker is doing this on its own, maybe the "install" utility could do that for us? Update: Nevermind. TIL about -adhoc_codesign and -no_adhoc_codesign linker options. 😅