Still No Trust: iOS Data Flow Restrictions Remain Bypassable in iOS 27.0.1

More than three years after our initial reports, we revisited the iOS data flow restriction bypasses on iOS 27.0.1. While Apple has closed at least one of the previously demonstrated paths, the fundamental problem remains: data can still cross the managed/unmanaged boundary using built-in iOS functionality.

In 2023, we reported several ways to circumvent Apple’s Managed Open In and Managed Pasteboard restrictions. These MDM controls are intended to separate corporate and personal data on managed iOS devices. In our previous article, No Patch, no Trust: Consequences of iOS Data Flow Restriction Bypasses for Enterprises, we discussed the consequences of these bypasses for enterprise deployments.

The previously demonstrated bypasses included the preinstalled Shortcuts app, Quick Look, and two additional issues involving the Files app. At the time, Apple responded to our reports by stating:

“MDM profiles provide configuration management but do not establish additional security boundaries beyond what iOS and iPadOS have to offer.”

Nevertheless, Apple continues to describe these MDM mechanisms as tools for protecting corporate data and separating managed from unmanaged environments.

Retest with iOS 27.0.1

We have now repeated our tests on an iPhone 16e running iOS 27.0.1, configured with the same data flow restrictions as in our previous tests:

allowOpenFromManagedToUnmanaged = false
allowOpenFromUnmanagedToManaged = false
requireManagedPasteboard = true

The result is mixed, but not reassuring:

  • Managed → unmanaged: A user can still use the preinstalled Shortcuts app to bypass the restrictions. Content originating from the managed side can be transferred to the unmanaged side using the clipboard and a simple shortcut. This works for simple text but also for files. (See screenshot examples)
  • Unmanaged → managed: For the opposite direction, the user can still use the Quick Look functionality of iOS, when a managed and an unmanaged file is present in the recents tab of the iOS file app. This is the case, when the files were viewed recently with their managed and unmanaged viewer apps, respectively. When checking the unmanaged file, the UI only provides unmanaged app in the “Open With” action. In the shown example this is the “PDF viewer” app. But when the user instead uses the “Quick Look” option, the user can choose the managed viewer app (on the bottom of the new view) to open the unmanaged file in the managed viewer app. This is “Acrobat” in the shown example.
  • Our previously demonstrated delete-and-copy bypass using the Files app is no longer effective. In our tests the option to paste a document into a folder is not provided, if the document would cross the managed/unmanaged border.

The last point indicates that Apple has changed some of the affected functionality since our previous tests. However, the actual security objective, reliably enforcing the managed/unmanaged data-flow boundary, is still not achieved.

Apple’s Intended Data Flow Restrictions

This result is particularly relevant when compared with Apple’s own description of these mechanisms. In its current Managing Devices and Corporate Data document (April 2022, accessed October 28, 2026), Apple describes Managed Open In as three separate functions designed to protect corporate data. Regarding data flowing from managed to unmanaged destinations, Apple states:

“Allow documents from managed sources in unmanaged destinations. Enforcing this restriction helps prevent an organization’s managed sources and accounts from opening documents in a user’s personal destinations.”

Apple also gives the explicit example:

“This restriction could prevent a confidential email attachment in your organization’s managed mail account from being opened in any of the user’s personal apps.”

More specifically, Apple states:

“When the restrictions above are enforced, pasting of content is designed to respect the Managed Open In boundary between third-party or Apple apps like Calendar, Files, Mail, and Notes.”

Finally, Apple explicitly summarizes the intended separation:

“On the most basic level, these three functions help divide the managed device into two environments: one for managed corporate apps and data and one for unmanaged personal apps and data.”

Our results on iOS 27.0.1 show that this intended separation can still be bypassed in both directions using built-in iOS functionality, as shown in the original proof-of-concept video.

Built-in Functionality Still Crosses the Boundary

The remaining bypasses are particularly problematic because they do not depend on obscure third-party applications. iOS deeply integrates Shortcuts app and provides access to the system clipboard. In our tests, this functionality still allows data to cross the configured boundary from managed to unmanaged. In the opposite direction, a user can still use Quick Look to transfer data from unmanaged to managed.

Quick Look-related bypasses are also not a new problem. As already referenced in our 2023 article, SySS GmbH reported an MDM restriction bypass involving Quick Look in 2020 and demonstrated the issue in a proof-of-concept video.

