APP File

What are APP files and how to open them

Are you having problems opening an APP file or are you simply curious about its contents? We're here to explain the properties of these files and provide you with software that can open or handle your APP files.

What is an APP file?

APP files have multiple uses, and MacOS Application Bundle is one of them. Read more about the other uses further down the page.

MacOS Application Bundle

Files containing the .app file extension are executable application program files run on the Mac OS X operating system. The APP file format is similar to the Windows EXE file format, but it is used on Mac computers instead of Windows-run computers.

These files contain all assets associated with an application, like the executable itself and related resource files.

How to open APP files

Important: Different programs may use files with the APP file extension for different purposes, so unless you are sure which format your APP file is, you may need to try a few different programs.

While we have not verified the apps ourselves yet, our users have suggested ten different APP openers which you will find listed below.

Last updated: August 18, 2026

All known file formats using extension .APP

While MacOS Application Bundle is a popular type of APP-file, we know of 21 different uses of the .APP file extension. Different software may use files with the same extension for different types of data.

APP Raster Bitmap File

This is an old bitmap format used on Atari computers.

Atari V4E GFA Basic Application

Atari V4E GFA Basic Application files are stand-alone executables produced by the GFA-Basic Editor (GBE) for Atari systems using the V4E (ColdFire/FireBee) CPU architecture. These applications are created by a BASIC-language compiler/linker; they package compiled BASIC programs together with the GFA runtime library adapted for the V4E target. The resulting binary can be run on compatible Atari GEM/TOS-derived operating systems without requiring the BASIC source or a separate interpreter.

These executables are written by the GFA-Basic Editor version 3.x using its "V4E library" when the developer selects the ColdFire/FireBee target. They differ from the traditional 68000 executables: applications built with the V4E runtime do not run correctly on original 68K Atari machines due to CPU incompatibilities. The workflow is: write BASIC source (.GFA or similar), compile and link with the V4E library, producing a binary with the .APP extension which is then executed directly as a native application by the OS.

Applications built this way use FireTOS and the CF68K compatibility library (CFLib) on the FireBee machine. These binaries support many GFA-Basic commands and the GEM user interface where implemented. When launching on machines or CPUS other than FireBee with V4E CPU, they often set an error condition or abort due to incompatible instructions or missing support. Developers often keep two builds: a 68K version with .PRG extension, and the V4E version with .APP extension.

In binary form this format is recognizable by certain embedded ASCII strings from GFA version 3.6, including "CODED BY FRANK OSTROWSKI'MODIFIED BY LONNY PURSELL", "GFA-BASIC LIBRARY 3.6", and copyright "COPYRIGHT 1986-1991'GFA SYSTEMTECHNIK GMBH" among others. It also starts with a distinct 4-byte signature 0x601A00 at offset 0.

Authorware Application

We know that one APP format is Authorware Application. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

Branch Always Program Packer Compressed Atari ST Program

Branch Always Program Packer compressed Atari ST program files are executable programs originally written for the Atari ST family of computers that have been compacted with a tool called Branch Always Packer, developed by Branch Always Software. The packing process reduces the file's size but embeds routines so that the packed file remains directly executable under the GEMDOS/"TOS" operating system, without needing a separate decomposition step.

Branch Always Packer works by taking existing program files (such as those with extensions .PRG, .TOS, .TTP, or .ACC) and compressing their code and possibly data segments, while retaining the program header and embedding a decompression stub so that at runtime the packed program first decompresses itself into memory and then jumps to the original entry point. Because the machine Code is compacted, packed files often occupy significantly less disk space, making them useful in contexts where storage or distribution was limited (for example on floppy disks).

Internally, these packed executables still follow the standard Atari ST program file header format. The first two bytes are the branch instruction magic number 0x601A (representing a branch to the start of the program) at offset 0. Following that is the text segment length, data segment length, BSS (uninitialized data) length, and symbol table length, each stored in long (4-byte) fields. Packed files produced by Branch Always Packer include recognizable signatures such as the ASCII string "*BRAS" near offset 26, and sometimes other internal strings like "AEFSBJ" or "GLSBJ". The signature at offset 0 is "bytes 0x601A00", matching the standard program header.

CA Visual Objects Application

CA Visual Objects Application files used by CA-Visual Objects store a full application project that resides in the repository inside the IDE. These files represent an "application" component inside a project - this application includes modules, entities, resources like menus, windows, icons, database and class definitions, and IDE settings. They are used when building the final executable (EXE, DLL, or library) under Windows.

