|
As with previous iOS versions, let's analyze the built-in apps of iOS 18 to answer a few questions: 📈 How many binaries are in iOS 18? 👉 https://blog.timac.org/2024/1208-state-of-swift-and-swiftui-ios18/ 8 comments
 Justin, I've always had the impression that Apple's goal with Swift was to make it a replacement for both Objective-C and C++. Swift does compile into regular machine code in the end, so there's nothing stopping one from writing performance-critical stuff in it. I'd guess that all that C++ code is mostly projects that predate Swift and would be too time-consuming to rewrite just for the sake of using a different language. @timac How are you detecting Swift in the Secure Enclave binaries? Those are nowadays using Embedded Swift, and there might not be the traditional "obvious" signs of Swift in those Mach-O binaries. @kubamracek I was unable so far to find any artifacts to detect Embedded Swift. The Secure Enclave binaries are well-stripped, with no typical Mach-O sections. What surprised me, was the SEP app name with the '_swift' suffix. I assumed that a SEP binary with the '_swift' suffix was built with Embedded Swift, but I could be wrong. It is also possible that the other binaries have been moved to Swift without using the "_swift" suffix. In any case, I plan to experiment more with Embedded Swift. @timac Aha, so previously you were using the presence of the Swift sections in the Mach-O header to detect Swift? You're right that those are gone with Embedded Swift, which doesn't use type metadata and generally compiles down to something much much closer to what C compilers would produce. Without symbols, it is probably pretty hard to reliably trace back whether the binary is coming from a Swift compiler or C compiler... @timac Though, that said, I can think of one pretty reliable way: If you dump the instructions (otool -xV) of an arm64e binary (SEP uses arm64e), and if you spot PAC sequences using the #0x6ae1 and #0xbbbf constants, then that's a very strong signal about the code being Swift. The constants are coming from this code in the Swift runtime: https://github.com/swiftlang/swift/blob/main/stdlib/public/SwiftShims/swift/shims/EmbeddedShims.h#L49,L60 @kubamracek I was indeed relying on the presence of the Swift sections to detect Swift in the SEP binaries. I just checked on macOS 15, and the sections are indeed missing in the hibernation binary. |
Gregory's Server
@timac C++ being used more than SwiftUI seems wild but it totally makes sense for performance critical stuff.