Hacker News Reader

Hacker News

Comment by newfeatureok | Hacker News Reader

Full thread

newfeatureok

Honestly I think the future of mobile will just be... mobile websites.

What's missing until regular websites have parity with mobile apps in functionality?

- Accelerometer and all sensor support (some of these are already supported on various browsers on various OSes)

- Background support

- Bluetooth

- WiFi

- Better notifications

- etc.

Sure there will always be a need for native, but 99% of apps don't need any of that stuff, really. Though I suppose both Apple and Google have an inherent interest to gatekeep.

Looking at my own most used apps:

- Messenger

- Mail

- White Noise

- Teams

- Google Maps

Literally all of them could be implemented as responsive pages with acceptable performance. There are a small number of companies that don't bother with mobile apps, Craigslist being the most notable of them until a few months ago. Part of the issue though is that the app stores give you a lot of visibility and to get that visibility you need to be in the app store. Sure you can use a web view, but in some ways that's even worse than just a responsive website because now you have to deal with the abstraction of your site that is a WebView. Not to mention the temptation to try for "best of both worlds".

View on HN

Ten years ago Facebook fought this battle and lost. [1] [2] [3]

[1]: https://www.facebook.com/notes/facebook-engineering/using-ht... "Using HTML5 Today"

[2]: https://appleinsider.com/articles/12/09/11/facebook_admits_h... "Facebook admits HTML5 not competitive with Cocoa Touch"

[3]: https://techcrunch.com/2012/12/13/facebook-android-faster/ "Facebook Speeds Up Android App By Ditching HTML5 And Rebuilding It Natively Just Like The iOS Version"

I have always rooted for mobile web apps, but the lack of feature parity and distribution challenge (“Add to Home Screen”) puts them at a constant disadvantage and companies who control mobile OS’s have little incentive to change this.

In re: distribution challenge, PWAs can already be published to the Google Play store.

Yeah, and those are called TWAs-as in Trusted Web Activities. As much as I dislike Google in general, they have been good at bringing web development and native apps closer than ever.

I think this is only another reason to dislike them. Google created the PWA as a way to encapsulate the market on their terms. As my other comments will belie me, I do not disapprove of this behaviour necessarily -- Apple do it too -- but they have the polar opposite attitude to my privacy and data protection.

As you said yourself though, this was 10 years ago.

It strikes me that, more than anything, it is the lack of an efficient "Add to Home Screen" flow, that has doomed mobile websites.

...and it's intentional. By having an app store, mobile OS distributors know that they have control over a massive revenue stream.

A good part of it is their absolutely massive 30% cut. The only reason they get away with it is that when Apple's app store first came out, most of the online casual applications were games. Hosted by a few gargantuan aggregators (cough newgrounds cough) who charged 70%+ of the revenue for their ... service.

Against a backdrop of above-criminal-rates extortion, 30% must have looked like a bargain.

To put these numbers in context, very good agents get 15%.

Forgive me a bit, since I haven't been on Newgrounds since before the iPhone came out, but did Newgrounds ever charge to host on their site? Did they allow you to monetize your games?

https://www.newgrounds.com/wiki/creator-resources/monetizati...

Most of the money being made on the App Store is for in app consumables from pay to win games. You’ll have to forgive me for not shedding a tear for them. I hope Apple Arcade takes a huge chunk of their revenue.

It’s not indy developers trying to make a living.

The other types of apps that use to make Apple a lot of money are streaming services. But most of those are now not allowing you to do in app purchases.

I’m looking through all of my apps, and I only have two or three that I actually paid money via in app purchases and those were to turn off ads.

All of the rest I had to buy subscriptions on the app makers websites or buy content in the case of Amazon for Kindle books.

Though we should shed some tears for those who just try to sell their apps and make a living, after already being ripped off for expensive equipment and an annual developer account fee.

If Apple would care, it would be possible to charge a smaller commission based on the app category, and to vaive annual developer account fees for verified open source developers.

Apple gear is no longer as comparatively expensive as it used to be -- they aren't ripping you off, they have put a lot of work into delivering different 'gear' to what's available in the rest of the market. Shed a tear for people who buy HP and need a new laptop every year or two. I'm typing this on a 7-year old MacBook Pro, which works better than the day I bought it.

Hosting an app marketplace is not a free endeavour either. They host infrastructure to facilitate all of this, and they review app code in an attempt to prevent malware being distributed by underhanded developers. Maybe they could vary the price based on the use case, but why should they? No one is compelled to publish on the App Store, why complicate their business model to give themselves more work for less money.

> Apple gear is no longer as comparatively expensive as it used to be

It still is if one can't afford it. Apple could provide macOS and iOS VirtualBox images for developers to build and test their apps.

> why complicate their business model to give themselves more work for less money.

Because that's the right thing to do when you shut out indie developers using expensive equipment and annual developer fees.

Developers who aren't affluent or don't get into app development solely for profit may stay away from the Apple ecosystem, and that's a loss for everyone.

Apple is now also selling access to their user base on macOS. Apps distributed outside the Mac App Store must be notarized to run on macOS, which requires a developer account ($99/yr). Yes, workarounds do exist for now, but all of them are inconvenient enough that they seriously hurt the distribution of open source apps, unless maintainers pay up.

If you can’t afford $900 for a Mac Mini and a 1 year developer license and can’t sell anyone on letting you borrow the money, is it really a great idea that would stand out among the million of apps out there?

Also, you don’t have to buy a Mac. You could always pay Mac Mini Colo $80 a month and develop remotely.

There are places where people make less than $80/mo, but they still have dreams and awesome ideas, and to deny them the opportunity to start programming and share their work because they can't afford to pay up is apalling.

A quick Google search shows you can buy a perfectly usable 2014 refurbished Mac Mini for $300 and you would still need at least one iPhone to test on.

How much would a PC cost that could hypothetically run MscOS in a VM well enough to run XCode?

Is it also “appalling” that if I had a great idea for a PS4 game I would have to pay at least $2500 if Sony would even let me buy one?

https://www.polygon.com/2013/7/24/4553842/so-how-much-does-i...

> Is it also “appalling” that if I had a great idea for a PS4 game I would have to pay at least $2500 if Sony would even let me buy one?

Yes.

> You could always pay Mac Mini Colo $80 a month and develop remotely.

In my country, one of the electronics stores has this thing where you pay about 35 USD per month, each month for 24 months, to have a MacBook Air in your possession, but which you don't own. So I guess in a way it is sort of rent/leasing. But the nice thing is that after the 24 months are up, you will be able to exchange it for a new model.

It's sort of like how mobile carriers do with mobile phones also sometimes. Except in this case of the MacBook Air that you are paying to have in your possession, there is no additional subscription to anything (unlike with the cellphones that mobile carriers charge you in a similar way for, but where in addition to paying for the phone you also need a to pay for subscription to a carrier plan).

I looked at the deal, considered it, and took it. My reasoning went that, over the span of 2 years battery life will probably degrade to the point that I want to replace the laptop after that. (Battery life was one of the major reasons I was looking to replace my previous laptop in the first place). And for the amount of money that you'd sell a two year old laptop, it will probably have lost about as much in value as what I am paying these guys to rent/lease the thing. (Obviously not quite the same, since they are making money from this deal. But close enough.)

So I went ahead and took the deal. They tried to sell me on insurance for it too. Guess that is one way for them to make a bit extra on the deal. I am generally careful with my stuff and I do have some home insurance plan already that should cover at least a bit of it if I do end up accidentally damaging the laptop.

I was very happy with that decision and continue to be so. It might not be for everyone, but for me it was a very suitable deal.

>In my country, one of the electronics stores has this thing where you pay about 35 USD per month, each month for 24 months, to have a MacBook Air in your possession, but which you don't own. So I guess in a way it is sort of rent/leasing. But the nice thing is that after the 24 months are up, you will be able to exchange it for a new model.

Interesting. That sounds like a so-called operating lease, which is quite common in my country for business technology purchases, and other operating assets that become outdated quickly and need to be rolled over every few years. It's similar to a regular financing arrangement (where a customer may spread the full cost of acquiring some asset over X months instead of paying in full up front), but the customer never actually owns the asset.

Instead of paying the full cost gradually via monthly payments, an operating lease is structured so that there will be a somewhat large residual payment due if the customer wants to keep the asset at the end, which allows for lower monthly payments. And, as you mentioned, encourages the usual situation where the customer returns the items at the end of the term, and immediately takes out a fresh lease on some new technology.

