I’ve been struggling to come up with a coherent response ever since I read Radek’s article on naming methods in Swift. While he makes a number of good points, I keep coming back to a deep-seated anxiety about moving toward shorter, less descriptive method names in Swift. The crux of my discomfort comes from this section of his post (emphasis mine):

Code is not made equal. It would be a mistake to apply the same naming convention to everything. Some methods are generic and broadly used. Some are rare or domain-specific.

Consider these functions and methods: map, reduce, stride, splice. These are very short and easy to remember. They’re not exactly self-explanatory, but that’s okay, because they are standard library methods that you’re going to use many, many times so the benefit of a short name is greater than the price of having to learn it first.

On the other side of the spectrum, there’s your application code. You probably don’t want to give methods in your view controllers obscure single-word names. After all, they’re probably going to get called once or twice in your entire codebase, they’re very specific for the job, and once you start working on another class, you’ll totally forget what the thing was.

I hope you see where I’m going with this. If you’re writing library/framework-like code, or some base class that’s going to be used throughout the app, it’s okay to use short and sweet names. But the more application-specific it is, the more you want clearer, more descriptive, intention-revealing methods.

I don’t think this logic pays enough attention to the fact that someone else will very likely be working with your code after you write it. Even if you’re a single developer, you might eventually pass that code off to someone else – maybe because you got a new job, or added a partner, or sold your app to another developer. Best practices are important because they help us make our code accessible to the next person who works on it.

I also think developers should take care to make a language accessible to people who are new to it. That’s especially true right now with Swift – we’re all new to it! Keeping the language accessible might mean trading off some conciseness in favor of descriptiveness. Consider the examples above of concise standard library methods: map, reduce, stride, etc. You have to learn what they do before you use them. That’s a barrier that you have to overcome before you can start working in the language. The more of those there are, the higher the barrier becomes. As a developer community, we’re best off keeping those barriers as low as possible.

Radek rightly points out that there’s a spectrum, and the more narrowly tailored your use case is, the more appropriate a concise method name might be. But I disagree with the idea that short method names are appropriate in a base class used across your app, or even in framework code. Even methods that get used all the time should be readable. Doing so reduces the amount of time that a new developer has to spend digging through your source code in order to figure out what’s going on. (I shudder to imagine all the command-clicking to figure out what things like funnel or fetch or grab might do.)

I propose that the only real place where very short, concise names make sense is in the language itself. Essentially, this refers to things like map that are already built into Swift. We’ve got autocomplete to help us with the rest, and Swift already reduces some of the extra typing from Objective-C.

Why does this all matter, and why have I been ruminating on it for the past couple of weeks? Because Swift is new, we have a unique opportunity to shape its conventions. I’ve done some Ruby programming in the past, and although it’s a nice language, I don’t want to develop iOS apps in it. I think the iOS and Mac developer communities will do themselves a favor by sticking to longer, more descriptive method names in all but the rarest of circumstances.

Brent Simmons on deciding to write new code in Swift:

And there has to be a time limit. I forget who proposed the 45-minute rule for CSS, where you give up and just use a damn table for your layout. I don’t want to be too quick to punt when using Swift, because it means I won’t be learning as much as I could be (and I need to become expert: that’s the point), but I also can’t let my productivity go too far from what’s normal.

I’ll give myself two hours of banging-head-on-disk, then punt. As a rough guideline. (I’m not actually going to use a stopwatch.) This number may change, but it’s important to have some limit as I’m doing this.

Sounds like a great approach to me.

I got thinking about size classes in iOS 8 after the Apple Watch announcement. As of right now, there are two size classes in each dimension: “regular” and “compact.” Broadly speaking, the compact size class desribes the iPhone, and the regular size class describes the iPad. Yes, I know that there’s not a strict mapping between size class and device, but there’s enough of a connection that we can mostly use size classes as a proxy for devices. (The iPhone 6 Plus muddies the waters here a bit.)

