Tags: webapp

Home Screen Advantage - Infrequently Noted

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.

Manton Reece - Apple is twisting the truth

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.

The European Union’s Digital Markets Act is being enforced and Apple aren’t happy about it.

Most of the discussion around this topic has centred on the requirement for Apple to provision alternative app stores. I don’t really care about that because I don’t really care about native apps. With one exception: I care about web browsers.

That’s the other part of the DMA that’s being enforced: Apple finally have to allow alternative browsing engines. Hallelujah!

Instead of graciously acknowledging that this is what’s best for users, Apple are throwing a tantrum.

First of all, they’re going to ringfence any compliance to users in the European Union. Expect some very interesting edge cases to emerge in a world where people don’t spent their entire lives in one country.

Secondly, Apple keep insisting that this will be very, very bad for security. You can read Apple’s announcement on being forced to comply but as you do you so, I’d like you to remember one thing: every nightmare scenario they describe for the security of users in the EU is exactly what currently happens on Macs everywhere in the world.

This includes risks from installing software from unknown developers that are not subject to the Apple Developer Program requirements, installing software that compromises system integrity with malware or other malicious code, the distribution of pirated software, exposure to illicit, objectionable, and harmful content due to lower content and moderation standards, and increased risks of scams, fraud, and abuse.

Users of macOS everywhere are currently exposed to all the risks that will supposedly overwhelm iOS users in the European Union. Weirdly, the sky hasn’t fallen.

It’s the same with web browsers. I just got a new Mac. It came with one browser pre-installed: Safari. It’s a good browser. But I also have the option of installing another browser, like Firefox (which I’ve done). A lot of people just use Safari. That’s good. That’s choice. Everyone wins.

Now Apple need to provide parity on iOS, at least for users in the EU. Again, Apple are decribing this coming scenario as an absolute security nightmare. But again, the conditions they’re describing are what already exist on macOS.

All Apple is being asked to do is offer than the same level of choice on mobile that everyone already enjoys on their computers. Rather than comply reasonably, Apple have found a way to throw their toys out of the pram.

As of the next update to iOS, users in the EU will no longer have homescreen apps. Those web apps will now launch in a browser window. Presumably they’ll also lose the ability to send push notifications: being a homescreen app was a prerequisite for that functionality.

This is a huge regression that only serves to harm and confuse users.

I have a website about traditional Irish music. Guess where a significant amount of the audience is based? That’s right: Ireland. In the European Union.

There is no native app for The Session, but you can install it on your phone nonetheless. Lots of people have done that. After a while they forget that they didn’t install it from an app store: it behaves just like any other app on their homescreen.

That’s all about to change. I’m going to get a lot of emails from confused users wondering why their app is broken, now opening in a regular browser window. And I won’t be able to do anything about it, other than to tell them to take it up with Apple.

Presumably Apple is hoping that users will direct their anger at the EU commission instead. They’re doing their best to claim that they’re being forced to make this change. That’s completely untrue. A lie:

This is emphatically not required by the EU’s Digital Markets Act (DMA). It’s a circumvention of both the spirit and the letter of the Act, and if the EU allows it, then the DMA will have failed in its aim to allow fair and effective browser and web app competition.

Throughout all their communications on this topic, Apple are sticking to their abuser logic:

Look what you made me do!

This is going to hurt me more than it hurts you.

Apple’s petulant policy of malicious compliance is extremely maddening. What they’re about to do to users in the EU is just nasty.

This is a very dark time for the web.

I feel bad for the Safari team. They’ve been working really hard recently to make Safari a very competitive browser with great standards support with a quicker release cycle than we’ve seen before. Then it all gets completely torpedoed at the level of the operating system.

I really hope that Apple won’t get away with their plan to burn down web apps on iOS in the EU. But hope isn’t enough. We need to tell the EU commission how much damage this will do.

If you’ve ever built a web app, then your users will suffer. Remember, it’s a world wide web, including the European Union.

Create a PDF with the following information:

• Your company’s name.
• Your name.
• That your company operates or services the EU.
• How many users your service has in the EU (approximately).
• The level of impact this will have on your business.
• The problems this will cause your business.
• Whether or not the submission is confidential.