Since the customer taking out the lease never owns the asset, they needn't depreciate it or worry about other long-term asset concerns, and can treat the payments as deductible operating expenses rather than as the purchase of a fixed asset that would go on the balance sheet. Paying a predictable expense every month for your equipment can often be more manageable than making one big capital outlay every few years, and sometimes has tax advantages too.

There are places in the world where developer labour (especially if the developer is trying to work for himself) is far cheaper than the 900$ capital investment of what essentially is 500-600$ worth of hardware with a shiny aluminum case. Don't forget that not everywhere in the world developers have to choose between several jobs that pay tens to hundreds of thousands of dollars a year.

So these same people couldn’t spend $300 on a used 2014 Mac Mini but could buy a PC?

In those places, old Apple hardware isn't significantly cheaper than new hardware. You might get a 25% discount for a degraded experience (security updates may end in ~3 years) or buy much older hardware (e.g. 9 year old models) that cannot run current macOS and Xcode, etc.

And yes, a local PC can work out to lower prices due to specific tax arrangements, sourcing components straight from manufacturers and assembling them locally.

So do you expect Apple to give away Mac OS if they did allow it to run on a VM or should they go back to charging $129 for the OS like they use to (and like MS still does)?

The current version of OS X runs on the 2012 Mac Mini. I see one on eBay for $145.

Ypu don't need to buy a PC - you already have one.

So if you already have a PC and such a great app idea, why not develop for Android first - where 85% of the mobile users are - make money on your great app idea and then by a Mac?

And how many of those developers would have “made a living” if it Apple lowered their fee to 15%, cut the price of a Mac Mini by $300 and waived the $99 a year?

As a developer of a pro app in a niche market trying to make a living on the app store, i can tell you those 30% are what prevents me from working full time on my app.

Could you elaborate on this a little? I understand that Apple only takes 30% the first year and then they drop their commission to 15%. Is the commission on the purchase price of the app what makes it too expensive, or is it too great a cut out of your in app revenue?

That drop on commission is only for app subscriptions that continue longer than a year.

Thanks! I hadn't spotted that...

If your app was such a great one, you couldn’t convince your customers to pay enough to make up the difference?

Marking things up 43% generally impacts sales.

If it is a “specialized”,”pro” niche app people are usually willing to spend more.

It’s hard to make a living selling a niche app to price sensitive people.

Also if it is a niche app, with a small addressable market, how do you continue making money on it since their is no facility for upgrade pricing - especially since you have to keep releasing updates to support newer devices and new screen sizes?

If it's a niche app, I'd imagine you would monetize it differently than a 99c clicker game (eg. sell a subscription to the app on your website, or supply it as a companion to hardware you sell, or something) and the app itself would most likely be free to install off the web store.

I've seen companies get around the upgrade pricing question by just releasing a new version of their app every year and deprecating the old one.

"people are usually willing to spend more" : not in my case ( and probably many other)

when i say it is a niche market i mean it not only in terms of number of customers, but also in term of potential generated revenues. there are businesses , especially in artistic fields, where people simply aren't willing to spend a lot of money on accessories, even if they are useful to their job.

now i'm not saying i will never be able to be profitable enough. just that with my current marketshare ( which is very good on a local scale, but not yet worldwide), those 30% are what makes the difference.

ps : as for the revenue model, i had to invent some kind of pay per use model, based on in app purchases.

I think perhaps your business model isn't as solid as you might think. Producing an app is not a free pass to live on the revenue, and the market capture is an important part.

I'm not an app developer, I'm in the music industry (day job in IT infra), but it seems to me there are some people projecting their bad business sense onto Apple. As per my other comment in this thread, and the reply someone made for me, the commission drops on subscription based apps, could you not use a subscription, rather than your pay-per-use system (which sounds like a creative workaround, kudos) and then you'll get the benefit of the tax rolloff.

Trying to make your own way in this world is damn hard work, and if a business model falls apart because one needs to "pay taxes," Apple will not be the biggest problem for very long. I'm sure most here would agree that it stinks that Apple are demanding a 30% tax whilst paying ~0% to the U.S. Government, but that is the way of things for now.

I don’t understand your comment. I have other sources of revenue, mainly doing development for customers. I didn’t bet everything on that app and raised money on the expectation this would be a gold mine. I’m just stating a fact : without those 30%, in my present situation, i could live only based on this app revenues. With the 30% cut, i can’t.

I’m sure most people could live off of less revenue if they didn’t have any expenses.

But, a niche product where people aren’t willing to spend money is a business model problem.

That's one way to look at it. All businesses come down to balancing income with expenses indeed. All i'm saying is that 30% cut on the income by apple makes it harder , and sometimes impossible , for some business model to survive.

Understood.

But do you know how many businesses would die to be able to sell products that had a 70% gross profit margin?

I'm not sure about your calculation. A business with only 29% gross profit margin wouldn't be able to survive on the app store because they'd have to give 30% to apple.

Where did you get 29% from? I’m assuming that you are the only developer working on this (you didn’t say otherwise), for every $1 that someone spends, you get .70 cents.

But then why do you assume i've got no expenses ? Just because i'm the only one working on it doesn't mean i don't have to pay myself something to live. That's actually my point : the app doesn't generate enough revenue to cover my personnal expenses.

The marginal profit is the price the good sold for - the marginal cost. The only thing Apple has to do with this is the 30%.

The only fixed cost imposed by Apple is the $100 developer fee and whatever it cost to buy a Mac.

This raises the question ‘harder than what’?

The services provided by the App Store would have to be present for the business exist at all.

So without the 30% Apple charges those businesses would certainly not survive unless they paid someone else for the services.

I understand, I was inferring some blame on Apple's part from your commentary -- as though they were denying you a living from your app. Anyway, thanks for the discussion. Probably shouldn't necro this thread any more than I have :)

There are thousands of desktop app developers that never got out of the hobby stage because they couldn’t get past the costs of processing payments, managing refunds, managing download servers, implementing licensing frameworks, implementing a smooth upgrade process, search engine optimization, establishing enough trust with users that they are confident they aren’t installing malware infected software, marketing, push notification infrastructure, and probably a few other things I’m not thinking of.

It’s probable that 30% is too much to pay for help with all of that, but people too often act like Apple’s just taxing them and providing no commensurate value at all.