Still No Effective Mitigation

The situation has therefore improved in one respect: the previously demonstrated delete-and-copy technique in the Files app appears to have been closed, as the option to paste a deleted managed file to an unmanaged folder is not available anymore. However, this does not solve the fundamental problem.

Due to the deep integration of Shortcuts and Quick Look into iOS, there is no effective technical mitigation in our tested configuration that reliably enforces the intended data-flow boundary while retaining this system functionality.

A short-term solution could be to delete the iOS Shortcuts app from the devices and block the installation with the MDM blacklist via the bundle ID “com.apple.shortcuts” or to exclude devices with installed Shortcuts app from the domain as non-compliant, depending on the provided functionality of the MDM solution used.

Since iOS27 Apple provides a “Denied App” functionality with the “App settings declarative configuration for Apple devices”. However, our tested Omnissa Workspace ONE UEM (AirWatch) MDM version (26.7.1829.6 (2607)) did not enforce this configuration. The MDM log indicates that the phone rejected the configuration payload. Workspace ONE UEM may have generated the configuration data incorrectly, as we can only provide the bundle ID for this configuration entry. Workspace ONE UEM then generates content for this MDM setting that is rejected by the iPhone.

However, blocking requires a bundle ID. In contrast to the Shortcuts app, Quick Look is an integral part of iOS for previewing and interacting with content. It is not a store app with a bundle ID. Therefore, administrators cannot mitigate the Quick Look bypass with the “Denied App” MDM feature.

Conclusion

The conclusion therefore remains essentially unchanged from our 2023 assessment:

Enterprises should not consider Managed Open In and Managed Pasteboard a reliable security boundary for preventing data transfer between managed and unmanaged apps.

Some individual bypass techniques may disappear over time. But as long as built-in iOS functionality still permits data to cross this boundary in both directions, the fundamental security problem remains.

Additional Consideration for COPE Environments

Organizations using Corporate-Owned, Personally Enabled (COPE) devices should also be aware that the managed/unmanaged data flow issue is not the only challenge when trying to maintain a strict separation between corporate and personal data on iOS.

As we have discussed in our previous article,“Security Implications of Apple ID Switching and Keychain Merging in COPE Mobile Environments”, Apple ID switching and Keychain merging can create an additional path through which the intended separation of corporate and personal information may be weakened.

Enterprises with COPE deployments should therefore be aware of both issues when assessing to what extent iOS can technically enforce the intended separation between corporate and personal data.

Four Languages in Every App: The Hidden Complexity of the iOS App Store

Objective-C has been the foundational language of the iOS ecosystem, serving as the primary language for building applications on Apple’s mobile platform. But times have changed. In our study [1] of 84,000 unique iOS apps collected over five years (2020-2025), we found that today’s App Store hosts a rich variety of programming languages. Modern iOS apps frequently combine multiple languages such as Swift, Objective-C, C++, JavaScript, C#, Dart (Flutter), and Kotlin. This growing diversity has direct implications for security analysis.

An IPA with its contents.

Automated security scanners rely on dataflow analysis to trace whether sensitive user data like location, contacts, or health records could be leaked to unintended destinations, sent over the network, or collected by tracking libraries. These analyses must understand the specific binary constructs each language produces, and they can only protect what they can parse. As the language landscape of iOS grows more diverse, keeping track of which languages are actually in use becomes essential for building tools that can keep up. In our ongoing research project XDaFlowD, we are actively developing tools to address this gap by building analysis capabilities that can handle the multi-language reality of today’s iOS ecosystem.

Language Traces in App Packages

An iOS app is distributed in the ipa format, which is essentially a zip archive containing configuration data, executable binaries in Apple’s Mach-O format, and various resources such as images or web content. Programming languages leave traces in the metadata that surrounds the executable code. Our goal was to perform a fast language analysis, so we focused on easily accessible language traces within the binary. Further details on our methodology can be found in [1].

Four Languages in Every App

Detected languages in the monthly app samples January 2020 - January 2025.
Detected languages in the monthly app samples of the top 2,000 popular apps in the iOS app store in January 2020 and January 2025.