The submission can be as short or long as you want. Send it to contactus@open-web-advocacy.org, ideally before Monday, February 19th.

I know that’s a lot to ask of you on your weekend, but this really matters for the future of the web.

At the very least, I encourage to get involved with the great work being done by the Open Web Advocacy group. They’re also on Discord.

Please don’t let Apple bully an entire continent of users.

Apple on course to break all Web Apps in EU within 20 days - Open Web Advocacy

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.

The web is mostly links and forms | Go Make Things

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 - 1 year anniversary - Webventures

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.

Concatenating text

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.

The Website vs. Web App Dichotomy Doesn’t Exist | jakelazaroff.com

Amen!

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.

I was impressed with how Safari now allows you to add websites to the dock:

It feels great to have websites that act just like other apps. I like that some of the icons in my dock are native, some are web apps, and I mostly don’t notice the difference.

Trys liked it too:

For all intents and purposes, this is a desktop application created without a single line of Swift or Objective-C, or any heavy Electron wrappers.

Oh, and the application can work offline! Service workers, and browser storage are more than stable enough to handle a variety of offline loading patterns. These are truly exciting times to be building for the web!

There was one aspect that I was particularly pleased with. External links:

Links within a Safari-installed web app respect your default browser choice.

Excellent! Except it’s no longer true. At least not in some cases. The behaviour is inconsisent but I’m running the latest version of Safari on the latest version of Sonoma, and now external links in a Safari-installed web app are broken. They just stay in the same application.

I thought maybe it was related to whether the website’s manifest file has the display value set to “standalone” rather than, say, “minimal ui”. Maybe the “standalone” instruction is being taken literally? But even when I change the value I’m still getting the broken behaviour.

This may sound like a small thing, but it completely changes the feel of using the web app. Instead of feeling like “I’m using an app that just happens to be on the web”, it now feels like “I’m using a web browser but with fewer features.”

I’ve been loving having Mastodon as a standalone app in my dock. It used to be that if I clicked on a link in a Mastodon post, it would open in my browser of choice (Firefox) where I could then bookmark it, or do any other tasks that my browser offers me. Now if I click on a link in Mastodon, I’m stuck in the same “app”. It feels horribly stifling.

I can right-click on a link and get options that still keep me in the same app, like “Open link” or “Open Link in New Window.” To actually open the link in my web browser, I have to select “Copy Link”, then go to my web browser, open a new tab, and paste the link in there.

This is broken. I hope it isn’t intentional. Maybe I’m just at the receiving end of some weird glitch. If this stays this way, I’ll probably just remove the Safari-installed web apps from my dock. They feel pointless if they’re just roach motels.

I’d love to file a bug for this, but this isn’t a Webkit bug, it’s a Safari bug (and the Webkit bug tracker is at pains to point out that Webkit and Safari are not the same thing). But have you ever tried to file a bug with Apple? Good luck!

Anyway, I sincerely hope that this change will be walked back. Otherwise websites in the dock are dead in the water.

WebKit Features in Safari 17.2 | WebKit

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

Desktop progressive web applications | Trys Mudford

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.

I updated my Mac to the newest operating system, Sonoma. I did this to try out the new “add to Dock” feature in Safari. It’s like the “add to Homescreen” action on iOS.

Before I get into what’s good, I have to start by ranting about a big problem on both desktop and mobile: discovery.

First of all, you have to know that a square with an arrow sticking out of it means “share”.

Okay, I can buy it. It’s no better or worse than the three horizontal lines of a hamburger icon, or the three horizontal dots of a kebab icon. And whereas the hamburger and kebab icons are used as a catch-all cupboard to sweep all your rubbish into, at least this icon has a specific meaning. It means share, right?

Well, it used to. But now it’s also home to “add to Homescreen” and “add to Dock”. Neither of those actions are sharing.

Stretching semantics, I suppose you could say you’re sharing something with yourself.

Anyway, this is the biggest issue with progressive web apps on both iOS and Mac. Regardless of how well they work, there’s not much point if most people don’t know the option exists.

(Update: Jen rightly points out that you can also get to “add to Dock” from the file menu. Doh! How did I miss that‽)

