iOS Pentesting

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

iOS Basics

pageiOS Basics

Testing Environment

In this page you can find information about the iOS simulator, emulators and jailbreaking:

pageiOS Testing Environment

Initial Analysis

Basic iOS Testing Operations

During the testing several operations are going to be suggested (connect to the device, read/write/upload/download files, use some tools...). Therefore, if you don't know how to perform any of these actions please, start reading the page:

pageiOS Basic Testing Operations

For the following steps the app should be installed in the device and should have already obtained the IPA file of the application. Read the Basic iOS Testing Operations page to learn how to do this.

Basic Static Analysis

It's recommended to use the tool MobSF to perform an automatic Static Analysis to the IPA file.

Identification of protections are present in the binary:

  • PIE (Position Independent Executable): When enabled, the application loads into a random memory address every-time it launches, making it harder to predict its initial memory address.

    otool -hv <app-binary> | grep PIE   # It should include the PIE flag
  • Stack Canaries: To validate the integrity of the stack, a ‘canary’ value is placed on the stack before calling a function and is validated again once the function ends.

    otool -I -v <app-binary> | grep stack_chk   # It should include the symbols: stack_chk_guard and stack_chk_fail
  • ARC (Automatic Reference Counting): To prevent common memory corruption flaws

    otool -I -v <app-binary> | grep objc_release   # It should include the _objc_release symbol 
  • Encrypted Binary: The binary should be encrypted

    otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # The cryptid should be 1

Identification of Sensitive/Insecure Funcions

  • Weak Hashing Algorithms

    # On the iOS device
    otool -Iv <app> | grep -w "_CC_MD5"
    otool -Iv <app> | grep -w "_CC_SHA1"
    # On linux
    grep -iER "_CC_MD5"
    grep -iER "_CC_SHA1"
  • Insecure Random Functions

    # On the iOS device
    otool -Iv <app> | grep -w "_random"
    otool -Iv <app> | grep -w "_srand"
    otool -Iv <app> | grep -w "_rand"
    # On linux
    grep -iER "_random"
    grep -iER "_srand"
    grep -iER "_rand"
  • Insecure ‘Malloc’ Function

    # On the iOS device
    otool -Iv <app> | grep -w "_malloc"
    # On linux
    grep -iER "_malloc"
  • Insecure and Vulnerable Functions

    # On the iOS device
    otool -Iv <app> | grep -w "_gets"
    otool -Iv <app> | grep -w "_memcpy"
    otool -Iv <app> | grep -w "_strncpy"
    otool -Iv <app> | grep -w "_strlen"
    otool -Iv <app> | grep -w "_vsnprintf"
    otool -Iv <app> | grep -w "_sscanf"
    otool -Iv <app> | grep -w "_strtok"
    otool -Iv <app> | grep -w "_alloca"
    otool -Iv <app> | grep -w "_sprintf"
    otool -Iv <app> | grep -w "_printf"
    otool -Iv <app> | grep -w "_vsprintf"
    # On linux
    grep -R "_gets"
    grep -iER "_memcpy"
    grep -iER "_strncpy"
    grep -iER "_strlen"
    grep -iER "_vsnprintf"
    grep -iER "_sscanf"
    grep -iER "_strtok"
    grep -iER "_alloca"
    grep -iER "_sprintf"
    grep -iER "_printf"
    grep -iER "_vsprintf"

Basic Dynamic Analysis

Check out the dynamic analysis that MobSF perform. You will need to navigate through the different views and interact with them but it will be hooking several classes on doing other things and will prepare a report once you are done.

Listing Installed Apps

Use the command frida-ps -Uai to determine the bundle identifier of the installed apps:

$ frida-ps -Uai
 PID  Name                 Identifier
----  -------------------  -----------------------------------------
6847  Calendar   
6815  Mail       
   -  App Store  
   -  Apple Store
   -  Calculator 
   -  Camera     
   -  iGoat-Swift          OWASP.iGoat-Swift

Basic Enumeration & Hooking