Such files are created and maintained by the CA-Visual Objects development environment. When an application is built (compiled), these application files are assembled using the repository's data. To distribute versioned work or move between versions of the IDE, application and project components can be exported or imported (often using the separate "Application Export" (.AEF) format) rather than shared as loose files.

The CA-Visual Objects repository stores each module and each entity (functions, classes, resources, etc.) independently so that the IDE can track changes at a fine-granularity: builds automatically recompile only those entities that have changed. Application files act as higher-level entities grouping modules and resources for executable creation.

Identification is possible via internal signatures: bytes in the file include strings like "CA-VO APPLICATIONS", "STD.UDC", "START()", "DEFINE", "INIT(", ".AEF", ".MEF", "CAVO", "CLIP" and so on. Also the file contains "STD.UDC" at a fixed offset. These help tools recognise the file as a CA-Visual Objects Application (v1.x).

Cybiko Application

Cybiko is a Russian handheld computer designed for teens. It features a two-way radio text messaging system.

EPOC/Symbian Application

These files are applications for embedded systems and mobile devices running the EPOC and Symbian operating systems. The application is written in Open Programming Language (OPL).

GEM Application (Intel)

GEM Application (Intel) files are executable programs built for the Intel‐based version of Digital Research's Graphics Environment Manager (GEM). They contain machine code and resources required to run under GEM's Application Environment Services (AES), which handles windows, dialogs, menus and user input. These programs are compiled and linked using tools such as MASM and C compilers provided in the GEM Programmer's Toolkit, creating a finished binary that runs as a native GEM application on MS-DOS or compatible systems.

When a file of this type is loaded, the computer's DOS loader sees it as a standard DOS MZ executable, and then GEM's AES identifies it at runtime as a GEM application rather than a plain DOS program. The distinction matters because GEM programs receive support from AES and VDI libraries for graphics, window management, and user interaction, whereas DOS programs do not. The GEM Toolkit includes example programs with names ending in .APP (such as INSTALL.APP, RCS.APP) that demonstrate these libraries and how GEM applications are structured.

Machine-readable signatures:

These files start with the ASCII characters "MZ" (bytes 0x4D 0x5A at offset 0), typical of DOS MZ executables, and additionally contain the ASCII string "GEMAES" somewhere in their contents, which identifies routines or data belonging to GEM's AES component.

Interfaze Application

We know that one APP format is Interfaze Application. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

LEEt/OS Application

We know that one APP format is LEEt/OS Application. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

MS Visual FoxPro 7 Application

The MS Visual FoxPro 7 Application format stores an application project in compiled FoxPro form. It represents code and executable instructions in a tokenized rather than native machine-code format. Such an application runs only under Visual FoxPro, not as a standalone executable unless built as an EXE. It is produced by using the Project Manager or the BUILD APP command within Visual FoxPro.

These files contain program definitions, menus, forms, reports, and support files as part of a single packaged app. Data tables (.DBF etc.) are typically not embedded unless specifically included; the APP file itself rarely holds data. APP files allow embedded resources and internal procedure directories; when building, the user must designate a main program entry point to set where the application starts.

Internally, the format begins with a fixed header giving version, program flags and offsets, lists of procedures and files in the project, with directory entries for forms, menus, etc. Procedures, forms, menus are represented in tokenized or intermediate code; EXE builds wrap this with a loader so the app runs without full Visual FoxPro installed. Byte signature: the very first two bytes are 0xFEF2 at offset zero.

OrbWorks PocketC CE Application

OrbWorks PocketC CE Application is a binary application file created by the PocketC compiler made by OrbWorks, designed for Windows CE (and related handheld Windows CE devices). Its purpose is to hold compiled PocketC "applets" (non-native executables) that run inside the PocketC runtime shell (often called PCshell), which provides necessary runtime libraries and a virtual machine environment so that such applications are device-independent in terms of CPU architecture.

A file of this kind is produced by compiling PocketC source code (typically files with a ".pc" extension) using PocketC either directly on a CE device or via its desktop edit-compile-run environment. These application files are then launched by PCshell rather than acting as fully standalone native executables; distributing a PocketC application generally requires bundling it with the PocketC runtime shell.