Discovery aside, I was interested to see how Safari handles web apps on desktop compared to how Chrome does it.

I’ve had one or two web apps in my dock for a while, installed through Chrome. Google Meet is one of them. I use it quite a bit, and honestly it feels no different to using a native desktop app.

One annoyance is that the Chrome browser also automatically launches whenever I launch the Google Meet icon in my dock. This wouldn’t matter if Chrome were my default browser, but I use Firefox. So whenever I’m using the Google Meet web app, there’s a Google Chrome icon hanging around in my dock, saying “gizza job, I can do that.”

I opened Google Meet in Safari and then selected “add to Dock” from the square with an arrow sticking out of it. Then I quit Safari. I was delighted to see that when I launched the Google Meet web app from the dock, it didn’t automatically launch Safari! Excellent!

Even better, links within a Safari-installed web app respect your default browser choice. What I mean is, previously when I had Google Meet installed via Chrome, if I clicked an external link in Google Meet it opened in Chrome. But now with the Google Meet installed via Safari, external links open in Firefox, my browser of choice. Very good!

But the Safari-installed version of Google Meet is, alas, over-zealous with permissions. I have to grant access to my microphone and camera every single time I launch it. Previously—with the version installed via Chrome—it remembered my choice.

Now I don’t know if the behaviour in the Safari-installed version is a deliberate choice made for security reasons, or if it’s a bug. I suspect it’s a bug. After all, on iOS you get access to more permissions if a site is added to the homescreen—it’s the only way to ask for permissions for notifications, for example.

I added a few more sites to my dock: mastodon.social and thesession.org. They both work really well as standalone apps.

Interestingly, if I click a link to thesession.org from within the mastodon.social standalone web app (or the other way around), the link opens in my default browser. So the web apps don’t “own” the domains. That’s fine, although I wonder if it violates the principle of least surprise—perhaps the expectation is that the installed web app is the preffered owner of that link.

I also tried adding Google Calendar to my dock. Ironically, I can only do this with Safari. For some reason, Google have chosen not to make their calendar a progressive web app …which means there’s no option to install it from Google Chrome.

They’re missing a trick there. It’s the perfect candidate for being a standalone app.

Actually, I take that back. Gmail is the perfect candidate for being a standalone app …and yet it’s not a progressive web app. Very odd!

With Safari, you can add any website to the dock. It doesn’t need to be a progressive web app. But the installation experience works best if there’s a manifest file pointing to some nice icons.

As it turned out, Google Calendar runs like an absolute dog in Safari (and therefore as a Safari-installed web app). Before you cry conspiracy, note that it runs absolutely fine in Firefox. I know because I use it in Firefox every day. But I can’t add it to my dock from Firefox because Mozilla turned their back on progressive web apps a while back. A bad decision.

Google Calendar isn’t the only thing that runs slowly in Safari’s engine. This page on The Session has a very large DOM and a badly-coded in-page search (I know, I know, I need to improve it). It works fine in other browsers but Safari struggles mightily.

(Update: I tried using Google Calendar from Safari again and it seems to be running just fine now. Maybe I caught it on a bad day? In any case, I’ve added it to the dock now and it’s feeling good as a standalone app.)

Still, aside from a few annoying little things around permissions and performance—and the situation with discovery—it feels great to have websites that act just like other apps. I like that some of the icons in my dock are native, some are web apps, and I mostly don’t notice the difference.

I wonder if there’s much point using wrappers like Electron any more? I feel like they were mostly aiming to get that parity with native apps in having a standalone application launched from the dock.

Now all you need is a website.

Web Apps on macOS Sonoma 14 Beta

It’s great to see how (progressive) web apps are being supported on both iOS and macOS …I just wish the discovery were better.

The most cartoonish misrepresentation of progressive enhancement is that it means making everything work without JavaScript.

No. Progressive enhancement means making sure your core functionality works without JavaScript.

In my book Resilient Web Design, I quoted Wilto:

Lots of cool features on the Boston Globe don’t work when JS breaks; “reading the news” is not one of them.

That’s an example where the core functionality is readily identifiable. It’s a newspaper. The core functionality is reading the news.

