{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibdm3quiqeupt276cowqplxmpddehjvurnfrzyg6dlnx6nvpm5yhi",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpqw5blwps32"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreihtoa6kclmfhlevufogtb65s2ah6ehnai4agvahpnjl4275x655dm"
    },
    "mimeType": "image/webp",
    "size": 84746
  },
  "path": "/ojach/ios-and-android-have-different-goals-for-pwas-the-real-difference-beyond-support-or-no-support-2am0",
  "publishedAt": "2026-07-03T15:52:00.000Z",
  "site": "https://dev.to",
  "tags": [
    "webdev",
    "pwa",
    "android",
    "ios",
    "https://tips.ojapp.app/en/ios-android-pwa-goal-difference-3/"
  ],
  "textContent": "> 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/]\n\n#  Android vs. iPhone: Different Goals for PWAs\n\nWhen people talk about PWAs, the explanation often sounds like this:\n\n  * Android supports PWAs.\n  * iPhone does not support PWAs very well.\n\n\n\nIf you only look at the PWA specifications, this explanation is easy to understand.\n\nAndroid Chrome supports manifest.json, Service Worker, installation, notifications, shortcuts, and many other PWA features quite strongly.\n\niPhone Safari, on the other hand, does not behave the same way as Android.\n\nBut after testing PWAs on both iPhone and Android many times, I started to see the difference in another way.\n\n**More accurately, Android and iPhone have different goals for PWAs.**\n\nThat is the biggest difference I noticed while testing repeatedly.\n\n##  Android tries to turn web pages into apps\n\nAndroid PWAs are clearly designed in the direction of making web pages feel closer to native apps.\n\nThe idea is to take a website opened in the browser and move it toward a native-app-like experience.\n\nThis direction is very strong on Android.\n\nThat is why many PWA-related features are well supported.\n\n  * manifest.json\n  * Service Worker\n  * Push notifications\n  * Install Prompt\n  * Shortcuts\n  * theme_color\n  * background_color\n  * maskable icons\n  * display modes\n  * orientation\n\n\n\nOf course, it is not perfect.\n\nManifest cache can be stubborn, multiple PWAs on the same domain can become confusing, and real-device testing can still create plenty of traps.\n\nEven so, when you build according to the PWA specification, Android usually responds in a fairly straightforward way.\n\nFor example, if you set `display: fullscreen`, the app feels much more full-screen.\n\n`theme_color` is often reflected in the toolbar color.\n\n`orientation` also works quite strongly on Android.\n\nIn other words, for Android, a PWA is **an app made from the Web**.\n\n##  iPhone starts from the experience of placing web pages on the home screen\n\niPhone is different.\n\nEven before the word PWA became common, iOS already had a culture of adding web pages to the home screen.\n\nThis is close to the WebClip idea.\n\nYou open a page in Safari and place it on the home screen as an icon.\n\nNext time, you tap that icon and open the page directly.\n\nThis is not exactly “turning the Web into an app.”\n\nIt is more like **making a frequently used web page part of the home screen**.\n\nThat is why iPhone PWAs appear to have a different goal from Android PWAs.\n\nAndroid tries to move the Web closer to native apps.\n\niPhone tries to let web pages live naturally on the home screen.\n\nOnce you understand this difference, iOS PWA behavior starts to look a little different.\n\n##  iPhone is not ignoring PWAs\n\nPeople often say that iPhone does not support PWAs properly.\n\nBut in reality, it is not true that nothing works.\n\nOn iPhone, Add to Home Screen, app-like standalone display, `short_name`, `start_url`, `scope`, and icon settings all matter.\n\n`scope` is especially important when you actually test it.\n\nWhile 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.\n\nThis would be unlikely if iOS were completely ignoring PWA behavior.\n\nHowever, these settings do not work in the same way as Android.\n\nEven if you set `display: fullscreen` or `orientation`, iPhone does not reflect them as directly as Android.\n\nMaskable icons are also not as important on iPhone as they are on Android.\n\nInstead, `apple-touch-icon` has a very strong presence.\n\nThis is where you can feel iPhone’s own home screen culture.\n\n##  Why iPhone PWA behavior feels unique\n\nThere are several points where PWA developers often get confused on iPhone.\n\n  * `start_url` does not always feel like it behaves as expected\n  * `scope` behaves differently from Android\n  * `apple-touch-icon` can feel stronger than manifest icons\n  * Some parts of manifest.json seem to have little effect\n  * `display` and `orientation`, which work on Android, barely change anything on iPhone\n\n\n\nIt is easy to summarize all of this by saying, “iPhone does not support PWAs.”\n\nBut I think the reality is a little more complicated.\n\nApple seems to treat PWAs less like “apps made from the Web” and more like web pages placed on the home screen.\n\nIn 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.\n\nThat is why `apple-touch-icon` is strong on iPhone.\n\nThe home screen icon has to look natural.\n\nThat is also why moving outside the scope can show Safari’s mini UI.\n\nThe user needs to understand that they have left the thing they placed on the home screen.\n\nWhen viewed this way, iOS behavior does not look like simple lack of support.\n\nIt starts to look like a very Apple-like design choice.\n\n##  If you care about PWA specification support, Android is stronger\n\nIf you judge PWAs purely by specification support, Android is much easier to understand.\n\nYou write manifest.json, register a Service Worker, prepare icons, and set display and theme color.\n\nThen the result is usually close to what you expected.\n\nIt is also easier for developers to predict.\n\nChrome DevTools and Lighthouse make it easier to check, and Android follows the textbook PWA flow more clearly.\n\nIf you want to make a web app feel truly close to a native app, Android is very strong.\n\nAndroid PWAs are especially useful for things like:\n\n  * Offline tools\n  * Business apps\n  * Dashboards\n  * Input forms\n  * Web apps that use notifications\n  * Game-like full-screen experiences\n\n\n\nAndroid is strong at moving the Web toward an app experience.\n\nI think that is clearly true.\n\n##  As a home screen experience, iPhone is also very polished\n\nHowever, if you look at PWAs as a home screen experience, iPhone is also very polished.\n\nYou open a page in Safari and add it to the home screen from the Share menu.\n\nAn icon appears on the home screen.\n\nWhen you open it, it launches in an app-like view without the URL bar.\n\nThis experience feels very natural.\n\nFor ordinary users, the question is not whether the manifest is perfectly reflected.\n\nWhat matters more is whether the thing they placed on the home screen opens naturally.\n\niPhone feels like it has been polishing that experience for a long time.\n\nIncluding the rounded icon shape, home screen alignment, and the way a web page blends into the home screen, the experience is very strong.\n\nSo iPhone PWAs are not simply worse than Android PWAs.\n\nThe goal is different.\n\n##  Android turns the Web into apps, iPhone turns web pages into home screen entries\n\nTo summarize the difference simply:\n\nItem | Android | iPhone\n---|---|---\nCore idea | Turn the Web into apps | Place web pages on the home screen\nStrong point | PWA specification support | Home screen experience\nmanifest | Works fairly directly | Partly works, but with strong iOS-specific behavior\nIcons | manifest icons and maskable icons matter | apple-touch-icon is strong\ndisplay | fullscreen and standalone are easy to see | standalone is the realistic default\nBest fit | Apps made from the Web | Web pages placed on the home screen\n\nAndroid wants to turn the Web into an app.\n\niPhone wants to make web pages first-class citizens on the home screen.\n\nWhen you look at it this way, the behavior differences become much easier to understand.\n\n##  For services like Petal, the iPhone way feels very natural\n\nWhen I think about this difference, the iPhone way feels very natural for a service like Petal.\n\nPetal is not mainly about placing the service app itself on the home screen.\n\nIt is about placing a person’s digital card or personal page on the home screen.\n\nIn other words, it is not “launching an app.”\n\nIt is closer to “opening a person.”\n\nThis 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.”\n\nYou quietly place someone’s page on your own home screen.\n\nYou open it with one tap when you need it.\n\nYou are not called back by notifications. You remember it yourself and open it.\n\nFor this kind of weak-connection design, iPhone’s home screen culture fits surprisingly well.\n\nThis is something I would not have noticed just by building a PWA.\n\nI saw it because I built Petal and thought seriously about the experience of placing a person on the home screen.\n\n##  OJapp is also more about home screen entrances than PWA itself\n\nOJapp is similar.\n\nOJapp is not a service that wants to show off PWA technology itself.\n\nWhat it wants to do is place URLs on the smartphone home screen and turn websites into app-like entrances.\n\nIn other words, it is less about turning the Web into apps and more about creating entrances that can live on the home screen.\n\nThis idea is also close to the iPhone way of thinking.\n\nOf course, on Android, it behaves more strongly as a PWA.\n\nBut the essence of OJapp is not only whether something can be installed.\n\nIt is the culture of placing URLs on the home screen.\n\nFrom that point of view, the difference between iOS and Android is not just about superiority.\n\nIt becomes a difference in what each platform is good at.\n\n##  In PWA development, the point is not choosing which one is correct\n\nWhen building a PWA, trying to decide whether Android or iPhone is “correct” usually makes things harder.\n\nIf you design only for Android, some settings will not work on iPhone.\n\nIf you design only for iPhone, Android may create problems around scope or install detection.\n\nI ran into exactly this issue.\n\nOn iPhone, I wanted a wider scope.\n\nOn Android, if the scope is too wide, multiple PWA boundaries can become messy.\n\nIt is not that one is right and the other is wrong.\n\nThe goals are different.\n\nSo what matters is designing separately based on the experience you want to create.\n\n  * Use Android’s strong PWA behavior for app-like experiences\n  * Carefully design the home screen placement experience for iPhone\n  * Check manifest and scope behavior separately by OS\n  * Think about icons differently on Android and iPhone\n  * Always test on real devices\n\n\n\nIf you start from this premise, it becomes much harder to make the wrong design choice.\n\n##  Summary\n\nPeople often say that Android supports PWAs and iPhone does not.\n\nBut after testing both, the reality looks a little different.\n\nAndroid is strong at turning the Web into apps.\n\niPhone is strong at placing web pages on the home screen.\n\nFor Android, a PWA is an app made from the Web.\n\nFor iPhone, a PWA is closer to a web page placed on the home screen.\n\nThat is why they behave differently.\n\nThat is why the same manifest.json does not produce the same result.\n\nWhat I felt after testing many times is that iPhone does not fail to understand PWAs.\n\nApple is giving a different answer from Google.\n\nWhen viewed that way, iOS-specific behavior becomes much easier to accept.\n\nAnd 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.\n\nIf you judge PWAs only by support or non-support, you miss the real difference.\n\nAndroid and iPhone have different goals for PWAs.\n\nStarting from that idea makes web app design much more interesting.",
  "title": "iOS and Android Have Different Goals for PWAs: The Real Difference Beyond Support or No Support"
}