The compiler includes a library of built-in functions for graphics, sound, database and serial I/O, and supports invisible data-type conversions, a string type, and other custom language extensions beyond standard C (though omitting full struct and pointer capabilities in some versions). Generated application files are CPU-independent so that the same compiled applet file can run under different processor architectures (SH3, MIPS, etc.) provided the matching runtime shell is present.

Internally the format can be identified by a fixed binary signature: the first 0x20 bytes begin with the bytes B8 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 at offset zero.

oZone GUI Application

oZone GUI is a multiplatform desktop environment that runs under DOS, Windows, and Linux. Apps compiled for oZone will run on all supported platforms without recompilation.

PRO-NTO Application

The PRO-NTO Application format is a stored application module for the TRS-80 PRO-NTO (later renamed PRO-WAM) Window and Application Manager. It defines how utility or user-defined applications are packaged so they can be loaded by PRO-WAM/PRUN, run in a window, respond to user input, and integrate with the system's fixed memory bank.

Each application module is written by MISOSYS or third parties using the PRO-CREATE assembler with special switches to produce a "core-image" version. These modules are not "command files" or relocatable object code; they include no load-address metadata and must be loaded at a fixed memory location (the same spot every time) and entry point defined by the PRO-WAM loader. Thereby PRO-NTO/PRO-WAM can invoke them, manage windows, export/import screen-data, and swap in/out overlays without breaking DOS or other running applications.

The workflow is as follows: the programmer writes source code using PRO-CREATE, specifying switches (notably "-CI") to emit the core-image format. The resulting module can be used standalone (invoked via PRUN with an APP parameter) or added to a library of applications. When PRO-WAM is loaded (in high memory plus a 32K RAM bank), it reserves memory for up to a small number of such applications and buffers. At run-time, when an application is called, PRO-WAM loads the module into a fixed memory area, jumps to its fixed entry point, and when done restores the previous screen and overlays.

Technically modules begin with the ASCII string "PRONTO" at offset zero (i.e. bytes 0x50 0x52 0x4F 0x4E 0x54 0x4F). They have no relocation or load address fields. The loader assumes a specified load address in the system's memory map and a predefined entry address. These application files are thus identified by their fixed signature and strict layout.

PRO-WAM Application

PRO-WAM Application files are modules used by PRO-WAM (also known as PRO-NTO), a window controller and applications manager produced by MISOSYS for the TRS-80 Model 4 with 128K RAM and running LS-DOS or TRS-DOS 6. The software supplies a "pop-up" environment: while a regular DOS program is in use, one of its resident tools, such as a calendar, calculator, editor, or terminal, can be brought up in an overlaying window. These applications allow for import and export of data between active programs and program windows, letting the user share screen data or resume a previous session without exiting the current DOS operation.

The applications come in a library format, and the PRO-WAM system provides utilities to manage both standalone and library-bundled modules. A library manager (WAMLIB) lets the user create, replace, delete, extract or list application modules. A launcher (PRUN) can invoke individual application files using a parameter ("APP") if testing outside the library. Many apps are included - ADDRESS, BRINGUP (appointments), CALENDAR, CALCULATOR, RPN CALC, CARD, CHARSET, DIALER, TERM, TYPER, and others. A full-screen popup editor, memory editors, disk sector editor, and video screen editor are part of the supplied suite.

PRO-WAM Application files contain compiled executable modules that are loaded at runtime by PRO-WAM. They begin with a fixed ASCII header "PROWAM" at offset zero. Utilities such as WAMDUMP recognize these files by that header and can convert or dump them into more generic command files (/CMD extension) to permit disassembly or examination of module contents.

PSION Application

PSION Application files are executable programs created for Psion Series 3 / 3a / 3c palmtop computers. These files contain compiled machine code (often from C or Assembler) and all of the accompanying resources an application needs to run, so that the program appears in the device's System menu and can be launched directly.

A PSION Application is built by combining a core executable module (often named with an .IMG extension during development) with optional "add-files" such as an icon (.PIC or .FON), resource files (.RSC or .RZC), and shell or metadata data (.SHD). These add-files are usually embedded into the main executable so that there is a single self-contained program file. The build process uses an add-file list (.AFL) to specify which add-files to include. Once the add-files are bound in, the final file is given the Application format. To appear in the System screen (so users can install and launch it like any standard app), the application must include a valid icon add-file and shell data add-file.

