This year, for me, was more inspirational than informative, which is not necessarily bad, but I think just a symptom of my session choices. I’ve included a list below of the sessions I attended and would recommend, and then sessions I didn’t attend but wanted to.

They are still working on transcoding all the session videos (which they put online for everyone for free!) so check back for updates.

Recommended Sessions

These are sessions I attended which are worth watching. I’ve filtered out the sessions which didn’t inspire or weren’t technically interesting (to me).

Something Deep With MikeMike Lee (@bmf) talks about world modeling, how the models predict our current global situation, and what we can do as software engineers to aid in the shaping of our planet’s future.

This is a must watch presentation. My potentially inadequate description might make this talk sound like something you can skip, but that is entirely not correct. The concepts and information presented here are so important and relavent that this should be mandatory viewing for everyone.

The 360iDev version of Mike’s presentation is more refined and to the point than his UIKonf discussion, but YouTube has Mike’s “World Modelling” UIKonf video online at this time and is worth watching.

Decision Fatigue is the name given to the effect in which the quality of your decision making deteriorates with the number of decisions you have to make.

What is interesting is that many studies have shown that the difficulty of the decisions actually have little effect on the rate of the deterioration, more so the quantity. This is to say that having to make a lot of ‘small’ or ‘easy’ decisions can seriously harm the quality of the ‘bigger’ decisions you make.

Have you ever had to repeatedly decide how you might implement an API design? How you’d implement a network layer? K&R braces? tabs or spaces? withCompletionBlock: or just completionBlock:? Each of these decisions especially when made over and over can take away from the much more important decisions along the lines of “What is the ultimate goal of what we’re building?” or “Why are we implementing this?”

We’re now a year into Swift. For those coming from Objective-C who are still testing the Swift waters, what do you need to do to switch your brain over to the new Swift way of thinking? What’s new, what’s the same, and what’s completely different when programming for the same platform in a new language?
Big-picture outline:
– focus on safety
– undefined behavior
– less dynamic behavior and fuzziness; more strong typing and predictability
– a little bit on Swift/Obj-C interop and how to make the transition

Join us as we explore tips and tricks for introducing Swift source into Objective-C projects. We’ll cover where in the networking-model-UI stack to begin writing Swift, how to maximize the benefits of using Swift without re-writing your apps, and how to avoid some of the common pitfalls getting Swift and Objective-C working harmoniously together.

Unit testing on iOS has always been a challenge, mainly because the ViewController creates a mix of UI and non-UI code. But, it’s totally possible to achieve good levels of coverage on view code for iOS, and this talk will cover some strategies for doing so, focusing on a real app (no contrived examples here!) Including: splitting up a ViewController to make a seam, verifying button actions, dealing with [self navigationController], handling asynchronous code, and how we can compare UIImages.

In a world where ViewControllers shoulder the burden of managing ever-changing vagarities of application state logic and complex navigation stacks, one design pattern emerges from the past to lead us toward a better, brighter, and lighter future of app development.

In this sequel to last year’s blockbuster presentation, “Good Intentions: Building Better ViewControllers”, we will revive a venerable programming technique for explicitly defining application behaviors and thereby reducing the responsibilities of our much maligned ViewControllers.

“TODO” Sessions

I didn’t attend these due to overlap in the schedule, but they sound like sessions which shouldn’t be missed.

Develop powerful, beautiful custom transitions using the APIs introduced in iOS7. In this session we’ll explore how to make both simple animated custom transitions as well as more complicated, interactive transitions.

Auto layout is hard. It requires developers to think different about structuring and manipulating views. If the developer doesn’t express themselves 100% correctly the results can be messy. And auto layout doesn’t help with it’s obtuse error message and verbose messages. This talk will cover some uses of auto layout that bedevil developers like: using auto layout in scroll views, self sizing tables and collections, and debugging conflicts.

Arguably Apple Pay might be the nudge that NFC needed to go mainstream. Let’s talk some implementation details of what happens when you tap your iPhone or Apple Watch and why tokenization is a $20 word for a 5-cent software concept.