When they were announced at WWDC, I was surprised the classes weren’t “regular” and “large” – regular for the iPhone and large for the iPad. That’s even more true with the introdution of the Apple Watch. It’s easy to imagine creating a size class matrix like this:

Size Class	Compact	Regular	Large
Device	Apple Watch	iPhone	iPad

But instead, I think the Apple Watch implies something like this:

Size Class	???	Compact	Regular	Large
Device	Apple Watch	iPhone	iPad	???

There’s two things to consider here:

1. Does the Apple Watch really fit into a size class smaller than “compact,” and/or does it use size classes at all?
2. Does the use of “regular” as the biggest current size class imply the existence of a “large” class in the future?

Where does the Apple Watch fit?

Apple hasn’t released nearly enough technical information about the Apple Watch to talk about this with much certainty. Paul Sprangers made some educated guesses that the Apple Watch screen is roughly 280 x 350px, which would seem to place it in a size class smaller than “compact.” Maybe this implies a new size class. (“Micro?”)

It could be that the Apple Watch exists outside the size class system entirely. Apple’s web site makes reference to something called the “Watch OS.” We don’t know much more about it than that, but even if it’s distinct from iOS, it’s likely to be strongly related. The odds are high that it’s using size classes under the hood somewhere, even if it’s not exposed to developers by name. After all, why create a system for flexibly adapting to different screen sizes if you’re not going to use it on a new, differently-sized screen?

Either way, we’ll know a lot more about this once we get a look at WatchKit.

Something bigger?

Both the iPad Air and the iPad mini have a “regular” size class in both dimensions, which implies that Apple is at least leaving room for something larger than the iPad. The likeliest explanation is that they’re keeping their options open for shipping larger devices in the future. Maybe a larger “iPad Pro”? Or perhaps an Apple TV SDK, in which the TV has a “large” size class. Time will tell.

Yesterday Apple introduced two new iPhones, which means it’s about that time when people to start asking me what phone they should buy. Since I often find myself repeating similar advice to a lot of people, I thought I’d jot down a few thoughts.

iPhone 6 or iPhone 6 Plus?

The newest models come in two sizes: the iPhone 6 at 4.7″ diagonally, and the iPhone 6 Plus, weighing in at 5.5″. By comparison, the iPhone 5 and 5S both measured 4.0″ on the diagonal. Both phones are offered in 16GB, 64GB, and 128GB capacities.

Both new models share a lot of the same components: an updated screen, somewhat faster processor, and support for the new Apple Pay contactless payment system. In short, they’re almost identical on the inside. There are only a key few differences between the two:

• Screen Size: Obviously, the iPhone 6 Plus is significantly larger than the iPhone 6.
• Battery Life: Apple says the iPhone 6 Plus gets somewhat longer battery life than the iPhone 6. For example, they claim 12 hours of LTE web browsing on the 6 Plus, versus 10 hours on the 6. We’ll have to wait until these phones are actually released to know how they do in real world situations, but it’s probably safe to say that the 6 Plus will last a bit longer on a charge. (More details on battery life comparison are available on Apple’s web site.)
• Optical Image Stabilization: The two phones share most of the same camera technology, but the iPhone 6 Plus also contains optical image stabilization as well. Apple says that it will result in clearer pictures in low-light situations.
• Price: All iPhone 6 Plus models cost $100 more than the equivalent iPhone 6 model. For example, the 16GB iPhone 6 costs $199 (on contract), while a 16GB iPhone 6 Plus will set you back $299.

My advice on choosing between them? It really comes down to personal preference. I don’t think the image stabilization will be a big deal for most users, and the iPhone camera is already quite good for a phone, so I think we can mostly set that aside. I also doubt that the battery life between the two models will be different enough in real world use to be noticeable for most people. That said, if battery life is a big issue for you, that might tip the scales in favor of the iPhone 6 Plus.