i think you also forget that many people buy ipads because of apps created by developers ( in my case, i believe my app is the direct reason for the sale of my customer's ipad pro). and that developpers need to buy apple hardware to build and distribute on the store. those 30% come in addition to all the revenue generated by hardware sales, because of independant app developers.

So your customers are willing to pay at minimum $799 for an iPad Pro but don’t value your product enough for you to charge enough to make it a sustainable business?

Just maybe it’s a product market fit issue?

Over the life of the ipad, they'll have paid me more than the ipad. But it'll be over a few years. It's a market with a few hundreds potential users (maybe a thousand) per country, not more.

Part of what makes it so galling is because Apple has those competencies in spades anyway (SREs, designers, datacenters, bizdev.)

Another aspect is that the App Store feels like a value-add for the actual marketed products — iPhones and iPads — and not something you are ever explicitly buying. It doesn’t show up on the receipt. People talk about buying a new iPhone, or getting then latest iPad. No one ever goes to the Apple store to buy the lates access to the App Store.

As such, Apple’s cut feels like it’s everything from cheeky to an abuse of their “monopoly” in the providers of iOS devices marketplace.

> Part of what makes it so galling is because Apple has those competencies in spades anyway (SREs, designers, datacenters, bizdev.)

But what do you mean 'anyway'? If Apple suddenly said 'you know what, App Store is EoL, do your own distribution' (because of legal or whatever reason) surely there would be a spade or two of those competencies that were consequently redundant?

I don't imagine they're hiring people to work on say Apple Maps; who subsequently say 'cor, good thing I'm here, someone should take a look at that unstaffed app store project'!

> There are thousands of desktop app developers that never got out of the hobby stage

There's so much money out there searching for an investment. It's a shame really.

Trust and payments being the largest.

I download any random crap on my iOS devices trusting that the sandbox and permissions model will keep the app from doing too many things I don’t expect. I’m not downloading a random app on my computer.

I can also pay a lot easier on my phone than digging out my credit card.

There has been an add to home screen shortcut on iOS since day 1.

Oh, 100%!

It is absolutely intentional that iOS Safari on iPhones does not have support for fullscreen api, for example, whereas both WatchOS (somewhat) and iPadOS do. Apple is quite anti-competitive when it comes to letting web apps utilize the full potential of modern web standards.

And they often use "industry advocates" driven psy-op tactics to manoeuvre public opinion such as the following:

[1] https://stackoverflow.com/questions/49589861/is-there-a-non-...

> more than anything, it is the lack of an efficient "Add to Home Screen" flow, that has doomed mobile websites...and it's intentional

It’s literally a default option on the safari “share” button: “Add to Home Screen”. I’m not sure how Apple could have made it easier.

Because it's not very intuitive that the share button would allow you to add something to your home screen.

TBF that icon is kind of apple's system hamburger as it contains sharing, sending the current "thing" to other apps, searching etc. If you don't know that (and I agree it's terrible, but at least it's consistent) you probably don't know you can add a page to the homepage at all.

The other downside is that even if mobile websites encouraged people to use the “Add to Home Screen” ability to the point it became somewhat popular, Apple and Google could just remove the ability all together in an OS release for “reasons” leaving users SOL.

Apple has an "add to home screen" option. Its in Safari.

That's true along with proper notification support. Firefox for Android has 'Add to Home Screen' and was one of the reasons along with extension support for my switch from chrome.

that's factually untrue since there have been ways to add web apps to the home screen for while.

Add to home screen is two clicks, how more efficient does it need to be?

Why does everybody think they have to build at the scale of Fb. Most of the apps will do perfectly fine when they are web based.

It makes sense that a company with a business model based on mining and selling personal data would not find mobile web to be acceptable - too many privacy and security protections that can be eschewed on native. For the same reasons, consumers should choose HTML.

Didn't Facebook also want native app access so they could work around OS limits like background processing via shady stuff like leaving the microphone on? I prefer webapps for security reasons because of Facebook's checkered history with native apps.

But what happens if Apple or Google gives web apps more of the capabilities of native apps?

I'd really hate it if browsers are capable to run in background and accessing microphone or camera. Especially if the tab is closed.

Buy why? People use those apps every day and fine with it. Why browser is bad? You'll still need to give your permission to do so anyway.

I'd say bloat is bad. And as the browser comes to encompass more OS functionality it does so more poorly than the underlying OS could.

People will leave hundreds of tabs open. It’s just not few apps, it’s the whole internet and knowing people they will most likely just smash through the ”deny/allow” warnings.

Ten years ago Facebook fought this battle and lost.

That was ten years ago. Phones and web sites have changed a lot since 2010.

If the battle was re-fought today, I'm not sure the winner would be all that clear.

You still cant crawl through all the local contacts with mobile HTML app. Contrary to native app. So thats a no go for FB from the start i guess.

[2] is from 2012 though, almost a decade ago. The web has come a long way since, and in five years to a decade could be competitive. With wasm and webgpu and what not. And as of today, i dont think the mobile web interfaces for fb and messenger are particularly worse than their native counterparts. They save me the notifications actually...

The web post-wasm could be a whole different beast from what the web was originally supposed to be.

Not that the current situation is idyllic, but I fear a post-wasm web would be even more opaque and less inspectable.

wasm is not less inspectable than minified JS.

> The web has come a long way since, and in five years to a decade could be competitive.

The web is always 5 to 10 years away from being competitive.

Meanwhile Twitter struggled to implement such a trivial thing as a virtual list on the web: https://grumpy.website/post/0RQvmdNmN

It took them almost a year after the resign to fix most of these issues. While breaking or half-breaking functionality for almost everything else.

And that's for a website that's nothing but text and pictures. I wouldn't he my breath waiting for web to be competitive.

Ten years ago, Facebook tried with HTML5 -- and 10 years before that Java tried with Swing and then JavaFX. There has always been this push for a "write once, run anywhere" application development platform - long before it was the mantra of Java in the late 90's, or QT a bit later, or React today.

The truth is that the platforms change faster than the cross-platform tools. Swing lost out not because it was horrible to work with, but because they couldn't track changes to the platform fast enough; Swing apps looked dated from the very start. I'm pretty confident this will continue to be the case; HTML apps don't look like native apps unless you do a lot of platform-specific work, and then you maybe would have been better off just building native.

In addition to tracking the look, feel and interoperability of the platform, HTML will always be slower than native, simply because there will always be more ways to optimise native apps than HTML apps.

In the end, there is no one-size-fits all solution. There will always be classes of application for which HTML is good enough, classes for which a blend of HTML and native will get you though, and classes for which HTML will not be good enough.

But I suspect that any sufficiently advanced and popular application will almost always move to native eventually. You just cant't integrate with the platform properly, over the long term, any other way.

Did you ever heard of WeChat? The Facebook quivalent of China, which is on its own an operating system serving many miniapps. What's interesting about it it lets other apps access qr scanning and the WeChat wallet for payment.

Is WeChat an example of React Native?

I don't think so, but WeChat hosts so called mini programs that are implemented using Web(ish) technologies. There's a million of those mini programs with 750 million monthly active users. So it's an example of successful mobile Web apps if you will.

If cross-platform tools are always behind because the native platforms change more quickly--and I think you're correct about that--then so are native apps that aren't constantly rewritten for the latest OS version. And then so are the native apps running on not-newly-upgraded client devices.

And since these quickly changing native OSes change in different ways, remaining "fully native" requires your app to have different UIs and feature sets, not just on different OSes but on different versions of those OSes.

If you have the resources to keep upgrading separate native apps for all the latest combinations of hardware and OS while also maintaining older versions, with different UIs and feature sets for each, you can have all the benefits of "native". Anything less, and you are deciding to live with less than "full native" and have to decide which compromises to make.

In that case, you might go for maximum speed with a consistent--therefore non-native--UI (PhotoShop), or good-enough speed with non-native UI that runs consistently and on even more platforms (a web app), or give up all but one OS but support all OS versions on all hardware (some dental office Windows app that hasn't changed for 15 years), or whatever. Or some cross-platform toolkit that will never completely keep up with "native" but might be okay, because you can't keep up with native either.

Native Mobile will be replaced by web in x years (where x is usually 2 to 5) has been uttered since day 1 of mobile apps.

I tend to skip reading these arguments nowadays unless they start by explaining why it hasn't worked so far and how it will be addressed.

edit : also, you can add progressive web apps to the home screen, so this ain't it AFAIK.

What if the issue with facebook wasn't HTML5 but rather feature bloat and a focus on Ad placement?

I always thought Sencha debunked that: https://www.sencha.com/blog/the-making-of-fastbook-an-html5-...

It can't be overstated how many apps are absolutely dependent on working push notifications (all chat for example) and can't be replicated as websites. And that's not yet implemented for iOS so we're all at Apple's mercy until it is, which may never be.

There's no reason why a web app can't work with push notifications. Won't? ya. Can't? no.

The sites I build at work have proper push notifications. This problem has already been solved.

How did you solve the lack of push notifications on iOS?

For iOS, can't you just wrap your web application in a thin native app layer that provides the push functionality?

From the app store guidelines:

4.2 Minimum Functionality

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store.

Perhaps the main distinguishing app-like thing is distracting notifications.

Right! I ran in to this when I wanted our app to “portal” to the website and just move Bluetooth data along. Apple thought about this and doesn’t like it.

4.3 We'll continue to get away with this until the EU makes us stop.

Would push notification support not be exactly the kind of feature that would qualify for this rule? In practice there are hundreds of apps like this on the app store.

You can, you just can't publish it on the appstore.

How do you distribute it in that case? Outside of enterprise apps, which are not allowed to be public.

Sorry but I think I don't understand your question.

If you use a native wrapper and load a webview inside you can publish it in the AppStore.

Yes you can and we are exactly doing this since quite a while. Actually a lot of companies do this.

Yes you can and there tons of apps that do just that.

The important part is that they go through the app store, so that apple has complete control of what goes through.

They probably embedded the browser in a client.

Short answer: He didn't. You cannot do it without your app being in the App Store.

for iOS you can have a work around. The users using the web based app in safari, then whenever a notification needs to be sent, twilio api will send a SMS message to alert the user. Of course it will only send an sms message if the user allows it and enters the mobile number.

I will never enable push notifications from websites. This problem has not been solved. It also doesn't hold across devices or if the browser isn't open.

Why not? You do, for apps, right?

App PNs also don't "hold" across devices. You don't need to have the browser "open", whatever that means.

BTW there are tons of apps that do push notifications wrong. There are many apps which keep sending you PNs after you log out or switch accounts. This can be really sensitive content (e.g. chat apps).

Replying to myself, here is a NSFW example: https://www.reddit.com/r/tifu/comments/e8ux6j/tifu_by_lettin...

I can’t stand push notifications, I disable them all except for a couple (like signal). They are usually only part of the app to manipulate you into using it constantly

What's your point? Do you think you represent most people? Can you not just turn it off?

Notifications have fine tuned controls on both iOS and Android with schedule Do Not Disturb features and varying levels of priority (iOS has 3 tiers). Plus per-app controls to disable them from annoying apps, which in newer versions of iOS prompt you before they turn on, making them opt-in.

It's essential for communication apps (texting, email) and useful for breaking news or a simple highlight of big news on WSJ/NYT on your activity feed, so you don't need to open either app to stay on top of big events if you're a news junkie like me.

I'd personally go as far as saying push-notifications + the activity feed is very underrated feature of smart phones and has become a core part of people's day-to-day lives (which plenty of technologies can't say).

> Do you think you represent most people?

I've seen poor push notification quality increase uninstall and churn rates. I think the lesson is that many people are quickly annoyed with push notifications.

I think that's inaccurate. There are plenty of push notifications that don't annoy people, that are often the primary basis for how people interact with certain apps — Facebook, Messenger, WhatsApp, Slack, Discord, etc.

Let's not assume that all push notifications are cynical attempts to get people engaged with the app or to push DLC. For things like mail, messaging, and plenty of other online services, push notifications are not just an important interface to the app; they can be the interface.

Its true that tons of news sites ask for permission just to spam you, or outright sell notifications to advertisers. I think the web notif channel has already been abused beyond repair. It may be time to redo the concept from scratch

Killer feature for email: add an email header that turns an email to notification. Then email apps would push the notification to the user, bypassing apple’s block. Websites already have the user’s email, so no need for more subscriptions. If gmail implemented this, it might push for adoption

That's a novel thought. I imagine then the native mail apps would expand in settings in order to block some bad senders from abusing that email header.

Tangentially related, iOS mail app has a VIP setting.

[1] https://support.apple.com/lv-lv/HT207213#vip

The apps don’t even need to think of spam, that would be handled by the mail server just like all other spam.

several applications require them to be useful. Security events from my home cameras, messages from clients, timers, email

Anytime I'm using a peice of small business software I'd probably like it to be able to give me notifications

Honestly curious and hopefully not rude, but how can you concentrate on anything? Or does your work/life not require you to concentrate ever/most of the time on anything?

(I have turned all but phone call and sms notifications off on my phone. I will check my email/whatsapp when I want and see notifications there as needed. If someone has something urgent, they know how to call.)

Simply, it doesn't affect me adversely at all. I think you have a misunderstanding as to how many notifications are generated.

Today I received:

* 3 reminders to eat

* 1 security alert (delivery)

* about two dozen instant messages between myself and clients

* a couple of dozen CI alerts

* 3 emails

Its easy to have different levels of notifications, and filter message channels. I have less distraction now than I had in an office by several orders of magnitude.

Everything is either immediately relevant or very important. The notifications I have make me more effective.

What kind of reminders to eat are you getting? Like "don't forget to eat?" or "don't forget, this is your plan for lunch"?

I'd assume some sort of "go eat now, it's time" scheme, so he can stay in deep flow without neglecting his food intake.

You got it!

For me neglecting food intake means:

If I don't eat enough I get grumpy. This lowers the quality of life of myself and my loved ones. Alternatively if I get hungry it can cause me to over-snack (justified by anti-grumps thoughts); then I get fat and lower my quality of life slightly slower.

So these notifications are perhaps the most important ones.

Do you use Whatsapp / Messenger regularly for social stuff? Coincidentally I was looking at my Digital Well-being settings in Android today and was told that I get over 170 notifications from Messenger a day.

I do. But I can't say I'm that popular! They are also muted and don't vibrate.

Most people I talk to work at the same time as me, so to get a social message during the day would be unusual.

Everyone knows to call if it matters.

Note: also be aware that the digital wellbeing count counts updates to an existing notification as a notification. As such my morning alarm counts a few dozen notifications (alarm in 8hrs, alarm in 7hrs, 30mins, 2 mins, etc.)

Not grandparent but for me:

1) only certain notifications that are important have unique sound, vibrate, etc.

2) other semi important notifications flash. Light is not that bright to notice.

3) other notifications have numbers on app so there are some despite not seeing any notifications.