Learn how to enumerate the components of the application and how to easily hook methods and classes with objection:

pageiOS Hooking With Objection

IPA Structure

The structure of an IPA file is essentially that of a zipped package. By renaming its extension to .zip, it can be decompressed to reveal its contents. Within this structure, a Bundle represents a fully packaged application ready for installation. Inside, you will find a directory named <NAME>.app, which encapsulates the application's resources.

  • Info.plist: This file holds specific configuration details of the application.

  • _CodeSignature/: This directory includes a plist file that contains a signature, ensuring the integrity of all files in the bundle.

  • A compressed archive that stores asset files like icons.

  • Frameworks/: This folder houses the application's native libraries, which may be in the form of .dylib or .framework files.

  • PlugIns/: This may include extensions to the application, known as .appex files, although they are not always present. * Core Data: It is used to save your application’s permanent data for offline use, to cache temporary data, and to add undo functionality to your app on a single device. To sync data across multiple devices in a single iCloud account, Core Data automatically mirrors your schema to a CloudKit container.

  • PkgInfo: The PkgInfo file is an alternate way to specify the type and creator codes of your application or bundle.

  • en.lproj, fr.proj, Base.lproj: Are the language packs that contains resources for those specific languages, and a default resource in case a language isn' t supported.

  • Security: The _CodeSignature/ directory plays a critical role in the app's security by verifying the integrity of all bundled files through digital signatures.

  • Asset Management: The file uses compression to efficiently manage graphical assets, crucial for optimizing application performance and reducing its overall size.

  • Frameworks and PlugIns: These directories underscore the modularity of iOS applications, allowing developers to include reusable code libraries (Frameworks/) and extend app functionality (PlugIns/).

  • Localization: The structure supports multiple languages, facilitating global application reach by including resources for specific language packs.


The Info.plist serves as a cornerstone for iOS applications, encapsulating key configuration data in the form of key-value pairs. This file is a requisite for not only applications but also for app extensions and frameworks bundled within. It's structured in either XML or a binary format and holds critical information ranging from app permissions to security configurations. For a detailed exploration of available keys, one can refer to the Apple Developer Documentation.

For those looking to work with this file in a more accessible format, the XML conversion can be achieved effortlessly through the use of plutil on macOS (available natively on versions 10.2 and later) or plistutil on Linux. The commands for conversion are as follows:

  • For macOS:

$ plutil -convert xml1 Info.plist
  • For Linux:

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Among the myriad of information that the Info.plist file can divulge, notable entries include app permission strings (UsageDescription), custom URL schemes (CFBundleURLTypes), and configurations for App Transport Security (NSAppTransportSecurity). These entries, along with others like exported/imported custom document types (UTExportedTypeDeclarations / UTImportedTypeDeclarations), can be effortlessly located by inspecting the file or employing a simple grep command:

$ grep -i <keyword> Info.plist

Data Paths

In the iOS environment, directories are designated specifically for system applications and user-installed applications. System applications reside in the /Applications directory, while user-installed apps are placed under /var/mobile/containers/Data/Application/. These applications are assigned a unique identifier known as a 128-bit UUID, making the task of manually locating an app's folder challenging due to the randomness of the directory names.

As applications in iOS must be sandboxed, each app will have also a folder inside $HOME/Library/Containers with app's CFBundleIdentifier as the folder name.

However, both folders (data & container folders) have the file that links both files in the key MCMetadataIdentifier).

To facilitate the discovery of a user-installed app's installation directory, the objection tool provides a useful command, env. This command reveals detailed directory information for the app in question. Below is an example of how to use this command:

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # env

Name               Path
-----------------  -------------------------------------------------------------------------------------------
BundlePath         /var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/
CachesDirectory    /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library/Caches
DocumentDirectory  /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Documents
LibraryDirectory   /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library

Alternatively, the app name can be searched within the /private/var/containers using the find command:

find /private/var/containers -name "Progname*"

Commands such as ps and lsof can also be utilized to identify the app's process and list open files, respectively, providing insights into the application's active directory paths:

