I’m live streaming my programming from start to finish on an iOS app to help folks explore and translate Scottish Gaelic phrases.
The last post about this provided links and director’s cuts for streams 10-15, in which we add several interactive elements to our app. In this post, we switch back over to some design stuff, then dive into another screen that we haven’t touched much yet—the menu screen.
First up:
|
Here, we update the icons on the tab bar to something a little fancier than the system icons we’ve been using. We also implement the launch screen—the screen that displays while an iOS app is loading to give the, ahem, impression of a faster app :).
In the end, I wasn’t satisfied with where we ended up at the end of that stream. So I made some changes:
|
In the next stream, we succeed at changing the tint on the tab bar items to a custom color. We also essentially re-do the constraints on the launch screen. We use the preview feature in XCode to see what our launch screen will look like on a large handset, a small headset, and a tablet all at once!
Now, it’s time to jump into the menu screen at last. We start with something static: the “About the Author” menu item:
|
This isn’t our first segue, but it’s a demonstration of manually connecting a button to a new ViewController with a segue—and embedding that ViewController in a UINavigationController so that people can navigate backward from one screen to the previous screen that brought them there.
Also featured: constraints on a scroll view. Again! Can’t get enough of this. I go kinda fast on that part, so I linked another video in the description where I walk through it slower, and explain more explicitly what’s happening.
Now let’s do another menu item: the “Rate the App” button:
|
Now, this implementation is more complicated than you’d expect. First, I implement a sort of custom solution, and explain why it won’t work for us right now: we don’t have our app store ID until we release the app, and we can’t release a version of this feature that requires the app store ID until we have already released a version of the app before. (I’m telling you, the iOS development world is all intrigue). Nevertheless, we get to explore lots of iOS API elements in the process, especially UIAlertControllers and local notifications. (Bonus: local notifications and push notifications look the same, but they’re different things. See stream recording for details.)
Anyway, I throw the custom solution on a branch and instead go with the standard SKStoreReviewController that you see featured in the thumbnail—and that iOS recommends for asking for app ratings.
So why didn’t we just lead with this, and why save the custom solution when we have this option provided by Apple?
The reason is that SKStoreReviewController.requestReview() does not guarantee that the review request modal will appear. That modal displays a maximum of 3 times per 360 day period, and its appearance is managed by the device.
For this reason, Apple does not really recommend calling this method as the response to a button press like we’re doing here, since anybody who presses the button would expect it, of course, to do something. We don’t want our app to appear broken, and with the custom workflow we implemented the first time around, it wouldn’t.
Mu devious plan: use the SKStoreReviewController on initial publication, with a plan to do another release within 360 days with the custom rating functionality and a working app ID for taking people to the app store. Hopefully not too many people press this button more than 3 times between the first release and the second!
If you liked this piece, you might also like:
Some of the other live coding I’ve done—on this app, and other apps!
Advanced Debugging with XCode and LLDB, perhaps?
The role of empathy in mobile apps for care management—the example is an app to help chemotherapy patients recover.