diff --git a/development/languages/c-cpp/naming.md b/development/languages/c-cpp/naming.md
index e4d319725aee0658fc430be5ff3797666572500d..166a9b55744d31408ba7f1e85c38ebe37b0286a6 100644
--- a/development/languages/c-cpp/naming.md
+++ b/development/languages/c-cpp/naming.md
@@ -76,6 +76,6 @@ the outside world: "lib".
 
 ###### Examples
 
-- `lib/app/cpp/application_context.h`
+- `lib/app/cpp/startup_context.h`
 - `lib/fbl/array.h`
 - `lib/zx/event.h`
diff --git a/development/languages/fidl/tutorial.md b/development/languages/fidl/tutorial.md
index 9207384bd0c5e9b4461d8f2732fa5b7bcef2b98e..de0864c2525d24381edf512ff1e7154b7bad6ceb 100644
--- a/development/languages/fidl/tutorial.md
+++ b/development/languages/fidl/tutorial.md
@@ -55,21 +55,21 @@ fx full-build
 
 FIDL is organized like so:
 
-A FIDL **Application** is software that's designed to work with FIDL interfaces.
-The primary thread in a FIDL application usually has a run loop to dispatch
+A FIDL **Component** is software that's designed to work with FIDL interfaces.
+The primary thread in a FIDL component usually has a run loop to dispatch
 calls and may have additional threads with run loops.
 
-An application is called through its **Interface(s)**. Interfaces are reusable
-and can be vended by multiple applications. An interface is defined with the
+A component is called through its **Interface(s)**. Interfaces are reusable
+and can be vended by multiple components. An interface is defined with the
 Fuchsia Interface Definition Language (IDL). The classes that bind an interface
 to a language are generated by the FIDL compiler.
 
-An application almost always implements the **ServiceProvider** interface, which
+A component almost always implements the **ServiceProvider** interface, which
 returns interfaces based on the name of the service. The FIDL client library
 provides default implementations of ServiceProvider for all supported languages.
 
 A **Service** is your implementation of an interface. Therefore, within a
-particular FIDL application, there is one service per interface. In the FIDL
+particular FIDL component, there is one service per interface. In the FIDL
 client library, you will see calls like `AddPublicService()` or
 `ConnectToService()`.
 
