Started off supporting Chrome, but realized that Safari was 40% of my traffic.... and now pulling my hair out, trying to support both... How do you guys deal with this?

General
1

To add insult to injury, I later realized that even “Chrome” on iOS devices, pretty much “acts” just like Safari - and in some cases, was more problematic - at least for my web-app.

Coming from developing an Android app (which can also lead you down device compatibility rabbit-holes), it’s been hellish trying to support the different browsers on desktop (portrait mode, & landscape mode monitors), Android devices, and iOS devices, on which those same browsers may act differently.

I finally adopted the following approach:

Scrap huge amounts of work, and revert to a previous commit, and make sure that I am getting my initial audience 100% right. That is, my Desktop users and Android Chrome users.

Of course, I can’t neglect 40% of my traffic, so I am heavily considering redirecting those users to an “iOS version” of my web-app. Do people even do this? Is this even a thing?

The other option would be countless “if (isIOS) { //do this instead }” checks, and that could get ugly…

This is my first serious web-app, and boy… what a rude awakening! :sweat_smile:

Any advice would be greatly appreciated!

EDIT:

As someone mentioned in the comments, I should probably state the specific issues. So currently, they’re related to touch-events / long-presses, and the ability to bring the focus into the textbox on Apple devices automatically (which is apparently a no-go) and any sort of mitigation has given me broken functionality back on Android.

The app in question is at https://postbaby.org

EDIT:

And as someone else mentioned, I should have started off using a modern JS framework…

2

What Safari-related problems are you running into, and what sort of frontend do you use?

3

Feng said:
What Safari-related problems are you running into, and what sort of frontend do you use?

That’s part of the problem. It’s just HTML/CSS/JS.

Also, I did not use pointer events. I ended up using both click and touch events to handle different desktops, and touch-devices, separately.

Current issues are related to making sure that upon new “sticky-note” creation, the edit box gets programmatic focus on iOS devices, but is currently requiring an extra double tap, which ruins the UX, and is also having the unintended effect of abruptly closing the text box on Android now…

Of course, some of this is implementation dependent, and I have to dig further.

4

@Reilly
Put autoFocus on the sticky note input?

5

Jin said:
@Reilly
Put autoFocus on the sticky note input?

I think the issue is that if the input field is part of a form or a modal that appears dynamically (e.g., via JavaScript), Safari requires a user interaction (like a tap) before allowing the autofocus to work.

6

@Reilly
You should be able to call .focus() on the input after it is added and visible.

7

Merlin said:
@Reilly
You should be able to call .focus() on the input after it is added and visible.

Not OP but I’ve had similar issues with Safari / iOS where apparently it goes against their design principles to open up the keyboard on .focus() for input fields. I swear I’ve tried a lot of things but it seems to be just a limitation.

8

@Reilly

modal

Pseudo or html-dialog?

9

@Reilly

…just HTML/CSS/JS.

lol

10

Chrome/FF etc on iOS all operate as Safari on iOS because Apple has locked down browser rendering/operations on their devices. Welcome to the world of Apple.

Also, supporting both isn’t that bad unless you’re trying to use some modern feature that’s been released in the last 2 years. Then yes… you’re going to be in pain especially on mobile iOS devices.

11

@Nico
requestIdleCallback is almost 10 years old.

12

@Nico
Not quite true, Firefox on iOS doesn’t have all of the features of Safari for some reason. But the dev team is in the middle of a refactor currently so hopefully things will improve soon.

Dynamic viewport heights are one example of FF lagging behind a little bit.

13

@Rey
https://firefox-source-docs.mozilla.org/overview/ios.html

FF uses a webview on iOS - this is part of why it lags behind. Webviews, as far as I recall (it’s been a few years) lag at least 1-2 versions behind the latest release. This is one reason why some alternative browsers on iOS appear to have the same or similar issues to Safari.

14

This problem has persisted throughout the almost 30 years of web development we’ve had so far :sweat_smile: welcome to the team!

to this day you can give me nightmares by whispering ‘IE 5 for mac’

15

caniuse.com study up.

16

Thorn said:
caniuse.com study up.

thank you!

17

Chrome on iOS is Safari under the hood. It’s all Safari on iOS.

18

If you do things right, there’s almost nothing you need to do. Stick to standards and everything will work across browsers.

19

Emerson said:
If you do things right, there’s almost nothing you need to do. Stick to standards and everything will work across browsers.

Standards like Autofocus attribute? 9 years old, not supported on Safari mobile.

:selection styles? 15 years old, not supported on Safari mobile.

CSS cursors? 20 years old… Not supported on Safari mobile…

Of course there’s also “standards” like @page, rel=“prefetch”, a lot of deeper level APIs - not even supported on Safari desktop let alone mobile.

Browser standards have always been a joke; we’re in a better age now than the “can’t even agree how we measure size” and “half a dozen vendor prefixes for everything”, but it’s still very easy to find things that mess up across browsers, even stuff we’ve all been using for years.

20

Emerson said:
If you do things right, there’s almost nothing you need to do. Stick to standards and everything will work across browsers.

This is not even remotely true. What the hell is this?