The web apps that will eat mobile
kruschecompany.com
kruschecompany.com
Apple's iOS Safari remains terribly lagging behind in PWA support. Even the latest iOS 12 beta support for PWAs is utterly broken[0], including full reloads on suspend/resume, local storage gets blown away on reload, no icon, incomplete support for web manifest, and much more[1].
A charitable interpretation of this would be, Apple hasn't felt the need to keep its PWA support up to par with the other browsers due to the success of its App Store. A cynical interpretation is that Apple is deliberately dragging their feet because PWAs undermine their $99/year + 30% app price + 30% in-app purchases business.
That interpretation doesn't make sense. The $99/year/active developer is a nominal amount -- sofa change to Apple -- that couldn't sanely affect the Safari development roadmap. The 30% is a much a larger amount (though still small to Apple's scale), but PWAs don't compete for that money; a PWA developer looking to monetize their app doesn't have an alternative monetization platform/store with anything like the reach into the iOS device market. Put another way: a PWA developer looking to monetize their app is surely going to release it through the Apple app store anyway.
I don’t necessarily agree that PWA developers have no way of monetising their apps though - if I’m not mistaken they could use ads and subscriptions for their services. These would normally grant a cut to Apple if they were done through the App Store, hence the incentive for apple to delay the implementation of PWAs.
Factor in 30% of app purchase price, plus 30% of in-app purchases, and you have a significant revenue stream.
"We're happy to announce that this week, we're going to achieve another huge milestone. The money that developers have earned through the App Store will top $100 billion."
So if that's the developer's %70 to Apple's 30%, then Apple's share is $43 billion. That's a lot, but over just about 10 years. I don't know how much was, e.g., in the last year, but Apple's revenue is over $200 billion/year, I think, so in terms of percent, it's in the low single-digits.
> I don’t necessarily agree that PWA developers have no way of monetising their apps though.
I didn't say they have no way of monetizing, just nothing with the reach comparable to the Apple app store. Outside the app store, a PWA developer can charge, e.g., subscriptions. But (1) it's not free (they'll have to create or buy a mechanism for doing so... there are transaction fees too, but much less than 30%); and (2) would entirely lack the discoverability of Apple's app store. Sure, it's perhaps possible that a completing PWA app marketplace could be created and marketed, but it doesn't exist now, and it would take a lot of time and a lot of money.
I didn't think Apple generally took a piece of ad revenue from iOS apps. Wasn't it just their own iAd network that took a piece? (Also, I thought that was killed off).
[1]https://www.macrumors.com/2018/06/04/live-from-wwdc-2018/
Is it really?
There are 2 million apps in the iOS App Store[0]. At $99/year to be listed in the store, that's $198,000,000/year for Apple.
On top of that, you have 30% price of an app. 12% of those apps are paid[1], that's 240,000 paid apps. Suppose the average price of a paid app is $5, and suppose each app is purchased 2000 times. (I have no idea what the average is, but this sounds reasonable.) 240,000 apps * $5 * 2000 purchases * Apple's 30% cut = $720,000,000 revenue for Apple.
Then we have to add 30% in-app purchases. This is a bigger number than app purchases, both free and paid apps have in-app purchases. This article[2] says in-app purchases make up half of all mobile revenue - that would put in-app purchases reaping Apple $918,000,000/year for their 30% cut.
These are educated guesses based on some napkin math, but I'm betting Apple's iOS App Store business is bringing in figures in the hundreds of millions, if not billions, of dollars every year. Either way, it's not nominal.
[0]: https://www.statista.com/statistics/276623/number-of-apps-av...
[1]: https://www.statista.com/statistics/263797/number-of-applica...
We don't have to guess: Apple reports these numbers. They earned $11.5 billion in revenue from the app store in 2017.
I'm not sure what you're expecting here. Apple clearly views their role as protecting users from the hostile aspects of the web: see content blockers, reader mode, anti-tracking features in iOS 12.
Of course Apple is not going to jump on unrestricted JS background execution, unreviewable OTA-updatable tracking, etc. And of course Apple is going to focus their efforts on their native APIs.
The problem with Apple, or any other big corporation, "protecting" users is that censorship is a two-edged sword. It's great that the iOS App Store doesn't suffer from, say, malware. It's not great that Apple has the final say over published content; Apple (or hostile governments forcing Apple) can block content for any reason; political, religious, or even vindictive. This is not merely theoretical[0].
The "censorship" angle doesn't really fly. Apple doesn't censor any web content: all websites are accessible via iOS. The App Store is a different matter. Yes, Apple blocks the boobs and the baby-shaking games, like Amazon blocked the "Keep Calm and Rape" t-shirts. That's not censorship, that's a storefront owner exercising common sense in the products they choose to stock.
Apple is in good company in limiting what can be installed. Chrome on iOS is hobbled, but Firefox on ChromeOS isn't even a thing, and Google Chromecast is even more locked down.
Ultimately it comes down to this: Apple is not a monopoly but a minority player, and iOS users have made a conscious decision because of the value they've found in Apple's ecosystem. If you want access to that market, you have to make your products appeal to that userbase.
It's not purely a money thing, it's keeping developers using swift/obj-c and inside the -OS ecosystem.
Service Workers, for example, are just a working draft and somehow not having the spec implemented is considered as lagging.
PWAs are fine for some uses. However I think it would be better for everybody if the vendors were extra cautions when creating and approving these standards as these APIs tend to crystallise and browsers end up supporting a lot of deprecated cruft. I was young when MS was doing the same thing with IE6 but I still remember the pain in the ass making anything remotely compatible was. And back then we were not talking about access to stuff like microphone or background activity.
Are they good proposals? How could they be improved? Do they meet the needs of the various interested parties, most especially end-users? Taken together, are they coherent, do they compose and complement each other, do they move toward a robust, comprehensive software framework?
Maybe it's happening, but I don't see these questions being asked a lot, much less addressed. Should we all just trust in Google? And expect Apple, MS, and other browser vendors to do so as well, not to mention implement Google's APIs as quickly as they come out?
No doubt, there is a lot of good work coming out of Google, but overall, I don't think the present system will be sustainable nor result in a good web.
The 90s called and want ActiveX back.
This growing aversion to device-specific apps is actually a good thing in itself. Remember when web sites used to state that they were 'best viewed with browser X at resolution Y'? The rise of Firefox and the related demise of Internet Explorer (I wrote 'Internet Exploder' initially, a habit very much ingrained after years of suffering at the hands of Github's new overlord) did away with that nonsense, the web was slowly starting to live up to its promise of universal access no matter the OS or browser vendor. Then apps showed up, and with them the balkanisation returned with vengeance: to access this service you need to use iOS, Android app under construction, no plans for other devices, sorry 'bout that.
There is a space for apps: games and other performance/timing-critical applications which are hard to implement using web technologies. Applications which by nature are device-specific, e.g. Android Xposed, firewall apps, etc. Things like checking the bus times or booking a train ticket should never require an app.
It's funny, because Microsoft seems to be actively encouraging/misleading developers to bundle their PWAs as "Microsoft Store apps".
Seems like Microsoft is looking at PWAs from the opposite angle - an opportunity to "liberate" users from Android/iOS stores lock users in to its store.
Will it work? That depends on all of you developers out there.
All this seems quite carefully calculated by Apple, not to miss the boat on service workers, but also to hamstring PWA's just enough to make them non-competitive.
I think the most interesting area is apps which are written with web technologies, and then deployed to different platforms. For example, that could be a React Native codebase which renders to Android's native toolkit, iOS native, and HTML, and through that to a PWA and perhaps a Windows UWP app. There's a lot of flexibility there, to start just on HTML, or just on the native toolkits, and expand organically as appropriate.
Under the current circumstances, businesses will certainly want to be on the app stores, but there are a lot of services where just having an app is limiting, for instance I was looking recently at banking services for amalgamating accounts, and every one that I could find available in the UK has a website which is just a marketing page with a link to Google Play and the iOS Appstore. But surely most people also want to be able to look at their bank accounts on their computer, not everyone owns and iPad and a smartphone is a small form factor for that kind of information. A PWA, responsive, installable and offline-capable, is a good way of handling that.
I think, PWA will probably end up being a third target, not a replacement for Android or iOS.
[1] https://www.tune.com/blog/no-the-average-american-does-not-d...
The actual tech behind the PWA hype is nice/neat, but hardly puts them on par with mobile apps. It's the old "necessary but not sufficient" distinction, which people find so easy to ignore.
If you really support the vision of PWAs, you should be busily tamping down the hype, because promising a lot more than can be delivered will likely kill PWAs before the vision can be realized.
Notice the article linked to this post is a hype piece by someone offering PWA consulting services. It's not hard to see why he's sold.
Are you saying that some websites may not offer as much trust as an app-store approved app? Maybe when discovering new web-apps, I agree, but for standard websites that you know the url for, maybe not so much? I can't imagine someone not trusting "pandora.com", for example.
A completely different question is whether vendors like Apple will refuse to support something like this because it circumvents the need to deliver via the app store (and the $$$ they collect through the Apple Developer Program) but there's no reason background services and processes can't be implemented in JavaScript.
That said, his holistic approach to treatment didn't help him at all.
https://www.forbes.com/sites/alicegwalton/2011/10/24/steve-j...
Steve would have been trying very hard to avoid the 'Osborne Effect', which was very well known to everyone in the early industry. Osborne portable/luggable computers had a very strong market share and growing, based on the CP/M operating system. They announced that they would be coming out with a DOS-compatible machine, far too early as it turned out. Everyone decided to wait for the introduction of the DOS machine, sales and revenue went to effectively zero, and the company died before it ever introduced the new machine.
https://en.wikipedia.org/wiki/Osborne_Computer_Corporation
http://www.businessinsider.com/the-amazing-rise-and-fall-of-...
May be Apple will curate list of blessed websites and allow them to launch background services, using icloud payments, etc. This way they'll continue to have their cut and their control.
I could see Apple et al resisting, but wouldn't a store still be useful for discoverability and giving the sense that an app is trustworthy? I agree stores would not be _required_ though, and I think that diminishes the value of a store and therefore the cost of listing your app in one.
I want to create an app where the users would be regular mom and pop- my primary users would be windows and Android and a few iOS (iphone).
Would you recommend I go the Xamarin way?
Who is xamarin good for and who not?
Xamarin is great for people who want to use C# to write mobile apps and know the underlying platforms well enough to know where the landmines are and how to side-step them. There's undeniable time-savings in being able to write non-platform-specific code one time and just link to it from the Xamarin.iOS and Xamarin.Android project. It's also possible to write cross platform apps very, very quickly with Xamarin.Forms if you understand where the issues are there as well...
But it's even faster to just write a mobile web site. When I am asked for my recommendations for a mobile app idea my first question always is: "Can this be done with a mobile web site (which is PWA these days)?" If yes, why go further? If you really want the app store exposure then packing up your PWA as a hybrid app isn't all that difficult so mobile web is still my first choice. It's not unless you have specific, unambiguous needs that mobile web or hybrid cannot handle that going native -- Xamarin or otherwise -- is recommended.
Keep it simple, deliver value, and go home happy and a little richer.
thanks. i got a lot out of your comment, but then you lost me when i read that.
i mean, what are the benefits of app store exposure? it's a needle in a haystack. the standard experience after putting an app in the store is crickets. do users pay more attention to app store listings than they do to mobile web sites?
I take it that you didn't compare xamarin to anything besides pwa- I'm assuming it's your way of saying that anything else you evaluated didn't stand up to xamarin?
Please let us know if there are any helpful getting started pointers and also for pitfalls.
Right now PWA is not something I'm considering although I see how they are the future (and am glad they are)
The stacks and options are just tools in a box; I believe in using the right tool for the job (or the tool required for the contract) rather than being a tool about this stuff. But if asked my opinion I will default to PWA until I know there's a feature requirement beyond PWA's growing abilities.
Snark aside, I've heard very little marketing around PWA that explains why users should want them - almost everything is focused on benefits for developers.
So the solution now is even more battery-killing HTML + Javascript + Secret Sauce? Hell no...
PS Just say no to push like the Hulk says no to Banner.
All IMO of course but these days, I use my phone for Yelp, Google Maps, weather, GMail, stock prices, and little more. The improvement in battery life from 6-8 hours to 2+ days has been astounding and what it's drove me to the viewpoint I just espoused. Am I missing something here?
Strange, i use my phone mostly to browse stuff. I prefer the web version of Gmail cause i can switch between accounts and i also avoid all those annoying notifications.
Web devs are a very optimistic bunch.
I also probably spend a large percentage of my time online on a handful of websites. That doesn’t mean the other 20% of my time isn’t incredibly valuable and not worth building an app/website for.
As an advertising company Google have plenty of incentives to push PWAs. Apple, who own the minority hardware platform with the most affluent users, do not. So long as this is the case their will be a strong monetary incentive to build Apps as the PWA experience will always feel a little off.
A non technical point glossed over by this article is the discoverability app stores afford the end user. I see this in person all the time: I tell someone about a new service or online store and the first thing they do is search the App Store for an app not the web.
In summary I think companies will build PWAs as either a complement to an existing mobile app or as a first product when they don’t have the budget to build an app.
1. Write native app's for both the platforms, pay once and cry once. 2. Write web mobile apps, realize how sub par the experience is, rewrite in native. Pay twice, loose competitive advantage, and cry twice.
This is what, 3rd or 4th iteration of web app's are going to take over mobile cycle?. My first instinct about any blog that promotes this turd is, either their business depends on selling this solution or the person is huge web guy and never really worked on complex native apps.
> conflict of interest
> ~simpleton
Says the guy that deliberately says: "both the platforms". Talk about ingrained propaganda
why is this a given?
The writing is on the wall with the ongoing efforts on .NET, Java, Go, Unity, Unreal and who knows, someone might even port Flash to it.
On Xerox PARC systems, the CPUs were micro-coded.
[0]: http://debuggerdotbreak.judahgabriel.com/2018/04/13/i-built-...
I dont want to, which is why I chose react native JS for this round of development. But the big deal IMO is getting the back end of the app developed and working.
Beautifying is annoying and time consuming, but I dont need to learn anything new.
Implementing a backend that is secure required learning a framework and massive testing.
IMO pretty is easy, but I havent made anything for IOS, so who knows.
A PWA will never be nicer than Tweetbot, but if it means I no longer get harassed to install an app for EVERYTHING it will have a place alongside native
For example, it makes web apps available offline.
It makes apps instantly updatable without having to install anything, which is a better experience for the user; apps are always up-to-date.
A few paragraphs later:
> -There’s still no Web Push or Background Sync on iOS (and it will take time).
And here is a response from Apple[0]:
> As we indicated we were doing last year, we’ve implemented the core ServiceWorker spec - https://w3c.github.io/ServiceWorker/ - in trunk WebKit. Web Push is a different spec that we’ve made no comment on one way or another.
[0]: https://www.allbusiness.com/web-apps-vs-mobile-apps-which-is...
I realize that selling binaries directly or via IAP isn't all that lucrative these days, but plenty of developers still make a living doing it. How, exactly, are you supposed to sell a PWA? I assume they're meant to be a value-add for the main product, which is probably SAAS/subscription/ad-based, but I think a world without a good way to sell software directly—a world exclusively centered around services, not software—would be a sad one indeed.
EDIT: I just remembered that, I guess, Android lets you sell PWAs directly through the Play Store. But if you're not installing them from the web, then what's the point?
The way the browser is currently being used to serve PWAs on mobile doesn't make any sense. No one wants to bookmark a website onto their phone and then have it load up inside a browser. It's clunky and dumb.
Not sure why this is taking so long but it is holding back the wide spread use of PWAs.
Pardon me if I take this all with a grain of salt.
Or something, I've lost track of what's hip, :p.
Although, after building my backend with php + frameworks, I already have a web app.
Im just hoping I wont need to update an IOS app every time apple breaks it. Also, I'm looking to avoid buying an apple computer and doing the compiling only 1 time. I hope...
I have emailed Jonathan Davis (web-evangelist@appl..) from Safari several times over the last few years asking when Push Notifications will finally be supported. Without this, websites need to rely on email as a retention mechanism.
But here’s the thing with all this. It’s a lot to build and support all these operating systems, where things constantly change. Even more to have an integrated unified solution.
Take for instance onboarding. New people click an invite link and go to your site. First you want an instant social experience. That’s easy enough: just have each invite have a unique link confirming that phone number or email, and when they arrive show them all the friends who uploaded hashes from their Contact list where they are found. And show all the content they have already engaged with. But wait, phone numbers only have 10^7 possibilities roughly, so that’s a trivially reversible space. SO now go read about the state of the art from Signal and others and figure out your own more secure solution.
And after this you want the user to download the native app so you can send notifications to them, they can upload their Contact list and find their friends, invite people easily etc. Seems easy: just redirect them to the store.
But wait. You want attribution for campaigns, and you want to resume sessions. How to do it? Well you could use SFSafariViewController to get the web cookies but that’s been deprecated in iOS so now you need to to use SFAuthenticationSession.
Wouldn’t it be nice if there was a project that would take care of all this shifting stuff for you so you can focus on building the core of your app?
Well that’s why I started Qbix initially. We keep adding free open source plugins to solve these individual problems:
https://github.com/Qbix?tab=repositories
Go ahead and grab them, we plan to maintain them as the OSes change since we use them in our ow apps.
But this is literally the tip of the iceberg. Most of the questions have to do with social and communty features like roles, permissions, realtime sync, offline notifications, user authentication across apps, payments, and so on.
If you want something that will let you develop new web based apps at record speed or support turning existing websites/apps into social apps with accounts (think turning git into github) without reinventing the wheel you are welcome to the code
https://github.com/Qbix/Platform
It is licensed under AGPL so if you want to keep your code private and not open source it to your website visitors then you’d have to contact us for a license, which at this point is probably like $100 a year regardless of users. But for FOSS projects and weekend stuff it’s totally free, to promote the improvements of the ecosystem.
Here is the vision long term: https://www.youtube.com/watch?v=pZ1O_gmPneI
Oh also we aren’t happy with the state of mobile browsers when it comes to supporting content addressable routing, verification of resources, encrypted web push notifications secure access to contacts by websites, and so on. So we are building the Qbix Social Browser:
Am I incorrect in my assumptions about PWAs? I know you can run them in browsers, but the intended use is to launch them in their own browser window as a separate process, right?