MSEdgeExplainers/WebInstall/explainer_same_domain.md at main · MicrosoftEdge/MSEdgeExplainers
This proposal is exactly what I was asking for!
C’mon browsers, let’s make this happen!
This proposal is exactly what I was asking for!
C’mon browsers, let’s make this happen!
It’s a shame that the newest Safari release is overshadowed by Apple’s shenanigans and subsequent U-turn because there’s some great stuff in there.
I really like what they’re doing with web apps added to the dock:
Safari adds support for the
shortcuts
manifest member on macOS Sonoma. This gives you a mechanism in the manifest file for defining custom menu commands that will appear in the File menu and the Dock context menu.
Hallelujah! Apple have backed down on their petulant plan to sabatoge homescreen apps.
I’m very grateful to the Open Web Advocacy group for standing up to this bullying.
This is exactly what it looks like: a single-fingered salute to the web and web developers.
Read Alex’s thorough explanation of the current situation and then sign this open letter.
Cupertino’s not just trying to vandalise PWAs and critical re-engagement features for Safari; it’s working to prevent any browser from ever offering them on iOS. If Apple succeeds in the next two weeks, it will cement a future in which the mobile web will never be permitted to grow beyond marketing pages for native apps.
Also, remember this and don’t fall for it:
Apple apparently hopes it can convince users to blame regulators for its own choices.
When it benefits Apple, they take the DMA requirements much further than intended. When it doesn’t benefit them, they lean back on the “integrity” of iOS and barely comply at all.
I don’t like to assume the worst and assign vindictitive motives to people, but what Apple is doing here is hard to read as anything other than petulant and nasty …and really, really bad for users.
If you’ve ever made a progressive web app, please fill in this survey.
In the same vein as that last link, Chris says what we’re all thinking:
Most of what we build is links from one page to another, and
form
submissions that send data from the browser to the server.
Web Push on iOS is nearing its one year anniversary. It’s still mostly useless.
Sad, but true. And here’s why:
On iOS, for a website to be able to ask the user to grant the push notification permission, it needs to be installed to the home screen.
No other browser on any of the other platforms requires you to install a website for it to be able to send push notifications.
Apple is within their rights to withhold Web Push to installed apps. One could argue it’s not even an unreasonable policy - if Apple made installing a web app at least moderately straightforward. As it is, they have buried it and hidden important functionality behind it.
I really, really hope that the Safari team are reading this.
Why the heck is everyone reaching for React as soon as something on the screen needs to update? And why do we insist on squishing our frontend concerns together with our backend concerns?
I’m glad I’m not the only one constantly asking myself those questions.
Look: is the idea of physically separating “code that runs business logic and builds markup” from “code that handles realtime interactions” really that awful? You can write both in JS if you like, I promise I won’t judge, but we can’t keep pretending that they’re basically the same.
If there’s one takeaway from all this, it’s that the web is a flexible medium where any number of technologies can be combined in all sorts of interesting ways.
Lots of new features landing in Safari, and it’s worth paying attention to the new icon requirements now that websites can be added to the dock:
To provide the best user experience on macOS, supply at least one opaque, full-bleed
maskable
square icon in the web app manifest, either as SVG (any size) or high resolution bitmap (1024×1024).
Following on from my post about websites in the dock, Trys upgraded to Sonoma and added a handy copy’n’paste resource to his dock. It works a treat.
Sit with that for a second, you can write a desktop application with no tooling, launch it from your phone to the internet for free, and seconds later install it on any computer. I didn’t have to ask permission, or jump through any App Store hoops. I wrote a thing, pushed it to the internet, and then I could use the thing. Even better, I could send the link to Chris and he could use the thing. That’s the power of the internet.
It’s great to see how (progressive) web apps are being supported on both iOS and macOS …I just wish the discovery were better.
Oh no! My claim has been refuted by a rigourous scientific study of …checks notes… ten people.
Be right back: just need to chat with eleven people.
An entire generation of apps-that-should-have-been web pages has sprung up, often shoehorned into supposedly cross-platform frameworks that create a subpar user experience sludge. Nowhere is this more true than for media — how many apps from newspapers or magazines have you installed, solely for a very specific purpose like receiving breaking news alerts? How many of those apps are just wrappers around web views? How many of those apps should have been web pages?
Instead of doing what the competing browsers are doing (and learning from years of experience of handling Web Push), Apple decided to reinvent a wheel here. What they’ve turned up with looks a lot more like a square.
But you can’t have a web app without a web-app-compatible browser, and you can’t get a web-app-compatible browser in Apple’s App Store. The only browsers permitted in the App Store are those based on WebKit, the browser engine behind Safari. This means that every browser on iOS, from Firefox to Edge to Chrome, is just a reskinned version of Safari.
The problem I’ve regularly encountered in my work is that I don’t get to do my job the way I think is best for both me and my employer or client. The employer, who isn’t the web development expert, almost always has a clear idea of what real web development is supposed to look like: Single-Page-Apps and React (or React-like frameworks).
An intimation that it wouldn’t be the right solution for this particular problem is taken as an admission of incompetence.
I’ve experienced this. And I think this observation is even more true when it comes to recruitment.
Web Push on iOS will change the “we need to build a native app” decision.
Push notifications are definitely not the sole reason to go native, but in my experience, it’s one of the first things clients ask for. They may very well be the thing that pushes your client over the edge and forces them, you and the entire project to accept the logic of the app store model.
Good news and bad news…
The good news is that web notifications are coming to iOS—my number one wish!
The bad news is that it won’t happen until next year sometime.