DEV Community: ojach

If You Want User-Specific PWA Home Screen Entries, start_url: "." Is the Best Approach

ojach — Sat, 11 Jul 2026 03:44:16 +0000

Many developers want to add user-specific profile pages or product pages to the home screen as a PWA.

When implementing this, one of the first ideas that comes to mind is a manifest.json like this:

{
  "start_url": "/user/123"
}

I initially planned to implement it this way as well.

However, after spending quite a bit of time experimenting with PWAs, I found that this approach has drawbacks—not only from a privacy perspective, but also in terms of overall design.

Eventually, I settled on a much simpler configuration:

{
  "start_url": "."
}

In this article, I'll explain why I chose start_url: "." and what I learned through real-world testing.

Why You Shouldn't Put User IDs in `start_url`

MDN recommends not including user-identifiable information in start_url.

For example:

{
  "start_url": "/user/123"
}

{
  "start_url": "/product/987"
}

The reason is that even after browser data is cleared, information associated with an installed Web App may still be used to identify a user.

In other words, it's safer to avoid embedding information such as:

User IDs
Session IDs
Tokens

inside start_url.

A Fixed URL Isn't Great for UX Either

So what about using a fixed URL like this?

{
  "start_url": "/"
}

While it avoids the privacy concern, it introduces another problem: user experience.

Imagine adding one of these pages to the home screen:

A blog article
A product page
A documentation page
A user profile

Even though the user added a specific page, launching the app always takes them back to the homepage.

The user expected to save that page, but instead the entire website becomes the entry point.

Trying `start_url: "."`

The solution I ended up testing was simply:

{
  "start_url": "."
}

The "." is treated as a path relative to the current page.

For example, if the current URL is:

/user/alice

adding it to the home screen will launch:

/user/alice

Likewise, if you're viewing:

/docs/install

the installed app opens:

/docs/install

No special routing logic is required.

It Works Extremely Well with Dynamic Manifests

This approach is especially convenient when you're generating manifest.json dynamically.

For example:

{
  "name": "Example",
  "display": "standalone",
  "start_url": "."
}

That's all you need.

There's no need to inject user IDs into the manifest.

Instead, the currently displayed:

profile page
product page
article

automatically becomes the app's entry point.

It also makes future URL structure changes much easier to handle.

The Behavior Felt Much More Natural

I tested several different scenarios.

Added From	Launches To
Blog article	Same article
Product page	Same product
User profile	Same profile
Documentation	Same document

The installed app always opened the page that had originally been added.

Personally, this feels much closer to how a PWA should behave.

But That's Not the Whole Story on Android

There is one important caveat.

While start_url: "." solves the launch URL problem, Android introduces another challenge when you want to install multiple pages.

For example, suppose users install:

User A
User B

If your manifest looks like this:

{
    "scope": "/",
    "id": "/"
}

Chrome may decide they're actually the same Web App.

As a result, I observed behavior such as:

The second installation is treated as already installed.
A second icon cannot be added.
Different pages are merged into the same app.

Simply changing start_url does not solve this problem.

You Need to Design the Entire Manifest

One thing became very clear during my experiments:

Thinking only about start_url isn't enough.

You also need to consider:

start_url
id
scope
icons

and how each operating system interprets them.

On Android in particular, both id and scope affect app identity, so they're critical when building dynamic PWAs.

Conclusion

You don't need to include user IDs inside start_url.

Simply using:

{
    "start_url": "."
}

lets the currently displayed page become the app's entry point.

Advantages include:

Follows MDN's privacy recommendations.
Provides a much more natural user experience.
Works well with dynamically generated manifests.
Remains flexible even if your URL structure changes.

However, on Android you'll also need to carefully design id and scope. In my case, the solution was to serve different manifest.json files for Android and iOS.

Using the following two manifests makes the behavior much more consistent across platforms.

Android

{
  "name": "OJapp | PWA LAB",
  "start_url": ".",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#2dd7ff"
}

iOS

{
  "name": "OJapp | PWA LAB",
  "start_url": ".",
  "scope": "/lab",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#2dd7ff"
}