ps -ef | grep -i <app-name>
lsof -p <pid> | grep -i "/containers" | head -n 1

Bundle directory:


    • This is the Application Bundle as seen before in the IPA, it contains essential application data, static content as well as the application's compiled binary.

    • This directory is visible to users, but users can't write to it.

    • Content in this directory is not backed up.

    • The contents of this folder are used to validate the code signature.

Data directory:

  • Documents/

    • Contains all the user-generated data. The application end user initiates the creation of this data.

    • Visible to users and users can write to it.

    • Content in this directory is backed up.

    • The app can disable paths by setting NSURLIsExcludedFromBackupKey.

  • Library/

    • Contains all files that aren't user-specific, such as caches, preferences, cookies, and property list (plist) configuration files.

    • iOS apps usually use the Application Support and Caches subdirectories, but the app can create custom subdirectories.

  • Library/Caches/

    • Contains semi-persistent cached files.

    • Invisible to users and users can't write to it.

    • Content in this directory is not backed up.

    • The OS may delete this directory's files automatically when the app is not running and storage space is running low.

  • Library/Application Support/

    • Contains persistent files necessary for running the app.

    • Invisible to users and users can't write to it.

    • Content in this directory is backed up.

    • The app can disable paths by setting NSURLIsExcludedFromBackupKey.

  • Library/Preferences/

    • Used for storing properties that can persist even after an application is restarted.

    • Information is saved, unencrypted, inside the application sandbox in a plist file called [BUNDLE_ID].plist.

    • All the key/value pairs stored using NSUserDefaults can be found in this file.

  • tmp/

    • Use this directory to write temporary files that do not need to persist between app launches.

    • Contains non-persistent cached files.

    • Invisible to users.

    • Content in this directory is not backed up.

    • The OS may delete this directory's files automatically when the app is not running and storage space is running low.

Let's take a closer look at iGoat-Swift's Application Bundle (.app) directory inside the Bundle directory (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # ls
NSFileType      Perms  NSFileProtection    ...  Name
------------  -------  ------------------  ...  --------------------------------------
Regular           420  None                ...  rutger.html
Regular           420  None                ...  mansi.html
Regular           420  None                ...  splash.html
Regular           420  None                ...  about.html

Regular           420  None                ...  LICENSE.txt
Regular           420  None                ...  Sentinel.txt
Regular           420  None                ...  README.txt

Binary Reversing

Inside the <application-name>.app folder you will find a binary file called <application-name>. This is the file that will be executed. You can perform a basic inspection of the binary with the tool otool:

otool -Vh DVIA-v2 #Check some compilation attributes
      magic  cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags

otool -L DVIA-v2 #Get third party libraries
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.1)
    /usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 274.6.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
    @rpath/Bolts.framework/Bolts (compatibility version 1.0.0, current version 1.0.0)

Check if the app is encrypted

See if there is any output for:

otool -l <app-binary> | grep -A 4 LC_ENCRYPTION_INFO

Disassembling the binary

Disassemble the text section:

