Google changes course, proposes proprietary in-app purchase API as web standard
(2020/04/02)
- Reference: 1585857416
- News link: https://www.theregister.co.uk/2020/04/02/google_web_store_proprietary/
- Source link:
Google has decided to try to openly standardize one of its own APIs for handling in-app purchases in web apps rather than pursuing a previously proposed proprietary plan.
In January, Google Chrome developer Jay Harris [1]announced the internet giant's intent to prototype a proprietary API in the Chromium project's Blink browser engine to allow web apps running in Chrome to query the product identifiers (SKUs) assigned to digital goods sold via an in-app purchase (IAP) in the Google Play store.
Developers of progressive web apps – PWAs are web apps that support specific capabilities like offline support and home screen installation – would like their applications to be listed in the Google Play Store, to increase visibility and distribution. But Google's store policies require that all IAP-enabled apps in the store use the [2]Play Billing API .
Google provides an SDK that allows Android apps to do this but there's no equivalent for web apps. So you can see the rub.
Pretty much everyone who develops web-oriented code – with [3]the possible exception of Apple , which Google developers, among others, have accused of [4]stacking the deck against mobile web apps – would like to see the capability gap between native and web apps closed as much as possible.
PWAs can use the relatively recent [5]Payment Request API , but that was designed to authorize specific transaction amounts (e.g. $5) rather than specific SKUs (e.g. "s123456789_us") used to track the sale of a specific digital product (e.g. a "tiny sword of power" sold in a mobile game).
The proposed API would let a PWA include code that queries Google Play, and the store would respond to that query with the product title, price in local currency, and other relevant metadata. It could then sell in-app items and could be distributed through Google Play, a commercially desirable possibility.
Harris noted that it was unusual to run the proposal for a Chrome-specific API through the Blink feature review process, which normally deals with open source code implementations relevant to makers of other Chromium-based browsers and competing browser makers.
How to make your HTML apps suck less, actually make some money [6]READ MORE
"In general, we are opposed to adding proprietary APIs via the browser," Harris said in [7]an explanatory document . "However, we consider the Play Billing APIs to be part of a separate ecosystem, similar to that of Android Apps in the Play Store, or iPhone Apps in the App Store."
But since the Google Play-specific API was being implemented in Blink, a public resource, it seemed prudent to let people know about it.
Harris's explainer touched on the benefits of seeking standardization for the API, but some disadvantages were mentioned too, specifically that the W3C standards process could take years, and Google Play will be unable to change its APIs once a standard gets put in place.
Nonetheless, over the past two months, other developers, from Google and elsewhere, urged those working on the would-be spec to consider an open API for any web app in any store. And on Wednesday, they prevailed.
In [8]a post to the Web Incubator Community Group (WICG), Matt Guica, a Chrome software engineer, put the nascent API on the path toward standardization.
"We originally proposed this API in the form of a proprietary API for Chrome web apps hosted in the Google Play Store," he wrote. "However, in the pursuant discussion, we were convinced to pivot to a standards-track API, so that potentially any browser can integrate with the store on the user’s device."
Let the debate begin, but don't hold your breath. It might take a while. ®
[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/vkS3k30lWNs/Gt4sKECQEgAJ
[2] https://developer.android.com/google/play/billing/billing_overview
[3] https://onezero.medium.com/apple-is-trying-to-kill-web-technology-a274237c174d
[4] https://twitter.com/slightlylate/status/1176857375531327488?s=20
[5] https://www.w3.org/TR/payment-request/
[6] https://www.theregister.co.uk/2017/10/24/try_to_make_your_web_apps_suck_less/
[7] https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit#
[8] https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350
In January, Google Chrome developer Jay Harris [1]announced the internet giant's intent to prototype a proprietary API in the Chromium project's Blink browser engine to allow web apps running in Chrome to query the product identifiers (SKUs) assigned to digital goods sold via an in-app purchase (IAP) in the Google Play store.
Developers of progressive web apps – PWAs are web apps that support specific capabilities like offline support and home screen installation – would like their applications to be listed in the Google Play Store, to increase visibility and distribution. But Google's store policies require that all IAP-enabled apps in the store use the [2]Play Billing API .
Google provides an SDK that allows Android apps to do this but there's no equivalent for web apps. So you can see the rub.
Pretty much everyone who develops web-oriented code – with [3]the possible exception of Apple , which Google developers, among others, have accused of [4]stacking the deck against mobile web apps – would like to see the capability gap between native and web apps closed as much as possible.
PWAs can use the relatively recent [5]Payment Request API , but that was designed to authorize specific transaction amounts (e.g. $5) rather than specific SKUs (e.g. "s123456789_us") used to track the sale of a specific digital product (e.g. a "tiny sword of power" sold in a mobile game).
The proposed API would let a PWA include code that queries Google Play, and the store would respond to that query with the product title, price in local currency, and other relevant metadata. It could then sell in-app items and could be distributed through Google Play, a commercially desirable possibility.
Harris noted that it was unusual to run the proposal for a Chrome-specific API through the Blink feature review process, which normally deals with open source code implementations relevant to makers of other Chromium-based browsers and competing browser makers.
How to make your HTML apps suck less, actually make some money [6]READ MORE
"In general, we are opposed to adding proprietary APIs via the browser," Harris said in [7]an explanatory document . "However, we consider the Play Billing APIs to be part of a separate ecosystem, similar to that of Android Apps in the Play Store, or iPhone Apps in the App Store."
But since the Google Play-specific API was being implemented in Blink, a public resource, it seemed prudent to let people know about it.
Harris's explainer touched on the benefits of seeking standardization for the API, but some disadvantages were mentioned too, specifically that the W3C standards process could take years, and Google Play will be unable to change its APIs once a standard gets put in place.
Nonetheless, over the past two months, other developers, from Google and elsewhere, urged those working on the would-be spec to consider an open API for any web app in any store. And on Wednesday, they prevailed.
In [8]a post to the Web Incubator Community Group (WICG), Matt Guica, a Chrome software engineer, put the nascent API on the path toward standardization.
"We originally proposed this API in the form of a proprietary API for Chrome web apps hosted in the Google Play Store," he wrote. "However, in the pursuant discussion, we were convinced to pivot to a standards-track API, so that potentially any browser can integrate with the store on the user’s device."
Let the debate begin, but don't hold your breath. It might take a while. ®
[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/vkS3k30lWNs/Gt4sKECQEgAJ
[2] https://developer.android.com/google/play/billing/billing_overview
[3] https://onezero.medium.com/apple-is-trying-to-kill-web-technology-a274237c174d
[4] https://twitter.com/slightlylate/status/1176857375531327488?s=20
[5] https://www.w3.org/TR/payment-request/
[6] https://www.theregister.co.uk/2017/10/24/try_to_make_your_web_apps_suck_less/
[7] https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit#
[8] https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350
Re: "see the capability gap between native and web apps closed as much as possible"
Andrew Hodgkinson
Amen. As for PWAs, their slow, janky, non-native, non-integrated "performance" is of benefit only to the lazy developer who cares not for battery life (or multitasking, given that means sharing RAM) of the end user devices.
Native development is and will always be very much faster, very much more integrated and very much more respectful of local device idioms than a PWA. And yeah, in particular, given the history of web security - having a clueless JavaScript monkey hack up a way to siphon money off my credit card via some kind of JavaScript in app purchase API fills me with horror. We _all_ know exactly where that's going to end up.
"see the capability gap between native and web apps closed as much as possible"
Yes. Great idea. For the hackers and scumware writers that is.
We've tried that already. It was called ActiveX, and it was a bloodbath.
Do you really think it's a great idea to offer local resources to someone else's server without any control whatsoever ? Hackers can already encrypt your data and hold it to ransom, what more do you want to give them ?