Yearly 1.2 is now available for download in the iTunes Store. The biggest change I made was enabling a custom start date other than January 1 for the reading schedule (a request I’d received from friends and strangers alike). For the settings panel I implemented SlideMenuControllerSwift, which was really a joy to work with.1
While I was at it, I added a few more things to the settings panel, including a handy link to go to the app’s Settings for notification management, as well as a link to iTunes for leaving a review.
One new change in 1.2 that I didn’t mention in the (admittedly scanty) release notes is this: when you download the app for the first time, instead of just blindly showing a standard alert dialog requesting that you grant permission for notifications, I first show a custom dialog box that contains this message:
Yearly works best when you receive a morning notification. It silently appears on your lock screen at 5:00 AM and shows what your reading is for the day. To enable notifications, please tap “Allow” in the next window.
Underneath this custom dialog box is a single button whose title is, “Ok, got it,” upon which tapping inside brings up the aforementioned default dialog.
All of Yearly’s UI is built in Storyboard and I’m starting to seriously wish I’d taken the time to learn how to do it programmatically instead. At this point, whenever I want to rearrange anything, the number of constraints I have to redo is tedious. Sometimes I even have to dip into the XML source code of the Storyboard to remove, say, an outlet reference to a view that’s been added, hooked up, and subsequently deleted.2
- I’ve learned that you can’t judge a book by its cover when it comes to 3rd party code. The documentation screenshots for
SlideMenuControllerSwiftwere a turn-off at first, but once I realized how smooth, reliable, and flexible its underlying UX was and that its UI was completely determined by what you brought to the table, I decided to give it a go. If I can be vain for a moment, I think the design of Yearly’s settings panel is better than the screenshots for
SlideMenuControllerSwiftand does a better job “selling” the library. ↩︎
- Perhaps the bigger lesson here is that unless you’re an iOS ninja, you want to do your design prototyping elsewhere, and only go into Xcode once you have a pretty solid idea of what you want to design. It doesn’t have to be drafted elsewhere to the pixel per se, but if you’ve got the basic building blocks nailed down before you start implementing them, you’ll save a lot of time. The pitfall I often run into is that I have exactly what I want to build in my head and think it’s all a solved problem, but then when I go to implement it, I’m forced to reckon with scenarios (relating to both UI and UX) that just don’t fly in real life. ↩︎