Progressive Web Apps have the potential to be massively disruptive to apps as we know them now... and that's before the near-native speeds that WASM will bring are factored into the equation. After making the mistake of going all-in on Xamarin in 2014 I realized, much to my chagrin, that the future of mobile is HTML, CSS, and JavaScript. Sure, there are cases where certain features require vendor-native apps for now, for example if you want to register a service that runs in the background without the app being launched. Currently that's not possible with mobile web or hybrid but there's no reason the mobile OS cannot look for and hook JavaScript -- or WASM -- code and run it as part of a background service. Could be as simple as specifying in the app manifest one or more code files which contain logic for background processes along with instructions like "run this only when the app is active, run it all the time, or run it on this cron schedule."
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.
People openly booed Steve Jobs in 2007 when he announced that the iphone would only support webapps. Obviously Apple changed their tune, but it would be funny if they started dragging their heels in the other direction.
Apple didn't have the app store and it's 30% rake of all transactional revenue at the time. Jobs was somewhat notorious about being adamantly opposed to something one day and then announcing to the world that Apple had created a best-in-class product that he previously said they would never make. I seem to recall him saying they would never make a tablet device -- that it wasn't so critical to surf the web on the toilet as people seemed to think it was. Until the iPad was ready for launch. And we learned in the Walter Isaacson biography of Jobs that the iPad project existed before the iPhone project did!
Also don't forget his famous comments on no one will watch video on small screens and no need for big phones. I don't think any of his comments were lack of insight, rather it was him playing the market until he was ready.
Pancreatic cancer is serious business. It's not "typically curable" by any stretch. The 5-year survival rate is 1% - 15% depending on how early it's detected.
That said, his holistic approach to treatment didn't help him at all.
He had a neuroendocrine islet tumor, not pancreatic adenocarcinoma. It has a much higher survival rate... as long as you don't try to treat it with acupuncture.
I'm the first one to criticize apple, but in this case they were clearly privately working on the things he was bashing in public. The only apple product I own is a macbook pro, so not your typical apple fanboy.
I'm not an apply fan by any means, but when they were already working on it internally, while he was publicly trashing the idea -- yes.
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.
I have the same thoughts. Phones were too slow few years ago, web standards were not mature, so well written native apps were in obvious advantage. Now phones have proper CPUs, lots of RAM, so web apps for many tasks won't be distinguishable from native apps. Web standards are good too.
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.
The javascript development community hasn’t exactly shown it has great engineering chops to solve basic problems yet, its a bit soon to be betting the farm on web apps replacing native ones.
> 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.
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 would take an app search engine -- or several of them -- or a curated lists of "new and interesting PWAs" that anyone can create and maintain versus a gatekeeper (or a collection of gatekeepers with differing standards) who demands to be paid before you can appear as an eligible entity for the platform.
I refer to my period as a Xamarin contractor as "bomb technician programming." The biggest advantage of Xamarin is also the greatest source of its problems: anyone who programs C# can start a Xamarin.Forms app and get a proof-of-concept sufficiently advanced to show their boss who will run it up the chain and get it approved as a project. And THEN the devs -- who are awesome web developers -- begin to realize just how much they don't know about mobile and that they've coded themselves into more than a few corners and aren't sure how to get out... and I know this from first-hand experience from my first couple Xamarin projects. There comes a point where you realize that knowing C# is only part of the solution. You wouldn't take an accomplished ASP.NET MVC developer who has only done web work and assign them to an Akka.net or advanced, massively concurrent, highly-multi-threaded Windows Service project and expect them to succeed right away just because it's all C#. Same idea... different platform.
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?
You and I know that, but some managers and companies soliciting mobile solutions only think in App Store terms. For these folks a PWA can be packaged and put in the store. And we can bill it as a value-add. :-)
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)
I’m not exclusive to PWA and Xamarin; React Native is huge right now and Google is pushing Flutter heavily (in order to ease the transition from Android to Fuchsia, but I digress). And Swift/ObjC with Xcode and Kotlin/Java with Android Studio are always solid options and the ones Apple and Google officially recommend if you ask them.
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.
I can't imagine why they'd "drag their feet" on doing free work to enable pseudo-apps with "near-native" performance and nonstandard UX.
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.
“According to Google’s data, for native apps 80% of time is spent in each users’ top 3 apps. Just 3 apps!“
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.
According to this article, yes, it is. On the other hand it is a really, really easy to convert a react native app to a web app with react so it might have been a very good choice of technology anyway.
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...
They didnt mention any frameworks actually. Normally I expect company web blogs to include some introspection into tools evaluated or used by them, but I guess this is more of a fluffy piece.
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.
"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 agree that the $99/year/developer isn’t that much for Apple. The 30% of all sales is probably significant though - the App Store has a lot of users.
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.
$99/year isn't small. There are 2m apps in the iOS App Store today. Each app must pay $99/year. That's $198m/year as a passive income stream for Apple.
Factor in 30% of app purchase price, plus 30% of in-app purchases, and you have a significant revenue stream.
This assumes (incorrectly) that every app is released by a different developer with their own account. In reality many of those 2M apps are basically shovelware - with developers releasing dozens if not hundreds of different apps under the same account.
> The 30% of all sales is probably significant though
I realized they just announced something on this yesterday, which I found transcribed[1]:
"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).
>> The $99/year/active developer is a nominal amount
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.
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.
Wow, even larger than my napkin calculations. So my assertion that the app store business is significant is correct.
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 cynical, it's their explicit intention to keep PWA off of iOS. Ask any dev rep and they will tell you the purpose is "because the native app experience is better across the board."
It's not purely a money thing, it's keeping developers using swift/obj-c and inside the -OS ecosystem.
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.
There is such a thing as "good enough". The cheap plastic solution tends to win when that happens. We weren't there in 2011, maybe we're not there in 2018, but the writing's on the wall.
When that happens, the browser would have turned into a general purpose VM running apps via WebAssembly with WebGL/WebGPU for rendering, thus becoming native as well.
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.
Do the CPUs of their respective systems directly understand the instructions? In my opinion, if they don't, that's not native code. Of course, for strategic reasons such as portability the manufacturer might not provide any kind of access. At which point that's the closest to "native" you're going to get...
Depends, on the mainframes and watchOS, bytecode (or bitcode) is used as portable binary format and JIT compiled at installation time into native code.
As with web apps and applications in general there's a wide gamut of different app categories. There's also frameworks such as Ionic that provide native or near-native capabilities and experience through native bindings.
They are clearly trying to sell their business "If you have further questions regarding the PWA development, reach out to the K&C team as right now we’re actively working in this field".
I wrote a PWA and got it published in 3 app stores[0]. I found this to be a pretty good mix: I can access native mobile features while using modern web features and rolling out instant updates without app store approval.
After writing enough front end work, I'm not exactly afraid of writing native apps for multiple platforms.
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.
Native apps can be a bootstrap shim for a more distributed back-end. PWAs are not going to be loading off onion nodes or ephemeral distributed networks any time soon. Native apps, especially those that can side-load or update without the app stores, will always be more resistant to these sorts of attacks.
the problem noone mentions with PWAs is that simple users do not know what A2HS means. They dont know what a PWA is so in the end we are talking about a web page that is mobile friendly.
With a popup asking to be added to the home screen. A lot of mobile websites I visit (usually if my HN reader app can't parse the content) either have one of those, or have it hidden somewhere in the other popups - sign up for our newsletter, agree to our cookies, fixed headers, etc.
As soon as we can "install" PWAs natively and launch them like an app from our phones they will go unused.
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.
> Dramatically, a huge change has happened again thanks to a move from Apple. This time with Safari.
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.
As long as people wants new apps quickly (now) and cheaply (free) the developers problems are _very_ important. Making those problems smaller or disappear makes it quicker and/or cheaper to develop apps and the companies paying for the apps will like that.
It's also false gold for the developer, it seems like less work but PWA's (in my experience) are almost always a worse experience for the User and require far more work to get them up really usable, if it's possible at all. Lot's developers are trying to sell this technique because they can't be bothered to learn something new. The reality is that it's a worse experience at the end of it for both the developer and the user.
Unpopular opinion here, but I just don't see PWAs living up to the hype. Yes, there are lots of technical advantages, they're catching up to native apps in capabilities, and there is reduced friction by bypassing app stores. However, the ingrained user behavior of downloading apps from the app store, trust of knowing what you're downloading by doing so (yes, even on Android), and browsability on mobile falling behind searching the app store from a ux standpoint make me think there are still some big barriers to PWAs taking the mobile world by storm. Yes, they'll have their place, but I don't see them living up to the hype often promised by their evangelists.
I very much agree, we evaluated PWA vs native recently and found PWA(on iOS) to be a really poor decisions. We likely build one for Android as the experience is better there but it's very poor on iOS and unlikely to get better anytime soon(next 1-2 years).
Web "standards" for PWA's are pushed out willy-nilly by Google. Just because it is preferable for Google to push towards everything on the web, it does not mean that all browser vendors should create new APIs that were declared "as standard" in their draft version and pushed out into Chrome.
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.
Right. We continue to use the word "standard", but a significant proportion of these things are, in effect, unilateral proposals from Google.
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.
Same. We are not normal users. For a native app and PWA for childcare centre management I worked on: the PWA flow just confused parents. I’m really hoping that’ll change in the future
As long as I can use a browser with uBlock Origin and API access (location, file system, camera, etc.) remains sane, I would very much prefer a web app. I don't want to: waste time installing; use up limited storage space; allow who knows what kind of access to other stuff on my device (e.g. LinkedIn and Facebook style abuse of native APIs); and have no way to combat ads. Especially for something I'm going to use maybe just once a month or less.
The world already downloads and executes everything. In browser sandbox, that is. And using native app truly means executing anything, but now within bounds of much weaker mobile sandbox.
Indeed, the assumption being that those who do their utmost best to steer users towards an app when a simple site would suffice for the purpose have ulterior motives, most likely related to data collection on said users.
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.
> there is reduced friction by bypassing app stores
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.
It will need Apple to introduce in Safari the same kind of prompts that Google has introduced in Chrome, to make saving to the home screen discoverable. At the moment there is no clear distinction on iOS between saving a standard web page to the home screen and saving a PWA, and a non-expert user simply won't make the conceptual leap to thinking of the PWA as an app.
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.
I'm assuming (or at least hoping) this isn't an unpopular opinion so much as a usually silent one.
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.
> trust of knowing what you're downloading by doing so
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.
PWAs feel to me as if they are a way for websites to get around adblocking or any kind of extra browser extension. They are the equivalent as a website wrapper webview as a native app.
I equate a PWA similar to an Electron-based stand alone web app (e.g. like Discord).
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?
Web apps have a bright future, with only Safari lagging behind. (Did you know Steve Jobs originally envisioned AL mobile apps to be web based?)
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:
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
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.
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:
How many years have we been hearing this tale? And yet almost every major web site continues to bend over backwards to persuade us to install their battery-killing surveillance system oops I mean mobile app.
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?
Major sites have devs to waste. For the rest of us web is a valid alternative.
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.
On the flip side, if your service has craptastic web performance, I just won't use it. The mobile-web currently drives me crazy on phones (doubly so with nonsense like FB blocking access to messages unless I request the desktop site), and I find it barely usable on tablets.
They are not better at a single and simple thing: cost of development for multiple platforms. And it means everything, unless you're swimming in money.
I'm down for enhancing what sites I only go to on occasion can do for me as a user, but that PWAs will replace Native is IMO not desirable (particularly every website asking me to allow notifications these days -- turn that right off immediately)
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
At least we do have a solid cross-browser implementation of Service Workers, that will allow a lot of quiet optimization in the background to make websites feel a lot snappier.
I’ve read this exact same article every year for ten years and in that time the web has become increasingly slower and more personally invasive while apps have become more capable and faster.
Pardon me if I take this all with a grain of salt.
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?
104 comments
[ 3.4 ms ] story [ 172 ms ] threadA 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.
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.
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...
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.
[0]: https://twitter.com/firt/status/1003761267155394561
[1]: https://twitter.com/tomayac/status/1003910651151085568
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...
[2]: http://www.businessofapps.com/data/app-revenues/
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].
[0]: https://en.wikipedia.org/wiki/Censorship_by_Apple
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.
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.
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.
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://bugs.webkit.org/show_bug.cgi?id=182566
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.
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.
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?
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:
https://projects.invisionapp.com/m/share/TKHYMVSJNW2
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.
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
[0]: https://www.allbusiness.com/web-apps-vs-mobile-apps-which-is...
Pardon me if I take this all with a grain of salt.
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?