The comments here are full of people complaining about iOS alarm bugs, so for anyone else who is sick of this: Sharp makes a lovely selection of alarm clocks. For between five to twelve US dollars, you too can be freed for life from Apple's software bugs. As a bonus, the first thing you touch in the morning, and the last thing at night, will no longer be a device that is socially engineered to destroy your mind for profit.
I have the Sharp Twin Bell, one of the higher end models at $12.63 from Walmart.
viccis · 2h ago
The real nasty bug (or feature, not sure) in the alarm app is that you have to wait for the wheel to bounce and come to a stop before the AM/PM part "sticks". If you just swipe and click save, it will keep the previous setting and then your important 7am alarm stays as 7pm and you're late for work.
PlunderBunny · 1h ago
They can’t code menus properly any more either - in macOS, try selecting something like a time from the drop-down menus for a reminder (on the main list of the reminders app, not in the window for editing that particular reminder). Immediately after releasing the mouse button while the cursor is over the time you want, move it slightly up or down while the flash animation occurs - you have now selected a different time with no warning. Completely inconsistent with the way every other menu has worked on macOS since 1984.
Logged a bug years ago, but presumably they have better things to do.
reneherse · 2h ago
That bug burned me a couple times before I switched to using 24-hour time exclusively on my devices.
For something that people use everyday, the iOS vertically-scrolling, fake-dial UI is just horrible in terms of usability and aesthetics, and I was glad when they added the ability to summon a numeric keypad with a single tap on the center dial.
The keypad input and interaction is extremely well thought out and efficient for setting the time.
clickety_clack · 31m ago
I once had to use a timesheet app that required scrolling around for all the times during the day. Timesheets are already horrendous, why compound that skin-crawling experience with such a horrendous UI? It was so hard for management to corral everyone to get the times entered that they went back to spreadsheets.
rootsudo · 2h ago
Wow so it wasn’t me.
All this time and Apple can’t code an alarm properly.
hopelite · 6m ago
I wonder if that’s also related to a bug or buggy UX, where in iOS safari you have to wait for the website scroll momentum to stop before the bookmark button context menu from long-press will fire/appear.
I guess it might all be computationally more efficient and better on battery life?
teekert · 22m ago
I can never remember if AM is After Midnight or After Midday or PM is Post Meridian or Post Midnight, or it's something like that, not to mention when 12:00 is... is it 12:00 or 0:00?. But ah well, I'm lucky to be in a place where we use 24h clocks (but hey, max we see is 23:59:59!) (unless they have arms). Btw, the iOS calendar is (was probably) also pretty "broken" [0]
Google’s Clock app seems to do most of the things: sliders on main screen, circular time picker (though I’m not exactly a fan), and a toast notification with the time until the alarm fires. The only thing missing are the every day/never options.
kevincox · 1h ago
One of the best features is that when you save the alarm you get a little toast (not a fully notification) "Alarm set for 9 hours and 22 minutes from now." It seems pretty silly, and can be a bit depressing when the number is less than 8h, but is the most obvious indicator when you set the time wrong.
NewJazz · 19m ago
can be a bit depressing when the number is less than 8h
Lol get out of my head
jeremyloy_wt · 2h ago
Funnily enough, the Sleep Schedule settings screen on iOS (accessed through the Health app) looks very similar to this.
losvedir · 3h ago
The Android clock app is pretty solid and looks something like that.
As a switcher to iPhone earlier this year, so many UI quirks drive me utterly bonkers. Can't stand these slow rotating dials, and for alarms specifically, I miss the confirmation that Android shows you "going off in 12 hours" or whatever, to make sure you didn't get the AM/PM or day of the week wrong.
But mostly, these numeric spinners are just terrible. In the Hilton app I have to put my kids ages all the time and it drives me crazy spinning the stupid little things to set their ages. Sigh.
I don't know how iOS got this reputation as magical and delightful and intuitive. I'm ready to go back to my Pixel, I think.
cosmic_cheese · 1h ago
> I don't know how iOS got this reputation as magical and delightful and intuitive. I'm ready to go back to my Pixel, I think.
Most of that reputation comes from the days when iOS was simpler, more opinionated, and wasn’t shy about how it wasn’t trying to make everybody happy. As more and more functionality has been tacked on in attempt to appeal to a broader audience, it’s been chipped away at. There’s still some ways it’s nicer than Android in my personal opinion, but often it’s just as bad with a different set of papercuts.
There’s probably a hole in the market for a mobile OS that intentionally does less in a very polished way. A lot of people don’t need their phones to do even half the things they’ve become capable of.
frizlab · 2h ago
I think you can just tap the rotating thingies now and just enter the number on a keyboard.
EDIT: Just tested, yes it works.
fauigerzigerk · 1h ago
This works in some places but not in others - doesn't work in Timers for instance.
ahartmetz · 3h ago
A good smartphone, really. Crying shame that Nokia gave up just when they had the best product in a long time.
BiteCode_dev · 3h ago
Many people nowaday can't read clocks with hands, so if you want to sell to the mass, you need to take that into consideration.
jeroenhd · 2h ago
While that's true, the numbers are still clearly readable and their position alongside a circle still makes a lot of sense. The alarm itself is also listed in digital time.
riffraff · 2h ago
really? I admit I don't deal with many youngsters, but I never met anyone who can't read clocks with hands, I think they may teach it in primary school here. This is deeply surprising to me.
Biganon · 20m ago
I'm 33 and I need an embarrassingly long time to tell the time from an analog clock
sokoloff · 2h ago
My kids are teens. We have an analog clock on the wall in the dining room.
It's shocking to me how many of their friends over for dinner (who are all on the "definitely not dumb" part of the distribution) either cannot read it at all or can read it only with obvious/significant difficulty.
jama211 · 1h ago
Even if technically know how if you rarely see them it wouldn’t come naturally to you
anotherhue · 4h ago
If we perfect the design we'll be out of the job!
ChadNauseam · 1h ago
The iOS clock app is so bad. Thank got we're getting AlarmKit in iOS 26 so people will finally be able to make custom ones. So many obvious features are missing, like a "keep my recurring alarm on, but skip it tomorrow" button (useful for when you don't want to wake up early on labor day), calendar-driven alarms, etc.
jakereps · 1h ago
> like a "keep my recurring alarm on, but skip it tomorrow" button (useful for when you don't want to wake up early on labor day)
If you use the Sleep feature, instead of a plain alarm for an “alarm clock,” it has had this feature for quite a few years now. Any modification made to Sleep, which is manageable from within the same Alarm app, prompts to ask if you’d like to change your entire sleep schedule or just apply the modification (shut off, or reschedule) to the next one up.
hedora · 1h ago
Ah, yes. The sleep alarm, as in “alert me with a loud noise if I should be asleep”.
There was a bug a week or so ago, where if you set a wind down schedule, and then updated iOS, it enabled itself.
Got woken up hours early, despite never using that feature.
hollow-moe · 1h ago
woah, Apple lets you make your own alarm app? looks like a wide open door for vulnerabilities...
Hamuko · 48m ago
Apple is probably penning a letter to the EU about how Facebook is going to violate your privacy using alarms.
frizlab · 1h ago
> keep my recurring alarm on, but skip it tomorrow
You can skip the next alarm or change it when using a sleep schedule (special alarm for waking up, also support schedules for different waking hours depending on the day of the week; setup directly in the same location as any other alarms).
jama211 · 1h ago
I don’t find it bad, just simple, which makes sense for a default offering.
layer8 · 2h ago
I wish that at least the minutes/seconds were short lists, so you can quickly go to 00 instead of always overshooting and having to go back.
On PalmOS there was the app BigClock [0][1], where tapping on the upper part of a digit would increment it and tapping on the lower part would decrement it. That way you could quickly and predictably select any time with a few precise taps, without needing to rely on visual feedback like you have to with bouncy scroll wheels.
The limitation comes from the UIPickerView system level UI component. I have a similar "bug" in my app.
ohdeargodno · 26m ago
It's written like this because making a circular, infinite list that repeats and recycles the same few components is awful to write, and "(0..60).times(50).flatten()" solves 99% of the problems with 1% of the effort.
Product would probably raise this as a blocker after QA managed to scroll to the end. Who cares.
kadoban · 4h ago
That's just a solid hack to avoid having to have a custom widget. Well done, random engineer.
egorfine · 4h ago
And we didn't find out for over a decade.
Speaking of practical solutions, right?
godelski · 3h ago
One of the things I find most interesting is that the implementation for the Timer is distant from the Alarm. In the alarm you can roll over on the minute but you can't on the timer. Why these aren't implemented similarly is beyond me. Same with why it isn't circular.
Sounds like junk code that's adding unnecessary complexity.
apparent · 57m ago
I cannot figure out why the snooze and stop buttons are reversed for the alarm and the timer. For one, the stop button is in the middle of the screen, and for the other it's at the bottom of the screen. Why wouldn't this be standardized?
wlesieutre · 52m ago
So if you're fumbling at your phone half asleep the large and bright orange button in the place you're most used to is the snooze button, which is easy to hit without actually waking up.
Hitting the out of place small gray button to turn the alarm off entirely is easy to do if you're slightly more awake.
If you turn snooze off in the alarm settings you can have a big orange Stop button in the middle like with timers.
But I understand this design was too helpful and is being removed in iOS 26 because the different looking buttons don't match and the most important thing for an alarm is that it look pretty.
apparent · 46m ago
I don't mind either setup, but I find the inconsistency between the two apps (actually, within the same app!) to be unjustifiable.
puttycat · 54m ago
Thank you brother. This has been driving me insane for years. A remarkable lack of attention to details.
arjvik · 4h ago
If you’re reading this on your iPhone, go to the alarm app, press the + button in the Alarms tab, and try to scroll to the top or bottom of the time picker
650 · 4h ago
Technically aren't the CPU cycles required to make it circular (via logic) a tradeoff to a list of 500 numbers stored statically (small size)
tpmoney · 3h ago
They're almost certainly not storing a static list of numbers. As others have noted, they're using a UIPickerView. The delegate for that class has two methods that are particularly relevant for this, one that gets the value at "current row number" and one that says how many rows are in the model. The logic for the "current row" is almost certainly the normal modulo logic we're all familiar with. But since the component needs a "size" value for the data set, they pick something arbitrarily large on the (reasonable) assumption that no one will actually ever scroll that far unintentionally.
garaetjjte · 29m ago
> They're almost certainly not storing a static list of numbers.
Probably. But I wouldn't bet on it. I once borrowed a car that would glitch if you pressed the cruise control buttons too fast. Normally + and - buttons increase and decrease the speed by 1 km/h. But if you do it too fast, it sometimes eats the entry, and starts skipping one position. Eg. it would increase from 105 to 107, and decrease from 107 to 105. It was persistent until cruise control was turned entirely off and on again. Eh? Making that bug must have taken more effort than doing it correctly. I guess it must be populating linked lists of possible speeds, and then screwing up the links when clicking too fast? (that was Jeep Renegade)
NobodyNada · 56m ago
Applying this to answer the question directly -- no, this doesn't waste CPU cycles or memory because UIPickerView only keeps the visible rows in memory and generates them lazily as you scroll. Thus, the number of rows does not affect the performance of the picker.
All table- or list-like UI components across Apple's platforms work this way.
SoftTalker · 4h ago
Yep something that years ago would have been worth the memory savings but now memory is cheap and even the CPU cycles are a non-issue: it's about what was faster for the developer to implement.
eviks · 3h ago
Technically you'd need precise measurements of specific implementations to determine that?
busymom0 · 4h ago
The time picker is implemented using a UIPickerView.
Tutorial for "UIPickerView - Loop the data" involves "simply create a picker view with a large enough number of repeating rows that the user will likely never reach the end".
I guess Apple didn't think OP would reach the end.
I think you could fake it by automatically snapping the user back to the middle when they reach the top or bottom. Still not “infinite scroll”
tsunitsuni · 1h ago
they do kinda fake it already. If you switch to another app, then switch back to the Clock or Calendar apps, it’ll snap you back to the top of the list
quotemstr · 2h ago
Am I the only one mildly surprised but not bothered by this implementation choice?
Sure, making a true circular list is easy enough both computationally and code-wise. Nevertheless, it's still something "weird" and "unusual", yet another thing that has to be tested and understood and debugged. A linear list is on the happy path, and the difference isn't going to matter for anyone in the real world.
I'd personally have made it circular anyway just for the sake of my inner sense of correctness, but making it linear and finite is, IMHO, a defensible engineering choice.
thakoppno · 4h ago
Anyone done the tedious work of figuring out the list length?
Just wondering how they determined the length was enough? Was it constrained by a datatype or just an assumption on user behavior?
eviks · 3h ago
If only they took it as a hint that the whole linear-circular design is bad as it removes any predictable fixed points... But no, let's do bad hacks instead
keernan · 1h ago
I just learned there is a bug wherein the timer will complete normally but fail to emit any sound. I have had this happen to me multiple times when using the timer for cooking and it has been driving me nuts.
The explanation said this could occur when the timer is set for the same number of minutes as the screen-lock setting. I suspect, however, it is more likely the screen-lock event and timer-end event occurring simultaneously since neither is deterministic.
jahnu · 3h ago
In case anyone else hasn’t discovered this, you can long press on the digits to bring up keyboard entry.
I hate that I had to find that by accident.
atopal · 3h ago
It’s terrible discoverability, but a single click seems to do the trick, no long press necessary.
jahnu · 2h ago
Ooh thank you!
eviks · 3h ago
Agree the discoverability is awful. Any chance you've discovered how to make keyboard entry the default?
jahnu · 2h ago
Sorry, no.
jama211 · 1h ago
Huh, thank you for this!
ayhanfuat · 3h ago
Reminded me all the hacks we had to use to emulate loops in Excel formulas. Good times.
whateveracct · 4h ago
Feels like an API that was backed by lazy cons lists like Haskell's would give you actual circular lists for free here.
Jaxan · 2h ago
It would still have a beginning. And it would not be “for free” as the used/seen part of the data structure would remain in memory.
unsnap_biceps · 4h ago
The time selector in a new calendar event is another case where it's a long list, not circular.
I have the Sharp Twin Bell, one of the higher end models at $12.63 from Walmart.
For something that people use everyday, the iOS vertically-scrolling, fake-dial UI is just horrible in terms of usability and aesthetics, and I was glad when they added the ability to summon a numeric keypad with a single tap on the center dial.
The keypad input and interaction is extremely well thought out and efficient for setting the time.
I guess it might all be computationally more efficient and better on battery life?
[0]: https://www.youtube.com/watch?v=ER1a6jgW1Gs
Discussion on it: https://news.ycombinator.com/item?id=19597253
Lol get out of my head
As a switcher to iPhone earlier this year, so many UI quirks drive me utterly bonkers. Can't stand these slow rotating dials, and for alarms specifically, I miss the confirmation that Android shows you "going off in 12 hours" or whatever, to make sure you didn't get the AM/PM or day of the week wrong.
But mostly, these numeric spinners are just terrible. In the Hilton app I have to put my kids ages all the time and it drives me crazy spinning the stupid little things to set their ages. Sigh.
I don't know how iOS got this reputation as magical and delightful and intuitive. I'm ready to go back to my Pixel, I think.
Most of that reputation comes from the days when iOS was simpler, more opinionated, and wasn’t shy about how it wasn’t trying to make everybody happy. As more and more functionality has been tacked on in attempt to appeal to a broader audience, it’s been chipped away at. There’s still some ways it’s nicer than Android in my personal opinion, but often it’s just as bad with a different set of papercuts.
There’s probably a hole in the market for a mobile OS that intentionally does less in a very polished way. A lot of people don’t need their phones to do even half the things they’ve become capable of.
EDIT: Just tested, yes it works.
It's shocking to me how many of their friends over for dinner (who are all on the "definitely not dumb" part of the distribution) either cannot read it at all or can read it only with obvious/significant difficulty.
If you use the Sleep feature, instead of a plain alarm for an “alarm clock,” it has had this feature for quite a few years now. Any modification made to Sleep, which is manageable from within the same Alarm app, prompts to ask if you’d like to change your entire sleep schedule or just apply the modification (shut off, or reschedule) to the next one up.
There was a bug a week or so ago, where if you set a wind down schedule, and then updated iOS, it enabled itself.
Got woken up hours early, despite never using that feature.
You can skip the next alarm or change it when using a sleep schedule (special alarm for waking up, also support schedules for different waking hours depending on the day of the week; setup directly in the same location as any other alarms).
On PalmOS there was the app BigClock [0][1], where tapping on the upper part of a digit would increment it and tapping on the lower part would decrement it. That way you could quickly and predictably select any time with a few precise taps, without needing to rely on visual feedback like you have to with bouncy scroll wheels.
[0] https://palmdb.net/app/bigclock
[1] http://www.gacel.de/bigclock/bigclock.htm
Back in the day the iPhone was notorious for messing up alarm timezones and failing to activate with DST changes… https://www.abc.net.au/news/2011-01-03/alarm-failure-leaves-...
The limitation comes from the UIPickerView system level UI component. I have a similar "bug" in my app.
Product would probably raise this as a blocker after QA managed to scroll to the end. Who cares.
Speaking of practical solutions, right?
Sounds like junk code that's adding unnecessary complexity.
Hitting the out of place small gray button to turn the alarm off entirely is easy to do if you're slightly more awake.
If you turn snooze off in the alarm settings you can have a big orange Stop button in the middle like with timers.
But I understand this design was too helpful and is being removed in iOS 26 because the different looking buttons don't match and the most important thing for an alarm is that it look pretty.
Probably. But I wouldn't bet on it. I once borrowed a car that would glitch if you pressed the cruise control buttons too fast. Normally + and - buttons increase and decrease the speed by 1 km/h. But if you do it too fast, it sometimes eats the entry, and starts skipping one position. Eg. it would increase from 105 to 107, and decrease from 107 to 105. It was persistent until cruise control was turned entirely off and on again. Eh? Making that bug must have taken more effort than doing it correctly. I guess it must be populating linked lists of possible speeds, and then screwing up the links when clicking too fast? (that was Jeep Renegade)
All table- or list-like UI components across Apple's platforms work this way.
Tutorial for "UIPickerView - Loop the data" involves "simply create a picker view with a large enough number of repeating rows that the user will likely never reach the end".
I guess Apple didn't think OP would reach the end.
https://stackoverflow.com/questions/26063039/uipickerview-lo...
Sure, making a true circular list is easy enough both computationally and code-wise. Nevertheless, it's still something "weird" and "unusual", yet another thing that has to be tested and understood and debugged. A linear list is on the happy path, and the difference isn't going to matter for anyone in the real world.
I'd personally have made it circular anyway just for the sake of my inner sense of correctness, but making it linear and finite is, IMHO, a defensible engineering choice.
Just wondering how they determined the length was enough? Was it constrained by a datatype or just an assumption on user behavior?
The explanation said this could occur when the timer is set for the same number of minutes as the screen-lock setting. I suspect, however, it is more likely the screen-lock event and timer-end event occurring simultaneously since neither is deterministic.
I hate that I had to find that by accident.