So you’ve got some downloads but downloads don’t necessarily equate to active users. How can you engage a first time user? How can you keep them coming back to your app?
The psychology of building habits

Joyful first experiences

The awesome power of email

Deep-linking

Pushing for good

Helpful help sections

Game Jam

As usual, this year I participated in the “Game Jam” on Tuesday night. Since the idea of the game jam has transitioned from building an actual game to more of a “stay up late and code on something” feel, I take the opportunity to build something I wouldn’t normally get a chance to play with. This year I chose to attempt to build a “cheat app” for a word game called Capitals (which is pretty fun).

The idea sounds simple enough… take a screen shot, run it through an Optical Character Recognition (OCR) process to identify the available letters, then pass those letters into an anagram algorithm to produce a list of possible words.

I might write up a more detailed post on my findings, but the short version is that I spent most of my time trying to get the OCR engine, Tesseract to recognize the characters in the screen shot. With some help from fellow 360iDev attendees I eventually managed to get the engine to recognize 90 percent of the letters… not good enough. So the idea didn’t merit a demo at the Gam Jam review, and is “on the shelf” for future attempts.

Con-clusion

The 360iDev conference has always been about the people and the community. This year was no exception. We, as iOS developers, have a great community with many very smart and open people in it. As with any community I care about, these are the tenets I try to follow:

So I mentioned that we’d be in big trouble if there was a star in front of the moon, and started to try to explain that many stars are much like our sun, and our sun is very big and very hot and if it was close enough to be between us and the moon like in the icon, we’d be toast.

But then I balked in my explanation, because I wasn’t sure what the relative size of the sun was to our lunar orbit. I didn’t know if the sun would actually fit inside the orbit of the moon (regardless of the consequences). So I had to look it up, and then make this graphic to get an idea of the relative sizes:

Click/Tap on the image for a different look at higher resolution (can you see the moon!?). Original image credit: NASA

Yeah, no way the sun is fitting between the Earth and Moon. In fact, the sun is about 3.6 times as big as the distance between the Earth and moon!

Our sun is so big, if the Earth was in the center of a ball the diameter of the Moon’s orbit, the Sun could almost hold two of these balls side by side!

The details:
Our sun is 1,391,684 km in diameter (1712 pixels). [Sun]
The Earth is 12,742 km in diameter (~16 pixels). [Earth]
The Moon is 3 474.8 km in diameter (~4 pixels). [Moon]
The average distance from the center of the Earth to the center of the moon is 384,400 km (~473 pixels). [ref])
* Please note, all pixel size references are to the full scale image

1,391,684 km / (384,400 km x 2) = 1.81

The Sun is 1.81 times as big as the average diameter of the Moon’s orbit around Earth!

WOW, the sun is big.

Now that we know what the relative size of the Sun is to the Lunar Orbit, take a look at this for an idea of how big (or small!) our sun is in general.

CreateTextFileHere is a manually activated AppleScript applet used to create a text file at the current Finder location with BBEdit

This utility works in tandem with the ‘bbedit’ command line binary (which should
already be installed and functional at /usr/local/bin/bbedit).

The intention is for this utility to be accessed from the currently active Finder window and acts on the current directory in the Finder. I suggest adding CreateTextFileHere.app to the a Finder window’s shelf (command-drag it into a Finder window at the top where the other tool icons are located) so it is available from the Finder as needed. Alternatively, it could be activated from the Script Menu.

Thanks to the kind folk over at Bare Bones Software for letting me use a modified version of their text document icon.

Bartender
De-clutter your menu bar. This manages all the little menubar warts that seem to show up with various tools. Keeps things nicely tucked away, but accessable.

BetterTouchTool
A tool for configuring your interaction with a mouse or trackpad. Basically it allows you to program various gestures, clicks, taps, etc. to do any number of things.