We tracked the 2,000 most popular free apps in the iOS App Store monthly over five years, covering more than 84,000 distinct apps in total. By January 2025, four languages had become nearly universal among popular apps: Objective-C, JavaScript, C++, and Swift. But this was not always the case. Swift in particular showed clear growth as Apple’s actively promoted language, rising from a presence of about two-thirds of apps in January 2020 to nearly all of them, yet without replacing Objective-C. We also observed newer cross-platform technologies gaining ground. Flutter, Kotlin, and the cross-platform framework React Native all showed notable growth. This points to an increasingly diverse iOS development landscape, where apps are built from a mix of many languages and frameworks.

New Languages, New Blind Spots

Emergence of new languages and cross-platform technologies in the iOS app store.
Emergence of new languages and cross-platform technologies in the iOS App Store: Kotlin, traditionally associated with Android development, first appears in mid-2020, while Flutter with its underlying language Dart shows rapid and sustained adoption over the five-year observation period.

As new languages and frameworks enter the iOS ecosystem, the tools used to analyze and secure these apps do not yet fully support them. Dart, the language behind Flutter, is barely supported by existing analysis tooling. React Native compiles JavaScript into Hermes bytecode, a bytecode format that cannot even be loaded by widely used reverse engineering tools like Ghidra [2]. This means that a growing portion of the code inside popular apps is effectively invisible to current security analysis. The more diverse the development landscape becomes, the larger these blind spots grow. To address this, we are actively building new tooling to support these emerging languages and enable dataflow analysis across language boundaries, with the goal of keeping security scans of mobile iOS apps up to date with how these apps are actually built today.

References.

[1] Florian Magin, Fabian Scherf, Martin Renze, Cléo Fischer, and Gwendal Patat. 2025. Measuring While Playing Fair: An Empirical Analysis of Language and Framework Usage in the iOS App Store. In Proceedings of the 2025 Workshop on Software Understanding and Reverse Engineering (SURE ’25). Association for Computing Machinery, New York, NY, USA, 41–47. https://doi.org/10.1145/3733822.3764671

[2] National Security Agency. 2019. Ghidra Reverse Engineering Framework. Available: https://github.com/NationalSecurityAgency/ghidra

Interactive App Security Reports – Powered by AI

With Appicaptor, we analyze mobile apps with a strong focus on their IT security quality. We provide companies with well-founded assessments of potential risks. These analyses serve as an important decision-making foundation for IT departments and security managers. However, we also know that in practice, receiving complex and extensive analysis reports often leads to very specific follow-up questions. Customers want more details about particular analysis criteria, the relevance in their environment, or background information on specific security issues. Such details are mostly already documented, but sometimes can require some effort to find due to the report’s size. 

To lower the barrier and improving the understanding of result implications for users, in a first step we are currently researching the possibilities for an AI-powered follow-up system on app security reports, based on our current Appicaptor reports.  

Technical Approach 

The centerpiece of the new interactive capability is a Large Language Model (LLM) that acts as a conversational interface to our analysis data and IT security expertise. To achieve this, we are using domain-specific embeddings that enrich the LLM with the context it needs to provide precise, reliable answers. The embeddings are generated from three main knowledge sources: the analysis results of a customer’s individual app report, the structured descriptions of our evaluation criteria (covering aspects such as data protection, cryptographic usage, platform-specific guidelines or permission management), and specialized knowledge from the domain of mobile app security, consolidated from best practices, common vulnerabilities, and security standards. 

By combining these data sources, the aim of our development is that the LLM can go beyond simple report summaries. Instead, thanks to the embedding approach, it retrieves relevant information from the curated knowledge base before responding. This minimizes the likelihood of incorrect outputs and ensures that responses stay consistent and precise. Through customer-specific data loading, privacy through the self-hosted LLM is guaranteed. Furthermore, data is not used for training nor could the LLM access content of other customers reports. 

Added Value for Customers 

With this development, we will reduce the effort required to understand complex security criteria. Instead of issuing additional requests or conducting further research, customers then can instantly receive tailored explanations. Responses are based on their customized report data, combined with industry knowledge. This saves time, improves transparency, and creates confidence in decision-making about which apps to approve or restrict. 

Outlook – Preview at it-sa in Nuremberg 

Although this development is still underway, we want our customers and interested visitors to experience it and get early feedback. That’s why we will showcase a preliminary version of the AI-powered follow-up system at it-sa in Nuremberg from October 7th to October 9th, 2025. You can find us at Hall 6, Booth 416. Visitors will be able to explore the system live and see firsthand the benefits of interactive app security AI reports. 