Result: I stopped checking every hour. It's actually been an improvement for me to stay away from phone.

I noticed that some apps abuse you for disabling notifications and Viber is biggest example. I don't care about holiday wishes or viber news but I need app to stay in touch with some people. Sadly, I only check at most once a fortnight because of this disabled notification nagging.

I wish there was a standardized or common methodology for classifying notifications. App developers could adopt this and consumers could take the pattern with them across all types of interfaces - desktop, smartphone, speakers, tv. Maybe someone knows if any government entity or force has a methodology for this?

I love push notifications. Its honestly how I stay up to date on whatever is happening. I aint got time to scroll through everything

are you the one exception that makes us all suffer from notification induced FOMO ? :)

No one makes you suffer through anything. You can’t get push notifications without specifically opting into them, and you can disable them forever for any app with about 3 taps.

their existence annoys

This is exactly what I was thinking a while ago. Most apps won't give you good notifications, just spam you so there could be an app that lets you have some good notifications instead of disabling them all through a filter.

I never looked into whether this is possible to do on android or iOS. I thought it might not be given the power available to hijack all the notifications available.

While the web notification story on android is much better than on iOS, it still has it's own share of issues.

The biggest one that i've run into is how exact timing of notifications is difficult. Sometimes notifications can be delayed for hours and there's not really much you can do to fix it, other times they will arrive minutes later.

I previously worked on a PWA which had to be converted into a thinly wrapped webview for Android because we needed notifications to pop within seconds of their scheduled time, and we just couldn't achieve that with web notifications at the time.

Apple will never give in and implement webpush on mobile safari because that would affect their precious app store. How will they extort developers then? That's also the reason mobile safari is so limited in other features.

You mean extort developers who are mostly publishing free apps backed by services or advertising?

How many apps do you use on a daily basis that you paid money for, find notifications useful, and would have been suitable as a web app?

Apple changes their mind fairly often, so I wouldn't say never. And in general, predictions based on incentives are often good bets but they are less reliable than many people pretend.

Is it possible that they haven't figured out how to sandbox the little bit of code that handles the notification from the rest of the webpage? Maybe this is solved already by the webpush standard but some websites are a ridiculously overcomplicated hot mess of javascript ads which make my phone heat up, I don't want them waking up my phone all the time and draining the battery.

Honest question: is there some reason you can't use standard web tech for push notifications? ie polling, WebSockets, etc?

You can use polling or sockets when the browser is open; the problem is showing those notifications on the phone's lock screen or when you're in another app.

Oh duh. And it sounds like iOS doesn't support that for PWAs yet?

Correct, many websites say that such support is "coming soon" but I've been hearing that for years now.

Sometimes I wonder if Apple wouldn't support web apps at all if they could get away with it. A fully functioning PWA could essentially sidestep the app store for a huge class of applications. The incentives really just aren't aligned.

I was under the impression that under memory pressure all of the tabs in every mobile browser (Firefox/Safari/Edge) I have ever used is unloaded by iOS.

There is an edge mobile browser?

Even if you think your app depends on push notifications, your customers don't necessarily want them. I would bet that in 98% of the cases you have in mind, I would be perfectly happy to use the functionality without push notifications. (For example, "all chat". Even if your app is capable of chatting with me, I doubt I actually want it to.)

They were likely referring to chat apps. Good luck building a messaging or chat app without notifications.

Yes, apps over-use notifications for marketing and engagement metrics just like email has been overused. They’re still remarkably useful for a large swath of other use cases, and downright necessary for many others. If you don’t like them, don’t enable them for a given app. Easy.

Building a chat app without notifications is a good way to get exactly zero users.

I hope not. I started using flutter recently and it is by far the best development experience I've had creating anything with a UI. Easy to install (even on windows), build, stateful hot reload, and the code is easy to read and write. No HTML/CSS/JavaScript.

I know web devs probably don't agree, but HTML and CSS weren't designed to build responsive, interactive applications, and all that has to be done to make it work makes it a pain in the ass to setup and develop. With stuff like WASM, Flutter, and Blazor, I'm hoping we have viable alternatives to traditional web development.

> What's missing until regular websites have parity with mobile apps in functionality?

Performance. But we're beginning to approach performance parity - not by the web becoming an faster, mind you, but by apps becoming slower. It used to be only cheap/poor-quality apps that felt like glorified web pages, but now even many high-profile apps are just parts of a web stack embedded into an app.