cd to
A great little app which you install in your Finder “shelf” to open a terminal window at the current Finder location. It’s a huge timesaver if you are moving between the finder and Terminal a lot.
There’s an updated Yosemite icon (from https://github.com/jbtule/cdto/issues/9) which you’ll most likely want too.

CreateTextFileHere (shameless self promotion)
Another little app which sits in your Finder “shelf” to create a text file at the current Finder location. Created by yours truly.

Degrees
A little weather widget. I use the Mac menubar version. It’s nice and unobtrusive.

The Unarchiver
Far better tool than Mac OS X’s standard unarchiving tool. It handles so many more file formats.

This frustration was caused by the latest in a long line of frustrations and their workarounds. Specifically, our bots are now spontaneously failing because of this error:

“Failed to mmap. Could not write data: Invalid argument (-1)”

(don’t be fooled by the “Fix It” button which doesn’t seem to)

I’m not the only one, as there are others on the Apple Dev Forums (login required) which are experiencing the same (or very similar) issue. The suggested workaround is to downgrade from Xcode 6.1.1 to 6.1. Yeah, I’m not about to do that, so our CI build is broken, and I’m left with no choice but to go back to Jenkins. Honestly, that kind of gives me a sense of relief since I know I can get Jenkins to perform all the tasks I need, and I know if our CI build breaks it will be my fault and not an external dependency like Xcode Bots, over which I have no control.

I mentioned a long line of frustrations with Xcode Bots, and that’s true. I’ve not taken the time to try to document them all, but here’s some off the top of my head:

In my post Xcode Bot Keychain Configuration I mentioned the fact that the bot server does not seem to fetch non-development provisioning profiles, and the steps needed to work around this issue.

Because of the aforementioned provisioning profile issue, we have never been able to get our Mac app build to work. We always get a provisioning profile mismatch error. We even went so far as to copy the developer cert and private key into the bot’s keychain…

Inexplicably, a CI build will fail, and automatically rebuild, which will then succeed.

If a build (“integration”) succeeds, we get two for the price of one (no idea why… no new commits triggered it).

The web UI is… gone? In previous builds of the Xcode Bot server there was a web UI which presented the details of each build. This was removed, so any truly useful information must be gathered from Xcode.

Tracking down build system issues is laborious and cumbersome. The only real source of valuable information is the raw “Build Log” file, which can be viewed from within Xcode, but only after the integration has finished (no “tail -f”-like behavior), but be prepared to wait and keep scrolling as this file loads, slowly, with no UI feedback from your remote build server.

In general, the internals of the Xcode Bot system are so black box and inaccessible that debugging the process, understanding how it works, or extending it, is a non-trivial time investment which I’d rather use to be working on actual projects.

After all this, I still have high hopes for Xcode Bots, I do want to like them, and I look forward to the day when I can use them for my needs. That day is not today, unfortunately.

The Xcode Bot server (as of 3.2.1) uses /Library/Developer/XcodeServer/Keychains/Portal.keychain to store the needed certs and keys used for codesigning (previously it used the System.keychain.

The server seems to only automatically download developement certs and profiles (not distribution) so we must manually populate the keychain with the dsitribution cert/key pairs needed and manually place the distribution profile(s) we need into the location which the server looks for them. In my iOSContinuousIntegration system I have a pre_action.sh script which handles copying the profiles from where they are committed in the repository to the proper location on the server for the bots to locate them, so no need to go into that here. The keychain is a bit more complicated…

Make sure the private keys have the correct access rights (in the “Access Control” tab of the “Get Info” for the private keys in Keychain Access), “xcsbuildd”, “xcscontrol”, “xcodebuild” and “codesign” should be listed. “xcsbuildd”, “xcscontrol”, and “xcodebuild” are inside the Xcode binary… /Applications/Xcode.app/Contents/Developer/usr/bin while “codesign” is usr/bin/codesign. Finder’s “Go to Folder…” command is useful for locating these binaries. Though you will likely need to “unhide” the /usr directory from the GUI.

This can be done by opening a terminal and issuing the command:

sudo chflags nohidden /usr

Then navigate to /usr/bin and select the codesign executable from the file picker GUI in the “Access Control List” tab of the Keychain Access’s Get Info dialog. Once added to the ACL you can (and should) re-hide /usr with this command:

Recently I’ve been reading up on Apple’s In-App Purchase system with the goal of understanding how to support various types of purchases. It seems to me that non-consumables are kind of the “poster child” in-app purchase, for the typical “remove adds” or “unlock content” models. Which makes sense, because, in-app purchases are pretty simple if you are talking about auto-renewing subscriptions, or non-consumable items. Simple because Apple sends you all the information you need in their receipt, and persists that information for you. The only thing you’re required to do is allow the user to “restore purchases” which basically gives you the receipt information back as if a purchase was made. Easy.

Things get more complicated when you want to handle the other types of purchases. Specifically consumables and non-renewing subscriptions. Apple pretty much says: “Here’s the receipt for your purchase… you better keep track of it for your user. Oh, and we’re never giving you this information again…” or at least that’s what it sounds like to me when reading through the “Persisting Using the App Receipt” section of the In-App Purchase Programming Guide

Where it says:

Information about consumable products and non-renewing subscriptions is added to the receipt when they’re paid for and remains in the receipt until you finish the transaction. After you finish the transaction, this information is removed the next time the receipt is updated—for example, the next time the user makes a purchase.

So that means, you, as the developer, must have your own server to maintain a record of these kinds of purchases, and allow a mechanism for your user to restore these kinds of purchases (on a new device, for instance). That means building and maintaining your own server to handle this, or integrate with something like Parse. Not the end of the world, but…

That’s kind of crummy.

Not only do you need to build/integrate with the server component, but now you must ask your users to create an account with your system so you can identify them to associate their purchases with their account. I’m sure users are used to this, but it’s still a drag.

So, I searched around and found this post which stated that non-renewing subscription information persisted in the receipt from Apple. Wait, what? This post is obviously crazy, the In-App Purchase Programming Guide said that didn’t happen…

Like many developers, I would guess, I have many ssh keys. Keys for various services such as github, bitbucket, and others, each with the potential for multiple accounts. Managing these keys when using git on the command line can be a pain, but I’ve got a decent working solution.

ssh-agent

ssh-agent is a process that sits around and helps ssh do its thing on your behalf. There are several helper apps which allow you to configure its behavior, but specifically we are interested in ssh-add.

ssh-add is your friend, especially on Mac OS X.

It can be used to store credentials which, upon a connection attempt, ssh will use. ssh will try all the credentials in the list until it finds one which works.

You can get a listing of what keys are already “known” by the agent with ssh-add -l:

So, if your ssh key has a passphrase on it, that passphrase is now stored in your Mac OS X keychain, and when ssh is looking for credentials to make the connection with it can find the key and use it without you needing to enter your passphrase again.

Win.

HTTPS

Further, for bonus points, when you’re not using ssh, but rather https, you can still use the keychain…

Being on Mac OS X, we have the osxkeychain which can be used to store and retrive the kind of information we need for authentication.

To set this up, add (or ensure it is already there) the helper line in the [credential] section of your ~/.gitconfig file:

123

[credential]helper= osxkeychain
useHttpPath=true

This will allow git to query the OS keychain when it is looking for stored credentials.

If you have multiple accounts on the same system, you may want to tie a set of credentials to the full repository path, so you can access different repositories with different credentials. That’s what the useHttpPath = true line does.

Now, once you authorize a connection to a specific repository those credentials will be stored in your keychain:

Having not posted anything here in quite some time I started to wonder “why not?” and discovered, after some introspection, that I have limited myself by considering this just a technical blog.

Often I would find myself with ideas for technical topics to write about, but faced with the daunting task of writing them up in a digestable format proved, obviously, too big a hurdle to overcome, and nothing actually got posted. So, I’m switching it up a bit.

While I’ll still happily write about technical topics which I come across, I also plan to delve into topics which are less technical, and perhaps even more of a personal or sociological nature.

With this change, I’ve also updated the visual theme here to be a bit lighter and less default.

I certainly hope to write more here, and I certainly hope others will appreciate that effort.