The Application format reserves four "add-file slots". Slot 1 is typically for the icon, slot 2 for a resource file, slot 3 for shell data, and slot 4 optionally for another add-file. The resource loader (via the RSCFILE class) expects resource data in slot 2. The System installer checks specifically that shell data in slot 3 is present. Icon files may be located in any slot for display in windows, though typically slot 1 is used.

Internally, the file begins with the same header as an .IMG file (including version numbers identifying the IMG format). Following the header, there are sections (add-file slots) each containing an embedded file with its own offset and length. The shell data (.SHD) is derived from a text format (.MS), which defines the application's public name, type number (identifying how the System should treat it), default file path or extension for file-based apps, and modifiers (flags controlling behavior such as multilingual support, shutdown handling, icon size, etc.).

Symbian Application

Symbian Application files are the compiled executable programs used on the Symbian OS, previously called EPOC. These files implement both applications with graphical user interfaces and background tools for mobile phones and embedded devices. They carry the main machine code and static data needed to run on Symbian's ARM or emulator architectures.

These application files are produced by the Symbian C++ build tools as the result of compiling and linking source code (usually organized via .mmp project files), incorporating Unique Identifiers (UIDs) for identity, metadata, import libraries, and framework libraries. During development, a companion .rsc resource file is generated to store UI layouts and strings, and a .aif file may be provided to include icons, captions, and other presentation details. At runtime or when installed, the Symbian OS loader reads the application file to start execution according to its specified entry point.

Inside the file, a recognizable binary header exists: it begins with multiple UID fields, followed by the ASCII signature "EPOC", flags indicating whether it's an executable or DLL, version and compression identifiers, and offsets and sizes for code, data, heap, stack, and other sections. Library names such as EIKCORE, FBSCLI, EUSER, and others appear among embedded import strings. The signature "EPOC" at offset 16 is a key marker.

Timex Datalink Smartwatch Application

These files are applications that run on Times Datalink smartwatches.

Z88 App Info File

The Z88 App Info File is used with the Z88 computer's Installer program to bundle everything needed to install a RAM application suite for the OZ operating system. It defines how binary "bank" files are grouped and laid out for loading into RAM, so that the system can install, activate, or remove the application set when running the .app file.

This file is written by the Z88 Installer (originally by Garry Lancaster) or by tools that can create Installer-compatible packages (such as building with z88dk using the "installer" subtype target). It is read by the Installer on the Z88 to perform the steps of locating the individual bank files (usually with extensions .ap0 through .ap7), copying them into available RAM banks, linking the application's descriptors (DORs) into the system device chain, and managing removal or updates.

The format header is exactly 40 bytes. The first two bytes are a file identifier (hex 0x5AA5), followed by a byte giving the number of banks (1 to 8), another byte for number of patches (unused in current versions), then a three-byte pointer to the first application DOR (or zero to use the ROM front DOR). Then comes a flags byte for even bank requirements. Following this are eight pairs of 16-bit values: for each bank file .ap0 through .ap7, its offset in the .app file and its length. These bank files each hold up to 16 KB of data.

Z88 Compressed RAM Apps

Z88 Compressed RAM Apps files hold software ready to be installed into RAM on the Cambridge Z88 portable computer under its OZ operating system (version 5.0). These apps are distributed as compressed bundles so that multiple "bank" binaries (AP0, AP1, etc.) can be packed together, compressed, and then installed more efficiently into the Z88's RAM filing system. The format enables apps to be installed, indexed, executed, or removed without needing a Flash card.

When an app is created in this format, tools like OZ's appmaker and the "lz49" compressor are used. The raw bank files (separate binaries) are compressed individually, and then combined with a header to produce a single bundle that the Z88 installer accepts. Once installed via the INDEX command in the Filer utility, these apps appear in the Z88's Application Index and can be launched like built-in programs. Removal is also handled through INDEX via the RMV (remove) command.

A compressed RAM App file begins with a 40-byte header containing data such as file identifier (0xA55A), the number of banks (1-8), a Type byte indicating legacy or compressed format, pointers or offsets and lengths for each bank's image (AP0, AP1…), plus flags. After the header the bank images follow, compressed with the LZ49 algorithm. These offsets are relative to the bank into which the app will be loaded.

Various apps that use files with this extension

These apps are known to open certain types of APP files. Remember, different programs may use APP files for different purposes, so you may need to try out a few of them to be able to open your specific file.

Help us help others

File.org helps thousands of users every day, and we would love to hear from you if you have additional information about APP file formats, example files, or compatible programs. Please use the links below or email us at submit@file.org to discuss further.