As with previous iOS versions, let’s analyze the built-in apps of iOS 18 to answer a few questions: How many binaries does iOS 18 contain? Which programming languages were used to develop these apps? How many apps are written in Swift? What percentage of apps use SwiftUI versus UIKit?

Want to support this blog? Please check out

MarkChart - Mermaid Preview

• Easily preview Mermaid diagrams
• Live update when editing
• Capture screenshots
• Create PNG from the Terminal
• Free download on the Mac App Store

Methodology

The methodology and tools to create this article have been detailed in my previous posts. If you are interested, please refer to:

• Apple’s use of AppKit, Mac Catalyst and SwiftUI in macOS
• Evolution of the programming languages from iPhone OS 1.0 to iOS 14
• Apple’s use of Swift in iOS 10.1 and macOS 10.12

Before jumping into the details, let’s clarify a few points:

• I only analyzed what is commonly called ‘iOS’, i.e. everything above the kernel. The XNU kernel and low-level firmwares are not included.

• I counted the frameworks located inside the dyld shared cache, a mechanism introduced in iPhone OS 3.1.

• Keep in mind that a developer can mix different programming languages to create one binary. In this article, an app containing a single line of Swift code will be counted as using Swift.

• You will see mentions of Objective-C and C++ but you might notice the absence of Objective-C++. The approach used here can’t really detect binaries built with Objective-C++. Such binaries are counted as using both Objective-C and C++.

• Finally, you should take this analysis with a grain of salt. While I believe the overall picture to be accurate, my approach has some limitations because I don’t have access to the iOS source code and relied on imprecise compilation artifacts.

Number of binaries

Let’s first answer a simple question: How many binaries are in iOS 18? The number of binaries composing iOS continues to increase: iOS 18 contains 6800 binaries, up from 6030 in iOS 17. That’s 770 new binaries.

Swift and SwiftUI in iOS 18

Unsurprisingly, the number of apps adopting SwiftUI continues to grow this year. Notable mentions include:

• The new Passwords app
• The Siri.app which now uses SwiftUI
• The Calculator app, which received a notable overhaul
• The new Journal app introduced in iOS 17.2

Newly developed technologies also rely on Swift, such as:

• Apple Intelligence with the ProactiveSummarization and SummarizationKit frameworks
• PrivateCloudCompute for Apple Intelligence, which includes some open-source components
• MarketplaceKit to create alternative app marketplace
• LimitedLibraryPickerViewService to access a person’s contact data

Additionally, several other apps and frameworks now use Swift, such as the Camera app and BarcodeScanner, as well as frameworks like CoreML, CoreNFC, CoreGraphics, CoreText, LinkPresentation, and DoNotDisturb.

iOS 18 now contains 592 binaries using SwiftUI and the number of binaries containing at least one line of Swift code increased by 50% between iOS 17 and iOS 18:

In iOS 16, only 4 apps used the SwiftUI-based app lifecycle, and this number grew to 14 in iOS 17. In iOS 18, 19 apps are now using the SwiftUI-based app lifecycle:

/Applications/Batteries.app/Batteries
/Applications/ClarityCamera.app/ClarityCamera
/Applications/ClarityPhotos.app/ClarityPhotos
/Applications/FinanceUIService.app/FinanceUIService
/Applications/FTMInternal-4.app/FTMInternal-4
/Applications/GAXApp.app/GAXApp
/Applications/LimitedAccessPromptView.app/LimitedAccessPromptView
/Applications/MusicRecognition.app/MusicRecognition
/Applications/PASViewService.app/PASViewService
/Applications/Preferences.app/Preferences
/Applications/Print Center.app/Print Center
/Applications/ProductKitViewer.app/ProductKitViewer
/Applications/SafetyMonitorApp.app/SafetyMonitorApp
/Applications/ShazamEventsApp.app/ShazamEventsApp
/private/var/staged_system_apps/Calculator.app/Calculator
/private/var/staged_system_apps/Passwords.app/Passwords
/private/var/staged_system_apps/Weather.app/Weather
/System/Library/CoreServices/AegirProxyApp.app/AegirProxyApp
/System/Library/CoreServices/ShortcutsActions.app/ShortcutsActions

The new apps in iOS 18 using the SwiftUI-based app lifecycle are:

• Calculator
• Passwords
• Print Center
• GAXApp related to the Guided Access feature
• LimitedAccessPromptView to access a person’s contact data
• ProductKitViewer

Evolution of the programming languages

By analyzing all major releases of iOS from iPhone OS 1.0 to iOS 18, we can see the evolution of the programming languages used by iOS. Again please note that a single binary can be counted multiple times, so the sum of the binaries in this graph is greater than the total number of binaries:

Some trends can be better visualized by displaying percentages:

