Hello all,

As promised, This will be a longer one. A lot going on here, Some of which you already know. We have a lot of book news, and I can finally tell you about the Lynda.com course.

First the tip of the week. With Practical Autolayout now released, I’m going to talk about Apple’s bizarre way of writing constraints. One thing I cover in the book is reading constraints directly in the document outline. For constraints that are relations between two views, there is a folder in the document outline that contains all of them. Suppose you have two buttons labeled Banana and Hot Fudge. They are spaced horizontally apart 10 points and pinned to the top and later margin.

Click open the constraints in the document you see they are written as algebra equations.

One equation in the set there would be: Hot Fudge.leading = Banana.trailing + 10. These equations default to plus, never minus. That equation tells you that there is spacing of 10 points between the Hot fudge leading edge and the trailing edge of Banana. If you see a minus, that means someone manually reversed the constraints. If it is flush with the margin, there would also be a constraint of Banana.leading = leadingMargin, meaning the leading edge of Banana is on the leading margin. It doesn’t not say +0 in those cases, it just leaves it off. An alignment can also be a equivalence. Both buttons when top aligned would have a equation of Banana.top = Hot Fudge.top.

If you know how to read these in the document outline, you can pick out constraints directly there, for modification or deletion. It’s a good skill to add, and speeds up selecting constraints. I go into this more in Practical Autolayout for Xcode 8, and where it is particularly useful.

Speaking of Practical Autolayout, its out and I’m starting to see sales. I’m going to assume that the first nine iBooks sales and eight Kindle sales for the Xcode 8 version I got are from my readers on the email list. Thank you for those sales. Hopefully I’ll be able to increase those sales over the next few weeks. For this list there an elephant still in the room I’m going to talk about right now: updates.

If you read my post late last week announcing the book, I told you the bad news: I made too many changes to the structure of the iBook to be an update of the previous book, and therefore had to issue a completely new edition. I did get a good question about this last week: If you have to buy a new book, which device should you pick? I have two answers for you: The first is the one you find most comfortable reading. The Kindle edition has the dynamic fonts so you can change the font and font size of the text. The iBooks version is static, but has been carefully formatted to fit the page Here’s examples of the same page in both formats. If you are listening to this on the podcast, you can check the show notes for the images.

Whatever device you like is great — in one perspective any book you buy is good for me. On the other hand, I do make more from the sale of an iBook at a 70% royalty than a Kindle version at 35%, so I’m kinda biased towards iBooks, where I can at least correct typos and update to everybody the corrections. You can also download free sample chapters on both platforms if you want to try them out.

You can find more on the iBooks version here and the Kindle version here. If you are listening to the podcast I left the links in the transcript.

There’s another elephant in the room too: updating Swift Swift View controllers. I have no idea what’s going to happen there. I was already planning for a update incrementally, and that might just get me past the filters that look for big structural changes.