Apple’s Required Reason API: Aftermath after one year in practice

Apple designed the “Required Reason” API to enhance user privacy and trust. It helps ensure that app developers clearly communicate the reasons for requesting access to personal data or certain device capabilities. The guideline is now active for almost a year, and we’ve observed that this approach seems to generally work. But in practice, we observe some developers sneaking around these restrictions without Apple acknowledging this fact.

A smartphone with a shield symbol on the screen is shown beside a red apple with a bite taken out of it, symbolizing incomplete privacy.

As we approach the first anniversary of Apple’s Required Reasons API, we feel it’s time to recap it’s privacy gains in practice.

For developers, the Required Reasons API acts as a gatekeeper into the app store. It requires them to provide clear justifications for using certain APIs that access sensitive user data or system capabilities. The users can then inspect and evaluate the provided reason during app install. The principle behind this API is to promote transparency and user control over personal data. A significant contribution is the seamless integration of third-party library required reasons into the main app. This has ensured that the privacy measures extend beyond the core app, covering all the integrated elements.

Diving into the Details: Boot Time Example

To illustrate this, let’s take the example of boot time. The boot time of a device in microseconds is unique and can easily be used for device identification. Thus, such data requires sufficient protection to hinder device fingerprinting and therewith protecting the user’s privacy. Apple has identified two boot time related APIs: systemUptime and mach_absolute_time(). These require developers to provide specified reasons for their use. Apps or libraries accessing these methods must provide a reason in the app’s/library’s PrivacyInfo.xcprivacy file. This XML-file contains among other things a key specifying a resource linked with a reason for accessing this resource. Apple provides different short identifiers which specify a usage purpose as shown here:

<key>NSPrivacyAccessedAPICategorySystemBootTime</key>
<string>35F9.1</string>

In this example, the short identifier specifies the following reason, documented by Apple:

“Declare this reason to access the system boot time in order to measure the amount of time that has elapsed between events that occurred within the app or to perform calculations to enable timers. Information accessed for this reason, or any derived information, may not be sent off-device. There is an exception for information about the amount of time that has elapsed between events that occurred within the app, which may be sent off-device.”

A Year of Practice: The Good…

To evaluate these advancements in practice, we have collected the most popular third-party libraries for iOS apps. Next, we searched for libraries, known for device fingerprinting activities. The Required Reason API typically impacts such libraries the most, since they heavily rely on this data. In practice, the top three libraries leveraging device fingerprinting techniques make up more than 80% market share. Thus, analysing the top three libraries already provides broad coverage. We found that the top three libraries in fact use APIs from the “Required Reasons API” list, but provide a proper reason declaration. This means, that whenever a respective API is used, an appropriate cause in the PrivacyInfo.xcprivacy is provided. Thus, developers are adhering to the rules, and/or Apple is effectively enforcing these rules in the App Store.

…and the Bad

However, we have observed instances in some used libraries where developers have found ways around these obligations. These libraries use other methods for querying boot time, such as sysctl and sysctlbyname.

In iOS, sysctl and sysctlbyname are system calls enabling access to kernel parameters at runtime. They allow developers to query essential information about the system, such as CPU and memory statistics or the boot time. The sysctlbyname call offers a more user-friendly access method by using string identifiers instead of integers. Thus, an alternative way to query the boot time with this function would be:

sysctlbyname("kern.boottime", &bootTime, &size, nil, 0)

Additionally enforcing these APIs would require evaluating the arguments during the static analysis in Apple’s app publishing process. Evaluating the arguments during a static code analysis can sometimes be complicated if the argument isn’t a constant. Advanced techniques like symbolic execution or data dependency analysis might be necessary, features already applied in Appicaptor.

We have already contacted Apple on May 2nd, 2024 and informed them about missing items in their Required Reason API. However, they did not respond up until this day. We think that Apple is well aware of these APIs but doesn’t want to confirm this due to political reasons.

The Road Ahead

In conclusion, we see that Apple strides in the right direction, but there are still loopholes that need to be addressed. We look forward to seeing Apple continue to enhance its privacy measures, closing remaining gaps. Meanwhile, we continue to monitor Apple’s Required Reason APIs usage with Appicaptor and check for violations.

Visit us at it-sa 2024: Threats of Device Fingerprinting for Enterprises