@@ -80,16 +80,16 @@ A
 is an [operating system construct for IPC (InterProcess
 Communication)](https://fuchsia.googlesource.com/zircon/+/master/docs/concepts.md#message-passing_sockets-and-channels),
 although it works equally well between processes, threads, or even within a
-thread. FIDL uses channels to communicate between applications.
+thread. FIDL uses channels to communicate between components.
 
-A **Connection** is the request sent to a FIDL application to return its
-**ServiceProvider** interface to another application. Requests for subsequent
+A **Connection** is the request sent to a FIDL component to return its
+**ServiceProvider** interface to another component. Requests for subsequent
 interfaces are _not_ connections. A connection refers to the construction of the
-initial channel between two applications.
+initial channel between two components.
 
-The word **Client** is used in this document to refer to a FIDL application that
-connects to a **Server** application. The difference between client and server
-is an artificial distinction for this tutorial. A FIDL application you write can
+The word **Client** is used in this document to refer to a FIDL component that
+connects to a **Server** component. The difference between client and server
+is an artificial distinction for this tutorial. A FIDL component you write can
 be a client, a server, or both, or many.
 
 ## Hello World "Echo" interface
@@ -100,7 +100,7 @@ world".
 Open
 [garnet/examples/fidl/services/echo2.fidl](https://fuchsia.googlesource.com/garnet/+/master/examples/fidl/services/echo2.fidl).
 A .fidl file defines the interfaces and related data structures that a FIDL
-applications vends (makes available to other FIDL applications). An interface
+components vends (makes available to other FIDL components). An interface
 can be used in any language supported by FIDL, which allows you to easily make
 calls across languages.
 
@@ -170,11 +170,11 @@ to execute an IPC call.
 1.  Fuchsia loads the server executable, and your `main()` function starts.
 1.  `main` creates an `EchoServerApp` object which will bind to the service
     interface when it is constructed.
-1.  `EchoServerApp()` registers itself with the `ApplicationContext` by calling
+1.  `EchoServerApp()` registers itself with the `StartupContext` by calling
     `context->outgoing().AddPublicService<Echo>()`. It passes a lambda function
     that is called when a connection request arrives.
 1.  Now `main` starts the run loop, expressed as an `async::Loop`.
-1.  The run loop receives a request to connect from another application, so
+1.  The run loop receives a request to connect from another component, so
     calls the lambda created in `EchoServerApp()`.
 1.  That lambda binds the `EchoServerApp` instance to the request channel.
 1.  The run loop receives a call to `EchoString()` from the channel and
@@ -200,29 +200,29 @@ Here are the #include files used in the server implementation:
 #include <lib/async-loop/cpp/loop.h>
 #include <lib/zx/channel.h>
 
-#include "lib/app/cpp/application_context.h"
+#include "lib/app/cpp/startup_context.h"
 ```
 
 -   `echo2.h` contains the generated C++ definition of our `Echo` FIDL
     interface.
--   `application_context.h` is used by `EchoServerApp` to expose service
+-   `startup_context.h` is used by `EchoServerApp` to expose service
     implementations.
 
 ### main
 
-Most `main()` functions for FIDL applications look very similar. They create a
+Most `main()` functions for FIDL components look very similar. They create a
 run loop using `async::Loop` or some other construct, and bind service
 implementations. The `Loop.Run()` function enters the message loop to process
 requests that arrive over channels.
 
-Eventually, another FIDL application will attempt to connect to our application.
+Eventually, another FIDL component will attempt to connect to our component.
 
 ### The `EchoServerApp()` constructor
 
 Before going further, a quick review from the [FIDL
 Architecture](#fidl-architecture) section. A connection is defined as the
-_first_ channel with another application. Strictly speaking, the connection is
-complete when both applications have bound their ServiceProvider to that first
+_first_ channel with another component. Strictly speaking, the connection is
+complete when both components have bound their ServiceProvider to that first
 channel. Any additional channels are not "connections". Therefore, service
 registration is performed before the run loop begins and before the first
 connection is made.
@@ -231,7 +231,7 @@ Here's what the `EchoServerApp` constructor looks like:
 
 ```cpp
 EchoServerApp()
-    : context_(fuchsia::sys::ApplicationContext::CreateFromStartupInfo()) {
+    : context_(fuchsia::sys::StartupContext::CreateFromStartupInfo()) {
   context_->outgoing().AddPublicService<Echo>(
       [this](fidl::InterfaceRequest<Echo> request) {
         bindings_.AddBinding(this, std::move(request));
@@ -239,8 +239,8 @@ EchoServerApp()
 ```
 
 The function calls `AddPublicService` once for each service it makes available
-to the other application (remember that each service exposes a single
-interface). The information is cached by `ApplicationContext` and used to decide
+to the other component (remember that each service exposes a single
+interface). The information is cached by `StartupContext` and used to decide
 which `InterfaceFactory<>` to use for additional incoming channels. A new
 channel is created every time someone calls `ConnectToService()` on the other
 end.
@@ -249,7 +249,7 @@ If you read the code carefully, you'll see that the parameter to
 `AddPublicService` is actually a lambda function that captures `this`. This
 means that the lambda function won't be executed until a channel tries to bind
 to the interface, at which point the object is bound to the channel and will
-receive calls from other applications. Note that these calls have
+receive calls from other components. Note that these calls have
 thread-affinity, so calls will only be made from the same thread.
 
 The function passed to `AddPublicService` can be implemented in different ways.
@@ -292,7 +292,7 @@ Any call to an interface in FIDL is asynchronous. This is a big shift if you are
 used to a procedural world where function calls return after the work is
 complete. Because it's async, there's no guarantee that the call will ever
 actually happen, so your callback may never be called. The remote FIDL
-application might close, crash, be busy, etc.
+component might close, crash, be busy, etc.
 
 ## `Echo` client in C++
 
@@ -305,7 +305,7 @@ and an `async::Loop`. The difference is that the client immediately kicks off
 work once everything is initialized. In contrast, the server does no work until
 a connection is accepted.
 
-**Note:** an application can be a client, a server, or both, or many. The
+**Note:** a component can be a client, a server, or both, or many. The
 distinction in this example between Client and Server is purely for
 demonstration purposes.
 
@@ -315,18 +315,18 @@ Here is the summary of how the client makes a connection to the echo service.
 1.  `main()` creates an `EchoClientApp` object to handle connecting to the
     server, calls `Start()` to initiate the connection, and then starts the
     message loop.
-1.  In `Start()`, the client calls `context_->launcher()->CreateApplication`
-    with the url to the server application. If the server application is not
+1.  In `Start()`, the client calls `context_->launcher()->CreateComponent`
+    with the url to the server component. If the server component is not
     already running, it will be created at this point.
 1.  Next, the client calls `ConnectToService()` to open a channel to the server
-    application.
+    component.
 1.  `main` calls into `echo_->EchoString(...)` and passes the callback. Because
     FIDL IPC calls are async, `EchoString()` will probably return before the
     server processes the call.
 1.  `main` then blocks on a response on the interface.
 1.  Eventually, the response arrives, and the callback is called with the
     result.
-1.  `WaitForResponse()` returns, and the application exits.
+1.  `WaitForResponse()` returns, and the component exits.
 
 ### main
 
@@ -360,17 +360,17 @@ int main(int argc, const char** argv) {
 
 ```cpp
 void Start(std::string server_url) {
-  fuchsia::sys::ApplicationLaunchInfo launch_info;
+  fuchsia::sys::LaunchInfo launch_info;
   launch_info.url = server_url;
   launch_info.directory_request = echo_provider_.NewRequest();
-  context_->launcher()->CreateApplication(std::move(launch_info),
+  context_->launcher()->CreateComponent(std::move(launch_info),
                                           controller_.NewRequest());
   echo_provider_.ConnectToService(echo_.NewRequest().TakeChannel(),
                                   Echo::Name_);
 }
 ```
 
-First, `Start()` calls `CreateApplication()` to launch `echo_server`. Then, it
+First, `Start()` calls `CreateComponent()` to launch `echo_server`. Then, it
 calls `ConnectToService()` to bind to the server's `Echo` interface. The exact
 mechanism is somewhat hidden, but the particular interface is automatically
 inferred from the type of `EchoPtr`, which is a typedef for
@@ -398,7 +398,7 @@ $ run echo2_client_cpp
 ```
 
 You do not need to specifically run the server because the call to
-`CreateApplication()` in the client will automatically launch the server.
+`CreateComponent()` in the client will automatically launch the server.
 
 ## `Echo` server in Rust
 
@@ -421,7 +421,7 @@ not necessary to understand all of this before you move on.
 1.  **Services Server:** The `ServicesServer` is the main top-level future
     being run on the executor. It binds itself to the startup handle of the
     current process and listens for incoming service requests.
-1.  **Service Request:** When another application needs to access an "Echo"
+1.  **Service Request:** When another component needs to access an "Echo"
     server, it sends a request to the `ServicesServer` containing the name of
     the service to connect to ("Echo") and a channel to connect.
 1.  **Service Lookup:** The incoming service request wakes up the
@@ -532,7 +532,7 @@ The `ServicesServer` represents a collection of services that can be provided.
 it the name of our `Echo` service, `EchoMarker::NAME`, and a function which
 takes a channel and spawns the echo server onto that channel. We then attempt
 to `start` the `ServicesServer`, which binds it to the startup handle of the
-current application. If that binding fails, the
+current component. If that binding fails, the
 "Error starting echo services server" occurs. Otherwise, we get back a `Future`
 which, when run on the executor, will process and delegate incoming service
 requests until a protocol error occurs or the startup handle is closed.
@@ -615,18 +615,18 @@ The echo client implementation in Rust can be found at:
 
 Our simple client does everything in `main()`.
 
-**Note:** an application can be a client, a service, or both, or many. The
+**Note:** a component can be a client, a service, or both, or many. The
 distinction in this example between Client and Server is purely for
 demonstration purposes.
 
 Here is the summary of how the client makes a connection to the echo service.
 
-1.  **Launch:** The server application is specified, and we request for it to
+1.  **Launch:** The server component is specified, and we request for it to
     be launched if it wasn't already. Note that this step isn't included in
-    most production FIDL-using applications: generally you're connecting with
-    an already-running server application.
+    most production FIDL-using components: generally you're connecting with
+    an already-running server component.
 1.  **Connect:** We call `connect_to_service` on the launched server
-    application and get back a proxy with methods for making IPC calls to
+    component and get back a proxy with methods for making IPC calls to
     the remote server.
 1.  **Call:** We call the `echo_string` method with the desired value to
     echo, get back a `Future` of the response, and `map` the future so that
@@ -678,7 +678,7 @@ The echo server implementation in Dart can be found at:
 
 This file implements the `main()` function and the `EchoImpl` class:
 
--   The `main()` function is executed when the application is loaded. `main()`
+-   The `main()` function is executed when the component is loaded. `main()`
     registers the availability of the service with incoming connections from
     FIDL.
 -   `EchoImpl` processes requests on the `Echo` interface. A new object is
@@ -719,7 +719,7 @@ import 'package:lib.app.dart/app.dart';
 
 -   `fidl.dart` exposes the FIDL runtime library for Dart. Our program needs it
     for `InterfaceRequest`.
--   `app.dart` is required for `ApplicationContext`, which is where we register
+-   `app.dart` is required for `StartupContext`, which is where we register
     our service.
 -   `echo2.dart` contains bindings for the `Echo` interface.This file is
     generated from the interface defined in `echo2.fidl`.
@@ -730,24 +730,24 @@ Everything starts with main():
 
 ```dart
 void main(List<String> args) {
-  _context = new ApplicationContext.fromStartupInfo();
+  _context = new StartupContext.fromStartupInfo();
   _echo = new _EchoImpl();
   _context.outgoingServices.addServiceForName<Echo>(_echo.bind, Echo.$serviceName);
 }
 ```
 
 `main()` is called by the Dart VM when your service is loaded, similar to
-`main()` in a C or C++ application. It binds an instance of `EchoImpl`, our
+`main()` in a C or C++ component. It binds an instance of `EchoImpl`, our
 implementation of the `Echo` interface, to the name of the `Echo` service.
 
-Eventually, another FIDL application will attempt to connect to our application.
+Eventually, another FIDL component will attempt to connect to our component.
 
 ### The `bind()` function
 
 Before going further, a quick review from the [FIDL
 Architecture](#fidl-architecture) section. A connection is defined as the
-_first_ channel with another application. Strictly speaking, the connection is
-complete when both applications have bound their `ServiceProvider` to that first
+_first_ channel with another component. Strictly speaking, the connection is
+complete when both components have bound their `ServiceProvider` to that first
 channel. Any additional channels are not "connections." The function names will
 make more sense if you keep this in mind.
 
@@ -760,8 +760,8 @@ void bind(InterfaceRequest<Echo> request) {
 ```
 
 The `bind()` function is called when the first channel is received from another
-application. This function binds once for each service it makes available to the
-other application (remember that each service exposes a single interface). The
+component. This function binds once for each service it makes available to the
+other component (remember that each service exposes a single interface). The
 information is cached in a data structure owned by the FIDL runtime, and used to
 create objects to be the endpoints for additional incoming channels.
 
@@ -771,9 +771,9 @@ per isolate, so there's no possible confusion over which thread owns a channel.
 
 #### Is there really only one thread?
 
-Both yes and no. There's only one thread in your application's VM, but the
-handle watcher isolate has its own, separate thread so that application isolates
-don't have to block. Application isolates can also spawn new isolates, which
+Both yes and no. There's only one thread in your component's VM, but the
+handle watcher isolate has its own, separate thread so that component isolates
+don't have to block. Component isolates can also spawn new isolates, which
 will run on different threads.
 
 ### The `echoString` function
@@ -796,7 +796,7 @@ The echo client implementation in Dart can be found at:
 
 Our simple client does everything in `main()`.
 
-**Note:** an application can be a client, a service, or both, or many. The
+**Note:** a component can be a client, a service, or both, or many. The
 distinction in this example between Client and Server is purely for
 demonstration purposes.
 
@@ -827,11 +827,11 @@ void main(List<String> args) {
     server = args[1];
   }
 
-  _context = new ApplicationContext.fromStartupInfo();
+  _context = new StartupContext.fromStartupInfo();
   final Services services = new Services();
-  final ApplicationLaunchInfo launchInfo = new ApplicationLaunchInfo(
+  final LaunchInfo launchInfo = new LaunchInfo(
       url: server, directoryRequest: services.request());
-  _context.launcher.createApplication(launchInfo, null);
+  _context.launcher.createComponent(launchInfo, null);
 
   _echo = new EchoProxy();
   _echo.ctrl.bind(services.connectToServiceByName<Echo>(Echo.$serviceName));
@@ -844,9 +844,9 @@ void main(List<String> args) {
 
 Again, remember that everything in FIDL is async. The call to
 `_echo.echoString()` returns immediately and then `main()` returns. The FIDL
-client library keeps its own pointer to the application object, which prevents
-the application from exiting. Once the response arrives, all of the handles are
-closed, and the application will terminate after the callback returns.
+client library keeps its own pointer to the component object, which prevents
+the component from exiting. Once the response arrives, all of the handles are
+closed, and the component will terminate after the callback returns.
 
 ### Run the sample
 
diff --git a/getting_started.md b/getting_started.md
index 6d274beb0814c52a83b3dde91b0e8bd62c3d240b..765c675a6e3f63db5e7e25abb71d9d8101865ddc 100644
--- a/getting_started.md
+++ b/getting_started.md
@@ -212,19 +212,19 @@ enabled](#enabling-graphics). The currently selected tab is highlighted in
 yellow at the top of the screen. You can switch to the next tab using Alt-Tab on
 the keyboard.
 
-- Tab zero is the console and displays the boot and application log.
+- Tab zero is the console and displays the boot and component log.
 - Tabs 1, 2 and 3 contain shells.
-- Tabs 4 and higher contain applications you've launched.
+- Tabs 4 and higher contain components you've launched.
 
 Note: to select tabs, you may need to enter "console mode". See the next section for details.
 
-### Launch a graphical application
+### Launch a graphical component
 
 QEMU does not support Vulkan and therefore cannot run our graphics stack.
 
-Most graphical applications in Fuchsia use the
+Most graphical components in Fuchsia use the
 [Mozart](https://fuchsia.googlesource.com/garnet/+/master/bin/ui/) system compositor. You can launch
-such applications, commonly found in `/system/apps`, like this:
+such components, commonly found in `/system/apps`, like this:
 
 ```
 launch spinning_square_view
@@ -271,4 +271,4 @@ You may wish to peruse the [testing FAQ](development/workflows/testing_faq.md).
 * [Fuchsia documentation](/README.md) hub
 * Working with Zircon - [copying files, network booting, log viewing, and
 more](https://fuchsia.googlesource.com/zircon/+/master/docs/getting_started.md#Copying-files-to-and-from-Zircon)
-* [Information on the system bootstrap application](https://fuchsia.googlesource.com/garnet/+/master/bin/sysmgr/).
+* [Information on the system bootstrap component](https://fuchsia.googlesource.com/garnet/+/master/bin/sysmgr/).
diff --git a/glossary.md b/glossary.md
index b4989b0c699d4d5c7b6d4d733eb8fad57aa64292..689a4fb1941c7a61a9394959020e3cf2b72cf694 100644
--- a/glossary.md
+++ b/glossary.md
@@ -29,8 +29,8 @@ messages, and make proposals to give suggestions to the user.
 
 #### **AppMgr**
 
-The Application Manager (AppMgr) is responsible for launching applications and
-managing the namespaces in which those applications run. It is the first process
+The Application Manager (AppMgr) is responsible for launching components and
+managing the namespaces in which those components run. It is the first process
 started in the `fuchsia` job by the [DevMgr](#DevMgr).
 
 #### **Armadillo**
@@ -215,7 +215,7 @@ Fuchsia's standard C library (libc) is based on Musl Libc.
 #### **Namespace**
 
 A namespace is the composite hierarchy of files, directories, sockets, [service](#Service)s,
-and other named objects which are offered to application components by their
+and other named objects which are offered to components by their
 [environment](#Environment).
 - [Fuchsia Namespace Spec](the-book/namespaces.md)
 
diff --git a/the-book/boot_sequence.md b/the-book/boot_sequence.md
index 92754b590aad8171a2d3c7c765ef3600fd1b9945..01b84b4e5c886eda2aabda67eacc353d4bda9f7e 100644
--- a/the-book/boot_sequence.md
+++ b/the-book/boot_sequence.md
@@ -21,20 +21,20 @@ app: `bootstrap`.
 # Layer 2: [sysmgr](https://fuchsia.googlesource.com/garnet/+/master/bin/sysmgr/)
 
 `sysmgr`'s job is to create the boot environment and create a number of
- initial applications in the boot environment.
+ initial components in the boot environment.
 
 The services that `sysmgr` offers in the boot environment are not provided by
 bootstrap itself. Instead, when `sysmgr` receives a request for a service for
 the first time, `sysmgr` lazily creates the appropriate app to implement that
-service and routes the request to that app. The table of which applications
+service and routes the request to that app. The table of which components
 implement which services is contained in the
 `/system/data/bootstrap/services.config` file. Subsequent requests for the same
 service are routed to the already running app. If the app terminates,
 `sysmgr` will start it again the next time it receives a request for a
 service implemented by that app.
 
-`sysmgr` also runs a number of applications in the boot environment at
-startup. The list of applications to run at startup is contained in the
+`sysmgr` also runs a number of components in the boot environment at
+startup. The list of components to run at startup is contained in the
 `/system/data/bootstrap/apps.config` file.
 
 # Layer 3: [device_runner](https://fuchsia.googlesource.com/peridot/+/master/bin/device_runner/)
diff --git a/the-book/namespaces.md b/the-book/namespaces.md
index 4e5a88deeecd317d4b964696f2d392d0b13f0574..1f84ed3946e290203ca4e96c8619b452886ee499 100644
--- a/the-book/namespaces.md
+++ b/the-book/namespaces.md
@@ -196,7 +196,7 @@ components running on Fuchsia.
 The precise contents and organization of a component's namespace varies
 greatly depending on the component's role, type, identity, scope,
 relation to other components, and rights. See [sandboxing.md] for information
-about how namespaces are used to create sandboxes for applications.
+about how namespaces are used to create sandboxes for components.
 
 _For more information about the namespace your component can expect to
 receive from its environment, please consult the documentation related to
@@ -209,7 +209,7 @@ There are some typical objects which a component namespace might contain:
 - Read-only executables and assets from the component's package.
 - Private local persistent storage.
 - Private temporary storage.
-- Services offered to the component by the system, the application framework,
+- Services offered to the component by the system, the component framework,
   or by the client which started it.
 - Device nodes (for drivers and privileged components).
 
diff --git a/the-book/package_metadata.md b/the-book/package_metadata.md
index 19f0c02d91122d7905e289ce778f25c261920246..0955f260b1a04289500176c9f2cf55af2f38519f 100644
--- a/the-book/package_metadata.md
+++ b/the-book/package_metadata.md
@@ -21,7 +21,7 @@ See [https://fuchsia.googlesource.com/pm#signature]
 
 ## runtime
 
-The runtime file specifies if execution of the application in the package
+The runtime file specifies if execution of the component in the package
 should be delegated to another process.
 
 The runtime file is a JSON object with the following schema:
@@ -38,9 +38,9 @@ The runtime file is a JSON object with the following schema:
 }
 ```
 
-The `runner` property names another application (or a package that contains
-one) to which execution is to be delegated. The target application must expose
-the [`ApplicationRunner`][application-runner] service.
+The `runner` property names another component (or a package that contains
+one) to which execution is to be delegated. The target component must expose
+the [`Runner`][runner] service.
 
 ## Component Manifest
 
@@ -105,21 +105,21 @@ The sandbox property is a JSON object with the following schema:
 ```
 
 The `dev` array contains a list of well-known device directories that are
-provided to the application. For example, if the string `class/input` appears in
-the `dev` array, then `/dev/class/input` will appear in the namespaces of applications
+provided to the component. For example, if the string `class/input` appears in
+the `dev` array, then `/dev/class/input` will appear in the namespaces of components
 loaded from the package. To whitelist access to a `misc` device, such as
 `/dev/misc/sysinfo`, add the string `misc` to the `dev` array. Unfortunately,
 whitelisting access to individual `misc` devices is not possible currently.
 
 The `system` array contains a list of well-known paths within the system package
-that are provided to the application. For example, if the string `bin` appears
+that are provided to the component. For example, if the string `bin` appears
 in the `system` array, then `/system/bin` will appear in the namespaces of
-applications loaded from the package.
+components loaded from the package.
 
 The `pkgfs` array contains a list of well-known paths within the pkgfs tree
-that are provided to the application. For example, if the string `packages`
+that are provided to the component. For example, if the string `packages`
 appears in the `pkgfs` array, then `/pkgfs/packages` will appear in the
-namespaces of applications loaded from the package, providing access to all
+namespaces of components loaded from the package, providing access to all
 packages fully cached on the system.
 
 The `features` array contains a list of well-known features that the package
@@ -160,4 +160,4 @@ The set of currently known features are as follows:
 See [sandboxing.md](sandboxing.md) for more information about sandboxing.
 
 
-[application-runner]: https://fuchsia.googlesource.com/garnet/+/master/public/lib/app/fidl/application_runner.fidl
+[runner]: https://fuchsia.googlesource.com/garnet/+/master/public/lib/app/fidl/runner.fidl
diff --git a/the-book/sandboxing.md b/the-book/sandboxing.md
index 101ca998f029cf53dc27a67aa3d1f3c68e441ef0..3811fc5d490682ccb9836bd07126f73d073ec039 100644
--- a/the-book/sandboxing.md
+++ b/the-book/sandboxing.md
@@ -31,13 +31,13 @@ In our current implementation, a process runs in a sandbox if its binary is
 contained in an archive (i.e., a [FAR](../glossary.md#FAR)). As the package manager
 evolves, these details are likely to change.
 
-An application run from an archive is given access to two namespaces by default:
+An component run from an archive is given access to two namespaces by default:
 
  * `/svc`, which is a bundle of services from the environment in which the
-   application runs.
- * `/pkg`, which is a read-only view of the archive containing the application.
+   component runs.
+ * `/pkg`, which is a read-only view of the archive containing the component.
 
-A typical application will interact with a number of services from `/svc` in
+A typical component will interact with a number of services from `/svc` in
 order to play some useful role in the system.
 
 The `far` command-line tool can be used to inspect packages installed on the
diff --git a/the-book/wireless_networking.md b/the-book/wireless_networking.md
index 0b9fef68afb670ecafce44af27ded5671633da37..216f7831007affd791e5477332f5e8d63db2c2d5 100644
--- a/the-book/wireless_networking.md
+++ b/the-book/wireless_networking.md
@@ -60,7 +60,7 @@ networking state. It communicates with a Soft MAC driver to manage the hardware.
 The Fuchsia Wireless Network Service implements the IEEE 802.11 SME functions
 and holds state about all the wireless networks that are available in the
 current environment. It is the interface to the hardware (via the drivers) used
-by applications like System UI.
+by components like System UI.
 
 ## Relation to the Ethernet stack