application -> app in several files

documentation/AppsOnSDCard.md

@@ -45,13 +45,13 @@ To debug FAPs, do the following:
 2. Flash it with `./fbt flash`
 3. [Build your FAP](#fap-howto) and run it on Flipper
 
-After that, you can attach the debugger with `./fbt debug` or VS Code and use all debug features.
+After that, you can attach the debugger to the target MCU with `./fbt debug` or VS Code and use all debug features.
 
 It is **important** that firmware and app build type (debug/release) match and that the matching firmware folder is linked as `build/latest`. Otherwise, debugging will not work.
 
 ## How Flipper runs an app from an SD card
 
-Flipper's MCU cannot run code directly from external storage, so it needs to be copied to RAM first. That is done by the App Loader app responsible for loading the FAP from the SD card, verifying its integrity and compatibility, copying it to RAM, and adjusting it for its new location.
+Flipper's MCU cannot run code directly from external storage, so it needs to be copied to RAM first. That is done by the App Loader responsible for loading the FAP from the SD card, verifying its integrity and compatibility, copying it to RAM, and adjusting it for its new location.
 
 Since the FAP has to be loaded to RAM to be executed, the amount of RAM available for allocations from heap is reduced compared to running the same app from flash, as a part of the firmware. Note that the amount of occupied RAM is less than the total FAP file size since only code and data sections are allocated, while the FAP file includes extra information only used at app load time.
 

documentation/FuriHalBus.md

@@ -5,7 +5,7 @@
 On system startup, most of the peripheral devices are under reset and not clocked by default. This is done to reduce power consumption and to guarantee that the device will always be in the same state before use.
 Some crucial peripherals are enabled right away by the system, others must be explicitly enabled by the user code.
 
-**NOTE:** Here and afterwards, the word *"system"* refers to any code belonging to the operating system, hardware drivers or built-in applications.
+**NOTE:** Here and afterwards, the word *"system"* refers to any code belonging to the operating system, hardware drivers or built-in apps.
 
 To **ENABLE** a peripheral, call `furi_hal_bus_enable()`. At the time of the call, the peripheral in question MUST be disabled, otherwise a crash will occur to indicate improper use. This means that any given peripheral cannot be enabled twice or more without disabling it first.
 

documentation/HardwareTargets.md

@@ -25,15 +25,15 @@ A target definition file, `target.json`, is a JSON file that can contain the fol
 * `excluded_modules`: list of strings specifying fbt library (module) names to exclude from being used to configure build environment.
 
 
-## Applications & Hardware
+## Apps & Hardware
 
-Not all applications are available on different hardware targets. 
+Not all apps are available on different hardware targets. 
 
-* For applications built into the firmware, you have to specify a compatible application set using `FIRMWARE_APP_SET=...` fbt option. See [fbt docs](./fbt.md) for details on build configurations.
+* For apps built into the firmware, you have to specify a compatible app set using `FIRMWARE_APP_SET=...` fbt option. See [fbt docs](./fbt.md) for details on build configurations.
 
-* For applications built as external FAPs, you have to explicitly specify compatible targets in the application's manifest, `application.fam`. For example, to limit the application to a single target, add `targets=["f7"],` to the manifest. It won't be built for other targets.
+* For apps built as external FAPs, you have to explicitly specify compatible targets in the app's manifest, `application.fam`. For example, to limit the app to a single target, add `targets=["f7"],` to the manifest. It won't be built for other targets.
 
-For details on application manifests, check out [their docs page](./AppManifests.md).
+For details on app manifests, check out [their docs page](./AppManifests.md).
 
 
 ## Building Firmware for a Specific Target

documentation/UnitTests.md

@@ -5,7 +5,7 @@
 Unit tests are special pieces of code that apply known inputs to the feature code and check the results to see if they are correct.
 They are crucial for writing robust, bug-free code.
 
-Flipper Zero firmware includes a separate application called [unit_tests](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests).
+Flipper Zero firmware includes a separate app called [unit_tests](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests).
 It is run directly on Flipper devices in order to employ their hardware features and rule out any platform-related differences.
 
 When contributing code to the Flipper Zero firmware, it is highly desirable to supply unit tests along with the proposed features.
@@ -28,13 +28,13 @@ See [test_index.c](https://github.com/flipperdevices/flipperzero-firmware/blob/d
 
 #### Entry point
 
-The common entry point for all tests is the [unit_tests](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests) application. Test-specific code is placed into an arbitrarily named subdirectory and is then called from the [test_index.c](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests/test_index.c) source file.
+The common entry point for all tests is the [unit_tests](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests) app. Test-specific code is placed into an arbitrarily named subdirectory and is then called from the [test_index.c](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests/test_index.c) source file.
 
 #### Test assets
 
 Some unit tests require external data in order to function. These files (commonly called assets) reside in the [unit_tests](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/debug/unit_tests/resources/unit_tests) directory in their respective subdirectories. Asset files can be of any type (plain text, FlipperFormat (FFF), binary, etc.).
 
-### Application-specific
+### App-specific
 
 #### Infrared
 

documentation/doxygen/app_publishing.dox

@@ -1,7 +1,7 @@
 /**
 @page app_publishing Publishing to the Apps Catalog
 
-You can publish your app in the Flipper Apps Catalog. Users will be able to download your app and install it on their Flipper Zero via [mobile apps](https://flpr.app/?ref=blog.flipper.net) and [Flipper Lab](https://lab.flipper.net/apps). Check out the documentation below:
+You can publish your app in the Flipper Apps Catalog. Users will be able to download your app and install it on their Flipper Zero via [mobile apps](https://flpr.app/) and [Flipper Lab](https://lab.flipper.net/apps). Check out the documentation below:
 
 - [Apps Catalog: Contribution Guide](https://github.com/flipperdevices/flipper-application-catalog/blob/main/documentation/Contributing.md) — How to publish and update your app in the Apps Catalog
 */

documentation/fbt.md

@@ -3,7 +3,7 @@
 FBT is the entry point for firmware-related commands and utilities.
 It is invoked by `./fbt` in the firmware project root directory. Internally, it is a wrapper around [scons](https://scons.org/) build system.
 
-If you don't need all features of `fbt` — like building the whole firmware — and only want to build and debug a single application, you can use [ufbt](https://pypi.org/project/ufbt/).
+If you don't need all features of `fbt` — like building the whole firmware — and only want to build and debug a single app, you can use [ufbt](https://pypi.org/project/ufbt/).
 
 ## Environment
 
@@ -77,7 +77,7 @@ To use language servers other than the default VS Code C/C++ language server, us
 - `get_blackmagic` — output the blackmagic address in the GDB remote format. Useful for IDE integration.
 - `get_stlink` — output serial numbers for attached STLink probes. Used for specifying an adapter with `SWD_TRANSPORT_SERIAL=...`.
 - `lint`, `format` — run clang-format on the C source code to check and reformat it according to the `.clang-format` specs. Supports `ARGS="..."` to pass extra arguments to clang-format.
-- `lint_py`, `format_py` — run [black](https://black.readthedocs.io/en/stable/index.html) on the Python source code, build system files & application manifests. Supports `ARGS="..."` to pass extra arguments to black.
+- `lint_py`, `format_py` — run [black](https://black.readthedocs.io/en/stable/index.html) on the Python source code, build system files & app manifests. Supports `ARGS="..."` to pass extra arguments to black.
 - `lint_img`, `format_img` — check the image assets for errors and format them. Enforces color depth and strips metadata.
 - `lint_all`, `format_all` — run all linters and formatters.
 - `firmware_pvs` — generate a PVS Studio report for the firmware. Requires PVS Studio to be available on your system's `PATH`.
@@ -88,8 +88,8 @@ To use language servers other than the default VS Code C/C++ language server, us
 
 - `faps` — build all external & plugin apps as [`.faps`](AppsOnSDCard.md).
 - `fbt` also defines per-app targets. For example, for an app with `appid=snake_game` target names are:
-  - `fap_snake_game`, etc. — build single app as `.fap` by its application ID.
-  - Check out [`--extra-ext-apps`](#command-line-parameters) for force adding extra apps to external build.
+  - `fap_snake_game`, etc. — build single app as `.fap` by its app ID.
+  - Check out [--extra-ext-apps](#command-line-parameters) for force adding extra apps to external build.
   - `fap_snake_game_list`, etc — generate source + assembler listing for app's `.fap`.
 - `flash`, `firmware_flash` — flash the current version to the attached device over SWD.
 - `jflash` — flash the current version to the attached device with JFlash using a J-Link probe. The JFlash executable must be on your `$PATH`.
@@ -125,7 +125,7 @@ You can find out available options with `./fbt -h`.
 
 ### Firmware application set
 
-You can create customized firmware builds by modifying the list of applications to be included in the build. Application presets are configured with the `FIRMWARE_APPS` option, which is a `map(configuration_name:str → application_list:tuple(str))`. To specify an application set to use in the build, set `FIRMWARE_APP_SET` to its name.
+You can create customized firmware builds by modifying the list of apps to be included in the build. App presets are configured with the `FIRMWARE_APPS` option, which is a `map(configuration_name:str → application_list:tuple(str))`. To specify an app set to use in the build, set `FIRMWARE_APP_SET` to its name.
 For example, to build a firmware image with unit tests, run `./fbt FIRMWARE_APP_SET=unit_tests`.
 
 Check out `fbt_options.py` for details.