Experimenting with various combinations of UITabController and UINavigationController has lead to some interesting discoveries, some of which may be documented (but I’m not sure where)

If you have a child view controller of a UITabController that is a UINavigationController, it will essentially inherit a UITabBarItem from its root view controller.

When you set up a UITabBarItem for a view controller, make sure you do so in the initializer of the view controller. Do not wait until viewDidLoad. You don’t have to allocate your own UITabBarItem. By default, when you access the tabBarItem property of the view controller for the first time, it will create and return a default tab bar item.

The title for the tab bar item can come from (at least) two different places. You can either explicitly set the title of the tabBarItem itself using its title property. Or, you can set the title of the view controller. If both are set, it seems that whichever is set last wins. So, even if you have explicitly set the title of a tab bar item, if you then change the title of the view controller, that new title will be used for the tab bar item. So, if you don’t want to inherit your view controller’s title for its tab bar item, set the title of the view controller first, then configure your tab bar item.

If you create a system tab bar item, you can’t override its name. You get the icon and the name together.

SplitViewController - the supplied navigation bar item that lets you get back to the master view controller depends on the title property of the master view controller. If that title isn’t set, it will just display an arrow pointing back. If it has a name, there will be the same back arrow, followed by the title.

Do you listen to Under the Radar, the new(ish) podcast from David Smith and Macro Arment? I have been enjoying it, having missed the shorter format of David Smith’s original podcast, Developing Perspective. It directly relates to topics of interest to indie developers, and the shorter format focuses the conversation a bit.

Because of their ergonomics episode, I finally took the plunge and bought a standing desk. I’ll talk more about that in a separate post, but it has been a really positive experience.

I was surprised by their take on Swift, though. Both developers were emphatically in the “no-Swift-for-me” camp for now. This post is my take on moving to Swift, and what I see as the benefits and drawbacks to doing so at this time.

For the new year, give Swift a try. The barrier to entry is low. Every developer has XCode, and its Swift support just keeps getting better. I can understand the reluctance during the Swift 1.0 days. I didn’t play with it then much, either. I found Playgrounds slow, and the compiler crash-prone. Everyone who was talking about Swift seemed to have jumped right into the deep end of complexity with discussions of functional programming and obscure language features.

But, things have improved. Apple has put together a lovely tutorial where they walk you through a nontrivial iOS app using Swift (no temperature converters here!) Start there and just see how you like it. Many of the tutorials on raywenderlich.com have been re-written in Swift. Take one you’ve done before (or a book you’ve purchased in the past), and try it out in Swift.

One approach I haven’t been as successful with is writing some new functionality in an existing Objective-C app in Swift. It can be done, but I find switching between the two to be less efficient. Plus, although the way Swift interacts with the existing Cocoa APIs is improving, it will still feel more clunky than just calling things from Objective-C.

Also, don’t start reading all of the hardcore Swift blogs right away. They bring up cool points, but are too specific and detailed to be useful at first. I found them confusing and overwhelming. However, now four months in to writing Swift almost every day, I have found myself revisiting some of the older posts, and better understanding the concepts they were trying to explore. The WWDC 2015 Swift videos are also nice to watch once you have a bit of practical Swift under your belt.

It will feel frustrating at first - Swift code will take you probably twice as long to write as equivalent Objective-C, and you’ll still be looking things up and fighting compiler errors. Once you have working Swift, it will probably just be Objective-C style, but written in Swift. THIS IS FINE. You spent years building up your Objective-C skills - they are not going to be as easy to discard for a newer, shinier language.

But, when it comes time to create something new, consider Swift. You will end up writing significantly less code overall. As you become comfortable with optionals, value types, and the class/protocol model, you will slowly start to change your style and write more “Swift”-ly. Only then start following Swift blogs. You should also keep an eye on the future of the language that is unfolding on Github. No point in getting attached to a language feature that is destined to disappear (I’m looking at you, c-style for loops…) Give the Xcode migrator less to do by starting to follow future conventions today.

I wrote two apps for AppleTV entirely in Swift. The first went pretty slowly. It felt like I was not only learning a new programming language, but the Cocoa APIs as well. Concepts that seemed so clear when reading the Swift docs seemed more complicated in practice. However, the next Swift app I wrote for AppleTV was essentially written in three days. I now have a hard time bringing myself back to Objective-C. I had written in Objective-C since 1992, and have been surprised by how quickly and completely I want to just stay in Swift.

And then, once you’re ready for it, definitely check out Erica Sadun’s new book, The Swift Developer’s Cookbook. This book is Hard Core, but in a totally amazing way. If you want to start writing code that is not warmed-over Objective-C, and takes advantage of some of the truly cool language features of Swift, this is the book for you. I’m working through it slowly, but find that I am learning something new in every chapter. It is to be savored and digested gradually (ha! because it’s a cookbook! didn’t even to mean to make that pun…).

Here’s to a 2016 is filled with great apps written in Swift!

Happy New Year!

I’m getting off to a slow start of the work week after a week off with the kids, so I decided to ease into things by stepping through a Ray Wenderlich tutorial. They are always fun to read, relatively short, and I learn something new.

The most recent non-video tutorial was:

Creating Custom UIViewController Transitions

It fulfilled my expectations in terms of better understanding view controller transitions. I still feel like there are just so many moving parts with those transitions (pun only slightly intended), but this was a straightforward enough example to have it make more sense.

But, the coolest thing I learned was just a small tidbit about perspective transforms. The tutorial has you rotate views in and out of view. It turns out that with a simple numeric constant, you can make those rotations look MUCH more realistic.

The trick is referred to here in the Apple Docs: Advanced Animation Tricks

Simply, you sent the layer.sublayerTransform 3DTransform of a parent view to have the m34 field of CATransform3D set to a relatively small negative number (it can be positive too, which appears to change the direction of a rotation). Then, when views contained inside of this container are rotated around the Y axis, they appear to recede into the distance as they spin. This is more realistic than if you didn’t set this field, because then the rotation looks more like a squeeze and expand rather than a true rotation. The value for the m34 field is a bit magical, with the tutorial using -0.002. This represents the inverse of the distance along the Z axis for the viewer, and 0.002 is about 500 pixels. Values in the range 0.001 to 0.004 seem too look fine, with larger values giving a more pronounced size change as the views spin around.

Another interesting fact about the transform is that it is applied to the container view of the views involved in the view controller transition. This container view appears to be created by UIKit to server as a safe place to mess around with transitioning from one view to another. So, each time you perform the transition, you want to reapply the perspective transform to the container view, since it disappears once the presentation/dismissal of the view controller finishes. Interestingly, it sticks around after a new view controller is presented, and only disappears once the presented view controller is dismissed. So, you are applying a transform to a view that already has one, but since this isn’t additive, it is not a problem.

So perspective transforms are neat things to know about it you want to make your y-axis rotations (and presumably x-axis too - I tried to do an x-axis rotation, but the newly presented view kept jumping in from of the existing view before the rotation had completed. But the rotation looked a lot nicer with the perspective enabled).

I may try to take this transitioning to the next level, and see how custom transitions inside of navigation and tab bar controllers can be implemented.

Happy rotating!