UIKit versus SwiftUI

Up until now, we compared SwiftUI to all binaries. SwiftUI being a UI framework, it would be fairer to compare it to other binaries displaying some UI. Native iOS apps can be built with 2 different UI frameworks: UIKit and SwiftUI (note that it is possible to mix both). My approach to count the number of binaries containing UI is not perfect but should give an approximate trend: I simply check if the binaries link against the UIKit or SwiftUI frameworks.

In iOS 18, the number of apps using UIKit only grew by around 8%, while the number of apps using SwiftUI grew by more than 50%:

We can clearly observe this trend with percentages:

An interesting point to note is that iOS 18 introduced a new SwiftUICore framework, which is used by UIKitCore (and indirectly by UIKit). This was likely done to help integrate some low-level SwiftUI code with UIKit.

Extended BlastDoor

iOS 14 introduced a new security feature called BlastDoor, designed to help protect the system by isolating untrusted data arriving in Messages and Apple Identity Services (IDS).

iOS 18 appears to have extended BlastDoor to help prevent attacks from more vectors:

/System/Library/PrivateFrameworks/BlastDoor.framework/BlastDoor
/System/Library/PrivateFrameworks/BlastDoor.framework/Resources/BlastDoorPosterArchiveBridging.bundle/BlastDoorPosterArchiveBridging (NEW)
/System/Library/PrivateFrameworks/CTBlastDoorSupport.framework/CTBlastDoorSupport (NEW)
/System/Library/PrivateFrameworks/IDSBlastDoorSupport.framework/IDSBlastDoorSupport
/System/Library/PrivateFrameworks/IDSBlastDoorSupport.framework/XPCServices/IDSBlastDoorService.xpc/IDSBlastDoorService
/System/Library/PrivateFrameworks/MediaAnalysisBlastDoorSupport.framework/MediaAnalysisBlastDoorSupport (NEW)
/System/Library/PrivateFrameworks/MediaAnalysisBlastDoorSupport.framework/XPCServices/MediaAnalysisBlastDoorService.xpc/MediaAnalysisBlastDoorService (NEW)
/System/Library/PrivateFrameworks/MessagesBlastDoorSupport.framework/MessagesBlastDoorSupport
/System/Library/PrivateFrameworks/MessagesBlastDoorSupport.framework/XPCServices/MessagesAirlockService.xpc/MessagesAirlockService
/System/Library/PrivateFrameworks/MessagesBlastDoorSupport.framework/XPCServices/MessagesBlastDoorService.xpc/MessagesBlastDoorService
/System/Library/PrivateFrameworks/TelephonyBlastDoorSupport.framework/TelephonyBlastDoorSupport (NEW)
/System/Library/PrivateFrameworks/TelephonyBlastDoorSupport.framework/XPCServices/TelephonyBlastDoorService.xpc/TelephonyBlastDoorService (NEW)

As of this writing, the Apple Platform Security documentation has not yet been updated for iOS 18, but I am eager to learn more about these new security features.

Secure Enclave

The Secure Enclave is a hardware-based security component, isolated from the main processor to provide an extra layer of security. It was initially introduced with the iPhone 5S to ensure the security of sensitive user data, playing a critical role for Touch ID, Face ID, and Apple Pay.

In the What's new in Swift session (5:35) of the WWDC22, Apple stated that Swift is now suitable for restricted environments like the Secure Enclave Processor.

The Secure Enclave in iOS 17 and iOS 18 contains the same number of binaries. To my surprise, the dxio binary was renamed to dxio_swift. However, a brief analysis of this binary did not reveal typical Swift artifacts. This could be explained by the use of a specialized Swift compiler with dedicated optimizations. Until a more detailed analysis is conducted, I will consider this binary to be using Swift:

In comparison, the Secure Enclave on macOS clearly uses Swift in the hibernation binary:

Raw Data

You can download below the raw data I generated for all major releases of iOS from iPhone OS 1.0 to iOS 18.0.

Want to support this blog? Please check out

DotChart - DOT and Graphviz Preview

• Easily preview DOT diagrams
• Live update when editing
• Capture screenshots
• Quick Look integration
• Free download on the Mac App Store

Conclusion

Even though we don’t have access to the iOS source code, we can determine the programming languages used to create the built-in apps in iOS and we can measure the evolution of these languages from iPhone OS 1.0 to iOS 18.

Unsurprisingly, the number of apps adopting Swift and SwiftUI continues to grow this year. In iOS 18, it also seems that Apple is starting or planning to use Swift in the low-level firmware of the Secure Enclave.

As previously mentioned, this approach has obviously some limits and while I believe the overall picture to be accurate, I can’t guarantee that the results are perfectly exact. If you think that I missed something, please reach out to me on Mastodon @timac@mastodon.social.