Primarily, I think the choice comes down to the size and price. Do you like very large phones, and is a bigger screen worth an extra $100 to you? Or would you be happier with a somewhat smaller (but still bigger than the iPhone 5S) phone that has more storage? Keep in mind that the iPhone 6 is already larger than last year’s iPhone 5S. For the sake of comparison, here’s a quick photo I snapped showing the relative sizes of an iPhone 5, iPhone 6, iPhone 6 Plus, and iPad mini:

Personally, I’m not a fan of really giant phones like the 6 Plus. Additionally, over the past few months I’ve run out of space on my 16GB iPhone 5 time and time again. I’m fairly certain I’ll end up buying a 64GB iPhone 6.

Keep My Old Phone?

I usually buy a new phone every other year. I bought an iPhone 4, skipped the 4S, bought the iPhone 5, and skipped the 5S. In large part, that’s because I’m not willing to pay full price for new phones, and every two years feels about right to me. However, I do advise people to buy iPhones early in their life cycle. For example, if you’re going to buy an iPhone 6, get it this fall instead of waiting until the spring. If you buy a phone in spring 2015, for example, you probably won’t be eligible for a new carrier-subsidized phone until spring 2017. Then you have to choose whether to buy another new phone that’s been out for six months, or wait unil the fall.

Furthermore, it used to be true that iPhone releases in even-numbered years were the “big” updates (iPhone 3G, iPhone 4, iPhone 5) and odd-numbered years were more incremental updates (3GS, 4S). That pattern has subsided a bit in the past couple of years, so I’m not sure it’s worth worrying about anymore. For example, you could argue that the iPhone 5S, with its powerful processor upgrade and TouchID sensor, was a bigger upgrade from the iPhone 5 than the iPhone 6 is from the 5S. Basically, if you’re eligible for an upgrade when new iPhones come out and you like the new models, go for it.

Of course, if you like your current phone and it’s running great, you can always hang on to it. Just remember, it’s extremely unlikely that there will be any new phones from Apple between now and next fall. iOS 8 will run on phones back to the iPhone 4S, although it’s likely to be fairly slow on the oldest devices. My guess is that it’ll run just fine on an iPhone 5.

Unlike Objective-C, Swift doesn’t have a concept of header files. In a lot of ways that’s great, because it eliminates a lot of unnecessary typing and repetition. However, I find myself missing headers because they were a great way to get an at-a-glance look at the public interface to a class. Consider the following Objective-C header:

The header defines a Message class with a number of properties, as well as a method for replying to the message and a class method for downloading all messages. It’s easy to tell from looking at the header what functionality it exposes to other classes without needing to worry about how it’s implemented. The header also hides any private variables that other classes don’t need to know about and don’t have access to.

In contrast, here’s the same class re-written in Swift:

The Swift class intermingles the interface and the implementation, as well as public and private properties and functions. We can see all the guts of what the class does under the hood, even though that’s not relevant to someone who just wants to use the class. Moreover, it’s conceivable that some of these functions would be long. (I’ve omitted an actual implementation here for the sake of this example.) That means a lot of scrolling and scanning through code just to see what functions are available.

In order to make this easier, I propose that Apple add a new view to the Assistant Editor in Xcode. This view would display an on-the-fly public “header” for the Swift file in the main editor pane. The header would only contain public (and maybe internal?) methods, as well as function signatures. Something like the following:

As you can see, it’s very similar to an Objective-C header. However, we didn’t actually have to write it manually, and there’s no actual file associated with the header. It’s just a view of the class generated by Xcode for convenience. This view would be uneditable, and would be automatically updated by Xcode as the Swift code changes. In practice, this would be a lot like developing in Objective-C using the “Counterparts” mode in the Assistant Editor to display header and implementation side-by-side. In short, the “header view” would give developers all the benefits of headers without actually having to write them.

UPDATE 9/6/14: I’ve filed a radar requesting this enhancement. Please consider duping!