It isn’t always so straightforward though. A lot of services that self-identify as “apps” will claim that even their core functionality requires JavaScript.

Surely I don’t expect Gmail or Google Docs to provide core functionality without JavaScript?

In those particular cases, I actually do. I believe that a textarea in a form would do the job nicely. But I get it. That might take a lot of re-engineering.

So how about this compromise…

Your app should work in a read-only mode without JavaScript.

Without JavaScript I should still be able to read my email in Gmail, even if you don’t let me compose, reply, or organise my messages.

Without JavaScript I should still be able to view a document in Google Docs, even if you don’t let me comment or edit the document.

Even with something as interactive as Figma or Photoshop, I think I should still be able to view a design file without JavaScript.

Making this distinction between read-only mode and read/write mode could be very useful, especially at the start of a project.

Begin by creating the read-only mode that doesn’t require JavaScript. That alone will make for a solid foundation to build upon. Now you’ve built a fallback for any unexpected failures.

Now start adding the read/write functionally. You’re enhancing what’s already there. Progressively.

Heck, you might even find some opportunities to provide some read/write functionality that doesn’t require JavaScript. But if JavaScript is needed, that’s absolutely fine.

So if you’re about to build a web app and you’re pretty sure it requires JavaScript, why not pause and consider whether you can provide a read-only version.

People do use Add to Home Screen – Firefox UX

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.

A pretty sweet push notification solution for mobile Safari

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?

Web Push on iOS requires installing the web app - Webventures

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.

Push notifications are finally arriving on iOS—hallelujah! Like I said last year, this is my number one wish for the iPhone, though not because I personally ever plan to use the feature:

When I’m evangelising the benefits of building on the open web instead of making separate iOS and Android apps, I inevitably get asked about notifications. As long as mobile Safari doesn’t support them—even though desktop Safari does—I’m somewhat stumped. There’s no polyfill for this feature other than building an entire native app, which is a bit extreme as polyfills go.

With push notifications in mobile Safari, the arguments for making proprietary apps get weaker. That’s good.

The announcement post is a bit weird though. It never uses the phrase “progressive web apps”, even though clearly the entire article is all about progressive web apps. I don’t know if this down to Not-Invented-Here syndrome by the Apple/Webkit team, or because of genuine legal concerns around using the phrase.

Instead, there are repeated references to “Home Screen apps”. This distinction makes some sense though. In order to use web push on iOS, your website needs to be added to the home screen.

I think that would be fair enough, if it weren’t for the fact that adding a website to the home screen remains such a hidden feature that even power users would be forgiven for not knowing about it. I described the steps here:

1. Tap the “share” icon. It’s not labelled “share.” It’s a square with an arrow coming out of the top of it.
2. A drawer pops up. The option to “add to home screen” is nowhere to be seen. You have to pull the drawer up further to see the hidden options.
3. Now you must find “add to home screen” in the list

• Copy
• Add to Reading List
• Add Bookmark
• Add to Favourites
• Find on Page
• Add to Home Screen
• Markup
• Print

As long as this remains the case, we can expect usage of web push on iOS to be vanishingly low. Hardly anyone is going to add a website to their home screen when their web browser makes it so hard.

If you’d like to people to install your progressive web app, you’ll almost certainly need to prompt people to do so. Here’s the page I made on thesession.org with instructions on how to add to home screen. I link to it from the home page of the site.

I wish that pages like that weren’t necessary. It’s not the best user experience. But as long as mobile Safari continues to bury the home screen option, we don’t have much choice but to tackle this ourselves.

I was chatting with my new colleague Alex yesterday about a link she had shared in Slack. It was the Nielsen Norman Group’s annual State of Mobile User Experience report.

There’s nothing too surprising in there, other than the mention of Apple’s app clips and Google’s instant apps.

Remember those?

Me neither.

Perhaps I lead a sheltered existence, but as an iPhone user, I don’t think I’ve come across a single app clip in the wild.

I remember when they were announced. I was quite worried about them.

See, the one thing that the web can (theoretically) offer that native can’t is instant access to a resource. Go to this URL—that’s it. Whereas for a native app, the flow is: go to this app store, find the app, download the app.

