Apple 在 iOS 17 中使用 Swift 和 SwiftUI
Apple's use of Swift and SwiftUI in iOS 17

原始链接: https://blog.timac.org/2023/1019-state-of-swift-and-swiftui-ios17/

总结 Timac 的《分析 iOS 17:二进制文件数量、使用的编程语言》文章: 在 iOS 17 中,二进制文件总数达到 6030 个,高于 iOS 16 中的 5403 个。SwiftUI 的使用量显着增加,超过一半 (14) 的 Apple 自家应用程序切换到 SwiftUI 而不是 UIKit。 此外,包含 Swift 代码的二进制文件数量几乎是 iOS 16 中的四倍(385 个)。但是,iOS 17 仍然主要使用 Objective-C、C 和 C++,约占所有二进制文件的三分之二。 这种模式表明,尽管苹果鼓励开发人员采用更新的技术,但传统方法仍然很流行。 最后,Secure Enclave 中似乎不存在使用 Swift 的二进制文件; 然而,根据 Apple WWDC22 会议期间的评论,它最终可能会出现在较低级别的系统组件中。 与往常一样,由于方法和工具集的限制,有必要对这些发现进行相应的解释。

为了解决您对所呈现图表中的相关性、因果关系和统计显着性的担忧,有必要考虑开发人员用于收集和分析二进制数据的方法的含义。 以下是需要考虑的几点: 1. The dataset includes binaries from official open-source projects, including Alamofire, AFNetworking, and FBSDKOpenUtils, which are widely adopted and contribute significantly to the overall statistics. 2. 为了检查趋势并得出有效结论,数据集必须包括影响编程语言和框架使用的所有相关因素。 然而,根据文章和随附材料中提供的有限数据,没有充分考虑使用频率和二进制大小之间的关系。 因此,变量之间的相关性可能会歪曲因果关系或由于隐藏变量而产生误导。 3. 影响统计数据的另一个关键方面是各个应用程序内软件大小和组件数量的分布。 如果某些应用程序倾向于合并更大的组件,或者同时使用 Objective-C 和 Swift 的组件,那么数据集中的平均组件数量将会增加。 因此,图表中显示的平均值或中位数可能会扭曲整个行业组件使用的实际情况。 关于因果关系和统计显着性,根本问题在于将组合频率、平均二进制大小和组件计数混为一谈,同时忽略了潜在的解释变量。 如果不通过实验设计或稳健的回归分析来控制或隔离影响变量关系的变量,从这些指标中得出的断言或主张无法证明因果关系或统计显着性。 此外,这些数据集中包含的样本量相对较小,可能导致高标准误差。 基于这些限制,建议在考虑影响或从这些数字或图表中得出推论时谨慎行事。 最终,源自它们的解释的有效性在很大程度上取决于它们的严谨性和准确性。
相关文章

原文

Now that iOS 17 is available, let’s analyze its built-in apps to answer a few questions: How many binaries are in iOS 17? Which programming languages are used to develop these apps? How many apps are written with Swift? What is the percentage of apps using SwiftUI versus UIKit?

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

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. Note that this year, I analyzed the Secure Enclave.

  • 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. One example is a Mac app I developed, Dependencies, where I use Swift, Objective-C, C++, and C, the most appropriate programming language used to solve each specific problem. 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.

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

Unsurprisingly, there has been a significant increase in the number of apps adopting SwiftUI this year. Notable mentions include:

  • The Preferences app with several of its bundles (StorageSettingsUI, WallpaperSettings, MultitaskingAndGesturesSettings, ThirdPartyApplicationSettings, ActionButtonSettings, …)
  • Several binaries related to Health (Health.app, HealthUI, MentalHealthUI, WorkoutUI, …)
  • The Home app, which appears to have undergone some major changes (Home.app, HomeEnergyUI, HomeUICommon, HomeDataModel, HomeAccessoryControlUI, …)
  • The support for the new Action button (ActionButtonSettings, ActionButtonConfigurationUI, …)
  • Additionally, several other important apps, such as Calendar and Reminders, are now using SwiftUI

In iOS 16, only 4 apps used the SwiftUI-based app lifecycle. In iOS 17, this figure has grown to 14 apps:

/Applications/Batteries.app/Batteries
/Applications/ClarityCamera.app/ClarityCamera
/Applications/ClarityPhotos.app/ClarityPhotos
/Applications/FinanceUIService.app/FinanceUIService
/Applications/FTMInternal-4.app/FTMInternal-4
/Applications/MusicRecognition.app/MusicRecognition
/Applications/PASViewService.app/PASViewService
/Applications/Preferences.app/Preferences
/Applications/SafetyMonitorApp.app/SafetyMonitorApp
/Applications/ShazamEventsApp.app/ShazamEventsApp
/Applications/WorkoutRemoteViewService.app/WorkoutRemoteViewService
/private/var/staged_system_apps/Weather.app/Weather
/System/Library/CoreServices/AegirProxyApp.app/AegirProxyApp
/System/Library/CoreServices/ShortcutsActions.app/ShortcutsActions

The Swift and SwiftUI adoption continues its climb: iOS 17 now contains 385 binaries using SwiftUI. Likewise the number of binaries containing at least one line of Swift code increased by 50% between iOS 16 and iOS 17:

By analyzing all major releases of iOS from iPhone OS 1.0 to iOS 17, 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:

What can we learn from these graphs?

  • Objective-C is still at the core of iOS and is used directly or indirectly by most apps
  • The adoption of Swift and SwiftUI continues to grow rapidly
  • The share of Objective-C, C and C++ continues to decrease

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.

For the first time, the number of binaries exclusively using UIKit has decreased in comparison to the previous year:

By displaying percentages, we can confirm that SwiftUI is clearly increasing in Apple’s own apps:

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:

In iOS 17, the Secure Enclave contains 19 binaries, and to my surprise, none of them are using Swift:

So is Swift used in the Secure Enclave? Yes! It turns out that the hibernation binary in macOS Ventura is using Swift:

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

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 17.

Swift and SwiftUI adoptions continue their growth: the number of binaries using these frameworks increased by 50% between iOS 16 and iOS 17. Another good sign of dogfooding is the more widespread use of the SwiftUI-based app lifecycle. Also for the first time, the number of binaries exclusively using UIKit has decreased in comparison to the previous year.

In the upcoming years, it will be interesting to observe whether Swift begins to spread into low-level firmware, such as the Secure Enclave. Currently, Swift is absent from the Secure Enclave in iOS, although macOS does incorporate it.

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 @[email protected].

联系我们 contact @ memedata.com