Actual Manifest Generation Used in Petal

const isIOS = /iPhone|iPad|iPod/i.test(ua);

const manifest = {
  name: `${shortName} | Petal`,
  short_name: shortName,
  display: "standalone",
  start_url: ".",

  ...(isIOS ? { scope: "/" } : {}),

  background_color: "#ffffff",
  theme_color: "#2dd7ff",

  icons: [
    {
      src: app.icon_url,
      sizes: "192x192",
      type: "image/png"
    },
    {
      src: app.icon_url,
      sizes: "512x512",
      type: "image/png"
    }
  ]
};

Petal is a project that I develop and maintain.

By setting app.icon_url as the app icon and using the user's name as short_name, each person's business card becomes its own home screen icon. Launching that icon opens the corresponding profile page.

I also wrote another article explaining why Android and iOS require different scope settings, and how to work around those differences:

https://zenn.dev/ojapp_tips/articles/1e477228185158

This article is also an English rewrite of my original Tips blog post:

"PWAs Can Do This: How to Add User-Specific Pages to the Home Screen"

https://tips.ojapp.app/pwa-start-url-dot-best-practice-2/

What I Learned by Using a Nonexistent URL: iPhone’s Hidden Home Screen Icon Behavior

ojach — Sat, 04 Jul 2026 10:02:25 +0000

This is a reprint from my tips blog. You can find the original article here: https://tips.ojapp.app/iphone-home-icon-auto-generated-theme-color/

Hi, I'm Ojach.

I built a feature in my test lab, "PWA LAB," that allows me to freely change the installation URL. The goal was simple: I wanted a place to try out, in real-time, how a PWA actually looks when added to the home screen.

Validating PWAs often comes down to these small, gritty experiments. Especially with maskable icons, where the differences in how Android and iOS handle cropping can change everything.

Reading the spec sheet 100 times can't compare to the moment you break your own code on a real device and finally "get it." Every developer has been there.

That's exactly what happened this time.

To be honest, it was just a simple URL typo. But that "oops" moment led me to discover some fascinating, undocumented behaviors regarding iPhone home screen icons. I just had to share this.

Validating the "Broken State"

The setup was incredibly simple. I used my PWA LAB to intentionally set an "invalid, non-existent URL" as the installation target. Then, I hit "Add to Home Screen" on both Android (Chrome) and iPhone (Safari) to see what would happen.

I was curious about a few things:

Can you even add a non-existent URL to the home screen?
How does the OS handle it when the icon image returns a 404?
How much of manifest.json is ignored versus respected?
What does this reveal about the underlying philosophy of each OS?

When you intentionally break things, the OS's fallback mechanisms—usually hidden behind the scenes—are laid bare.

【Android】 Chrome: The Strict Disciplinarian

As expected, Android (Chrome) completely shut me out. It wouldn't even let me press the "Install" button. It essentially said, "This isn't a valid app, so beat it."

It's a perfectly sound and correct behavior. If it's going to be a PWA on the home screen, the launch URL must work. Android Chrome's validation is rigorous.

In Android's "mind," it’s a simple logic: "This URL won't launch as an app, so it doesn't deserve PWA status. Rejected." It’s a very Google-like approach—treating the Web as a foundation to be elevated into "real" native-like experiences.

【iPhone】 Safari: The Over-the-Top Concierge

Now, the iPhone (Safari). This is where things got really interesting.

To my surprise, the iPhone let me "Add to Home Screen" without a hitch, even with an invalid URL. It didn't have any of the cold refusal you see on Android.

Of course, the icon image (PNG) returned a 404. But here’s the kicker: The iPhone immediately auto-generated a "placeholder icon" on the fly and made it look like a real app.

Observing this logic led to three surprising discoveries:

1. `theme_color` was actually alive

Frontend developers know the pain: theme_color in manifest.json often feels like a "dead" property on iOS. On Android, it smoothly paints the toolbar and headers, which is satisfying. But on iOS, it’s rarely felt.

