Google changes course, proposes proprietary in-app purchase API as web standard

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 announced the internet giant's intent to prototype a proprietary API in the Chromium project's Blink browser …

[Pascal Monett]

"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 ?

[Andrew Hodgkinson]

Re: "see the capability gap between native and web apps closed as much as possible"

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.

[Anonymous Coward]

Re: "see the capability gap between native and web apps closed as much as possible"

PWAs don't have any less security that a standard web page run through chrome. You can put the same, or better controls in place and have a bit more control than many web pages.

As for PWA vs Native it's often a different use case and a decent PWA doesn't have to be 'janky and slow'.

Apps have passed their peak for most people. When smartphones first came out many people were searching APP review sites, waiting for app of the day recommendations. Reading every update note for every app to see what amazing new features it had. Doesn't happen anymore. People don't search for apps randomly, it is based on a real user need and most people would prefer not to download a full blown native app just to get information when staying at a hotel, or pay for their pizza etc.

Combine that with the fact that you can have a website (lets say for a theme park) with fully up to date information, shopping carts, pricing, calendars etc. You then get a native app built (perhaps two if you want to utilise all the features of IOS and Android and don't want to restrict yourself to Xamarin or the like). Now you add a major new feature to you responsive web page and you might have to get the apps re-written and accepted onto the app stores. If your new functionality actually breaks the old functionality you risk any users of the old app or the period where it is getting published not working and have to try to carefully sync between website and apps.

If it was a PWA run off the main site the changes by the web developer could instantly and automatically 'update' the PWA. Always the same code, always in sync, nearly always the same bugs to fix. The same backlog, same developers and project team.

Absolutely won't suit all app use case but that doesn't mean they aren't much better for some use cases (and a short term app when you are visiting somewhere would be a good use case).

It reminds me of the days of the web where a parts catalogue supplier would require you to download a piece of software to see their catalogue, nowadays you just have the parts catalogue and checkout on their website. No one would download a piece of software just to browse part (or book a holiday, or get driving directions), but they would download program to play a modern game.

[Andrew Hodgkinson]

Re: "see the capability gap between native and web apps closed as much as possible"

PWAs don't have any less security that a standard web page run through chrome.

YES. Exactly the point.

Reading every update note for every app to see what amazing new features it had. Doesn't happen anymore

Because thanks it large part to agile and in part to lazy change log writing, "nothing apparently changed" updates on a 2 or 3 week cycle with update notes saying something lame like "bug fixes and performance improvements" are the norm. That aspect of lazy development is only tangentially related at best to PWA vs native. People don't read them anymore because app updates are very annoyingly frequent and very rarely have anything interesting to say in the notes.

As for PWA vs Native it's often a different use case and a decent PWA doesn't have to be 'janky and slow'.

Compared to native, sorry, yes it does; the basic domain of HTML, CSS and JavaScript is simply a very poor and very inefficient toolset for constructing the kind of dynamic user interfaces we associate with apps, for which native APIs like Cocoa Touch are dramatically better optimised and designed.

People don't search for apps randomly, it is based on a real user need and most people would prefer not to download a full blown native app just to get information when staying at a hotel, or pay for their pizza etc.

So your argument here appears to be that a PWA is used when people don't want a "full blown app". This is surely a tacit admission of the limitations of the web based environment compared to native. Basically we're saying we just need web sites optimised for mobile a lot of the time. Agree! We don't need or want really to install things. Agree! So, um, wait. What's PWA for again? It's not to replace native apps, and it's a kind of installable thing...

...glorified home screen bookmark with an over complicated cacheing model that would've been better served just by the built-in web browser providing a first class ability to pin things to the home screen? Oh, wait, we have the latter. So, uuuh... All we've really got left is the ability to work offline. And of course, given that we recognise native is best unless you'd really want just to access what's on a web page, and the point of the web page is to be online, we're left with what? Crap games written in JavaScript that'll just about work offline because you jumped through the hoops needed to declare the resource collection in a manner that allows it to be accessed as a PWA?

If it's worth an app, treat your users with respect and make a decent native app that conforms to all your target operating system's best-practice recommendations, layouts, integrations with the rest of the system, accessibility features, and so-on. Have it lean on native frameworks as much as it possibly can to keep the app as small as possible and allow it to conform, often with little or no effort, with things like dark modes or system-wide contrast variations or animation styles or whatever.

If it's not worth an app, just make sure your inherently online web site is a best-possible online web experience on mobile and stop wasting your development money on PWA bundling.

[Gene Cash]

How long before they abandon it, like most everything else?

6 months? 8?

[IGotOut]

Re: How long before they abandon it, like most everything else?

When Dave the intern leaves that department.

[e^iπ+1=0]

"tiny sword of power"

Want one.

Can I transfer it from one game to another now?

Or even from game version X to game version X+7 without having to buy all the intermediary games?