I really appreciate, and will buy a beverage of choice anytime for, anyone who tries to go down these paths, including OP, whether with web or desktop technology.
Painstakingly mimicking, then eventually improving on, Apple's interactivity/motion design is IMHO one of those things that could make open-source desktops a superior option to both Windows and Apple from a mainstream user viewpoint, and those possibilities should be cherished.
Someone was trying to raise money and find engineering time for the effort (but, no longer):
> We recognize that our rate of visible updates has slowed to the point where it no longer makes sense to continue billing sponsors of this project.
> But at the moment, our lead developer is working on Linux touchpad improvements at less than 1/8 capacity. This means that progress is slow as he can only spend half a week per month on improvements.
I was forced to use Apple laptops (M1, M2) for work the past years and I really don't understand what people find so great about mac touchpads compared to the one of at least average laptop with Linux.
I did not really notice a difference or when i noticed some it was in defavor of the Mac. Like precise selecting/drag and drop is marginally harder, you gave to put more force for the physical click, and I find the tap to click to be easier, more reactive, faster "click to effect" on my linux laptops.
Iām not sure why people always praise Apple on interaction Design. I just got a MacBook again, and thereās little things that just drive me crazy: when you use tap-to-drag on macOS, thereās a delay when releasing the drag (presumably so u can continue dragging by putting the finger back down). This doesnāt exist in windows or Linux, so when working with multiple OSs, one keeps mis-dragging, making a big mess every time. But there doesnāt seem to be a setting for it, either.
Or why does Apple insist on having a non-standard keyboard in Germany, it doesnāt even have characters like ~{}[] on it, only accessible via hidden key combinations that donāt match the standard keyboard. Oh and the US keyboard is only available in the Apple Store, where everything is 200ā¬ more expensive. Just like, why mess with basic interaction design in a way thatās really unrefined and infuriating.
Something being unfamiliar doesn't make it worse. Or better necessarily, but it seems noteworthy that your frustration is with a feature designed to make it possible to drag draggable things around without losing them if your finger leaves the trackpad for an instant.
> Or why does Apple insist on having a non-standard keyboard in Germany,
Precisely. I just switched to the german layout, which has some amusing consequences for words like layout, but: []{}~, looks like everything is where Wikipedia says that a T1 German layout should put things. What's the complaint exactly? Because it's not that the keyboard is nonstandard, is it?
If you'd rather use another layout, you very easily can, right? I mean, I just did.
Not it does not. On the default German MacOs keyboard, keys are moved compared to the standard layout, in particular the braces and brackets (used for you know, coding):
5 6 7 8 9 0 Ć - unmodified
[ ] | | { } ā - with option on Mac
{ [ ] } - with alt on windows
The tilde is also moved, and the at-sign.
You can claim "change is good", "why do you need to show keys on the keyboard, just memorize them" [1] and "you're holding it wrong", but then why at the same time fawn over Apple's supposedly super-refined interaction design.
[1] my wife, moving from linux/english to MacOs/German for work, actually uses a desktop background of the full keyboard layout, to help her find the hidden keys.
> it seems noteworthy that your frustration is with a feature designed to make it possible to drag draggable things around without losing them if your finger leaves the trackpad for an instant.
I agree with your point that "unfamiliar" is not "better" or "worse". But I will observe that much engineering, and much pushing of new mental models on users, has gone into working around the unwillingness to have mouse buttons.
With no mouse buttons: "double-tap-and-drag, release, possible delay on release for possible finger repositioning"
With mouse buttons: "click, drag, release"
Both models can work, but I marvel at the proposition of preferring the former.
Based both on macOS documentation and on the experiences of people who use macOS:
> without Drag Lock: Double-tap an item, then drag it without lifting your finger after the second tap; dragging stops immediately when you lift your finger.
> with Drag Lock: Double-tap an item, then drag it without lifting your finger after the second tap; dragging continues when you lift your finger, and stops only when you tap the trackpad once.
> three finger drag: Drag an item with three fingers; dragging stops immediately when you lift your fingers.
It may well be that with current mac systems that have "force touch", it might be possible (or necessary) to replace some of those steps with "press hard". I stand by my statement that this is a lot of engineering and a lot of user adaptation in order to not have mouse buttons.
> To drag and drop something on the Mac, you: click it, drag it, and release it.
It's not true. On windows/linux:
tap, release, tap, drag, release
On MacOs:
tap, release, tap, drag, release, wait
When moving back and forth between windows/linux and MacOs, and after working for 20 years with windows, that "wait" isn't built in into finger-memory. So if you "move on" with the next actions, it means that you'll drag whatever you were dragging to the next button.
FWIW, that is a thing that Apple actually gets wrong a bit across the world.
The default layout for Macs sold in Poland is also nonsensical ā it's "technically" more correct, and maps closer to what the typewriters looked like (I think?); but it is a layout that literally nobody else uses.
I don't think I could easily find a non-Apple keyboard with that layout in Poland if I tried.
I just tested the German ā Standard layout on a Mac, it's the first one you indicate. Apple calls right-ā„ the Compose key, not AltGr, but works the same way, other than being transposed with the Command key from the familiar Windows style of layout.
There's also a keyboard layout just called German, maybe that one works the way you refer to? But surely it's not too much to ask that someone select the keyboard style they're accustomed to using?
Thinking about what feels different here, there are a couple of things that could be fun to implement:
- On iOS, opening and closing an app also scales and blurs/unblurs the wallpaper at the same time that itās animating the app entering/exiting the foreground.
- Also, years ago, Apple added a very subtle 3D effect to the Home Screen. Essentially, when youāre looking at the Home Screen, as you tilt the phone, the icons and widgets move a few pixels in the direction of the tilt, which makes it feel like theyāre popping out of the screen a little. To study the effect in detail, you can just look at the edge of an icon or the text below an icon and tilt the screen around and notice how it moves relative to the background image. Itās meant to be a very subtle effect, not some garishly dramatic effect.
I did that parallax background effect on a web site many years ago. Unfortunately (but understandably) accelerometer data is now behind a permission prompt on the web. Displaying a garish modal permission prompt so that you can do a subtle background transition doesn't make sense as a tradeoff.
I actually added the parallax effect back in my version of iOS 7 on the web (2013). It was meant for people to check the new design out on their phones before upgrading. You could even open/zoom into folders. Spend quite too much time on it, but it was quite novel back then.
https://streamable.com/pki7ux
That linked discussion doesn't say it is broken all the time (which your comment strongly implies to anyone who doesn't read the link)... and I had verified the parallax effect was working fine earlier today when I made my comment.
I hadn't rebooted my phone in quite awhile, so I'm not sure what the conditions are for that bug, but I think that discussion is wrong that rebooting is the only way to get it working again. I had surely accessed the App Library since the last reboot at some point, and yet parallax was working fine. But I can confirm that it does break (at least temporarily) after accessing the App Library.
Really nice, and I say that as someone that built a quite popular mobile web framework that duplicated a lot of iOS UI (Ionic). One thing I noticed is the swipe gestures arenāt working. This is all very doable on the web which many people donāt believe. Itās pretty wild what the web platform is capable of, the gap is absolutely with web devs who donāt know how to put the many modern APIs and capabilities into practice.
In my experience the gap is also about supporting a wide range of users and their old or not so powerful devices. Sure polyfills do the job of support but at the cost of bundle size and compute, which may degrade the experience for that particular audience. My number one moto in web app design and development is KISS.
And the amount of fine-tuning done on ios for the various gestures is quite astounding. Re-creating them using browser APIs isn't really entire possible.
You can extremely close if not imperceptibly there for a lot of interactions. The bigger issue is actually mobile browser āchromeā getting in the way (i.e. baked in gestures in mobile browsers)
Remember when optimizing sites for mobile was new and everyones first impulse was to unironically turn their site into a fake iOS app? Those were the days.
The biggest contributor to this was jQuery Mobile. Surprisingly, the "ThemeRoller" is still up, despite the project being discontinued. Quite a fun trip down memory lane.
Don't laugh, but we still have a big software solution based on jQuery Mobile up and running, used daily by hundreds of users on tablets and smartphones, and getting new features every few weeks.
(yes, a successor is planned, but it will be a huge amount of work)
I kind of miss the days where building a mobile app was just plopping giant widgets on a screen, and we didn't need giant figma files and design languages.
I don't, however, miss dealing with the 300ms click delay.
What bothers me more is that those giant Figma files don't have anything special about the design anymore. Very often they're just using some uncanny-valley version of Material Design. Companies spend a lot of time reinventing almost the exact same wheel for almost no benefit at all. So much wasted potential.
ā wow there sure are a lot of subleties in iOS animations and interactions that seem very _very_ hard to replicate
ā why is my brain _so good_ and noticing those little things?! I shouldn't be able to notice that the battery indicator is too thick; that the squircles are not continnous, or that the curves on all animations are just ever so slightly off.
Tap on the button line. AFAIK thereās no such a think as back button in iOS. Apps can display one from the SDK but donāt if no need. Going to the homescreen is done by swiping from bottom on iOS. This site doesnāt handle swipe and use the bottom bar visual indicator as a home button like in the oldā days. As a long time user I find it evident but totally get that itās not obvious for those not accustomed
I normally use iOS, but recently got a Pixel as a secondary phone.
Whenever I try to use the Pixel and swipe ābackā or āforwardā (left and right), often times something I wasnāt expecting happens, I think my mental model is missing/incorrect of what ābackā is on Android.
Fun anecdote, firefox on iOS is still broken years after its launch.
If you play a video in horizontal mode, then go back to horizontal mode the bottom bar vanishes and never comes back, meaning to actually manage tabs you have to keep your iphone horizontal.
Interesting bug: if you swipe on screen with the mouse button pressed and slide of screen to release the mouse button the on screen swipe action stays attached to the mouse cursor. Only sort of a bug because it's only because it runs in a web page vs on an actual phone. Still would be interested in how to fix that in general.
Overall it looks cool, I'm a native mobile app guy so I'm always skeptical about mobile web. This doesn't change that for me but I can see growth in the web platform for mobile.
Itās a common ui bug in all software, happens due to release event firing outside of controlling element. People donāt know about pointer grab, which should be used in drag operations, and frameworks donāt even inform nor encourage it. Modern ui/ux school.
From a design perspective, this is really impressive. However, I noticed a few basic functionalities seem to be missingāat least for meālike the ability to return to the home screen from an app.
On a related note, Try Galaxy (https://news.ycombinator.com/item?id=35886033) is another fascinating project. It offers a web-based One UI clone, and when installed as a PWA, the experience becomes even more seamless.
There's a really specific behaviour that iOS has with its collapsible top bars that I've been trying off and on to nail with CSS for ages as a little puzzle, but for some reason it's always not quite right. As you scroll down or up, the bar remains perfectly in place and only starts moving up once it's fully revealed or down once it's fully gone. There should be a way to do it with `position: sticky` but whether you use some javascript or not, it's always slightly jerky or wrong, especially on safari. Apple really does pay attention to these little things in ways others don't.
And then they go and release that recent photos app update and make me seriously want to leave their ecosystem completely.
I also dislike the updated Photos app, I think itās because of lots of small things that add up. What you dislike?
Largest one for me is probably playback behavior in full screen is strange. You start playing a video, it goes full screen, then you tap on it and it resizes to slightky smaller size.
We have come full circle. Kids these days forget that the official application framework for iPhone OS in 2007 was a bunch of HTML/CSS/images that mimicked iPhone OS UI as a web application (basically poor man's PWA).
The jailbreak community reverse-engineered iPhone headers and developed an unofficial toolchain based on llvm-gcc right away to build iPhone applications and they had an app store which still lives as Cydia (saurik et al) before Steve believed in that. Apple only threw the towel half a year later with an official beta SDK after the product-market-fit was so strong that they had no choice.
Does anyone else remember the online Userās Manual for early iPhones? It was web-based, but had a full JavaScript reimplementation of UINavigationController, UIScrollView, and UITableView.
I always suspected it was part of some bigger project that never panned out (maybe just prototyping?).
I once did something like this for Nokia when their phones moved to Windows Phone. The devil is in the details, and 90% of the time was spent mimicking the animations and transitions.
It's impressive, but it's completely broken on Macs with a normal mouse connected and Firefox, because scrollbars appear everywhere and they break the layout.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... is a parallel saga for mimicking the macOS touchpad behavior on Linux; it's been a full 8 years in the making. It's so much more than acceleration settings!
I really appreciate, and will buy a beverage of choice anytime for, anyone who tries to go down these paths, including OP, whether with web or desktop technology.
Painstakingly mimicking, then eventually improving on, Apple's interactivity/motion design is IMHO one of those things that could make open-source desktops a superior option to both Windows and Apple from a mainstream user viewpoint, and those possibilities should be cherished.
Someone was trying to raise money and find engineering time for the effort (but, no longer):
> We recognize that our rate of visible updates has slowed to the point where it no longer makes sense to continue billing sponsors of this project.
> But at the moment, our lead developer is working on Linux touchpad improvements at less than 1/8 capacity. This means that progress is slow as he can only spend half a week per month on improvements.
https://news.ycombinator.com/item?id=39607747
I was forced to use Apple laptops (M1, M2) for work the past years and I really don't understand what people find so great about mac touchpads compared to the one of at least average laptop with Linux.
I did not really notice a difference or when i noticed some it was in defavor of the Mac. Like precise selecting/drag and drop is marginally harder, you gave to put more force for the physical click, and I find the tap to click to be easier, more reactive, faster "click to effect" on my linux laptops.
One of the mayor things to hate is that you need to hold down the trackpad to do any stuff
System Settings > Trackpad > "Tap to click" fixes that.
Try out the other options there too: two-finger tap for right-click, two-finger drag for scroll, and three-finger drag window by title bar.
Also the default speed is useful for Gen X or older. Gotta max out pointer speed and keyboard repeat rate when you buy a new Mac.
Battery life and trackpad is why I've been buying Apple for like 20 years now.
All other hardware companies have been doing a mediocre job on these two features.
I've tried looking up the source code, but this seems to be the CEO of a security company blogging about their closed source side project.
Iām not sure why people always praise Apple on interaction Design. I just got a MacBook again, and thereās little things that just drive me crazy: when you use tap-to-drag on macOS, thereās a delay when releasing the drag (presumably so u can continue dragging by putting the finger back down). This doesnāt exist in windows or Linux, so when working with multiple OSs, one keeps mis-dragging, making a big mess every time. But there doesnāt seem to be a setting for it, either.
Or why does Apple insist on having a non-standard keyboard in Germany, it doesnāt even have characters like ~{}[] on it, only accessible via hidden key combinations that donāt match the standard keyboard. Oh and the US keyboard is only available in the Apple Store, where everything is 200ā¬ more expensive. Just like, why mess with basic interaction design in a way thatās really unrefined and infuriating.
Something being unfamiliar doesn't make it worse. Or better necessarily, but it seems noteworthy that your frustration is with a feature designed to make it possible to drag draggable things around without losing them if your finger leaves the trackpad for an instant.
> Or why does Apple insist on having a non-standard keyboard in Germany,
This:
https://www.apple.com/shop/product/MXCL3D/A/magic-keyboard-u...
Appears to my eye to match this:
https://en.wikipedia.org/wiki/German_keyboard_layout
Precisely. I just switched to the german layout, which has some amusing consequences for words like layout, but: []{}~, looks like everything is where Wikipedia says that a T1 German layout should put things. What's the complaint exactly? Because it's not that the keyboard is nonstandard, is it?
If you'd rather use another layout, you very easily can, right? I mean, I just did.
> This:
> https://www.apple.com/shop/product/MXCL3D/A/magic-keyboard-u...
> Appears to my eye to match this:
> https://en.wikipedia.org/wiki/German_keyboard_layout
Not it does not. On the default German MacOs keyboard, keys are moved compared to the standard layout, in particular the braces and brackets (used for you know, coding):
The tilde is also moved, and the at-sign.You can claim "change is good", "why do you need to show keys on the keyboard, just memorize them" [1] and "you're holding it wrong", but then why at the same time fawn over Apple's supposedly super-refined interaction design.
[1] my wife, moving from linux/english to MacOs/German for work, actually uses a desktop background of the full keyboard layout, to help her find the hidden keys.
> it seems noteworthy that your frustration is with a feature designed to make it possible to drag draggable things around without losing them if your finger leaves the trackpad for an instant.
I agree with your point that "unfamiliar" is not "better" or "worse". But I will observe that much engineering, and much pushing of new mental models on users, has gone into working around the unwillingness to have mouse buttons.
With no mouse buttons: "double-tap-and-drag, release, possible delay on release for possible finger repositioning"
With mouse buttons: "click, drag, release"
Both models can work, but I marvel at the proposition of preferring the former.
I'm not sure what you're talking about here. To drag and drop something on the Mac, you: click it, drag it, and release it.
Are you... under the impression that Macs don't have, clicking?
Based both on macOS documentation and on the experiences of people who use macOS:
> without Drag Lock: Double-tap an item, then drag it without lifting your finger after the second tap; dragging stops immediately when you lift your finger.
> with Drag Lock: Double-tap an item, then drag it without lifting your finger after the second tap; dragging continues when you lift your finger, and stops only when you tap the trackpad once.
> three finger drag: Drag an item with three fingers; dragging stops immediately when you lift your fingers.
It may well be that with current mac systems that have "force touch", it might be possible (or necessary) to replace some of those steps with "press hard". I stand by my statement that this is a lot of engineering and a lot of user adaptation in order to not have mouse buttons.
> To drag and drop something on the Mac, you: click it, drag it, and release it.
It's not true. On windows/linux:
On MacOs: When moving back and forth between windows/linux and MacOs, and after working for 20 years with windows, that "wait" isn't built in into finger-memory. So if you "move on" with the next actions, it means that you'll drag whatever you were dragging to the next button.It's simply a very unrefined interaction.
FWIW, that is a thing that Apple actually gets wrong a bit across the world.
The default layout for Macs sold in Poland is also nonsensical ā it's "technically" more correct, and maps closer to what the typewriters looked like (I think?); but it is a layout that literally nobody else uses.
I don't think I could easily find a non-Apple keyboard with that layout in Poland if I tried.
Old Italian Macs used a classical QZERTY keyboard, like typewriters, but no other computer keyboard uses that layout.
Normal computer keyboards use QWERTY (plus some accented letters). Luckily, Apple switched to that layout for Italian keyboards many years ago.
What they mean is that on a standard german keyboard layout to type []{}~ one would press
While on an Apple keyboard you useI just tested the German ā Standard layout on a Mac, it's the first one you indicate. Apple calls right-ā„ the Compose key, not AltGr, but works the same way, other than being transposed with the Command key from the familiar Windows style of layout.
There's also a keyboard layout just called German, maybe that one works the way you refer to? But surely it's not too much to ask that someone select the keyboard style they're accustomed to using?
Donāt confuse āstandardā with āwhat IBM and Microsoft implemented in the 80sā.
Thinking about what feels different here, there are a couple of things that could be fun to implement:
- On iOS, opening and closing an app also scales and blurs/unblurs the wallpaper at the same time that itās animating the app entering/exiting the foreground.
- Also, years ago, Apple added a very subtle 3D effect to the Home Screen. Essentially, when youāre looking at the Home Screen, as you tilt the phone, the icons and widgets move a few pixels in the direction of the tilt, which makes it feel like theyāre popping out of the screen a little. To study the effect in detail, you can just look at the edge of an icon or the text below an icon and tilt the screen around and notice how it moves relative to the background image. Itās meant to be a very subtle effect, not some garishly dramatic effect.
I did that parallax background effect on a web site many years ago. Unfortunately (but understandably) accelerometer data is now behind a permission prompt on the web. Displaying a garish modal permission prompt so that you can do a subtle background transition doesn't make sense as a tradeoff.
I'm a bit confused, what permissions would this animation require?
You donāt want every website in the world to have unfettered access to your accelerometer - way too much sensitive info can be grokked from that.
Accelerometer data from the phone in order to determine the position for the parallax effect.
I actually added the parallax effect back in my version of iOS 7 on the web (2013). It was meant for people to check the new design out on their phones before upgrading. You could even open/zoom into folders. Spend quite too much time on it, but it was quite novel back then. https://streamable.com/pki7ux
The parallax background effect has actually been broken for a few years now
https://forums.macrumors.com/threads/home-screen-parallax-ef...
That linked discussion doesn't say it is broken all the time (which your comment strongly implies to anyone who doesn't read the link)... and I had verified the parallax effect was working fine earlier today when I made my comment.
I hadn't rebooted my phone in quite awhile, so I'm not sure what the conditions are for that bug, but I think that discussion is wrong that rebooting is the only way to get it working again. I had surely accessed the App Library since the last reboot at some point, and yet parallax was working fine. But I can confirm that it does break (at least temporarily) after accessing the App Library.
It does have the blur thing when you slide over the widget screen.
That's disappointing if it's removed now, I used to really like that on my old phone!
I didnāt say it was gone! Just that Apple added it years ago.
The website this post is about doesnāt implement the feature.
You realize that quite a few people have disabled that 'subtle 3D effect' because they found it annoying?
Really nice, and I say that as someone that built a quite popular mobile web framework that duplicated a lot of iOS UI (Ionic). One thing I noticed is the swipe gestures arenāt working. This is all very doable on the web which many people donāt believe. Itās pretty wild what the web platform is capable of, the gap is absolutely with web devs who donāt know how to put the many modern APIs and capabilities into practice.
> modern APIs
In my experience the gap is also about supporting a wide range of users and their old or not so powerful devices. Sure polyfills do the job of support but at the cost of bundle size and compute, which may degrade the experience for that particular audience. My number one moto in web app design and development is KISS.
Iām glad so see ionic have a browser support page https://ionicframework.com/docs/reference/browser-support and will probably give it a try someday.
Itās usually the difference between having a low-level api and high-level api. iOS gives a lot āfor freeā.
Creating stuff from scratch is not a fun experience
>Creating stuff from scratch is not a fun experience
It's one of those things that I love the idea of doing. I'd love to create my own look and feel and design.
But day to day at my job I just need a dang button that does the thing or transition between things, a spinner or ... whatever.
And the amount of fine-tuning done on ios for the various gestures is quite astounding. Re-creating them using browser APIs isn't really entire possible.
You can extremely close if not imperceptibly there for a lot of interactions. The bigger issue is actually mobile browser āchromeā getting in the way (i.e. baked in gestures in mobile browsers)
> Creating stuff from scratch is not a fun experience
I'd have to say that I completely disagree here - it's one of the things I get most fun out of, even at work.
Remember when optimizing sites for mobile was new and everyones first impulse was to unironically turn their site into a fake iOS app? Those were the days.
The biggest contributor to this was jQuery Mobile. Surprisingly, the "ThemeRoller" is still up, despite the project being discontinued. Quite a fun trip down memory lane.
https://themeroller.jquerymobile.com
Don't laugh, but we still have a big software solution based on jQuery Mobile up and running, used daily by hundreds of users on tablets and smartphones, and getting new features every few weeks.
(yes, a successor is planned, but it will be a huge amount of work)
I kind of miss the days where building a mobile app was just plopping giant widgets on a screen, and we didn't need giant figma files and design languages.
I don't, however, miss dealing with the 300ms click delay.
What bothers me more is that those giant Figma files don't have anything special about the design anymore. Very often they're just using some uncanny-valley version of Material Design. Companies spend a lot of time reinventing almost the exact same wheel for almost no benefit at all. So much wasted potential.
Take me back
I still see the fake, 2010 era mobile banners bases on my device' user agent
No.
[flagged]
My main takeaways from this are:
ā wow there sure are a lot of subleties in iOS animations and interactions that seem very _very_ hard to replicate
ā why is my brain _so good_ and noticing those little things?! I shouldn't be able to notice that the battery indicator is too thick; that the squircles are not continnous, or that the curves on all animations are just ever so slightly off.
Loosely related, there are frameworks for recreating native UI for mobile apps written in JS, e.g: https://framework7.io/
> free and open source framework to develop mobile, desktop or web apps with native look and feel
Here is a demo page of the individual ui widgets for iOS:
https://framework7.io/kitchen-sink/core/?theme=ios
There's another great one called Konsta UI: https://konstaui.com/ . Live demo here: https://konstaui.com/kitchen-sink/react/dist/
yup, also used the excellent swiper.js by the same guy back in 2013 for a homescreen clone.
Sproutcore.js was the framework used for early day iCloud. It was super snappy and got implemented for the Web UI on Transmission.
Authentic in so far as there's no back button and using it in Android backs you out of the whole site!
Tap on the button line. AFAIK thereās no such a think as back button in iOS. Apps can display one from the SDK but donāt if no need. Going to the homescreen is done by swiping from bottom on iOS. This site doesnāt handle swipe and use the bottom bar visual indicator as a home button like in the oldā days. As a long time user I find it evident but totally get that itās not obvious for those not accustomed
I normally use iOS, but recently got a Pixel as a secondary phone. Whenever I try to use the Pixel and swipe ābackā or āforwardā (left and right), often times something I wasnāt expecting happens, I think my mental model is missing/incorrect of what ābackā is on Android.
I don't even know how to go back on ios so I am stuck on firefox.
Fun anecdote, firefox on iOS is still broken years after its launch.
If you play a video in horizontal mode, then go back to horizontal mode the bottom bar vanishes and never comes back, meaning to actually manage tabs you have to keep your iphone horizontal.
I like Firefox but with mobile they do seem to sit on pretty major bugs for multiple years
On Android it is a pretty normal experience, I haven't found any bugs yet.
Interesting bug: if you swipe on screen with the mouse button pressed and slide of screen to release the mouse button the on screen swipe action stays attached to the mouse cursor. Only sort of a bug because it's only because it runs in a web page vs on an actual phone. Still would be interested in how to fix that in general.
Overall it looks cool, I'm a native mobile app guy so I'm always skeptical about mobile web. This doesn't change that for me but I can see growth in the web platform for mobile.
Itās a common ui bug in all software, happens due to release event firing outside of controlling element. People donāt know about pointer grab, which should be used in drag operations, and frameworks donāt even inform nor encourage it. Modern ui/ux school.
From a design perspective, this is really impressive. However, I noticed a few basic functionalities seem to be missingāat least for meālike the ability to return to the home screen from an app.
On a related note, Try Galaxy (https://news.ycombinator.com/item?id=35886033) is another fascinating project. It offers a web-based One UI clone, and when installed as a PWA, the experience becomes even more seamless.
Speaking of web-based UI clones, I canāt resist giving an honorable mention to Puter (https://news.ycombinator.com/item?id=33838179) and DaedalOS (https://news.ycombinator.com/item?id=38830132). I believe they are exceptional projects that deserve recognition.
I remember that Try Galaxy was previously called iTest.
There's a really specific behaviour that iOS has with its collapsible top bars that I've been trying off and on to nail with CSS for ages as a little puzzle, but for some reason it's always not quite right. As you scroll down or up, the bar remains perfectly in place and only starts moving up once it's fully revealed or down once it's fully gone. There should be a way to do it with `position: sticky` but whether you use some javascript or not, it's always slightly jerky or wrong, especially on safari. Apple really does pay attention to these little things in ways others don't.
And then they go and release that recent photos app update and make me seriously want to leave their ecosystem completely.
I also dislike the updated Photos app, I think itās because of lots of small things that add up. What you dislike?
Largest one for me is probably playback behavior in full screen is strange. You start playing a video, it goes full screen, then you tap on it and it resizes to slightky smaller size.
They really missed the opportunity to show a gorilla or something when you flip the camera.
We have come full circle. Kids these days forget that the official application framework for iPhone OS in 2007 was a bunch of HTML/CSS/images that mimicked iPhone OS UI as a web application (basically poor man's PWA).
The jailbreak community reverse-engineered iPhone headers and developed an unofficial toolchain based on llvm-gcc right away to build iPhone applications and they had an app store which still lives as Cydia (saurik et al) before Steve believed in that. Apple only threw the towel half a year later with an official beta SDK after the product-market-fit was so strong that they had no choice.
Now we recreate the whole OS in browser.
Does anyone else remember the online Userās Manual for early iPhones? It was web-based, but had a full JavaScript reimplementation of UINavigationController, UIScrollView, and UITableView.
I always suspected it was part of some bigger project that never panned out (maybe just prototyping?).
I once did something like this for Nokia when their phones moved to Windows Phone. The devil is in the details, and 90% of the time was spent mimicking the animations and transitions.
It's impressive, but it's completely broken on Macs with a normal mouse connected and Firefox, because scrollbars appear everywhere and they break the layout.
Why does it stutter and flash black screen first time you open an āappā or even switch tabs in e.g. clock app? Does it use react as a renderer?
Nice, the most jarring difference to me is when you scroll up in Photos or Settings, the topmost area isnāt blurred.
Well done! This reminds me of my own recreation (11 years ago!) of the iOS 7 homescreen as a webapp! :P
Font size in inputs should be strictly 1rem / 16px. Otherwise, theyāll be zoomed in Safari iOS.
It even replicates how annoying it is to swipe with a mouse.
looks good. Main thing is the swipe gestures need some work
The icons look blurry.
Device, OS and browser names (versions are even better) would probably help a lot the site author to fix it.
Looks nice on iPhone 12 mini iOS 18.0.1 and iPhone SE iOS 15.8.3, both safari.
On desktop Firefox (133) on Ubuntu (24.10) it does look blurry.
Good point. The setup was Windows/Chrome/1440p.
The "screen" div has a transform scale attached, which on Chromium based browsers (Chrome, Edge, etc) leads to blurriness.
Blurry for me too, Chrome on Mac OS on a non-retina external display.
Crystal clear for me - nice! ip16pm
at least the calculator should work...
Impressive!
com
I thought this would be about the interactions that are so charactetistically iOS and are hard to recreate on the web.
Well, it seems that the things that are hard to recreate have been omitted, making this not all that interesting.
On that note: It would be interesting to see something that actually does this.
I've been trying to do that, though it's not entirely finished yet.
Settings-like app: https://jotalea.com.ar/iOS Homescreen test: https://jotalea.com.ar/tests/animations.html
[flagged]
your commenting here is wasted effort
[dead]
[flagged]
Here I was expecting to see emulated Cisco software