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
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.
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
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.
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.
That's why the sleep/wake up alarm exists. It's a really nice UI. You set your weekly schedule, and if you need to push your alarm back, it uses a circular clock UI showing you how much sleep you'll get.
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.
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.
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.
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.
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?
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 said 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.
29 comments
[ 5.5 ms ] story [ 58.5 ms ] threadSpeaking of practical solutions, right?
Discussion on it: https://news.ycombinator.com/item?id=19597253
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-...
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...
Just wondering how they determined the length was enough? Was it constrained by a datatype or just an assumption on user behavior?
I hate that I had to find that by accident.
Sounds like junk code that's adding unnecessary complexity.
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
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.
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 have the Sharp Twin Bell, one of the higher end models at $12.63 from Walmart.
Also: I can't use the alarm app anymore now.
Reddit sucks.