How to inspect .ipa files and secure your iOS app from common mistakes

Do you wonder what's inside your favorite iOS app? Which third-party frameworks are used? What hidden resources are added to the app bundle?

In this guide, you'll learn how to inspect .ipa files — the package format for iOS apps — and explore their internal structure. We'll also highlight common security mistakes and offer three essential rules to help you avoid exposing sensitive data.

Getting .ipa file

There are several ways to get .ipa file:

• Apple Configurator. An official Apple app for managing iOS devices, you can download it from the App Store.
• iMazing. A third-party tool with .ipa exporting features (requires a paid license).
• ipatools. A command-line tool that allows you to download .ipa files from the App Store.
• Jailbreaking. Advanced method requiring technical knowledge and a modified device. Not recommended.

I prefer Apple Configurator for its simplicity. After installing the app and connecting your iPhone:

1. Launch Apple Configurator.

2. Click Add → Apps, then search for the app you want. As an example we will use Headspace, an app for meditation and mindfulness.

3. Select the app and click Add.

If the app is already installed, a warning appears after a few minutes:

Ignore it and open the following folder to locate the .ipa file:

~/Library/Group Containers/K36BKF7T3D.group.com.apple.configurator/Library/Caches/Assets/TemporaryItems

Change the file extension to .zip and unarchive it. The contents may resemble:

The Payload folder contains the actual app bundle. Right-click the app and select Show Package Contents.

Inspecting app bundle content

Let's dive into the contents of the app bundle and highlight what developers — and attackers — can find.

Info.plist

The first thing we check is the Info.plist file. It's a full copy of Info.plist file from Xcode project:

Here you can find all the app's metadata, such as bundle identifier, version, build number, and more. Moreover, you can find queried URL schemes. Some banking apps use URL schemes to check installed apps on your device. In Headspace we also see custom keys like REMOTE_LOGGING_JWT or STRIPE_AUTH_KEY.

Frameworks

The Frameworks directory contains dynamic libraries and third-party SDKs used by the app. From the names, we can infer that Headspace integrates Flutter modules:

...
flutter_email_sender.framework
flutter_keyboard_visibility.framework
flutter_secure_storage_darwin.framework
...

Resources

You can also find resources that added to app targets: fonts, images, videos, etc. But sometimes developers add resources to the app bundle that are not used in the app itself. These resources can be used for testing or developing purposes. In Headspace app you can found .swiftlint.yml that is used for linting Swift code. Here is one custom rule from it. Good one!

constants_use_enums:
    name: "Constants use enums"
    regex: "struct Constants"
    message: "Prefer enums over structs for Constants"

The next interesting file is Accounts.json. It's a set of test accounts:

Luckily, it doesn’t work in the production app. The next file is config.yml. It's a file for CI/CD pipelines:

Headspace uses Lottie for animations, according to added Lottie.framework. Usually, Lottie animations are stored in plain json files. Look at this cute caterpillar!

Assets.car

The app bundle also contains a file called Assets.car. This file contains the images and other resources used in the app. It's a compiled version of the asset catalog, you can use AssetCatalogTinkerer to inspect it:

Strings

macOS has a built-in tool called strings that can extract strings from binary files. To use strings, open Terminal and run the following command:

> strings Headspace\ Mobile > strings.txt

Nothing criminal here, we can found strings that look like in-app purchase identifiers:

...
IOSIAP1M
STAY10
IOSIAP12M
STAY10_12MPLAN
STAY10
STAY10
STAY50_2
IOSIAP1M
STAY50_2
IOSIAPINTRO40
IOSIAP12M
STAY10
IOSIAP12M
...

And a warning to the development team:

Accessing Environment<%s>'s value outside of being installed on a View. This will always read the default value and will not update.

Pay attention to the string literals in your code. They can contain sensitive data, such as API keys, tokens, or other information that should not be exposed.

Conclusion

Inspecting .ipa files can reveal a surprising amount of internal information — both useful and risky. Following the three security rules outlined above will help ensure that your iOS app avoids common pitfalls and protects user data.

But remember: attackers use reverse engineering tools like Hopper or IDA Pro to decompile and analyze app internals. Don't make their job easier.

If you've never examined your own .ipa files — now's the perfect time. Stay curious, stay secure, and thanks for reading!