Check out a free preview of the full Build Progressive Web Apps (PWAs) from Scratch course

The "Scope & Display" Lesson is part of the full, Build Progressive Web Apps (PWAs) from Scratch course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano discusses the web manifest properties scope and display and demonstrates their individual effects on the PWA for both iOS and Android. Students' questions regarding if the starting URL can be in a different domain and what the theme_color property in the manifest does to the application are also covered in this segment.


Transcript from the "Scope & Display" Lesson

>> We have a question about domains and subdomains, and it's actually a good introduction for the next property. So I'm going to probably answer the question while writing the next property. The next property is called scope, okay? Scope defines actually the folder or subfolder that defines what's within the app and what's outside of the app.

So, let me try to explain that. First, most of the time 99% of the PWAs are setting the scope as this, the current folder. So that means that, If you have a link here in your HTML to another HTML, if it's in the scope, so if it's in the same folder, the app will render that link.

Our window will render that link. But if it's outside of the scope, such as an external domain, a different domain, or a different folder, it will be rendered in some kind of a browser, and we're going to see it in action later. The problem is with subdomains, and I'm going to make a broader question here, is that what happens if we have a PWA basis planning?

It's URLs across different domains. They can be sub-domains, or different, sometimes country TLDs. Like you have a different TLD for UK, another one for France. Well, actually, this is a challenge, or let's say a limitation that we have today in the PWA platform. Each domain even if it's a sub domain, will always be treated as an external origin.

So it's not going to be part of a PWA. Even if you're pointing to the same manifest, it doesn't matter. They will be different PWAs. So if you have different domains, and the user will be able to install different apps, so you will end up with duplicates probably, okay?

And so you shouldn't do that. It's actually a problem. So if you're creating, if you're using dynamic DNS like that is pointing to different apps, like you are deep linking into different IDs based on the domain, you will have infinite PWAs actually, not one. So it's always a good idea to keep everything under one domain.

What happens with logins, like if you're using OAuth and you have a different domain, that's not actually a problem. Okay, you can call that and we will see it in action later, but it will actually open an inner browser. So for example, if you open Tinder, and if you click Login, remember this is a PWA, if we try to log in with Google, in Tinder, that goes to another domain that is not under

Well, this is what will happen. We have at the top, like a URL bar that is not editable, so this is called an inner browser. So when you link within your PWA to an external file, an external URL, an inner browser will appear. And this is not Safari.

I'm still in the Tinder app. So this is by default, automatic, free in a browser that will get in a PWA on every platform, Android, iOS or dekstop. From here, you can open the browser, you can share. Or if you hit Done, or if this URL in a different domain goes back to my domain, like returning from the OAuth, it will go back to the PWA.

So it will close the browser automatically, as if I hit Done. If you have a link to an external URL, an external domain, have in mind and in a browser will appear. And the user can go back, or the user will get back automatically if that URL goes back to your domain.

So the question is about the start URL. Can the start URL be a different domain, being subdomain or a completely different TLD? The answer is no. The browsers today are checking that the start URL must be within the same origin as the web manifest itself. If you have an absolute link here to somewhere else, you're not passing the PWA criteria, and the start URL may be ignored at all.

So it's not gonna work. That's why multiorders Xing PWAs is not something that we have available these days. We have a question on the theme color. The spec, the web manifest spec, defines the metadata as a way to define the theme color. The theme color that we have in the manifest is actually a fallback.

So in case this metatag is not present, it's going to use the one in the manifest that is actually statically defined. And also, the one that is in the theme in the manifest, the theme color that is in the manifest, is actually useful for when your app is still not ready.

Think about this, when you open an app, the app typically starts with a splash screen, and we're going to talk about that later. That splash screen will use the theme color from your manifest, because the HTML is not loaded yet. So it's not really your metatag. So that's why it's always a good idea to have the theme color on both places.

Most of the time, you're going to see that the start URL is also being used with some arguments. This is completely optional. But for example, something that is common to see is that you can add something like a Google analytics attribute here, like UTM source, where you say PWA or homescreen, or a standalone.

So then, within your Google Analytics or any other analytics providers, you can automatically separate between when the user is using the browser or when the user is using your app from the icon. And we are still missing one very important property. If we don't set this property, we don't have a PWA rate.

The property's called display, and we are going to set one of the possible values that we have these days. It can be browser, and if we said browser it means that we do not want a PWA. So if the user installs the icon, it will be a bookmark, a shortcut to the browser.

So we don't want that, right? Another option, and it's nine of ten PWAs are actually using this value, is standalone. Most of the time you're going to use standalone. A standalone means that you actually want your web content to be rendered as a standalone application. That's the idea if you don't have that you have a problem.

Other options that we have are minimal UI. Minimal UI will ask the browser to render a minimal navigation user interface. For example, Sqoosh is standalone. YouTube music is minimal UI. How do I know that? Because YouTube music in the title bar has this Stop and Reload button, and the Back button.

Those buttons are not available in Sqoosh. That's the difference from dekstop between standalone, Sqoosh and minimal UI YouTube music. Okay, make sense? iOS is not supporting minimal UI, only standalone. So if you set minima UI, it falls back to browser. So it will just open the browser it won't be actually a PWA.

And the final value that we have here, at least today, is full screen. That is only suitable for Android. So dekstop and iOS will fall back to standalone, like a normal PWA. To understand what's the difference between full screen and a standalone and Android, let me jump back to the slides.

On Android, when we have a standalone experience, it will look like this. You have the theme color in the Status bar, and the rest of the app appears with your HTML and CSS. Minimal UI will actually render like a larger URL bar with your theme color, in this case the orange, and you will see the current page title, the current origin, the URL.

And also there is a little menu, a drop-down menu on Android, where you can share, you can see the current info. And the info for example has the TLS certificate. And the full screen, it's completely full screen. You don't even see a Status bar. To understand this, let's see all the display modes in Android in action all at once.

We have standalone, minimal UI, and full screen. So when you're in full screen, you're actually using also the space for the Status bar and for the navigation bar at the bottom, which means the user won't see notifications, the current battery level, or the time. So full screen is suitable for games or immersive experiences, such as if you're doing mixed reality, or built a reality.

For most apps, typically, standalone is the way to go. And remember, minimal UI is not supported on IOS, and full screen is not supported on iOS or desktop.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now