Tags: ios

125

sparkline

Tuesday, February 25th, 2025

The web on mobile (a response) | Clagnut by Richard Rutter

Rich suggests another reason why the UX of websites on mobile is so shit these days:

The path to installing a native app is well trodden. We search the App Store (or ironically follow a link from a website), hit ‘Get’ and the app is downloaded to our phone’s home screen, ready to use any time with a simple tap.

A PWA can also live on your home screen, nicely indistinguishable from a native app. But the journey to getting a PWA – or indeed any web app – onto your home screen remains convoluted to say the least. This is the lack of equivalence I’m driving at. I wonder if the mobile web experience would suck as badly if web apps could be installed just as easily as native apps?

Monday, February 17th, 2025

trot

Working on this project is great but ten minutes into it and I already miss the resilience of the web. I miss how you have to really fuck things up to make a browser yell at you or implode.

Wednesday, October 16th, 2024

Docks and home screens

Back in June I documented a bug on macOS in how Spaces (or whatever they call they’re desktop management thingy now) works with websites added to the dock.

I’m happy to report that after upgrading to Sequoia, the latest version of macOS, the bug has been fixed! Excellent!

Not only that, but there’s another really great little improvement…

Let’s say you’ve installed a website like The Session by adding it to the dock. Now let’s say you get an email in Apple Mail that includes a link to something on The Session. It used to be that clicking on that link would open it in your default web browser. But now clicking on that link opens it in the installed web app!

It’s a lovely little enhancement that makes the installed website truly feel like a native app.

Websites in the dock also support the badging API, which is really nice!

Like I said at the time:

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.

The biggest issue remains discovery. Unless you already know that it’s possible to add a website to the dock, you’re unlikely to find out about it. That’s why I’ve got a page with installation instructions on The Session.

Still, the discovery possibilities on Apples’s desktop devices are waaaaay better than on Apple’s mobile devices.

Apple are doing such great work on their desktop operating system to make websites first-class citizens. Meanwhile, they’re doing less than nothing on their mobile operating system. For a while there, they literally planned to break all websites added to the homescreen. Fortunately they were forced to back down.

But it’s still so sad to see how Apple are doing everything in their power to prevent people from finding out that you can add websites to your homescreen—despite (or perhaps because of) the fact that push notifications on iOS only work if the website has been added to the home screen!

So while I’m really happy to see the great work being done on installing websites for desktop computers, I’m remain disgusted by what’s happening on mobile:

At this point I’ve pretty much given up on Apple ever doing anything about this pathetic situation.

Thursday, September 26th, 2024

The datalist element on iOS

The datalist element is good. It was a bit bumpy there for a while, but browser implementations have improved over time. Now it’s by far the simplest and most robust way to create an autocompleting combobox widget.

Hook up an input element with a datalist element using the list and id attributes and you’re done. You can even use a bit of Ajax to dynamically update the option elements inside the datalist in response to the user’s input. The browser takes care of all the interaction. If you try to roll your own combobox implementation, it’s almost certainly going to involve a lot of JavaScript and still probably won’t account for all use cases.

Safari on iOS—and therefore all browsers on iOS—didn’t support datalist for quite a while. But once it finally shipped, it worked really nicely. The options showed up just like automplete suggestions above the keyboard.

But that broke a while back.

The suggestions still appeared, but if you tapped on one of them, nothing happened. The input element didn’t get updated. You had to tap on a little downward arrow inside the input in order to see the list of options.

That was really frustrating for anybody on iOS using The Session. By far the most common task on the site is searching for a tune, something that’s greatly (progressively) enhanced with a dynamically-updating datalist.

I just updated to iOS 18 specifically to see if this bug has been fixed, and it has:

Fixed updating the input value when selecting an option from a datalist element.

Hallelujah!

But now there’s some additional behaviour that’s a little weird.

As well as showing the options in the autocomplete list above the keyboard, Safari on iOS—and therefore all browsers on iOS—also pops up the options as a list (as if you had tapped on that downward arrow). If the list is more than a few options long, it completely obscures the input element you’re typing into!

I’m not sure if this is a bug or if it’s the intended behaviour. It feels like a bug, but I don’t know if I should file something.

For now, I’ve updated the datalist elements on The Session to only ever hold three option elements in order to minimise the problem. Seeing as the autosuggest list above the keyboard only ever shows a maximum of three suggestions anyway, this feels like a reasonable compromise.

Wednesday, September 25th, 2024

An Abridged History of Safari Showstoppers - Webventures

In an earlier era, startups could build on the web and, if one browser didn’t provide the features they needed, they could just recommend that their users try a better one. But that’s not possible on iOS.

I’m extremly concerned about the newest bug in iOS 18:

On-screen keyboard does not show up for installed web apps (PWAs) when focusing a text input of any kind

Whaa? That’s just shockingly dreadful!

Thursday, June 27th, 2024

WP2 - The requirement for browsers operating on iOS devices to use Apple’s WebKit browser engine [PDF]

The Competition & Markets Authority brings receipts:

