Architecture and Technical Elements
The Web App manifest
The Web App manifest — a JSON file — is the first component that gives the progressive its native app interface appearance. With the manifest, a developer can control the way the app is displayed to the user (i.e. full-screen mode without visible URL bar) and how it can be launched. The file allows a developer to find a centralized place for the web app’s metadata. The manifest usually contains starting URL, an app’s full and short name, links to icons and icons’ sizes, type, and location. A developer can also define a splash screen and a theme color for the address bar.

Google shows the features the Web App Manifest supports
To apply these settings, a developer only has to add a single link to the manifest in all website pages headers.
Service Worker
A service worker is another technical element that supports one of the main features of progressive web applications — the offline work mode, background syncs, and push notifications typical for native apps. The service worker is a JavaScript file running separately from the web page/app. It responds to user interactions with the app, including network requests made from pages it serves. Because the service worker runs only to process a specific event, its lifetime is short.
Offline work mode. The service worker allows for caching an application shell (interface), so it loads instantly on repeat visits. The necessary dynamic content (i.e. message or payment history, shopping cart, avatars) is refreshed every time the connection is back. These mechanics allows for decent app performance and improved user experience. For example, a messenger user won’t see the difference between the online and offline modes regarding interface: It still works; a message history is available. However, messaging requires connection.
Push notifications. Push notifications are an efficient tool for user re-engagement through the content and prompt updates from websites they like. Progressive web apps can send push notifications even when the browser is closed, and the app isn’t active.
Background synchronization. The service worker is also in charge of this feature. It delays actions until stable connectivity is back. For example, the message sent right before the connection fails will be marked as sent and then will be delivered as soon as service is restored. So, servers can send periodic updates to the app allowing it to update itself when the connection is restored.
The application shell architecture
Building and maintaining PWAs entails separating static content from dynamic content.

The illustration by Google explains that the app shell is generally static, while the content can change
So, the use of the application shell architecture (that is the base of the UI) we mentioned above is the only approach to their development.
The app shell consists of core design elements required to make the application run without the connection.
The app shell approach works especially well for JavaScript-heavy apps consisting of one page and apps with relatively stable navigation and changing content.
Transport Layer Security (TLS)
PWAs leverage the Transport Layer Security (TLS) protocol. TLS is the standard of secure and robust data exchange between two applications. The integrity of the data requires serving the website via HTTPS and installing an SSL certificate on a server.