otool -tV DVIA-v2
(__TEXT,__text) section
+[DDLog initialize]:
0000000100004ab8    sub    sp, sp, #0x60
0000000100004abc    stp    x29, x30, [sp, #0x50]   ; Latency: 6
0000000100004ac0    add    x29, sp, #0x50
0000000100004ac4    sub    x8, x29, #0x10
0000000100004ac8    mov    x9, #0x0
0000000100004acc    adrp    x10, 1098 ; 0x10044e000
0000000100004ad0    add    x10, x10, #0x268

To print the Objective-C segment of the sample application one can use:

otool -oV DVIA-v2
Contents of (__DATA,__objc_classlist) section
00000001003dd5b8 0x1004423d0 _OBJC_CLASS_$_DDLog
    isa        0x1004423a8 _OBJC_METACLASS_$_DDLog
    superclass 0x0 _OBJC_CLASS_$_NSObject
    cache      0x0 __objc_empty_cache
    vtable     0x0
    data       0x1003de748
        flags          0x80
        instanceStart  8

In order to obtain a more compact Objective-C code you can use class-dump:

class-dump some-app
//     Generated by class-dump 3.5 (64 bit).
//     class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2013 by Steve Nygard.

#pragma mark Named Structures

struct CGPoint {
    double _field1;
    double _field2;

struct CGRect {
    struct CGPoint _field1;
    struct CGSize _field2;

struct CGSize {
    double _field1;
    double _field2;

However, the best options to disassemble the binary are: Hopper and IDA.

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:

Data Storage

To learn about how iOS stores data in the device read this page:

pageiOS Basics

The following places to store information should be checked right after installing the application, after checking all the functionalities of the application and even after login out from one user and login into a different one. The goal is to find unprotected sensitive information of the application (passwords, tokens), of the current user and of previously logged users.


plist files are structured XML files that contains key-value pairs. It's a way to store persistent data, so sometimes you may find sensitive information in these files. It's recommended to check these files after installing the app and after using intensively it to see if new data is written.

The most common way to persist data in plist files is through the usage of NSUserDefaults. This plist file is saved inside the app sandbox in Library/Preferences/<appBundleID>.plist

The NSUserDefaults class provides a programmatic interface for interacting with the default system. The default system allows an application to customize its behaviour according to user preferences. Data saved by NSUserDefaults can be viewed in the application bundle. This class stores data in a plist file, but it's meant to be used with small amounts of data.

This data cannot be longer accessed directly via a trusted computer, but can be accessed performing a backup.

You can dump the information saved using NSUserDefaults using objection's ios nsuserdefaults get

To find all the plist of used by the application you can access to /private/var/mobile/Containers/Data/Application/{APPID} and run:

find ./ -name "*.plist"

To convert files from XML or binary (bplist) format to XML, various methods depending on your operating system are available:

For macOS Users: Utilize the plutil command. It's a built-in tool in macOS (10.2+), designed for this purpose:

$ plutil -convert xml1 Info.plist

For Linux Users: Install libplist-utils first, then use plistutil to convert your file:

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Within an Objection Session: For analyzing mobile applications, a specific command allows you to convert plist files directly:

ios plist cat /private/var/mobile/Containers/Data/Application/<Application-UUID>/Library/Preferences/

Core Data

Core Data is a framework for managing the model layer of objects in your application. Core Data can use SQLite as its persistent store, but the framework itself is not a database. CoreData does not encrypt it's data by default. However, an additional encryption layer can be added to CoreData. See the GitHub Repo for more details.

You can find the SQLite Core Data information of an application in the path /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support

If you can open the SQLite and access sensitive information, then you found a miss-configuration.

Code from iGoat
-(void)storeDetails {
    AppDelegate * appDelegate = (AppDelegate *)(UIApplication.sharedApplication.delegate);

    NSManagedObjectContext *context =[appDelegate managedObjectContext];

    User *user = [self fetchUser];
    if (user) {
    user = [NSEntityDescription insertNewObjectForEntityForName:@"User"
                                                  inManagedObjectContext:context]; = CoreDataEmail;
    user.password = CoreDataPassword;
    NSError *error;
    if (![context save:&error]) {
        NSLog(@"Error in saving data: %@", [error localizedDescription]);

        NSLog(@"data stored in core data");


YapDatabase is a key/value store built on top of SQLite. As the Yap databases are sqlite databases you can find them using the purposed commend in the previous section.

Other SQLite Databases

It's common for applications to create their own sqlite database. They may be storing sensitive data on them and leaving it unencrypted. Therefore, it's always interesting to check every database inside the applications directory. Therefore go to the application directory where the data is saved (/private/var/mobile/Containers/Data/Application/{APPID})

find ./ -name "*.sqlite" -or -name "*.db"

Firebase Real-Time Databases

Developers are enabled to store and sync data within a NoSQL cloud-hosted database through Firebase Real-Time Databases. Stored in JSON format, the data gets synchronized to all connected clients in real time.

You can find how to check for misconfigured Firebase databases here:

pageFirebase Database

Realm databases

Realm Objective-C and Realm Swift offer a powerful alternative for data storage, not provided by Apple. By default, they store data unencrypted, with encryption available through specific configuration.

The databases are located at: /private/var/mobile/Containers/Data/Application/{APPID}. To explore these files, one can utilize commands like:

iPhone:/private/var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Documents root# ls
default.realm  default.realm.lock  default.realm.note|

$ find ./ -name "*.realm*"

For viewing these database files, the Realm Studio tool is recommended.

To implement encryption within a Realm database, the following code snippet can be used:

// Open the encrypted Realm file where getKey() is a method to obtain a key from the Keychain or a server
let config = Realm.Configuration(encryptionKey: getKey())
do {
  let realm = try Realm(configuration: config)
  // Use the Realm as normal
} catch let error as NSError {
  // If the encryption key is wrong, `error` will say that it's an invalid database
  fatalError("Error opening realm: \(error)")

Couchbase Lite Databases

Couchbase Lite is described as a lightweight and embedded database engine that follows the document-oriented (NoSQL) approach. Designed to be native to iOS and macOS, it offers the capability to sync data seamlessly.

To identify potential Couchbase databases on a device, the following directory should be inspected:

ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/


iOS store the cookies of the apps in the Library/Cookies/cookies.binarycookies inside each apps folder. However, developers sometimes decide to save them in the keychain as the mentioned cookie file can be accessed in backups.

To inspect the cookies file you can use this python script or use objection's ios cookies get. You can also use objection to convert these files to a JSON format and inspect the data.

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
        "domain": "",
        "expiresDate": "2051-09-15 07:46:43 +0000",
        "isHTTPOnly": "false",
        "isSecure": "false",
        "name": "username",
        "path": "/",
        "value": "admin123",
        "version": "0"


By default NSURLSession stores data, such as HTTP requests and responses in the Cache.db database. This database can contain sensitive data, if tokens, usernames or any other sensitive information has been cached. To find the cached information open the data directory of the app (/var/mobile/Containers/Data/Application/<UUID>) and go to /Library/Caches/<Bundle Identifier>. The WebKit cache is also being stored in the Cache.db file. Objection can open and interact with the database with the command sqlite connect Cache.db, as it is a normal SQLite database.

It is recommended to disable Caching this data, as it may contain sensitive information in the request or response. The following list below shows different ways of achieving this:

  1. It is recommended to remove Cached responses after logout. This can be done with the provided method by Apple called removeAllCachedResponses You can call this method as follows:


    This method will remove all cached requests and responses from Cache.db file.

  2. If you don't need to use the advantage of cookies it would be recommended to just use the .ephemeral configuration property of URLSession, which will disable saving cookies and Caches.

    Apple documentation:

    An ephemeral session configuration object is similar to a default session configuration (see default), except that the corresponding session object doesn’t store caches, credential stores, or any session-related data to disk. Instead, session-related data is stored in RAM. The only time an ephemeral session writes data to disk is when you tell it to write the contents of a URL to a file.

  3. Cache can be also disabled by setting the Cache Policy to .notAllowed. It will disable storing Cache in any fashion, either in memory or on disk.


Whenever you press the home button, iOS takes a snapshot of the current screen to be able to do the transition to the application on a much smoother way. However, if sensitive data is present in the current screen, it will be saved in the image (which persists across reboots). These are the snapshots that you can also access double tapping the home screen to switch between apps.

Unless the iPhone is jailbroken, the attacker needs to have access to the device unblocked to see these screenshots. By default the last snapshot is stored in the application's sandbox in Library/Caches/Snapshots/ or Library/SplashBoard/Snapshots folder (the trusted computers can' t access the filesystem from iOX 7.0).

Once way to prevent this bad behaviour is to put a blank screen or remove the sensitive data before taking the snapshot using the ApplicationDidEnterBackground() function.

The following is a sample remediation method that will set a default screenshot.


private var backgroundImage: UIImageView?

func applicationDidEnterBackground(_ application: UIApplication) {
    let myBanner = UIImageView(image: #imageLiteral(resourceName: "overlayImage"))
    myBanner.frame = UIScreen.main.bounds
    backgroundImage = myBanner

func applicationWillEnterForeground(_ application: UIApplication) {


@property (UIImageView *)backgroundImage;

- (void)applicationDidEnterBackground:(UIApplication *)application {
    UIImageView *myBanner = [[UIImageView alloc] initWithImage:@"overlayImage.png"];
    self.backgroundImage = myBanner;
    self.backgroundImage.bounds = UIScreen.mainScreen.bounds;
    [self.window addSubview:myBanner];

- (void)applicationWillEnterForeground:(UIApplication *)application {
    [self.backgroundImage removeFromSuperview];

This sets the background image to overlayImage.png whenever the application is backgrounded. It prevents sensitive data leaks because overlayImage.png will always override the current view.


For accessing and managing the iOS keychain, tools like Keychain-Dumper are available, suitable for jailbroken devices. Additionally, Objection provides the command ios keychain dump for similar purposes.

Storing Credentials

The NSURLCredential class is ideal for saving sensitive information directly in the keychain, bypassing the need for NSUserDefaults or other wrappers. To store credentials after login, the following Swift code is used:

NSURLCredential *credential;
credential = [NSURLCredential credentialWithUser:username password:password persistence:NSURLCredentialPersistencePermanent];
[[NSURLCredentialStorage sharedCredentialStorage] setCredential:credential forProtectionSpace:self.loginProtectionSpace];

To extract these stored credentials, Objection's command ios nsurlcredentialstorage dump is utilized.

Custom Keyboards and Keyboard Cache

With iOS 8.0 onwards, users can install custom keyboard extensions, which are manageable under Settings > General > Keyboard > Keyboards. While these keyboards offer extended functionality, they pose a risk of keystroke logging and transmitting data to external servers, though users are notified about keyboards requiring network access. Apps can, and should, restrict the use of custom keyboards for sensitive information entry.

Security Recommendations:

  • It's advised to disable third-party keyboards for enhanced security.

  • Be aware of the autocorrect and auto-suggestions features of the default iOS keyboard, which could store sensitive information in cache files located in Library/Keyboard/{locale}-dynamic-text.dat or /private/var/mobile/Library/Keyboard/dynamic-text.dat. These cache files should be regularly checked for sensitive data. Resetting the keyboard dictionary via Settings > General > Reset > Reset Keyboard Dictionary is recommended for clearing cached data.

  • Intercepting network traffic can reveal whether a custom keyboard is transmitting keystrokes remotely.

Preventing Text Field Caching

The UITextInputTraits protocol offers properties to manage autocorrection and secure text entry, essential for preventing sensitive information caching. For example, disabling autocorrection and enabling secure text entry can be achieved with:

textObject.autocorrectionType = UITextAutocorrectionTypeNo;
textObject.secureTextEntry = YES;

Additionally, developers should ensure that text fields, especially those for entering sensitive information like passwords and PINs, disable caching by setting autocorrectionType to UITextAutocorrectionTypeNo and secureTextEntry to YES.

UITextField *textField = [[UITextField alloc] initWithFrame:frame];
textField.autocorrectionType = UITextAutocorrectionTypeNo;


Debugging code often involves the use of logging. There's a risk involved as logs may contain sensitive information. Previously, in iOS 6 and earlier versions, logs were accessible to all apps, posing a risk of sensitive data leakage. Now, applications are restricted to accessing only their logs.

Despite these restrictions, an attacker with physical access to an unlocked device can still exploit this by connecting the device to a computer and reading the logs. It is important to note that logs remain on the disk even after the app's uninstallation.

To mitigate risks, it is advised to thoroughly interact with the app, exploring all its functionalities and inputs to ensure no sensitive information is being logged inadvertently.

When reviewing the app's source code for potential leaks, look for both predefined and custom logging statements using keywords such as NSLog, NSAssert, NSCAssert, fprintf for built-in functions, and any mentions of Logging or Logfile for custom implementations.