Concerning Swift

swift 1-point-no

I came across an excellent article by Erica Sadun talking about her experiences with the Xcode Betas and her expectations of Swift 1.0, and I think it was a nice dose of reality. (…And not only because I have a domain that will be obsolete in a post Objective-C world.)

It’s nice to pretend that we will all be writing Swift apps by the end of the year, but if this git repo is any indication, we will have a little while to go before the language is stable enough for prime time.

I feel sorry for all the people who decided that Swift was their excuse to start learning iOS development, because of all the strange quirks with Objective-C compatibility, it won’t be as easy as picking up a Swift book and writing an app. There will be challenges and changes for at least the next year and possibly longer. As it is now, you will have to update your Swift apps very often to keep up with what will certainly be many revisions of the language.

I have a friend who I am trying to teach iOS development, and even though it will be available fairly soon, I have urged him to pretend that Swift doesn’t exist for the time being, and I urge the same to anyone else just starting out.

I intend to practice what I preach, while I will undoubtably tinker with Swift over the next several months (I am not completely nuts), I will not do any serious writing in it until they at least start updating the Cocoa API’s to be a bit more Swift-like.

How I Finally Understood Swift Optionals

I had a bit of trouble understanding Swift Optionals. When should I use a question mark, and when should I use an exclamation point? The iBook was a bit confusing on this point for me. Until I was sitting at IndyCocoaHeads last night and @AndyDuff was giving a talk about Swift. When he got to the part about Optionals, something finally clicked for me and I was able to finally understand them.

Optionals are like Schrödinger’s Cat!

Think of it like this, you can have an integer, and we all know that integers are whole numbers (-1, 0, 1 , 2, 3…) within a certain range depending on what type of system you are on. In Swift you would declare it as such:

var n: Int = 23

The compiler does not need the type here, but I included it for clarity. This is telling the compiler that while, n “could” be any integer, here, it’s 23. Now lets look at an Optional:

var n: Int? = 23

In this line we are telling the compiler something else. Currently n is 23, but n “could” be any integer OR nil. If you are familiar with Objective-C, this is quite familiar with NS objects. NSString can equal @”Hello, World” but you can also set it to nil, which is not a string, or any type for that matter. This is why I like to say it’s like Schrödinger’s Cat If you are not familiar with the concept, I believe this link is a fun place to start. Essentially the variable can contain a value, or nil (the cat is either alive or dead), but we don’t know until we check.

if (n != nil) {
    println("n = \(n!)." // Note the ! after n.

Once you are 100% sure that n does have a value, then you can force it to behave like a normal integer by using “!”, if you use ! and n is a nil value, then your app will crash.

var n: Int? // Optionals default their initial value to nil.
println("n = \(n)." // This will crash because it's trying to print nil.

Once you get the hang of it, it becomes natural and feels like things we have done in Objective-C for quite some time now just we now have access to this feature on “Primitive” types.

Format specifiers for NSInteger and NSUInteger (Without Warnings)

%zd = NSInteger
%tu = NSUInteger
%tx = Hex

I have been bothered by the fact that if I use NSInteger NSUInteger in [NSString stringWithFormat:], I will get warnings depending on what architecture I am building for.

Does this look familiar?

Does this look familiar?

You can change the format to %ld and the cast to (long), but that felt really awkward. After googling around for a while and even Apple’s Documentation is not helping much, I decided to pose the question in #iphonedev. I got a response from someone named “Jer” with the following link Gred Parker describes the %zd (NSInteger), %tu (NSUInteger) and %tx (Hex) format specifiers which will suppress the warnings when switching architectures.

I immediately double-checked the docs to make sure I hadn’t overlooked something, and I had not. So I filed a bug report with Apple and hopefully this will get cleared up soonish. In the mean time I decided to make this blog post, to help Google, help others.

Are Secure Input Fields Relevant on Mobile Devices?

Picture of a phone with secure entry field

I was logging into my bank app the other day and started thinking, “Are all of those dots really necessary?”.

When you are sitting at a desk, using a big-screen and physical keyboard, I can see how it makes sense to keep your password hidden from passers-by, but when you are using a smart-phone or tablet, the usage is much more intimate and you are less likely to have to worry about prying eyes.

Based on my 10 minutes of Google research, I have determined that most people use their smartphones ~15 inches from their face, so it’s doubtful that you will have to worry about a random person catching your password. If they do somehow get in the viewing angle of your phone, then the dots will be pretty much useless as most touchscreen inputs will display characters as they are entered before turning them into dots.

So far I have demonstrated that they are not likely needed, and if they are, they are useless. I will now explain why they can also be an annoyance.

How often do people typo on a touchscreen keyboard? Unfortunately, I have as of yet been unable to find analytics on this topic, but I would be willing to bet that it happens quite often (companies have spent a lot of money developing predictive text for a reason). I can speak from experience that I frequently typo my password and fail to correct it before submission because I am unaware of the typo. If this was a plaintext field, I would not have this issue.

I realize that this may sound nuts, and I would love to hear a rebuttal. Please, if you have an argument message me on Twitter.