How Does an App Work? The Main Parts Explained

An app works by connecting what a person sees and does with instructions that produce a result. Depending on its purpose, it may also save information or communicate with other software.

You can understand this through four common responsibilities:

• The interface: What people see and interact with.
• The application logic: The rules and decisions behind the behaviour.
• Data storage: How information is kept for later.
• External services: Other systems the app communicates with when needed.

These are a useful way to think about an app. They do not mean every project needs four separate files or every app needs an external service.

Understanding these responsibilities helps you discuss changes with AI and recognise which parts may be involved when something goes wrong.

The Interface Lets People Use The App

The user interface, often shortened to UI, is the part through which someone interacts with the software.

It includes things such as:

• Text, images, and lists.
• Buttons and input fields.
• Menus and navigation.
• Messages explaining success, progress, or failure.

In our errands app, the interface includes the field where someone enters a task, the “Add task” button, and the list showing saved errands.

The interface has two closely connected jobs. It receives the person’s actions and communicates what the app is doing.

For example, pressing “Add task” tells the app that the person wants to create a task. Seeing the task appear in the list communicates the result.

The screen alone does not explain how that result happened. Other instructions decide whether the task is allowed and how it should be saved.

Application Logic Gives Actions Their Meaning

Application logic means the rules and decisions that control the app’s behaviour.

In the previous blog, we defined requirements such as:

“A task must have a name. A name containing only spaces counts as empty.”

The application logic puts that rule into practice. It determines whether the entered text is acceptable before allowing the task to be created.

Logic can also handle calculations, comparisons, and decisions about what should happen next.

For example:

• A shopping app calculates a basket total.
• A recipe app decides which recipes match a search.
• A task app decides whether a new entry meets its rules.

The interface and logic work together. If someone presses Add task without entering a name, the logic identifies the problem. The interface explains it to the person.

Keeping this distinction in mind helps you understand why a button can look correct while producing the wrong behaviour.

Data Storage Keeps Information Available

Data is the information an app works with. In the errands app, it includes task names and the details needed to keep those tasks organised.

Some information only needs to exist briefly. Other information needs to remain available after the app closes.

Data storage provides a way to keep that information and retrieve it later.

The errands app needs storage because its purpose includes finding tasks again. Without it, a task might appear during the current session and disappear when the app restarts.

Information can be stored in different places, including:

• On the person’s device.
• On a remote computer reached through a network.
• In both places, with a system for keeping the copies consistent.

A small app can store information on the device without requiring an online account.

When you hear the word database, think of an organised store of information that software can read and change. A database is one storage option; it does not automatically mean the information is kept online.

The important questions are what needs to be kept, where it is kept, and how the app retrieves it.

External Services Provide Capabilities From Elsewhere

An external service is another system that the app communicates with.

For example, a weather app might request a forecast from a weather service. A delivery app might use a mapping service to show an address.

The app needs a way to make a request and understand the response. You will often hear this connection described as an API, short for application programming interface. It is a defined way for one piece of software to interact with another.

An external service can provide a useful capability without you building the whole system yourself. It also introduces another part the app depends on.

For example, a weather screen needs to account for the possibility that a forecast cannot be retrieved.

Our first errands app can record and retrieve tasks on the device. An external service would become relevant if the agreed experience required something beyond that, such as sharing information between people.

We will examine dependencies and their trade-offs more closely in Blog 10.

What Do “Frontend” And “Backend” Mean?

These terms describe broad parts of many software systems.

The frontend is the part a person interacts with, such as a website in a browser or an app on a phone. It can include interface code and logic that runs on the person’s device.

The backend is the supporting software that runs elsewhere, often on a server. A server is a computer or program that responds to requests from other software.

A backend might manage shared information, check account access, or perform work needed by several users.

These terms do not divide every responsibility neatly. Some rules may run on the device, while others run on a server. Information may also be stored in either place.

An app that performs its work entirely on the device may not need a separate backend. Its purpose determines what supporting systems are necessary.

Responsibilities Are Different From Files And Screens

A screen is something the person sees. A file is a place where project material, such as code, is organised. A responsibility describes what a part of the app does.

They do not always match one another directly.

One screen may rely on several files. A single saving component may support many screens. A small project may initially put several responsibilities together.

For example, the task list screen might use:

• Interface code to display the list.
• Logic to decide its ordering.
• Storage code to retrieve the saved tasks.

Later in the book, we will discuss how to organise code clearly. For now, focus on understanding the jobs involved rather than memorising a particular folder arrangement.

Use This Picture When Talking To AI

Knowing these parts gives you more precise questions to ask.

If the task list is hard to read, you can discuss the interface. If blank tasks are being accepted, you can ask about the rule that checks task names. If tasks disappear after restarting, you can investigate saving and retrieval.

These are starting points for investigation, rather than proof of where a fault lies. A visible problem can have a cause in another part of the app.

A useful request is:

“Explain which parts of this project display tasks, apply the task rules, and save or retrieve information. Tell me whether any external service is involved.”

You now have a basic picture of the system behind the screen. In the next blog, we will follow a piece of information through that system—from what a person enters to what the app changes, displays, and keeps.