However, since my icon image was missing, I saw the "backdoor" Apple prepared. The background color of the auto-generated icon was dyed in the color I specified in theme_color.

Red theme_color -> Reddish background.
Blue theme_color -> Bluish background.

Because we usually set 100% custom icons, we never notice this. When the icon is lost, iPhone digs up the theme_color and uses it as a "seat cushion" for the background. I was honestly impressed: "So that's where you were working!"

2. The Apple-style "Initial Character" Fallback

Next is how it handles text. When there's no icon, the iPhone automatically extracts the first character of the site title and centers it in the icon.

If the title is "Ojach's Blog," it displays a beautifully rendered character in the center, like this:

お

It actually looks quite stylish—like a minimalist app logo. It shows Apple’s pride (or obsession) to not let the home screen be cluttered with ugly "NO IMAGE" icons.

3. The "Emoji-as-an-App-Icon" Hack

Experimenting further, I found something even better. If you put an emoji at the beginning of your site title, the iPhone will use that as the app icon.

If you name your site:

😀 PWA LAB

The home screen icon becomes:

😀

It works flawlessly with transparency and looks great. I spent way too much time trying to figure out which emoji made the best app icon. You get these unexpected gems when you mess around with real devices.

Philosophy Clash: Android Builds Apps, iPhone Places Objects

Looking at these differences, the contrast in philosophy is striking:

OS	Handling Invalid URLs	Icon Missing	Core Philosophy
Android	Blocks addition (Error)	Cannot install	"Elevate Web to a strict App."
iPhone	Forces it onto home screen	Auto-generates nicely	"Decorate Web pages as home screen pieces."

Android is logical; if the structure is broken, it's not an app.
iPhone is emotional; even if the link is dead, it prioritizes keeping the user's home screen beautiful and forced it into a usable object.

【Note】 Don't skip your icons just yet! (lol)

While this was a fascinating discovery, please don't use this as an excuse to stop designing icons! In production, you absolutely should provide your own assets.

Especially on iOS, apple-touch-icon caching is aggressive, so you need to stick to the standard implementation. On Android, providing a 512x512 PNG with any maskable support in manifest.json is still the gold standard.

This auto-generation is just an "insurance policy" from Apple to keep things looking good in case of an emergency. Don't rely on it as your primary strategy.

Summary: There's a world you can only see by "breaking" things

It's easy to stick to the textbook implementations. But by seeing how the OS desperately tries to "take care" of your broken code, you catch glimpses of the hidden polish and thoughtfulness put in by the engineers at Apple and Google.

This experiment, born from a simple typo, taught me two things:

iPhone will go to great lengths to ensure your home screen looks clean, even without an icon.
theme_color, which I thought was dead on iOS, is actually doing heavy lifting in the background.

"PWA LAB" is incredibly fun precisely because it lets me run these "buggy experiments" without consequences.

If you're tired of implementing by the book, try deleting your PWA icon settings and see what kind of "hospitality icon" your iPhone generates for you. You'll likely be pleasantly surprised.

※ This article is a reprint from my tech blog: OJapp Tips｜What I Learned by Using a Nonexistent URL: iPhone’s Hidden Home Screen Icon Behavior

iOS and Android Have Different Goals for PWAs: The Real Difference Beyond Support or No Support

ojach — Fri, 03 Jul 2026 15:52:00 +0000