Absolutely this. Native apps are just so much smoother, and I say this as someone who really wants the web to win, and who used web apps almost exclusively because my 16GB iPhone 6 had very little space for apps. Also, the quality of native apps was much higher (e.g., Twitter feed doesn’t abruptly jump all over on mobile) although this could just be due to more budget allocation into native apps for whatever reason.

Not just smoother, native apps done right are interactive at the visual element level.

Can you elaborate on this? I’m not following.

Native iOS developer here (10 years). Knowing how to leverage UIKit and CoreAnimation properly can give a very smooth UX. SwiftUI has significantly upped the ante on iOS13 and future versions; it's reactive without the middleware layers, and it lets you get your app done (with live view previews) and not have to drag in a pant-load of external frameworks.

It depends pretty much on what the app is all about.

CRUD mobile apps can be made pretty fast when not doing an SPA bigger than Quake just for displaying text.

SSR, pure CSS3, caching, server workers, mobile first, can go a long way.

Naturally there are other kind of apps where native wins hands down, e.g. WebGL vs GL ES 3.2/Vulkan/Metal/DX.

It certainly possible, but there is a lot of arcane knowledge that goes in to the techniques listed. Native apps, generally, has better performance “built in”.

Arcane knowledge? That is pretty basic stuff for anyone doing Web since the HTML 3 days.

Have you ever done native Android, including using the NDK?

It is full of arcane knowledge, scattered about commit comments, medium, G+ and Twitter posts from Android team instead of being on developer.android.com, APIs introduced in one IO are deprecated/replaced by the next IO, OEMs (cough Samsung) that change AOSP behaviours,...

Yes. Web is full of arcane knowledge. Take virtual lists for example: https://news.ycombinator.com/item?id=22186827

Unfortunately I can also provide several items of arcane knowledge for Android and iOS.

So should we now measure who wins in arcane knowledge counts?

Yes. We could. The web would lose hands down.

The Web lacks even the most primitive of UI primitives that desktop and mobile UI kits have had for decades. Virtual lists is the prime example.

You can't even reliably animate an element independently of other elements without breaking your entire page.

You can't pick an arbitrary group of components and place them in a different location of the page without them breaking in subtle and not-so-subtle ways unless you are extremely careful with your flat global namespace that is CSS. WebComponents solve some of that, extremely poorly.

And the list of things that are taken for granted in the desktop/mobile world is near-infinite. All of them have to be re-created from scratch, poorly, on the web.

Sure you can animate, that is what WebGL and SVG allow for.

Ah, like breaking Android UIs when dealing with fragment management or misplaced constraints on ConstraintLayout, usually only solvable after one finds the golden post on medium?

That's not really a fair comparison. I don't think WebGL and SVG allow you to do the type of animation OP is referring to.

Furthermore, ConstraintLayout is a brand-new layout manager. Totally agree that there's bugs in it but nothing that could be called arcane knowledge. Do you have any examples for the actually arcane layout managers? Relative, Layout, etc?

> Sure you can animate, that is what WebGL and SVG allow for.

Yeah, sure. Try animating an element without breaking layout. Trying animating an element that gets destroyed (oh, it's impossible, there are no events for when element gets removed). Try smooth animation while changing layout. And so on and so on.

Yeah, sure. If you constrain your entire animation to just the one box of a single SVG/Canvas/WebGL, then you can pretend that everything is fine. In reality when you try to animate anything, you're really constrained to animations that don't force re-flow. So, about 3 of them. And you have to be really careful (transposing an element's position will leave gaps).

Meanwhile both desktop and mobile have hundreds of animations big and small that are either impossible or extremely hard to do in a consistent manner on the web.

Performance is about a lot more than speed. I want low battery, CPU, data, and memory usage. That's a lot harder to do in a web app.

It's the native apps that kill my battery, fetching content in the background all the time, not the mobile web which is suspended when I exit safari.

You think if those developers made a web app it would be significantly better?

Plenty of native apps are also not the best example of that, and not being able to control when they really die, including background running tasks, doesn't help.

Agreed. Map performance especially on native is night and day -- 60fps smooth scrolling even with React Native, vs choppy shitiness on the web.

You make a fair point but it's one about the current state of apps rather than the future of apps. In the future phones will be more powerful and apps will do mostly the same stuff. In theory that should mean the apps will be faster.

> In the future phones will be more powerful

Single-core performance is largely topping out. The gains are incremental at best.

Mobile SoCs have gone incredibly multi-core incredibly quickly (6-8 cores are common!). Meanwhile the web is incredibly bad at handling that. JavaScript code still has to fight with the GC for CPU time on the single thread they both occupy. WebWorkers are incredibly heavy & limited.

WebAssembly might have threads eventually (it's on their roadmap), but then how long until that happens and will the typical webapp ever even migrate to webasm?

Meanwhile CSS & DOM performance continues to be poor, so webapps are left in this awkward state of needing to re-write part of the browser.

Hardware isn't fixing any of this. It's been almost a decade of hardware not fixing this at this point.

Web apps need a parallel layout engine, and such a thing exists with Mozilla’s Servo, but they’re for some reason Mozilla using it for WebVR rather than building a functional browser.

> Meanwhile CSS & DOM performance continues to be poor

The DOM is not slow, that is brain washing from React developpers to justify your VDOM.

Most Reactive app performance issue nowadays comes from library bloat loading, network saturation or data dependencies.

The main problem with the DOM is not the performance but the API. The DOM API is not appropriate anymore for a reactive usage with transactional reflows. And this triggers a lot of quirks damaging performance.

> The DOM is not slow, that is brain washing from React developpers to justify your VDOM.

I'm comparing against native apps, not React VDOM vs. DOM. Direct fiddling of widget properties is common & perfectly fast in native apps, even when done naively. The same is not true of the DOM, especially with all its synchronous layout & style resolution foot-guns.

> Honestly I think the future of mobile will just be... mobile websites.

This.

Having to install software on my phone to use a service is cringy as hell and is a huge red flag for me. Like when trying to order food from a restaurant or shop somewhere.

It's almost always going to be a automatic no. I just don't trust them. They always want permissions to access things on my phone, which is just pure nonsense.

It's going to take a while for businesses to realize that in order to get a wide audience for the software they are paying for the last thing they want to do is force people to jump through hoops in order to use it.

For every one of 'google maps' there is going to be ten thousand other apps that simply have no benefit from being 'native'.

I agree with the overall points, less so the pointless vitriol. Installing software is cringey as hell now?

The main issue here isn't native apps. It's the existing framework for installing them.

For instance, would it be that far-fetched to be able to open an app in a single click?

Current extended process: 1) Click link that takes me to app store page 2) Find and click install button 3) wait 4) Click "open app" button

Streamlined process that accomplishes the same: 1) click link 2) wait 3) app opens up (download/install hidden behind spinner)

Even if you have to add a pop-up in there to display permission requests, it's still a much smoother experience.

You'd have to worry about app sizes but that's a solveable problem as well.

https://developer.android.com/topic/google-play-instant

> Installing software is cringey as hell now?

When you know that the features you're interested in can be made easily available by a simple web app.

Perhaps I'm misunderstanding the logic but doesn't that mean using a fancy pen is "cringey as hell" since you can just use a simple ballpoint pen?

Sorry, it just seems unnecessarily negative to me.

Yes, you are misunderstanding the logic. A normal web app doesn't need to be installed, disappears each time you close it, runs in a tight sandbox. Much better and lighter than have an app installed.

Besides, I do find fancy pens cringey, but that's another story :)

haha fair enough. Thanks for the clarification!

It's like you ask someone if you can borrow their pen, and they say "Sure, but only if I can rifle through your wallet and attach this GPS tracker to you"

This sounds like you're implying that all apps must require invasive permissions which is wholly incorrect.

It's cringy when you see how reddit does it. Or far worse, yelp. I would personally love to meet whoever approved the yelp mobile website and app so I could shake their hand and thank them for making the world just a little bit more horrible in their own small way.

Only if mobile web can jump the hurdle of feel. Even the best mobile web apps still feel kinda clunky/laggy in subtle ways that the average native app doesn’t.

It’s actually pretty comparable to the situation with desktop Linux where the gaps between the layers are subtly perceptible, which leads to a sort of slipshod/duct tape impression that isn’t great.

A lot of native apps feel clunky because they are poorly coded and thought out. As OP said, 90% of cases are where companies don't need native apps, because they simply don't require that performance level or permission set.

This is the right answer. You've got the web paradigm of the nav bar showing up when you scroll up (among other oddities). I think it would be very easy to have a mobile browser extension to show pages full screen in a special interactivity mode to make most mobile apps work on the web.