What data is transferred by business apps, and how secure is their processing? Our research shows: If your employees use apps arbitrarily, you put your company’s security at risk.

At it-sa 2024, we present our app analysis framework Appicaptor. You can use it to automatically check whether apps are compliant with your company’s IT security demands. New results within the Athene funded research project FiDeReMA will improve Appicaptor analysis techniques. Among other things, the goal is to identify and evaluate privacy implications when using arbitrary apps.

A fluffy blue monster holds a smartphone displaying the message "DENY ALL COOKIES," referencing cookie permissions. A bowl of black cookies sits beside it, creating a humorous contrast between the tech message and the monster's love for cookies.

Our current efforts to improve Appicaptor revolve around different privacy aspects:

  • Device fingerprinting
  • App DSGVO Consent Banners
  • Permission piggybacking of Android in app third-party libraries

Device Fingerprinting

Device fingerprinting is a technique used to uniquely identify devices and therewith typically also users. Mobile apps make use of different device properties such for example device name, software version and others. They combine such values mostly with a hashing function to a unique identifier. Use cases for device fingerprinting are app usage statistics, fraud detection and mostly targeted advertisement.

When employees install apps with device fingerprinting on their mobile corporate devices, it can lead to the loss of sensitive business data for companies. Attackers can acquire the collected data and potentially identify the devices of company management, spy on trade secrets, and ascertain customer contacts. In practice, the Cambridge Analytica case shows how sufficient data from various sources can be used to analyze users and manipulate them through targeted advertising, thereby influencing even election results.

Identified Device Fingerprinting Activity for the Top 1.000 Android Apps (source)

Our analysis results show that more than 60% of the top 1,000 apps on Google Play employ device fingerprinting techniques. This allows a unique device identification even across app borders.

We extracted 30,000 domains from the most popular 2,000 iOS and Android apps. Afterwards, we filtered out domain names for the most prevalent device fingerprinters covering 90% market share. We were able to prevent device fingerprinting in 40% of the cases by using publicly available domain blocklists. These lists are specialized on tracking and advertisement domains and can be easily applied to for example a firewall. Another 40% would easily be blockable by updating the blocklist: Some fingerprinters use random subdomains for their communication in the form of https://8726481.iFingerprinter.org giving many possibilities to be blocked.

We also proposed an approach to randomize return values of popular properties used for device fingerprinting. Our results prove that this technique dramatically reduces the uniqueness of the device fingerprint. Nevertheless, respective APIs remain accurate enough for their intended use cases. The hope is that our proposed techniques are included in future Android and iOS releases.

In-App DSGVO Consent Banners

Many of the previously mentioned device fingerprinting properties would typically require user consent as stated by the DSGVO. According to recent court decisions and EU regulations, rejecting must be just as easy as accepting consent banners. However, many companies don’t obey such regulations. Those who obey mostly apply dark pattern to push the user into accepting all tracking.

Example DSGVO Consent Banner with the option to reject all tracking on first instance.

We are currently working on detecting if apps provide a reject option on first instance, without having to click through several submenus. In our attempt, we are employing artificial intelligence to analyse such consent banners for reject options on first instance. The results yield a success rate of 82%. Some apps try hard to remain within legal boundaries but make it hard for users to reject data usage. Can you find the first level reject option in the following consent banner? – Yes there is an option.

Example DSGVO Consent Banner that uses dark patterns to hide reject tracking option.

We have collected the most interesting consent banners and bundled them into a game. With the app “Reject all cookies” you need to overcome several consent banners and keep your data private. Having rejected all “cookies” in the app you can win real cookies at our it-sa 2024 booth (6-314).

Permission piggybacking in Android Apps

Traditionally, Android apps comprise a main application and several supporting libraries. These libraries often inherit permissions from the main app, granting them unnecessary access beyond their core functions. This leads to permission piggybacking, where libraries exploit inherited permissions to gather data without requesting them directly. Advertisement and tracking libraries particularly leverage this tactic to collect extensive user data.

We have developed an analysis tool to detect third-party app libraries only probing for already granted permissions, without ever requesting permissions themselves.

Analysing the top 1,000 apps on Google Play reveals that 50% of the libraries exhibit this permission probing behaviour. Presumably, these libraries then adapt their behaviour according to the granted permissions of the main app. Accordingly, they collect more or less data, as available. Most of the identified libraries exhibiting such behaviour are well-known advertising and tracking libraries. This fact underlines the urge for a finer granular permission system to separate main app and third-party libraries.

