The process varies widely, but I'll explain a typical configuration--the same that Facebook uses.
Networking is complicated, especially when we're talking about a network as large as the internet--the biggest network in existence. Network-base communication between devices is divided into seven layers in what's called the
OSI model:
- Physical layer
- Data link layer
- Network layer
- Transport layer
- Session layer
- Presentation layer
- Application layer
As we work our way toward higher layers, we move away from the physical hardware, such as wires, Wi-Fi, and 4G LTE, toward more abstract, more "friendly" protocols, like HTTP. At the lower layers, protocols are highly technical and involve working with raw 1's and 0's, if even that. At higher layers, we start to see more human-friendly concepts appear, like legible text.
Typically, the purpose of the physical layer would be transferring data between two nearby devices: for example, getting data from your phone to a cell tower, and vice versa. At this layer, devices are typically identified by unfriendly numeric addresses, such as
MAC addresses, which look like 00:14:a5:41:61:6b. These aren't very friendly or easy to remember, and they're only useful within a small logical area--to actually get data across the internet, information has to hop between many different devices located within numerous companies, each of which has a different physical address.
This is where IP addresses come in. IP addresses are still unfriendly numbers, but they tell networking equipment were data is ultimately headed. A router at one ISP might know to send all IP addresses beginning with a certain sequence of digits to a specific router at another ISP, which gets the data closer to its final destination. Routers at different ISPs keep handing off the data to each other, passing it along until it reaches its intended destination. Each router only needs to worry about the next "hop"--who to hand the data to next--rather than needing to determine the entire path of the data. The routers know who their neighbors are--the other routers to which they're directly connected.
Let's say you're sending a package from Boston to San Francisco. You write the address on the package--that's the IP address. You give it to a carrier--that's the ISP. They route it across the country, placing it on different vehicles along the way. It stops at several different facilities, each of which routes the package to a facility closer to its final destination. You, as the sender, don't have to worry about which facilities the package needs to travel through. The facilities themselves don't need to worry about the entire path, either; they just have to hand it off to someone closer.
IP addresses, like street addresses, are quite handy, but they're not very friendly. I don't want to have to remember the address of each friend to whom I might ever send a package. I know them by name, and I use my address book to look up their street addresses whenever I need them. This is DNS: we, the users of computers, want to remember friendly names, like namepros.com. DNS acts as one giant, distributed address book: when I enter namepros.com into my computer, it looks in its address book to see if it knows the corresponding IP address. My computer's address book is pretty small, so it probably doesn't know. It then phones up a mutual friend who's a bit more pedantic about maintaining his address book--the DNS server.
This is the essence of the internet: each individual device only knows contains a small amount of the information that exists on the internet. Whenever you try to access information that your computer doesn't have, it passes off your request to your ISP, who passes it off to another ISP, and so on.
The primary purpose of a domain name is to be friendly to humans. They can serve other technical purposes, but friendliness and ease of memorization is why they were invented.
Which brings us to apps: they don't have to use domain names. Domains are for humans; apps aren't humans. The programmers can easily stick a raw IP address in an app, and some do exactly that. However, it's usually more convenient to use a domain name for a variety of technical reasons.
Mobile apps typically only deal with the uppermost layer, the application layer. They send data in a form that would be legible to a human, typically some kind of text. The mobile operating system is responsible for dealing with the other layers.
HTTP is an increasingly common application layer protocol. Originally, it was designed for transmitting web pages. These days, it's used for all manner of data. As you interact with the Facebook app, it's sending and retrieving data in a similar manner to your web browser. There isn't really a technical reason for this; it's just that they already have the infrastructure for handling HTTP, so why reinvent the wheel?
Progressive Web Apps (PWAs) are a bit different in that they're true websites--they're using HTTP exactly as intended. The phone displays them in a slimmed-down web browser; it'll typically remove the address bar and tabs from the interface, since they're not relevant. Otherwise, it's exactly the same as the native web browser app.
Both PWAs and normal apps typically utilize HTTP, and both are capable of analytics. Native (normal) apps are theoretically capable of a higher level of analytics than PWAs, but, in practice, this rarely makes a difference, and the same analytics frameworks, like Google Analytics, are often used in both.
The main advantages of a PWA:
- Lower development costs: rather than developing a website plus a separate app for each platform, you only need to develop an app.
- No need to download the app: since it's just a website, data is downloaded as the user interacts with the app, rather than all at once when the app is installed.
Disadvantages of a PWA:
- Web-based interfaces are slower and use more battery than equivalent native apps. This is an inherent limitation of current web technologies. There are efforts to alleviate this, but it will be several years at least before consumers will benefit from such improvements.
- Non-native experience. Rather than matching the appearance of a native mobile app on each respective platform, the app will look the same on all devices. Users of a platform will expect certain buttons and controls to behave in a certain way; the web app may not follow all of their expectations. This makes it harder for less experienced users to interact with the app.
- The app will be slower to respond. Because data is downloaded as the user interacts with the app, each time the user taps something, more data has to download. This means there's a delay before the app responds to interactions, whereas a native app will appear to respond instantly. The delay can be minimized or even eliminated in certain cases, but, in practice, such optimizations are rare.
- PWAs will typically use more data. A native app downloads most of its resources when the app is installed, but a PWA is progressively requesting resources such as images as the user interacts with the app. Depending on the user's cell plan, this could be costly.
Due to their limitations, as of writing, PWAs aren't particularly popular. There's a push from companies like Google to make this change, but other companies, such as Apple, are pushing strongly in the opposite direction.
