Hello, I received an App Store rejection (ITMS-91065: Missing signature) for one of my iOS apps related to vendor-signed third-party SDKs and I want to understand the rule more clearly. My understanding is that some third-party SDKs must be vendor-signed; I believe the vendor list is: https://developer.apple.com/support/third-party-SDK-requirements/. In my app, for example, I have a fork of RxSwift that we build from source and therefore self-sign. That seems reasonable, but it does mean that it will no longer be signed by the vendor. How can I ensure I won't be flagged for using a non–vendor-signed third-party SDK in this case? Thanks, Sam

Hey there Are there any recommendations or guidance for apps on alternatives to certificate pinning to secure their device network traffic? I want to move away from the overhead and risk associated with rotating certificates when using leaf pinning. However, I also don't want people to be able to perform a MITM attack easily using something like Charles Proxy with a self‑signed certificate added to the trust store. My understanding is that an app cannot distinguish between user‑trusted certificates and system‑trusted certificates in the trust store, so it cannot block traffic that uses user‑trusted certificates.

Hi there I've recently had my upload rejected in Xcode Organizer as a result of one of the frameworks we use containing bitcode. Error: [ContentDelivery.Uploader.XXXXXXXXXX] Validation failed (409) Invalid Executable. The executable 'Sam.app/Frameworks/Foo.framework/Foo' contains bitcode. Is there an accurate way to determine whether an .xcframework contains bitcode ahead of time without using Xcode Organiser? My current methodology is below, please can I get some confirmation that this is accurate, or suggest a more efficient approach? I have concerns about my approach and whether it throws false positives for empty bitcode markers. 1. get original framework size 2. run xcrun bitcode_strip -r framework_path -o temp 3. get new framework size 4. if new size is smaller than original, then it contains bitcode Thanks for the help, Sam

Hi there The behaviour of using Locale(identifier: "ar") with NumberFormatter.locale appears to have changed between iOS 17 and iOS 18. Is this expected? Steps to reproduce import UIKit func numberFormatter(withlocaleString localeString: String) -> NumberFormatter { let locale = Locale(identifier: localeString) let numberFormatter = NumberFormatter() numberFormatter.locale = locale return numberFormatter } let numbers = 0...9 let localeDigits = numbers let ar_digits = localeDigits.compactMap { numberFormatter(withlocaleString: "ar").string(for: $0)?.first } print(ar_digits) Results The results show: **** numbering system on iOS 17 latn numbering system on iOS 18. iOS Output iOS 17 ["٠", "١", "٢", "٣", "٤", "٥", "٦", "٧", "٨", "٩"] iOS 18 ["0", "1", "2", "3", "4", "5", "6", "7", "8", "9"]