The requirement that all browsers on the iOS operating system use a specific version of the WebKit browser engine controlled by Apple, means that there is no competition between browser engines on the platform. Browser vendors cannot switch to an alternative browser engine or make changes to the version of WebKit used on iOS. Similarly, consumers are unable to switch to a browser based on an alternative browser engine. We consider that the lack of competitive pressure is likely to reduce Apple’s incentives to improve WebKit.

Wednesday, June 12th, 2024

Web App install API

My bug report on Apple’s websites-in-the-dock feature on desktop has me thinking about how starkly different it is on mobile.

On iOS if you want to add a website to your home screen, good luck. The option is buried within the “share” menu.

First off, it makes no sense that adding something to your homescreen counts as sharing. Secondly, how is anybody supposed to know that unless they’re explicitly told.

It’s a similar situation on Android. In theory you can prompt the user to install a progressive web app using the botched BeforeInstallPromptEvent. In practice it’s a mess. What it actually does is defer the installation prompt so you can offer it a more suitable time. But it only works if the browser was going to offer an installation prompt anyway.

When does Chrome on Android decide to offer the installation prompt? It’s a mix of required criteria—a web app manifest, some icons—and an algorithmic spell determined by the user’s engagement.

Other browser makers don’t agree with this arbitrary set of criteria. They quite rightly say that a user should be able to add any website to their home screen if they want to.

What we really need is an installation API: a way to programmatically invoke the add-to-homescreen flow.

Now, I know what you’re going to say. The security and UX implications would be dire. But this should obviously be like geolocation or notifications, only available in secure contexts and gated by user interaction.

Think of it like adding something to the clipboard: it’s something the user can do manually, but the API offers a way to do it programmatically without opening it up to abuse.

(I’d really love it if this API also had a declarative equivalent, much like I want button type="share" for the Web Share API. How about button type="install"?)

People expect this to already exist.

The beforeinstallprompt flow is an absolute mess. Users deserve better.

Tuesday, April 16th, 2024

Pickin’ dates on iOS

This is a little follow-up to my post about web components for date inputs.

If you try the demo on iOS it doesn’t work. There’s nothing stopping you selecting any date.

That’s nothing to do with the web components. It turns out that Safari on iOS doesn’t support min and max on date inputs. This is also true of any other browser on iOS because they’re all just Safari in a trenchcoat …for now.

I was surprised — input type="date" has been around for a long time now. I mean, it’s not the end of the world. You’d have to do validation on inputted dates on the server anyway, but it sure would be nice for the user experience of filling in forms.

Alas, it doesn’t look like this is something on the interop radar.

What really surprised me was looking at Can I Use. That shows Safari on iOS as fully supporting date inputs.

Maybe it’s just semantic nitpickery on my part but I would consider that the lack of support for the min and max attributes means that date inputs are partially supported.

Can I Use gets its data from here. I guess I need to study the governance rules and try to figure out how to submit a pull request to update the currently incorrect information.

Wednesday, March 6th, 2024

WebKit Features in Safari 17.4 | WebKit

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.

Sunday, March 3rd, 2024

Apple backs off killing web apps, but the fight continues - Open Web Advocacy

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.

Tuesday, February 27th, 2024

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.

Saturday, February 17th, 2024

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.

Rotten Apple

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 [email protected], 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.

Thursday, February 15th, 2024

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.

Tuesday, January 30th, 2024

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.

Tuesday, May 16th, 2023

Thursday, February 23rd, 2023

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.

Wednesday, February 22nd, 2023

Audio Session API Explainer

Jen pointed me to this proposal, which should help smooth over some of the inconsistencies I documented in iOS when it comes to the Web Audio API.

I’ve preemptively add this bit of feature detection to The Session:

if ('audioSession' in navigator) { navigator.audioSession.type = "playback"; }

Web Audio API update on iOS

I documented a weird bug with web audio on iOS a while back:

On some pages of The Session, as well as the audio player for tunes (using the Web Audio API) there are also embedded YouTube videos (using the video element). Press play on the audio player; no sound. Press play on the YouTube video; you get sound. Now go back to the audio player and suddenly you do get sound!

It’s almost like playing a video or audio element “kicks” the browser into realising it should be playing the sound from the Web Audio API too.

This was happening on iOS devices set to mute, but I was also getting reports of it happening on devices with the sound on. But it’s that annoyingly intermittent kind of bug that’s really hard to reproduce consistently. Sometimes the sound doesn’t play. Sometimes it does.

I found a workaround but it was really hacky. By playing a one-second long silent mp3 file using audio, you could “kick” the sound into behaving. Then you can use the Web Audio API and it would play consistently.

Well, that’s all changed with the latest release of Mobile Safari. Now what happens is that the Web Audio stuff plays …for one second. And then stops.

I removed the hacky workaround and the Web Audio API started behaving itself again …but your device can’t be set to silent.

The good news is that the Web Audio behaviour seems to be consistent now. It only plays if the device isn’t muted. This restriction doesn’t apply to video and audio elements; they will still play even if your device is set to silent.

This descrepancy between the two different ways of playing audio is kind of odd, but at least now the Web Audio behaviour is predictable.

You can hear the Web Audio API in action by going to any tune on The Session and pressing the “play audio” button.

Sunday, February 19th, 2023

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?