I want to build a Swift library package that uses modified build of OpenSSL and Curl. I have already statically compiled both and verified I can use them in an Objective-C framework on my target platform (iOS & iOS Simulator). I'm using XCFramework files that contain the static library binaries and headers: openssl.xcframework/ ios-arm64/ openssl.framework/ Headers/ [...] openssl ios-arm64_x86_64-simulator/ openssl.framework/ Headers/ [...] openssl Info.plist I'm not sure how I'm supposed to set up my Swift package to import these libraries. I can use .systemLibrary but that seems to use the embedded copies of libssl and libcurl on my system, and I can't figure out how to use the path: parameter to that. I also tried using a .binaryTarget pointing to the XCFramework files, but that didn't seem to work as there is no module generated and I'm not sure how to make one myself. At a basic high level, this is what I'm trying to accomplish: where libcrypto & libssl come from the provided openssl.xcframework file, and libcurl from curl.xcframework

Running through the tutorial on how to sign data using security.framework, I was trying to understand the format Apple is using & wanting for signatures (as this isn't documented anywhere): https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/signing_and_verifying?language=objc I've learned the format of the signatures are just ASN.1 objects, with EC signatures being a sequence of the R and S coordinates as ASN.1 integers. However, I am noticing when using SecKeyCreateSignature that either the R or S value will always be prepended with an extra byte. For example: 30 45 02 20 66 B7 4C FB FC A0 26 E9 42 50 E8 B4 E3 A2 99 F1 8B A6 93 31 33 E8 7B 6F 95 D7 28 77 52 41 CC 28 02 21 00 E2 01 CB A1 4C AD 42 20 A2 ^^ why is this here? 66 A5 94 F7 B2 2F 96 13 A8 C5 8B 35 C8 D5 72 A0 3D 41 81 90 3D 5A 91 This is a ASN.1 sequence, first is a 32-byte integer and second is a 33-byte integer. Why is that 00 byte being prepended to the integer? Why is it sometimes the R and sometimes the S? Removing it causes SecKeyVerifySignature to fail, so obviously it's required, but I need to know the logic here as I'm having to hand-craft these ASN.1 objects as all I have are the raw R and S values.

I am trying to fix an annoying issue here a list of navigation links will shift if the user taps on one of the links after scrolling down. Notice how after I scroll down a bit and tap on item 60 - the entire list jumps down as the transition to the new view plays out. This is the source to reproduce the issue. Note that it only happens after you've scrolled down a bit. import SwiftUI struct ContentView: View { let items = generateItems() var body: some View { NavigationStack { List(items, id: \.self) { item in NavigationLink { Text(item) } label: { Text(item) } } .navigationTitle("Items") } } } #Preview { ContentView() } func generateItems() -> [String] { var items: [String] = [] for i in 1...1000 { items.append("\(i)") } return items }

My app depends on two frameworks that I don't want to check-in to source. Previously, when I was using traditional frameworks, I had a run script phase in the build steps that would compile the frameworks. This worked well as the first time one would try to build the app it would also build the needed frameworks. However, after switching to xcframeworks, this no longer works. Even though the run script phase is before the compile and link steps - the build still fails because the frameworks don't exist yet. Is there a workaround for this, or have I encountered a bug?

After updating to Xcode 14 I can no longer compile my app which targets iOS 9.3. Nothing in my source changed. The build fails because my project depends on the Swift package https://github.com/Wevah/IDNA-Cocoa, that package specifically support iOS 9 as indicated in the Package.swift file: platforms: [.macOS(.v10_11), .iOS(.v9), .tvOS(.v9), .watchOS(.v2)], However, when I build my app it fails with the following error: URL+Encode.swift:2:8: error build: Compiling for iOS 9.3, but module 'IDNA' has a minimum deployment target of iOS 11.0: <>/Build/Products/Debug-iphoneos/IDNA.swiftmodule/arm64-apple-ios.swiftmodule Which doesn't make sense, as it doesn't have a minimum target of iOS 11, and this worked just fine moments ago on Xcode 13. Removing the import and the app compiles just fine, even targeting iOS 9. Is this a bug?

Is it possible to extract the master key from a TLS session when using the network framework? libssl 1.1.1 and newer offers a native way using SSL_CTX_set_keylog_callback, does the network framework offer something similar? The master key is quite useful for debugging TLS connections as it can be fed into programs like Wireshark to decrypt captured messages.

I'm debugging an issue on IPv4 networks and am trying to force a nw_connection to use IPv4 as opposed to IPv6, which it's defaulting to on my network. The documentation for IP Options is extremely sparse, so I had to dive into the nwcat example - https://developer.apple.com/documentation/network/implementing_netcat_with_network_framework?language=objc to see how one is supposed to use nw_ip_options_set_version. Here's what I've got: nw_parameters_t parameters = nw_parameters_create_secure_tcp(configure_tls, configure_tcp); nw_protocol_stack_t protocol_stack = nw_parameters_copy_default_protocol_stack(parameters); nw_protocol_options_t ip_options = nw_protocol_stack_copy_internet_protocol(protocol_stack); nw_ip_options_set_version(ip_options, nw_ip_version_4); This matches what is done in the nwcat example at main.c:359 The problem is, despite explicitly setting the IP version ip IPv4, it's still using IPv6 (the website in question supports both). I can see this by looking at the effective remote endpoint. This issue happens both in my iOS app as well as the nwcat example itself, which I verified with Wireshark Is this a SDK bug? Or is just bad luck that the documentation is lacking and the example is incorrect?

How can I get the resolved IP address from a nw_connection? I tried using: nw_endpoint_t endpoint = nw_path_copy_effective_remote_endpoint(nw_connection_copy_current_path(connection)); But that just returns the same endpoint that I provided (which was a URL + port), when I want the resolved IP address that was actually connected to. With CFStreams I'd have gotten the file descriptor and then called getpeername(). I looked into nw_resolver_t, but that just seems to be for specifying a DoH or DoT resolver, which isn't what I want.