[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.

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

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%.

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.

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.

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.

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'!

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.

Just maybe it’s a product market fit issue?

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

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?

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'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.

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

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.

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

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

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.

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.

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.

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.

Also, you don’t have to buy a Mac. 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.

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.

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.

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

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...

Yes.

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.

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-...

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.

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.

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.

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.

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.

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

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.

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?

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).

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.

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

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).

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

Tangentially related, iOS mail app has a VIP setting.

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

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.

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.

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

(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.)

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.

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.

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.)

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.

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.

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.

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.

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.

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.

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,...

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

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.

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?

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?

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.

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.

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.

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.

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'.

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.

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

Sorry, it just seems unnecessarily negative to me.

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

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.

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.

- 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.

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

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.

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

Android is native, too (no source)

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.

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.

> 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.

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.

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

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

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

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

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.

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.

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.

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.

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

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

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)

- 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.

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.

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.

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.

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.

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

https://github.com/gopherjs/vecty

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

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.

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.

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.

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.

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.

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, '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.

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.

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 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.

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.

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

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

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).

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.

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

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.

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

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....

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).

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.

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).

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.

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

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.

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).