Look at your most used apps - none of them are "responsive pages". That should tell you something. Folks who have tried responsive pages haven't done that well.

I am curious - what is the most popular responsive webpage on iphone would people say? I'd like to check out the current leader in this space.

Google?

I use Facebook's as I don't want Facebook's grubby hands using private APIs on my phone to get every bit of data they can. At least the browser limits them.

Plus the facebook app eats battery life. IME my phone battery lasts all day unless I install facebook: then it lasts a few hours.

and for whatever mind boggling reason their stand alone chat client is 300mb.

None of my most used apps are responsive pages because Safari neuters the functionality.

- White Noise -> Safari can't play background sounds once closed.

- Messenger -> Notification trouble, not to mention Facebook won't let you use the mobile version of Messenger without a lot of effort.

- Google Maps -> Close, but a lot of the functionality, like reminders require notifications which isn't up-to-par with just Safari

- Teams -> See messenger.

Apple does some fairly beautiful responsive webpages... Albeit rather heavy! https://www.apple.com/apple-arcade/

Whats the slack app written in?

The iOS app is native UIKit I believe.

Desktop apps are (in)famously Electron.js

iOS is native: https://twitter.com/SlackHQ/status/931599784137363459?s=20

Android is native, too (no source)

Because once a company is invested in the native side, they probably aren't going to look at greenfield solutions anytime soon?

If you're considering building a new app, a responsive site with JS is definitely a contender. Take a look at the performance numbers. https://twitter.com/dhh/status/1174802413548474368

And they're only increasing, making it a more viable choice with each year passing.

I haven't tried it on iOS, but Twitter's web app is quite good on Android/Firefox and Android/Chrome. Not quite as good as native, and prone to developing lag if I don't occasionally restart the browser. But surprisingly good.

They talk about the process of building it here: https://blog.twitter.com/engineering/en_us/topics/open-sourc...

It's unusable on Firefox Focus though. Trying to expand anything completely breaks scrolling on the page.

No just focus. And I've run into issues even if I don't expand anything. Around 40% of pages have a point below which I can't scroll (I'm jumped to the top of the page if I try). And then there's the unspecified error you get on around 60% of page loads that requires a refresh to fix.

I tried it, it's pretty close honestly, but the performance just feels off and it does weird stuff all the time. The iOS app is just better.

I use the web app on iOS. Feature parity is 100% for me because I don't use push notifications at app on Twitter. The performance is a little worse (mostly touch targeting is not as good) but once you get used to it it is not noticeable. This is an acceptable tradeoff to me because it allows me to block almost all promoted tweets with Safari content blockers. I also think the Twitter native app may do devious things that are less likely to be permitted by Safari.

Users hate web apps, especially on mobile, and it has nothing to do with functionality. Web apps on the App Store invariably provoke angry screeds about how the look and feel is not right.

Native apps are even more essential on mobile. On the desktop, web apps just look weird and waste battery life. On mobile, they feel wrong. That difference in feel provokes visceral hatred.

No. Designers and some devs hate web apps for minuscule reasons your average user doesn’t care about and doesn’t notice at all.

If an app helps them to get a task done, it simply doesn’t matter if the thing is native or not. At least, if you use a somewhat reasonable UI approach like Ionic.

Users absolutely want their apps to be as fast and fluid as possible. This is why they buy the newest Apple and Android phones every year, because their web apps are getting slower and slower.

> Users hate web apps, especially on mobile, and it has nothing to do with functionality. Web apps on the App Store invariably provoke angry screeds about how the look and feel is not right.

> Native apps are even more essential on mobile. On the desktop, web apps just look weird and waste battery life. On mobile, they feel wrong. That difference in feel provokes visceral hatred.

They don't have to waste battery life. This is mostly due to poor coding/architecture, instead of "web". Especially with WebGl and Wasm.

I agree with this. When you are creating a mobile experience for a website, you typically are burdened by the knowledge and existing designs/functionality of the desktop version which was usually built first.

When you are designing for a mobile app, you are free from the shackles that bind you to the desktop.

Of course, there is nothing stopping you from creating a separate web mobile experience, but human nature makes it harder to do so.

The biggest problem with mobile apps is that you don't always have a reliable connection to the internet, even when your carrier is claiming you have 4g lte with all the bars.

Web apps should really have the option to cache the page entirely for offline use.

They do. It's called a PWA. Service workers cache the assets.

https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

The biggest feature I'd like parity on for mobile web.... is logins.

As the tracking war rages, humble little login cookies are becoming a casualty. For example if someone gets a transactional email (say a new booking notification), opens it on their iphone, it opens safari.... in a new context. No login! So frustrating for them. You can send tokens with the links, but they really need to have an expiry date on them, and if the user forwards the email it risks exposing their whole account. So now you have to start playing with an intermediate 'sort of logged in but don't let them do anything too dangerous' state

And now browsers are using "AI" to magically work out which cookies to delete. That's great, but.. can we not have an explicit UX for the user to say hey, this is a login cookie, I'm logged in because I want to see my data and be authorized on this website every single time I come here (and an equally special logout function that deletes it without trouble).

I'm a pretty heavy user of mobile web and rarely use apps, but logins for power users and tech impaired users is pretty much the main reason we're looking at react-native too

Theres native platform support for that now with shared login context between browsers and apps.

e.g. https://developer.apple.com/documentation/authenticationserv...

If I’m reading it right that’s for if you control the app though. They still lose login if they follow a link from a mail client or slack app over to a mobile web app, which wouldn’t happen if they were going to an actual app

It should all be shared as long as the sides are using the official cookie storage. I understand it as its essentially an HTTP only cookie stored at the device level (rather than in the brower).

I feel quite the opposite, most of the phone apps will likely to be thick client variants of the web apps, given that the hosts have so much power and storage available. Privacy concerns are gonna force this model where almost every activity having minimal network overhead. We are going back to the desktop app era, is what I feel.

> We are going back to the desktop app era, is what I feel.

Can't wait, to be honest. This era of everything as a service is great for developer convenience but is incredibly user-hostile in that it enables and encourages surveillance capitalism and the erosion of privacy.

I really like the idea of PWAs, but I've tried a few of them and I always come away being annoyed at the app launch latency. They still feel like they're hitting a remote server when starting up for.... something? My uneducated hunch is that they're over-zealously checking their server for updates.

The other issue I have with their implementation is the opaqueness of how offline caching works. How much space do apps get? When does the offline cache get invalidated? I care about that because of that terrible launch latency.

I think these issues can be attributed to PWAs being second-class citizens in Android and iOS.

Developers love the idea of PWAs. Users are less enthusiastic.

I for one personally like that Apple does some rudimentary vetting of apps in their store. I really have no interest in running a web app that could be great today and loaded with malware and trackers tomorrow.

This is a solved problem via service workers. They can cache all the app's content and you can choose to cache whatever you like including api responses from any service. They could also be configured to serve cache first and replace the content in background. At this point if the app is slow to start, it's 100% on devs/architecture. The only problem is if you exceed the quota for cache, which is varied by browser/platform, you risk the browser just nuking all your cache/localstorage/indexeddb.

Ads and Exposure.

Ads: Make a native app and a PWA, put a banner at the bottom. You'll get more from the native app.

Exposure: I made some stupid apps and without any SEO I get 10K-50K installs, you can't get that with a PWA and Google Search.

I'm 100% for PWA because I can't take anymore monopole shit from google play and his rules, but that's the reality.

Ads are the past.

The future is getting paid to make the app that actual is useful

Hmmm... What are these "ads"? Says the uBlock kid....

> Honestly I think the future of mobile will just be... mobile websites.

Indeed.

A lot of people still think that native is superior than web but the problem is that most websites are bloated pieces of crap.

If anyone doubts this check the Missive email client on iOS which was even featured by Apple on the AppStore and runs on Cordova:

https://medium.com/missive-app/our-dirty-little-secret-cross...

(sorry for the Medium link)

I didn’t have to go any further than the login and signup screens to see that it doesn’t feel native.

- No transitions between screens, just jumps

- Tapping field brings up keyboard, then whole screen jumps up about 30 pixels instead of smoothly animating

- Scrolling while there’s a blinking cursor has cursor detach from field until you lift your finger

- Doesn’t respect dark mode

- Doesn’t respect dynamic type consistently (text size)

- Other weird little display artifacts

Not saying it’s terrible, but it’s a good example of why native is still the way to go if you can afford it. It’s just a better user experience.

You think all of those are inherent flaws of using a webview?