Visit us at it-sa 2024 and have a cookie with us!

You’ll find us in hall 6, booth number 6-314 for a demonstration and discussions.

iOS Privacy Manifest: Data Collection and Usage in Top Free iOS Apps

Since May 2024, the inclusion of an iOS Privacy Manifest has been a requirement for app submissions with newly added third-party SDKs. We analyzed first results about data collection practices, compliance issues with Apple’s guidelines, and privacy risks posed by SDK providers.

Apple mandates that all app submissions with specific newly added third-party SDKs have to include a comprehensive iOS Privacy Manifest. This manifest outlines the data collection and usage practices of apps, providing users with transparency and empowering them to make informed decisions about their digital privacy. As outlined in our previous blog post, Appicaptor correlates the privacy manifest contents with additional privacy findings through static analysis.

In our evaluation, we analyzed the iOS Privacy Manifests definitions of our app sample set, that consists of the most popular 2,000 free iOS apps available on the German Apple App Store in June 2024.

Apple mandates that apps with newly added third-party software development kits (SDK) of one of the 86 listed third-party SDKs have to include a iOS Privacy Manifest (see Apple Developer Support). Our analysis of the app sample set revealed the presence of all 86 SDKs in at least one app. We evaluated whether apps integrating these SDKs adhered to the privacy manifest requirement: Our findings indicate that only 47 out of the 86 SDKs were associated with at least one app that defined a privacy manifest. Conversely, the remaining 39 SDKs were utilized at least within one app within the sample set, but no app employing these SDKs defined a privacy manifest. This discrepancy may stem from the following factors: either the SDK developers may have not provided a privacy manifest template for their SDKs, or the app developers have not incorporated SDK versions that include privacy manifest template or explicitly deleted the manifest entry, or the app update does not include a newly added third-party SDK from the list. So our analysis can only investigate the Privacy Manifest declarations of about half of the libraries that Apple has selected. However, these first results already provide interesting insights in the data analytics industry.

What data is requested in real apps and why?

As first evaluation on the manifest content, we evaluated the data types declared within the iOS Privacy Manifests of our app sample set. Our analysis revealed that 50% of the apps declare in the manifest that they collect data types such as OtherDiagnosticData, CrashData, and DeviceID. Especially the data type DeviceID is privacy-sensitive as it provides the possibility to correlate actions of users across the sandbox boundaries of individual apps.

The full list of collected data types and the number of apps in which such data is collected according to the privacy manifest is given in the following graph. It can be seen, that a wide range of data types are defined in the app set, including very sensitive data types as Health (Health and medical data), PhysicalAddress, PreciseLocation and SensitiveInfo (racial or ethnic data, sexual orientation, pregnancy or childbirth information, disability, religious or philosophical beliefs, trade union membership, political opinion, genetic information, or biometric data).

Although Apple clearly specifies how data type classes should be defined in the iOS Privacy Manifest, we found 205 apps within our app sample set that included malformed or self-defined data types in iOS Privacy Manifests. Consequently, these do not align with Apple’s specified requirements and the discrepancy highlights issues in the implementation and adherence to Apple’s guidelines.

Following the evaluation of data types, we proceeded to assess the given purposes. The next graph presents the distribution of purposes defined in the iOS Privacy Manifests per app. Our analysis indicates that collecting data is declared for the purposes of AppFunctionality or Analytics in over 60% of the apps of the sample set. Consistent with our findings in the data type evaluation, we observed that a substantial number of apps (235 apps) which included purpose definitions deviate from Apple’s expected values. These are summarizes in the category Malformed / Self-defined Purpose in the chart below.

Do the declared data type and their reasoning align?

Further analysis was conducted to determine which data types are collected for which specific purpose and in how many apps of the app sample set this occurs. For this evaluation, we analyzed the iOS Privacy Manifest definitions of the 2,000 apps in our sample set, focusing on tuples of data types and associated purposes. The following graphic illustrates which data types are accessed for which purposes. The size of the circles corresponds to the number of apps in which that specific data type-purpose tuple was defined in the iOS Privacy Manifest. It is interesting to see, that collecting certain sensitive data types such as SensitiveInfo, PhysicalAddress, PreciseLocation and Health are declared for purposes besides AppFunctionality and almost all data types are used also for the purpose of Analytics, which could have an effect on user’s privacy.