(I say that the benefit is theoretical because the website found at the URL should download quickly—the reality is that the bloat of “modern” web development imperils that advantage.)

App clips—and instant apps—looked like a way to route around the convoluted install process of native apps. That’s why I was nervous when they were announced. They sounded like a threat to the web.

In reality, the potential was never fulfilled (if my own experience is anything to go by). I wonder why people didn’t jump on app clips and instant apps?

Perhaps it’s because what they promise isn’t desirable from a business perspective: “here’s a way for users to accomplish their tasks without downloading your app.” Even though app clips can in theory be a stepping stone to installing the full app, from a user’s perspective, their appeal is the exact opposite.

Or maybe they’re just too confusing to understand. I think there’s an another technology that suffers from the same problem: progressive web apps.

Hear me out. Progressive web apps are—if done well—absolutely amazing. You get all of the benefits of native apps in terms of UX—they even work offline!—but you retain the web’s frictionless access model: go to a URL; that’s it.

So what are they? Are they websites? Yes, sorta. Are they apps? Yes, sorta.

That’s confusing, right? I can see how app clips and instant apps sound equally confusing: “you can use them straight away, like going to a web page, but they’re not web pages; they’re little bits of apps.”

I’m mostly glad that app clips never took off. But I’m sad that progressive web apps haven’t taken off more. I suspect that their fates are intertwined. Neither suffer from technical limitations. The problem they both face is inertia:

The technologies are the easy bit. Getting people to re-evaluate their opinions about technologies? That’s the hard part.

True of progressive web apps. Equally true of app clips.

But when I was chatting to Alex, she made me look at app clips in a different way. She described a situation where somebody might need to interact with some kind of NFC beacon from their phone. Web NFC isn’t supported in many browsers yet, so you can’t rely on that. But you don’t want to make people download a native app just to have a quick interaction. In theory, an app clip—or instant app—could do the job.

In that situation, app clips aren’t a danger to the web—they’re polyfills for hardware APIs that the web doesn’t yet support!

I love having my perspective shifted like that.

The specific situations that Alex and I were discussing were in the context of museums. Musuems offer such interesting opportunities for the physical and the digital to intersect.

Remember the pen from Cooper Hewitt? Aaron spoke about it at dConstruct 2014—a terrific presentation that’s well worth revisiting and absorbing.

The other dConstruct talk that’s very relevant to this liminal space between the web and native apps is the 2012 talk from Scott Jenson. I always thought the physical web initiative had a lot of promise, but it may have been ahead of its time.

I loved the thinking behind the physical web beacons. They were deliberately dumb, much like the internet itself. All they did was broadcast a URL. That’s it. All the smarts were to be found at the URL itself. That meant a service could get smarter over time. It’s a lot easier to update a website than swap out a piece of hardware.

But any kind of technology that uses Bluetooth, NFC, or other wireless technology has to get over the discovery problem. They’re invisible technologies, so by default, people don’t know they’re even there. But if you make them too discoverable— intrusively announcing themselves like one of the commercials in Minority Report—then they’re indistinguishable from spam. There’s a sweet spot of discoverability right in the middle that’s hard to get right.

Over the past couple of years—accelerated by the physical distancing necessitated by The Situation—QR codes stepped up to the plate.

They still suffer from some discoverability issues. They’re not human-readable, so you can’t be entirely sure that the URL you’re going to go to isn’t going to be a Rick Astley video. But they are visible, which gives them an advantage over hidden wireless technologies.

They’re cheaper too. Printing a QR code sticker costs less than getting a plastic beacon shipped from China.

QR codes turned out to be just good enough to bridge the gap between the physical and digital for those one-off interactions like dining outdoors during a pandemic:

I can see why they chose the web over a native app. Online ordering is the only way to place your order at this place. Telling people “You have to go to this website” …that seems reasonable. But telling people “You have to download this app” …that’s too much friction.

Ironically, the nail in the coffin for app clips and instant apps might’ve been hammered in by Apple and Google when they built QR-code recognition into their camera software.

Pluralistic: Web apps could de-monopolize mobile devices (13 Dec 2022) – Pluralistic: Daily links from Cory Doctorow

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.