Some of those are because the developer didn't implement them (transitions, dark mode) and others are because Apple didn't implement them in WKWebView to follow the OS behaviors (cursor, keyboard). Not sure about your comment about the text size or the display artifacts.

Not really interested in tracking down who is responsible for what. My point is that literally every single time someone comes along claiming that their hybrid framework or app is indistinguishable from native and I go check it out, it’s obvious within 30 seconds that it’s a poor substitute.

We are in a conversation about the future, most of which seems to be being held back by players who have a vested interest in keeping people using native apps; so while you might have the "we are already there" conversation a lot, your knee jerk response doesn't really have a place here.

My response wasn’t knee jerk. I went and downloaded the app in question and played with it. I disagree that the main reason we haven’t gotten to a better place is vested interests. The “write once, deploy anywhere” fantasy has been going on for thirty years now. It’s not that it doesn’t work at all, of course it does. But it comes with many downsides vs software written with one platform in mind, and that’s unlikely to ever change.

Technically, and from user experience point of view, this makes perfect sense. Native apps are rarely actually needed.

However, Apple is making a huge pile of money out of app store sales, and it has huge leverage as long as the 'app' model lives on. They are strong enough to prevent this from happening.

Ever ask yourself why mobile iOS web doesn't support push notifications like Android does? It's because that will be a shift in the wrong direction from Apple's standpoint.

As I asked before, which apps have you paid for, that would have been better as a web app, and that needed push notifications?

> acceptable performance

Until your competitor shows up. I think you are honestly right for the most cases, but the expectation on mobile, (esp. since the OS is written in native and 120Hz screens are coming) is so freaking high. The touch response rate expected is just going to make hybrid and web apps just seem like trash to the average consumer when compared directly with native apps. They just don't do it and just don't feel right.

> esp. since the OS is written in native and 120Hz screens are coming

High-refresh rate mobile displays already happened. There's more 90Hz than 120Hz on the market at the moment. Typically gamer-focused phones like the Asus ROG Phone or the Razer Phone, but non-gamer-focused flagships are also now 90Hz like the Pixel 4.

And of course on the iOS side of the ecosystem some iPad models already have 120hz displays, too.

Of course there are current examples, but in general the scale is not large at all on phones. Less than 1% of sales. Being first doesn't mean anything if it doesn't sell, being the majority of sales is a much different world.

I'm referring to the 2020 iPhone Pro and the Galaxy S20 both being rumored to have 120Hz displays, massive changes in the market.

I was really impressed recently by Wealthfront's mobile site. It's so good and fast, they don't even push you to download their native app. You just don't need it when the website works that well on mobile.

I'm convinced that the long-term future of all UI development is web based, at least at the rendering layer. WASM may free us from JavaScript.

IS WASM canvas-based or HTML/CSS? Because canvas is not what comes to mind when thinking in terms of Web UI.

WASM can access the DOM. Check out this:

https://github.com/gopherjs/vecty

Like React but in Go. Not quite mature yet but getting there.

The fact that Facebook themselves will never be able to replace their native iOS and Android apps with RN implementations says it all imo.

It just says that web apps can't steal enough data from your phone.

But RN apps are not web apps...?

Tricky question. They start as web apps since they're built with mostly web technologies, but then they're compiled as native apps with native components and they don't run in the browser. So, I'd lean towards "no" -- they're not web apps at runtime.

React Native apps do not use web technologies.

That depends on what you include in your definition of web technologies. React and Javascript at this point mostly fall under mine.

I guess we can agree to disagree -- I consider JavaScript a web technology.

React Native is widely used in both Instagram and the main Facebook app (market places). It’s also used in a number of other apps they make (oculus, ads manager).

this is the dumbest take on here. You think that because Facebook hasn't rewrote their apps in RN that RN must suck? What kind of evaluation for software is that.

They haven't rewrote in RN because it's unnecessary. Its not worth the engineering resources. There is so many things on the global product roadmap to build then rewrite something that already exists and works fine.

Like all software, RN is great for certain use cases. Just because someone isn't using it for X doesn't mean it also sucks for Y.

Apps are dominant on web because, well, the web sucks. We can gloss over this on desktop because of raw processing power but still, layout if html is just plain terrible.

Of course mobile processors will continue to improve but on mobile you’re making a trade off between performance and battery life and battery life will probably never be not a concern.

The mobile web sucks because of ads and bloated websites not because some inherent technological flaw.

And because of the "separate sites" approach to mobile web development. Good for some media-focused applications, but usually the separate mobile site has an oversimplified interface that can't be zoomed in or out.

Other things missing: Contacts, Device Identifier, In-app Purchases, and a trustworthy distribution platform with a large base of affluent customers.

> What's missing until regular websites have parity with mobile apps in functionality?

Performance.

> Literally all of them could be implemented as responsive pages with acceptable performance

But not with great performance. A user feels the slight stutters, glitches and slow-downs.

It's times like this where it becomes painfully clear that FirefoxOS was (1) ahead of its time and (2) woefully poorly managed.

Actually Symbian Web Runtime and WebOS were ahead of their time.

Honestly I think the future of mobile will just be... mobile websites.

That was Steve Jobs' original vision for the iPhone.

The difficulty was that once the App Store launched, people and middle managers thought that if a company didn't have an "app," it wasn't a real company.

Now that the web has matured, there are not that many things outside of games that require an app. But there are still many people (including many in my own company) that think an "app" adds credibility to a company, even if that app does less than the web site.

The power of websites is that they run cross-platform. If your website works on chrome on windows it’ll work (for the most part) on Firefox on Mac and safari on iOS. Apple is against this philosophically because it doesn’t take advantage of the unique capabilities their devices provide. It’s the same reason why Apple stopped supporting flash https://www.apple.com/hotnews/thoughts-on-flash/

That’s not true.

Back in 2007, Adobe claimed that they could get Flash working on the original iPhone if Apple had allowed them.

When they finally got it to run on Android years later, it required a 1Ghz processor and 1GB of RAM and it still barely ran and was horrible on battery life. The original iPhone had 128Mb of RAM and a 400Mhz processor. It wasn’t until around 2011 when there was an iPhone that met those specs.

Adobe was always late delivering Flash on mobile from Android phones and Palm phones.

It was so bad, that the Motorola Xoom was advertised to be able to browse the “real Internet” because it could support Flash. At launch it didn’t. Leaving it in the embarrassing position that you couldn’t browse the Xoom advertising page that required Flash on a Xoom.

This.

I developed a number of Air mobile apps back in 2012-2014 and all the blame is on Adobe. Flash was extremely inefficient and Adobe didn't want to invest the necessary resources to properly bring it to the mobile world.

Adobe cancelled AS4 (aka Flash Next) which would have made Air a very competitive crossplatform solution. They shifted all its resources into HTML5 to throw a bone to the Flash community and it was a complete failure.

https://insights.stackoverflow.com/trends?tags=actionscript-...

Don't get me wrong, it probably made economical sense for Adobe but it was a shame.

Also flash player on the Mac was terrible and consumed a lot of energy. I’m not surprised Apple didn’t want it on iOS.

Truth is even if Apple had wanted to bring it to iOS it didn't really have a choice. Users would have blamed Apple for the low battery time.

Supporting all of Apple's functionality was one of the reasons for not supporting Flash that Steve shared in his post, but I think you're right that Adobe not being able to get Flash working on iPhone was the main reason. Thanks for the correction!

Messenger, Mail, and Teams would be absolutely crippled without background support and notifications. Maps would be somewhat viable, and I'm not familiar with White Noise.

Also, 'native parity' is a moving goalpost. At the point you get support for all those things across all platforms, what else has been added to native that you are now missing?

This isn't even considering the fact that there is no incentive for apple to play nicely without an anti-trust ruling against them.

Progressive web apps can already receive notifications.

iOS supports push notifications in a PWA context? Thats news to me.

Seeing that the only apps that make money for either Google or Apple are mostly games with in app purchases, they wouldn’t be appropriate for web apps anyway.

I'd believe you for some of those apps. But definitely not for Google Maps. Even on their own OS and their own hardware, they are clearly pushing performance limits for the Google Maps app. And have been for years.

I think you're definitely right about gatekeeping, though. Apple's app store gross revenue is ~$50 billion/year. That's an incredible incentive to make sure that web apps will never be as good.

I m a web fanatic and use only the browser. My other apps are dropbox and skype , a decibel meter and strava, so things that cant exist on the web anyway. I use multiple gmail accounts so webmail is better

Since most content apps use browser links at some point it doesn’t even make sense to e.g. have a twitter app

Now, i wish we could have a better api than web push notifications though