This is a reprint from my tips blog. You can find the original article here: [https://tips.ojapp.app/en/ios-android-pwa-goal-difference-3/]

Android vs. iPhone: Different Goals for PWAs

When people talk about PWAs, the explanation often sounds like this:

Android supports PWAs.
iPhone does not support PWAs very well.

If you only look at the PWA specifications, this explanation is easy to understand.

Android Chrome supports manifest.json, Service Worker, installation, notifications, shortcuts, and many other PWA features quite strongly.

iPhone Safari, on the other hand, does not behave the same way as Android.

But after testing PWAs on both iPhone and Android many times, I started to see the difference in another way.

More accurately, Android and iPhone have different goals for PWAs.

That is the biggest difference I noticed while testing repeatedly.

Android tries to turn web pages into apps

Android PWAs are clearly designed in the direction of making web pages feel closer to native apps.

The idea is to take a website opened in the browser and move it toward a native-app-like experience.

This direction is very strong on Android.

That is why many PWA-related features are well supported.

manifest.json
Service Worker
Push notifications
Install Prompt
Shortcuts
theme_color
background_color
maskable icons
display modes
orientation

Of course, it is not perfect.

Manifest cache can be stubborn, multiple PWAs on the same domain can become confusing, and real-device testing can still create plenty of traps.

Even so, when you build according to the PWA specification, Android usually responds in a fairly straightforward way.

For example, if you set display: fullscreen, the app feels much more full-screen.

theme_color is often reflected in the toolbar color.

orientation also works quite strongly on Android.

In other words, for Android, a PWA is an app made from the Web.

iPhone starts from the experience of placing web pages on the home screen

iPhone is different.

Even before the word PWA became common, iOS already had a culture of adding web pages to the home screen.

This is close to the WebClip idea.

You open a page in Safari and place it on the home screen as an icon.

Next time, you tap that icon and open the page directly.

This is not exactly “turning the Web into an app.”

It is more like making a frequently used web page part of the home screen.

That is why iPhone PWAs appear to have a different goal from Android PWAs.

Android tries to move the Web closer to native apps.

iPhone tries to let web pages live naturally on the home screen.

Once you understand this difference, iOS PWA behavior starts to look a little different.

iPhone is not ignoring PWAs

People often say that iPhone does not support PWAs properly.

But in reality, it is not true that nothing works.

On iPhone, Add to Home Screen, app-like standalone display, short_name, start_url, scope, and icon settings all matter.

scope is especially important when you actually test it.

While the user stays inside the scope, the app-like appearance is easier to maintain. When the user moves outside the scope, Safari may show a small browser UI.

This would be unlikely if iOS were completely ignoring PWA behavior.

However, these settings do not work in the same way as Android.

Even if you set display: fullscreen or orientation, iPhone does not reflect them as directly as Android.

Maskable icons are also not as important on iPhone as they are on Android.

Instead, apple-touch-icon has a very strong presence.

This is where you can feel iPhone’s own home screen culture.

Why iPhone PWA behavior feels unique

There are several points where PWA developers often get confused on iPhone.

start_url does not always feel like it behaves as expected
scope behaves differently from Android
apple-touch-icon can feel stronger than manifest icons
Some parts of manifest.json seem to have little effect
display and orientation, which work on Android, barely change anything on iPhone

It is easy to summarize all of this by saying, “iPhone does not support PWAs.”

But I think the reality is a little more complicated.

Apple seems to treat PWAs less like “apps made from the Web” and more like web pages placed on the home screen.

In other words, Apple may care less about how much of the PWA specification is implemented, and more about what the user intended to place on the home screen.

That is why apple-touch-icon is strong on iPhone.

The home screen icon has to look natural.

That is also why moving outside the scope can show Safari’s mini UI.

The user needs to understand that they have left the thing they placed on the home screen.

When viewed this way, iOS behavior does not look like simple lack of support.

It starts to look like a very Apple-like design choice.

If you care about PWA specification support, Android is stronger

If you judge PWAs purely by specification support, Android is much easier to understand.

You write manifest.json, register a Service Worker, prepare icons, and set display and theme color.

Then the result is usually close to what you expected.

It is also easier for developers to predict.

Chrome DevTools and Lighthouse make it easier to check, and Android follows the textbook PWA flow more clearly.

If you want to make a web app feel truly close to a native app, Android is very strong.

Android PWAs are especially useful for things like:

Offline tools
Business apps
Dashboards
Input forms
Web apps that use notifications
Game-like full-screen experiences

Android is strong at moving the Web toward an app experience.

I think that is clearly true.

As a home screen experience, iPhone is also very polished

However, if you look at PWAs as a home screen experience, iPhone is also very polished.

You open a page in Safari and add it to the home screen from the Share menu.

An icon appears on the home screen.

When you open it, it launches in an app-like view without the URL bar.

This experience feels very natural.

For ordinary users, the question is not whether the manifest is perfectly reflected.

What matters more is whether the thing they placed on the home screen opens naturally.

iPhone feels like it has been polishing that experience for a long time.

Including the rounded icon shape, home screen alignment, and the way a web page blends into the home screen, the experience is very strong.

So iPhone PWAs are not simply worse than Android PWAs.

The goal is different.

Android turns the Web into apps, iPhone turns web pages into home screen entries

To summarize the difference simply:

Item	Android	iPhone
Core idea	Turn the Web into apps	Place web pages on the home screen
Strong point	PWA specification support	Home screen experience
manifest	Works fairly directly	Partly works, but with strong iOS-specific behavior
Icons	manifest icons and maskable icons matter	apple-touch-icon is strong
display	fullscreen and standalone are easy to see	standalone is the realistic default
Best fit	Apps made from the Web	Web pages placed on the home screen

Android wants to turn the Web into an app.

iPhone wants to make web pages first-class citizens on the home screen.

When you look at it this way, the behavior differences become much easier to understand.

For services like Petal, the iPhone way feels very natural

When I think about this difference, the iPhone way feels very natural for a service like Petal.

Petal is not mainly about placing the service app itself on the home screen.

It is about placing a person’s digital card or personal page on the home screen.

In other words, it is not “launching an app.”

It is closer to “opening a person.”

This idea is closer to the iPhone-style “place a web page on the home screen” than the Android-style “turn the Web into an app.”

You quietly place someone’s page on your own home screen.

You open it with one tap when you need it.

You are not called back by notifications. You remember it yourself and open it.

For this kind of weak-connection design, iPhone’s home screen culture fits surprisingly well.

This is something I would not have noticed just by building a PWA.

I saw it because I built Petal and thought seriously about the experience of placing a person on the home screen.

OJapp is also more about home screen entrances than PWA itself

OJapp is similar.

OJapp is not a service that wants to show off PWA technology itself.

What it wants to do is place URLs on the smartphone home screen and turn websites into app-like entrances.

In other words, it is less about turning the Web into apps and more about creating entrances that can live on the home screen.

This idea is also close to the iPhone way of thinking.

Of course, on Android, it behaves more strongly as a PWA.

But the essence of OJapp is not only whether something can be installed.

It is the culture of placing URLs on the home screen.

From that point of view, the difference between iOS and Android is not just about superiority.

It becomes a difference in what each platform is good at.

In PWA development, the point is not choosing which one is correct

When building a PWA, trying to decide whether Android or iPhone is “correct” usually makes things harder.

If you design only for Android, some settings will not work on iPhone.

If you design only for iPhone, Android may create problems around scope or install detection.

I ran into exactly this issue.

On iPhone, I wanted a wider scope.

On Android, if the scope is too wide, multiple PWA boundaries can become messy.

It is not that one is right and the other is wrong.

The goals are different.

So what matters is designing separately based on the experience you want to create.

Use Android’s strong PWA behavior for app-like experiences
Carefully design the home screen placement experience for iPhone
Check manifest and scope behavior separately by OS
Think about icons differently on Android and iPhone
Always test on real devices

If you start from this premise, it becomes much harder to make the wrong design choice.

Summary

People often say that Android supports PWAs and iPhone does not.

But after testing both, the reality looks a little different.

Android is strong at turning the Web into apps.

iPhone is strong at placing web pages on the home screen.

For Android, a PWA is an app made from the Web.

For iPhone, a PWA is closer to a web page placed on the home screen.

That is why they behave differently.

That is why the same manifest.json does not produce the same result.

What I felt after testing many times is that iPhone does not fail to understand PWAs.

Apple is giving a different answer from Google.

When viewed that way, iOS-specific behavior becomes much easier to accept.

And when you think about use cases like Petal, where someone’s page is placed on the home screen, the iPhone way can sometimes feel even more natural.

If you judge PWAs only by support or non-support, you miss the real difference.

Android and iPhone have different goals for PWAs.

Starting from that idea makes web app design much more interesting.