Are there component providers that stand out in terms of data type and usage?

Data types and purposes are defined for specific components in the iOS Privacy Manifest. For that reason, our next focus was to investigate if specific purposes to collected data types are specific to certain component providers. Therefore, the following analysis examines the purposes for collected data types grouped for each component provider within the iOS Privacy Manifest. The following graph highlights the relationship between purposes and the SDK provider. To do so, we associated the providers to their SDKs and extracted the 20 most frequently contained SDK providers in the Privacy Manifests within the evaluated app set. We analyzed in how many apps each purpose is defined for these top 20 providers within the app set. In the diagram it can be seen that certain providers, such as Firebase, concentrate on a few specific and targeted purposes. In contrast, others, like Adjust, request data for a wide array of purposes. As the purposes relate to the activities of the SDK providers, this can be seen as summary on the functionality aspects provided by the SDK components and their providers.

Similar to the evaluation of the specific purposes related to component providers, we expanded the view to cluster the information according to the data types accessed. To do so, we again took the 20 most frequently mentioned SDK component providers in the Privacy Manifests within the evaluated app set and counted how many apps declare a data type and purpose tuple for these top 20 component providers. In the following graph the size of the circles in the graph corresponds to the number of apps in which each specific data type-purpose tuple was declared in the iOS Privacy Manifest. Like the former evaluation, this graph shows, that certain component providers (like Firebase) focus on certain data type and purpose tuples, whereas other component providers define various data type and purpose tuples (e.g, Google and Facebook).

The data type definition may additionally contain boolean processing flags, that should specify external usage of the data. The processing flag linked specifies that the data type is linked to the user’s identity, whereas tracked specifies that the data type is used to track users. Our final evaluation of the Privacy Manifest data of the app sample set focus on the aspect whether certain data providers specify data types with these processing flags or not.

Data types flagged with tracked can be shared with a data broker. Therefore, if the processing flag tracked or linked/tracked is set, this may threaten the user’s privacy significantly. Therefore, we examined what processing flags are set by different component providers for requested data types. We took the ten most frequently mentioned SDK component providers in the Privacy Manifests within the evaluated app set and analyzed how many apps declare a data type, processing type and purpose tuple for these top ten component providers. The size of the circles in the following graph corresponds to the number of apps in which each specific data type-processing flag-purpose tuple was defined in the iOS Privacy Manifest. The graph groups the data types in relation to the requested purpose in circle groups. The circle group’s label states which processing flags are set to true: If the circle group is labeled with linked, then only the data type is linked to the user’s identity. If circle group is labeled with linked/tracked, then the data type is linked to the user’s identity, and it is used to track users. Elements of a circle group that has no label are neither linked nor tracked.

A significant difference in the processing flag usage can be seen when comparing the results for Google and Facebook. Google defines the processing flag linked or no processing flag for most data types and purposes. In contrast, Facebook sets the processing flag with the most possible extent linked/tracked for most data types and purposes.

Conclusion

The analysis of iOS Privacy Manifests for the 2,000 most popular free iOS apps on the German Apple App Store in June 2024 reveals several insights about data collection practices and compliance with Apple’s guidelines.

About half of the Privacy Manifests in apps have declared to collect data type OtherDiagnosticData, CrashData or DeviceID, with various sensitive data types also being collected. However, the presence of apps with malformed or self-defined data types indicates inconsistencies in adhering to Apple’s guidelines. Additionally, the observed entries for data collection purposes were found to violate Apple’s specification. This undermines the effectiveness of the privacy manifest and hopefully will be addressed with checks by Apple during the app review process.

However, even in this preliminary analysis with a lot of data missing for SDKs, the benefit of the Privacy Manifests can be seen. This way, it is possible to inspect the relations between collected data types, purposes and components, showing that in some apps sensitive data types are collected for purposes not related to the app’s functionality.

The examination of specific data type-purpose tuples and their association with component providers revealed that certain SDK providers, focus on targeted purposes, while others, request data for a broader range of purposes. Notably, the processing flags for data types, particularly those flagged as tracked, pose significant privacy risks. The contrast between providers, which primarily uses the linked flag, and those which extensively use the linked/tracked flag, may underscore the varying levels of privacy impact across different SDK providers.