I'm kind of done with notifications on my phone. Plenty of apps turn approving legitimate notifications into an excuse to push ads or attempts at engagement through os notifications. The most recent offender on my phone was the moovit app, that sent something inane with emojis in the notification. deleted.

I don't even have email notifications anymore. Just texts and calls from contacts. Notifications just serve to divert your attention from the task at hand. If I want to sit down and be distracted by reddit or whatever, it will be on my own time by my own choice damnit.

Native controls can afford to be richer (in principal) because knowledge transfers across apps. Websites do not enable such transfer: there's too much of a culture of customizing everything. On mobile the problem is somewhat less noticeable because rich native interaction models haven't really emerged.

Good point.

In the mobile and desktop world devs are totally fine with using native GUIs that ship with the OS (even encouraged to do so) but in the web world projects are criticized for using libraries like Bootstrap and devs and designers are expected to reinvent the wheel every time. Also don't use a native alert or you will condemned to hell.

Another feature lacking in the mobile web are touch gestures.

I'm facing this problem right now and the best option for recognizing gestures seems to be HammerJS which adds 7.5kB gzipped to your app.

After that your app still needs to react kinetically (eg: the image moves while dragging it to the left and then the view transitions to the next image). It's a lot of code that needs to be shipped in the JS bundle.

BTW if you have a better solution than HammerJS please comment here:

https://news.ycombinator.com/item?id=22184079

This would be great if HTTP, HTML and co would have been designed as a stateful low-latency application platform and not a distributed encyclopaedia. Retrofitting state and all of the things you listed into it resulted in the Javascript mayhem which is quite pathetic for several reasons including security and energy consumption. I think the future should be native applications that can be optimized for data transfer and latency, have much better security and stateful behaviour by default.

Monetization. Native apps provide app & in-app purchases seamlessly integrated in the platform. Web payment solutions are clumsy in comparison. Sure, there are new APIs that ask for CC number, holder etc. to be prefilled but the friction is still not at the same level IMO.

You need to pay the cut to Apple/Google but in certain scenarios it's preferable than asking for payment details.

Is there a difference now? Websites in Safari ask me to pay with an Apple ID popup that takes my fingerprint and charges me exactly the same way apps do, I don't see any difference in how it appears or is handled.

Shopify's growth model relies on bringing people into an app dependent ecosystem. They're not looking to be a one app company. They want users to locked into having many Shopify apps. When people are using mobile sites, the sense of dependency just isn't there. Not to mention it feels terribly inconvenient and the tracking can be stymied.

>What's missing until regular websites have parity with mobile apps in functionality?

Some means of preventing users from blocking ads and tracking? Sure, there are ways around this for native apps but they're not nearly as trivial as installing an ad blocker (provided the mobile browser supports extensions).

And what happens when I don't have any signal? Writing an offline-first mobile website is INCREDIBLY hard. Where are you going to store the data? How are you going to detect the network connectivity without polling and hosing the battery because the radio doesn't timeout? Geo-fencing events?

One thing I feel is overlooked in these discussions is WebView UI performance isn’t as good as native. You’ll always notice a difference scrolling a list natively vs on web. It just _feels_ different, same goes for all the other micro-interactions if pushing/popping views.

This. And if you compare it with the very best say, iOS has to offer in touch interaction it's just different worlds. Look at the multitasking and swipe interaction on an iPad pro at 120Hz. You just can't even think of that world.

I have a funny feeling that Apple's next big developer move on the iPhone is to enable those types of smooth, cancelable interactions out of the box in Xcode via new SwiftUI components just for it. When they make it easy and clear, people will use it and then the gap will widen.

>Literally all of them could be implemented as responsive pages with acceptable performance.

Speaking personally I like the division between highly sandboxed websites (no GPS access, no notifications, etc...) and trusted apps.

This is only because the trust given to apps is insane. No distinction between foreground GPS and background GPS? Sure, I wouldn't want web sites to work that way either. But if permissions were sane there would be no reason not to have native apps and web apps ask for the same permissions in the same way.

I don't ever want to give a website access to microphone because someone could turn it on via an XSS. Websites on the whole seem to be far more vulnerable than mobile apps because:

1. their code is refreshed on every load,

2. their software is often updated on a daily if not hourly basis,

3. they will often pull code from remote sources on every page load,

4. they don't even have to pass the minimal review and code signing of an app store,

5. and it is very likely that they are written in javascript.

I agree with your general point that better permissions would improve the situation. For instance asking each time it wants to use the microphone, rather than an approve once model.

There has been a distinction between the two on iOS for at least two years.

Mail is the last thing I want as a web app. I don’t use web mail on my PC. I definitely wouldn’t want to use it on my phone.

Maps is also much more responsive even on older phones than it is on a web page on a modern PC.

I thought this too. You know recent TWA with PWA makes the website accessible with anything on the system level. Like the location and other information.

I just wish with PWAs ... there was some more love as far as how they're handled.

Last time I looked at them it was really wonky to install a PWA from Chrome.

Developer advocacy at the time from Google was big on PWAs, but they were second class citizens everywhere in Google land....

You can now wrap a PWA up as a TWA (Trusted Web Activity) and publish it to the Play Store, which should make a huge difference.

OH TIL that. That's good, showing up on the Play Store was kinda random benchmark I was looking for.

They are first class on UWP since Microsoft decided to drop WinJS in favour of PWAs.

It is also one of the ways they are pushing for cross platform development on their upcoming foldable devices (Other being React Native and Xamarin, depending where one is coming from).

Yeah I really liked MS's support that way.

With all of your most used apps, you could just switch to using web apps. You can save any mobile site to the home screen of your iphone with safari.

> What's missing until regular websites have parity with mobile apps in functionality?

The desire to build web apps instead of mobile apps.

> Literally all of them could be implemented as responsive pages with acceptable performance.

Exactly. It's not a technical issue as much as an issue of focus/interest. Unfortunately, this has been a losing battle since 2008.

> Exactly. It's not a technical issue as much as an issue of focus/interest. Unfortunately, this has been a losing battle since 2008.

This is true, but there are a lot of features missing from a responsive site that apps have. Of course, I'd argue that all of the missing functionality can easily be added to Safari and Chrome (to name the big two mobile browsers).

You're viewing it through the lens of a developer.

The user wants the best experience. Because software costs 0$ to distribute, the best user experience will always win out.

The future of all software is faster, better software. Websites are shitty, arcane technology - the opposite of the future.

If a website is popular and does the basics well, it doesn't matter how 'shitty' the technology is.

Amazon.com has easily the most hideously designed product pages out there. Because sellers can "customize" the product page, you get their content (usually hero images with tiny text) mixed in with text-only product details, "users also bought" carousels, Q&A and Reviews all jammed together.

And they're still doing better than most large ecommerce stores (Walmart, Best Buy etc.) because the stuff that matters (pricing, delivery time) is better than the competition.

Switching to the Amazon app doesn't fix any of these problems because it's primarily a content and UX issue.

Of course if a store is just plain cheaper and over all quality wise better, it it's not that important that it looks hideous and abandoned. But to some people it matters. And if two stores provide the same product at the same price, I think I'll prefer the one that looks nicer.

It doesn't decide everything, but it's pretty certainly a factor (although Amazon must have determined that it's a small one to them, as they are still micro-optimizing for other page-related aspects like loading speed).

I don't know, I get to use uBlock when I use web apps and I have some control over the client even on my phone. Native apps can basically do whatever they want and users are waking up to this.

I would like all of my applications to be sandboxed by a browser I have control over.

Offline is still a thing.

But website can be packed up and saved as PWAs, also "offline sites" have been a thing since the 90s.

pwa are one thing, but safari based web apps are nothing more than a bookmark that happens to sit on your home screen. should they and could they be catched? absolutely. does apple care enough about us nerds with our web apps to implement a 30 year old feature? not at all.

Yes! This is something that would greatly benefit the app world.

Actually the future of the application UI is React.

non-native never feels the same. fuck web apps.

I thought that native mobile would be out 4 years ago and not much has changed, my only conclusion now is that I don't want to do android/ios apps for startups, but I'll do it for large organizations that are actually leveraging all the technology.

I was going to build a mobile web app but I don’t like the way iOS handles button clicks on the bottom of the screen. The first click is ignored and it slides up your bottom menu bar, then you can click the button. You don’t have as much control in the browser.

No mobile website has match the performance of native though

No 2D renderer has matched the rendering engine of chromium aka skia. Show benchmarcks otherwise, instead of hearsay evidence.

Reply on news.ycombinator.com