# `mix compile.app`
[🔗](https://github.com/elixir-lang/elixir/blob/7ff272706afc522e74121493b7166719985cb099/lib/mix/lib/mix/tasks/compile.app.ex#L5)

Writes a `.app` file.

A `.app` file is a file containing Erlang terms that defines
your application. Mix automatically generates this file based on
your `mix.exs` configuration.

In order to generate the `.app` file, Mix expects your project
to have both the `:app` and `:version` keys. Furthermore, you can
configure the generated application by defining an `application/0`
function in your `mix.exs` that returns a keyword list.

The most commonly used keys are:

  * `:extra_applications` - a list of OTP applications
    your application depends on which are not included in `:deps`
    (usually defined in `deps/0` in your `mix.exs`). For example,
    here you can declare a dependency on applications that ship
    with Erlang/OTP or Elixir, like `:crypto` or `:logger`.
    Optional extra applications can be declared as a tuple, such
    as `{:ex_unit, :optional}`. Mix guarantees all non-optional
    applications are started before your application starts.

  * `:registered` - the name of all registered processes in the
    application. If your application defines a local GenServer
    with name `MyServer`, it is recommended to add `MyServer`
    to this list. It is most useful in detecting conflicts
    between applications that register the same names.

  * `:env` - the default values for the application environment.
    The application environment is one of the most common ways
    to configure applications. See the `Application` module for
    mechanisms to read and write to the application environment.

For example:

    def application do
      [
        extra_applications: [:logger, :crypto, ex_unit: :optional],
        env: [key: :value],
        registered: [MyServer]
      ]
    end

Other options include:

  * `:applications` - all applications your application depends
    on at runtime. By default, this list is automatically inferred
    from your dependencies. Mix and other tools use the application
    list in order to start your dependencies before starting the
    application itself.

  * `:mod` - specifies a module to invoke when the application
    is started. It must be in the format `{Mod, args}` where
    args is often an empty list. The module specified must
    implement the callbacks defined by the `Application`
    module.

  * `:start_phases` - specifies a list of phases and their arguments
    to be called after the application is started. See the "Phases"
    section below.

  * `:included_applications` - specifies a list of applications
    that will be included in the application. It is the responsibility of
    the primary application to start the supervision tree of all included
    applications, as only the primary application will be started. A process
    in an included application considers itself belonging to the
    primary application.

  * `:maxT` - specifies the maximum time the application is allowed to run, in
    milliseconds. Applications are stopped if `:maxT` is reached, and their
    top-level supervisor terminated with reason `:normal`. This threshold is
    technically valid in any resource file, but it is only effective for
    applications with a callback module. Defaults to `:infinity`.

Besides the options above, `.app` files also expect other options
like `:modules` and `:vsn`, but these are automatically added by Mix.
The complete list can be found on [Erlang's application
specification](https://www.erlang.org/doc/man/app).

From Elixir v1.17 onwards, the application .app file is also loaded
whenever the task runs.

## Command line options

  * `--force` - forces compilation regardless of modification times
  * `--compile-path` - where to find `.beam` files and write the
    resulting `.app` file, defaults to `Mix.Project.compile_path/0`

## Configuration

  * `:reliable_dir_mtime` - this task relies on the operating system
    changing the mtime on a directory whenever a file is added or removed.
    You can set this option to `false` if your system does not provide
    reliable mtimes. Defaults to `false` on Windows.

## Phases

Applications provide a start phases mechanism which will be called,
in order, for the application and all included applications. If a phase
is not defined for an included application, that application is skipped.

Let's see an example `MyApp.application/0` function:

    def application do
      [
        start_phases: [init: [], go: [], finish: []],
        included_applications: [:my_included_app]
      ]
    end

And an example `:my_included_app` defines on its `mix.exs` the function:

    def application do
      [
        mod: {MyIncludedApp, []},
        start_phases: [go: []]
      ]
    end

In this example, the order that the application callbacks are called in is:

    Application.start(MyApp)
    MyApp.start(:normal, [])
    MyApp.start_phase(:init, :normal, [])
    MyApp.start_phase(:go, :normal, [])
    MyIncludedApp.start_phase(:go, :normal, [])
    MyApp.start_phase(:finish, :normal, [])

---

*Consult [api-reference.md](api-reference.md) for complete listing*