Caption goes here.

My first run at a packing list was suprisingly solid: everything worked pretty much as intended and there wasn’t anything I desparately missed or needed during my US trip. However, I misjudged the needs of my travel bag:

I very rarely used my Silver Streak bag as a backpack, and when I did, it was just too heavy for prolonged use. (The total weight of all my equipment was almost 50 pounds.) As a result, I mostly ended up detatching the backpack and carrying the main bag on a shoulder strap, which was very uncomfortable.
All my important equipment rarely left my backpack. I hardly ever used the expanded compartment in the main bag for anything other than a few spare parts, souvenirs, and my Wacom tablet.
I gathered a lot of food ingredients during my travels, and to avoid a mess, I carried them in a separate cloth bag. There was never any need to store perishables in the main bag.

As a result, I have replaced my Silver Streak with an Eagle Creek Switchback 22 (on sale). The Switchback does almost everything the Silver Streak does, but adds one vital feature for city use: wheels! Contrary to most of the advice I found on travel blogs, I desparately wished for wheels many times during my trip. (Maybe this would be different if I were spending long miles walking on unpaved roads, but the fact is that most of my traveling happens in modern cities and not the countryside.) The backpack half of the bag now serves as the store for all my tech equipment, while the main bag keeps all my clothes and accessories. Among other things, this consolidation means that I no longer have to move things from bag to bag when I’m leaving the main bag in a locker or on a bus/train/plane. Space is more tight than in the Silver Streak, but everything still fits. (At the moment, I’ve decided to roll up my jacket and clip it onto the handle, since cramming it in takes a bit too much effort.) The Switchback offers great flexibility in regards to transport: backpack zipped onto the main bag, backpack threaded onto the carrying handle, or backpack and main bag separate. (So far, I’ve found the most convenient option to be zipping the backpack onto the main bag and using the wheels. You can walk many miles like this without a problem.) There are many other details that make the Switchback feel like a high quality product, from the multipurpose outside straps to the secondary handle position all the way down to the stitching. It’s clear that a lot of thought was put into the design. One minor annoynace is that the backpack straps have to be taken off the backpack to be used with the main bag, but since I’m mostly set on using the wheels, this isn’t a big deal for me. Before I settled on the Switchback, I also tried the Osprey Meridian, but I was simply not able cram all my stuff in!

Caption goes here.

I also made a few other changes:

An Eider Roc de Chere jacket in blue (also on sale). I made a bad call on my previous jacket: it was cold, scratchy, and most definitely not waterproof. I briefly considered applying more wax, which is what you’re supposed to do to make a waxed cotton jacket more water resistant, but I decided it wasn’t worth my time. Instead, I set out to find a no-compromise jacket this time around: waterproof, warm, comfortable, usable in all cold weather conditions, featuring a detatchable hood, and not horrendously ugly. (Most of the widely-recommended technical jackets and rain shells fell into that category for me.) I tried on a large number of different jackets from REI, Nau, Carhartt, Patagonia, Marmot, Eider, and Helly Hahn. Close contenders were the REI Montour (green is not my favorite color), the Carhartt Grayling (fit perfectly, but material felt plasticky), and the Nau Temp (super comfy, but too warm and the fit wasn’t right around the waist). The Roc de Chere’s material is light enough for use even in warm-ish weather, and the color and material are fairly unique. Still, I wish it had buttons down the front! Is jacket envy a thing?
A pair of Adidas Duramo slides. The Nike Benassis I had earlier were very comfortable, but the mesh lining took forever to dry out, to the point where, one, I simply couldn’t shower in them if I had to leave the next day, and two, they actually had a propensity to mold! Their everlasting wetness also ensured that they could never double as slippers. Despite being made of a plastic-like material, my new Duramos are shockingly comfortable and dry out pretty much immediately. Somebody on the internet described them as “prison sandals”, but no worries: all you have to do is lower your standards and you’ll be going out in public in no time!
Two cloth bags: one for food (as mentioned earlier) and one for carrying dirty laundry around. They barely take up any space.
A very small tea cup from DAVID’s Tea. I keep it in the same bag as my socks and glasses. Purchased in Toronto!
An Anker Astro E5 battery charger. Way too often, I would leave my house without having charged my phone and then end up desparately looking for a power outlet by the end of the day. With this device, I always have some extra charge on me. (Quite a bit of extra charge, actually.) It’s also useful for charging all my small electronics when I’m too far from an outlet, or when I want to keep my belongings close to me in a hostel. An essential gadget.
A tiny Lightning cable for my keychain. It bends in a way that allows me to hook up my iPhone to the aformentioned battery charger in my jacket pocket without having to deal with cable spaghetti.
A small multitool, consisting mostly of pliers and screwdrivers. No knives, so it’s (nominally) TSA-safe.
A ShedRain Windjammer umbrella, based on last year’s recommendation on The Wirecutter. London Fog’s umbrella was awful and broke after about a week of use.
A long stainless steel mesh tea infuser. Aside from a little metal tag which I bent out of the way, this thing fits perfectly into my Klean Kanteen and allows me to brew loose-leaf tea with plenty of room for leaf expansion. It’s the only one of its kind that I was able to find! Every other teaball is either tiny or doesn’t fit into the Kleen Kanteen.
A Logitech G602 wireless mouse. It works well enough and eliminates an annoying stretch of cable. Sensitivity, tracking, and latency are great for gaming use. (In fact, I saw some measurements that put the latency on par with wired mice!) Battery lasts a month. Range is really iffy, but I’m only planning to use it next to my computer, so that’s not really an issue.
A set of collapsible compact chopsticks. I occasionally find myself in situations where I could really use some sort of utensil, and these chopsticks get the job done in most situations. (Plus, they’re great for munching on small, greasy foods like popcorn or chips!)
A Pilot Metropolitan fountain pen— just because it’s sweet. :)

Already, HoboPack Mark II feels so much more useful and refined. Onward to more adventures!

This is the time of year when a lot of people are upgrading their phones. If you are, don’t chuck your old phone just yet!

Here’s a thing you might not know about your iPhone¹: the GPS unit works even without a data connection. I was confused for a long time about what “assisted GPS” actually meant. My understanding was that it was impossible for an AGPS phone (which the iPhone is) to acquire a GPS signal without a data connection. Turns out it works fine — you just have to wait a bit longer for the phone to find a satellite.

So here’s what I do with my old iPhone 4. Whenever I set out for a walk, I load up an app called myTracks and hit the Record button. Then I chuck the phone in my bag and forget about it. At the end of the day, I retrieve the phone — more often than not with plenty of charge remaining — and stop the recording. Finally, I can connect my phone to my computer and export this data as a kml file (among several others) to use with Google Maps:

(Incidentally, setting this viewer up was surprisingly easy. First, I exported the kml data from the app — in this case, EasyTrailsLT, which I’m also trying out. Next, I went and got a Google Maps Javascript API key. Finally, I wrote a quick Jekyll plugin to replace kmlasset tags with a bit of boilerplate Javascript code that calls Google Maps. End result: I can drop my kml in a folder, add a tag, and have the map show up magically in my blog post. This is just a small example of how Jekyll makes doing data-heavy blogging a lot more simple, which I’ll delve into in later posts!)

Most of the GPS apps I’ve looked at still support iOS5, so your phone doesn’t even have to be a recent model. I’d still use my 3GS for this purpose if the battery was up to snuff.

People always panic when Google or Apple slips up and caches a bit of your location data, but I feel the opposite. With an old iPhone and just a bit of dilligence, I can create a map of everywhere I’ve walked in the world!

Jekyll assets created over the course of this exercise

kmlasset_tag.rb— A Liquid tag that feeds a kml file url into a Google Maps applet.

Since I only have Apple hardware at the moment, I have no idea if this also applies to Android. Sorry! ↩

I recently released my first commercial project: Translit Keyboard, a 3rd party keyboard for iPhone that lets you transliterate Latin characters into Cyrillic and some other alphabets. When I was first investigating this problem, around the time that iOS 7 came out, I discovered that I could implement an elegant solution in OSX using the lesser-known Input Method Kit. My program sat between the keyboard and text field; the framework provided me with each raw character as it was entered, and I could either pass it along with the default behavior, or instead take control of the output and send off whatever I pleased¹. Sadly, iOS was off-limits: since 3rd party extensions weren’t even on the radar at the time, there was nothing anyone could do to enable this sort of behavior system-wide. The only solution was to make a nice app with a special text field that you could copy and paste from — too clunky for rapid-pace tasks like messaging.

When iOS 8 was announced and unexpectedly blew open the doors on extensions, my interest was immediately piqued. Although, on initial glance, the keyboard APIs were rather crude — you were given a gray box at the bottom of the screen and practically nothing else — this gave me a roundabout “in” to making input methods work on iOS. What if I were to recreate the system keyboard from scratch? I could make it behave any way I wanted!

And so, Tasty Imitation Keyboard was born. If I may take a moment of vanity, the keyboard is very solid: on most phones, it looks and types very much like the system keyboard, minus the landscape side buttons on the 6 and 6+. (iPad support isn’t too high on my priority list, but it is functional.) This was a satisfying project to work on, giving me great insight into Swift, autolayout (since removed), Core Graphics, and a bit of Interface Builder. But it also gave me experience with something that I had yet to encounter in my sheltered iOS development existence: the horror of undercooked Apple frameworks and tools.

Below are as many of the problems I encountered during development as I can remember. I have high hopes that these will be fixed over the next few years, but until then, perhaps this article will help some poor programmer in dire straits!

Behavioral Bugs

Prevalent in Apple land is the expectation that software should adhere to the conventions of its host OS. We like our apps to use common widgets, behave consistently, react smoothly, and acknowledge the current design trends; very much unlike the “anything goes” philosophy that Windows and Android have often adopted. So it surprises me that 3rd party keyboards are even a thing on iOS. To take such an essential, constantly used, frequently visible UI element and put it at the mercy of developers — many with their own twisted ideas of how a keyboard should look — seems like a very un-Apple-y thing to do.

But it gets worse. 3rd party keyboards on iOS don’t just have the opportunity to look alien; they act alien, and this is something that programmers can’t guard against. Consequently, all the 3rd party keyboards currently available on iOS feel like some sort of jailbreak hack.

That Pop-In

This is the first thing you notice. Unlike the system keyboards, which smoothly slide in from the bottom of the screen, 3rd party keyboards just… pop into existence. (Most of the time. Sometimes they slide in, though it’s hard to predict when this will happen. There are also some scary bugs associated with this particular entrance. More below.) Worse, if you’re switching from a default keyboard to a 3rd party keyboard, the entire keyboard disappears for a second while the 3rd party keyboard loads up.

Invalid State

And guess what? Sometimes you’ll have to wait forever!

On occasion — frighteningly frequent occasion — I’ve seen the keyboard simply fail to appear, even after waiting for many seconds. When this happens, it’s hard to tell when the keyboard is going to come back. Will it happen when you hit the home button and re-open the app? (Sometimes it doesn’t.) When you switch to another app? (Sometimes it doesn’t.) One of the few sure-fire ways to fix this problem is to force-close and re-open your current app, which isn’t always possible. (Spotlight.) And until then, have fun not being able to type!

There are other fun states that your keyboard can get into. For example, sometimes the keyboard view will show up, but never actually load the keyboard:

And the fun is not just limited to 3rd party keyboards! If you hit the globe icon on a system keyboard, sometimes the button will run away from under your finger — and stay that way for a long time:

What Is the Text Even Doing?

The text entry behavior of 3rd party keyboards is a bit erratic. For example, try using SwiftKey (or any other 3rd party keyboard) to type out part of a saved URL in Safari — to the point where it starts to autocomplete the rest — and then press delete. You’d expect the highlighted part to disappear, right? No: what actually happens is that the cursor simply moves to the left, leaving the autocompleted part intact and still highlighted. This does not happen with the system keyboard.

Settings? What Settings?

With 3rd party keyboards, you can’t access any of the keyboard preferences that the user has set, including auto-capitalization, automatic spaces after periods, disabling the shift key, and playing clicks when typing. As a result, you either have to assume a default, or re-implement the settings entirely.

(Fortunately, accessibility settings like “reduced transparency” are still available.)

Broken Apps

Some apps are downright broken with 3rd party keyboards.

Editor’s note: None of the problems below seem to happen anymore with Google’s recent Maps redesign. Still, the fact that they were happening at all is troubling, since there’s nothing an app should theoretically be able to do to influence keyboard behavior.

In Google Maps, a number of strange behaviors happen with the search box. First, it’s one of the few text fields I’ve seen that have custom keyboards slide back in after they’ve been dismissed, rather than just popping in as described above. Why this particular text field and not others? I have no idea. Furthermore, if you track the UIInputViewController lifecycle during this process, you’ll see that even though viewWillAppear is called correctly when this happens, viewDidAppear is not. This is especially odd given that the keyboard still appears to go through init.

Next, if you tap on the search field in portrait and then rotate to landscape, your keyboard will suddenly expand almost to the top of the screen.

How about another app? Hilariously, in the App Store app, if you try to write a review using a 3rd party keyboard, you’ll find that the page turns entirely blank!

Reloading the Extension

If you’ve recently updated a 3rd party keyboard, your apps might still have the old keyboard bundle loaded in. This is fixed by force-closing and reopening the app.

Mystery Crashes

I have seen numerous mystery crashes affecting their 3rd party keyboards. Sometimes they just… close for no reason. And you don’t even necessarily see it in your crash logs!

Mystery Glitches

3rd party keyboards can sometimes exhibit bizarre graphical glitches. For example, this one is easy to consistently reproduce.

Missing Features

There are some features that customers are used to — or even find essential! — in their keyboards, but that we cannot currently provide. One is autocorrect, including the red-squiggle variety. Another is physical keyboard support.

Full Access Is Almost Necessary

There are two ways that 3rd party keyboards can run. By default, the keyboard cannot do much of anything outside its own sandbox. But if the user goes into their settings and manually flicks a carefully hidden switch, they can enable “full access” for that particular keyboard. In the process, they are greeted with this terrifying popup:

This totally makes sense if there’s a chance that your keyboard could send your precious keystrokes over the net. Unfortunately, there are a number of other vital features that require getting past the full access barrier. Sharing data between your keyboard and your container app. Sharing data between multiple keyboards in a single app. Having a settings bundle. Using in-app purchases with your keyboard. Playing sounds, for crying out loud. Some of these are reasonable since they could allow private data to escape out of the sandbox in roundabout ways, but it’s causing many developers to strongly encourage their users to enable full access.

I wanted to be as secure as possible in my app, so I worked around these problems in various ways. To compensate for the demo aspects of IAP, I released my app for a fixed price, and then released a Lite version with a useless transliterator (Old Slavonic) for trial purposes. Instead of having a single keyboard with a language selector accessible from the container app, I opted to have multiple keyboards instead. The one feature in my keyboard that still requires full access is sound; this defaults to “off” in the in-keyboard settings and offers users an explanation on how to enable it.

The Reviews; Oh, the Reviews!

As you would expect, customers have no idea that any of these behaviors are caused by the OS. Just look at these reviews for various 3rd party keyboards:

You’ll find it difficult to find a 3rd party keyboard with more than 3 stars. (And can you blame the customers? After seeing these behaviors, I certainly wouldn’t switch to a 3rd party keyboard full-time!)

What can we do about this? Nothing! We have to pay for these bugs with our precious developer cachet.

Programming Problems

In addition to the above hassles, us programmers have other things to worry about. The framework that Apple has given us is… rough around the edges.

Changing the Height

Unlike the system keyboard, your custom keyboard is confined to the rect it was created in. There’s no drawing outside the box and no adding transparency. This becomes a problem if you want to add popups to your keys like the ones in default keyboard. How do you handle the top row when you can’t draw over the top?

In the early betas, you couldn’t do much at all. Your best option was to either draw sideways popups or just do nothing. Closer to release, we got the ability to expand the height of the keyboard view. Sadly, the implementation feels like an afterthought.

Apple specifies in the docs that you can change the height of your keyboard by adding an autolayout constraint with a constant value to the keyboard view. However, if you actually follow these instructions, you’ll find something like this in your log:

2014-11-08 17:17:09.741 Keyboard[8079:3155417] Unable to simultaneously satisfy constraints.
	Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) 
(
    "<NSLayoutConstraint:0x618000096350 'UIView-Encapsulated-Layout-Height' V:[UIInputView:0x7fe0be909690(216)]>",
    "<NSLayoutConstraint:0x608000093b50 V:[UIInputView:0x7fe0be909690(246)]>"
)

Will attempt to recover by breaking constraint 
<NSLayoutConstraint:0x608000093b50 V:[UIInputView:0x7fe0be909690(246)]>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.

Adding a constraint to the keyboard view doesn’t set the height; it rams against the existing autolayout height constraint created by the autoresizing mask, and overrides it in most cases. This is important: if you add the constraint before the view appears on the screen (this is specified in the docs), or in certain cases where your keyboard view doesn’t contain any subviews with autolayout constraints (this is not), your height constraint will lose and the keyboard will revert to the default height. That second case is particularly mystifying: at one point, I had to create an invisible kludge view with autolayout constraints and add it to my keyboard view in order for the height to set correctly!

But even with the extra height, you can’t actually make any part of your keyboard transparent. This means that if you want to implement popups for the top row, you either have to add an ugly strip to the top of your keyboard (my solution — it’s a good place to put extra UI anyway), or alternatively try increasing the height whenever you tap a key in the top row and then shrink it back down afterwards.

I ran into another problem with this constraint technique. For my keyboard, I didn’t really want to provide an entirely unique keyboard height; all I needed was an extra 30 points or so on top of the native keyboard height. The first idea I had was to change my height constraint from just a constant, to “equal to the keyboard height” plus 30. This did not work. Next, I tried to capture the keyboard height before I added my constraint, as well as on rotations; unfortunately, after my constraint was added, I found that this technique stopped working. (It warrants further investigation, however.) Finally, I decided to just hardcode the keyboard heights for each device and each orientation.

Speaking of which: with a custom height constraint, on rotation, everything goes nuts. I don’t think I’m doing anything too crazy. This is what my rotation code looks like:

override func willRotateToInterfaceOrientation(toInterfaceOrientation: UIInterfaceOrientation, duration: NSTimeInterval) {
    self.keyboardHeight = self.heightForOrientation(toInterfaceOrientation, withTopBanner: true)
}

…which simply sets the height constraint’s constant to the correct height.

But if you perform the rotation in the Simulator, you see things like this:

And this:

And maybe this:

In the process of trying to figure out what was causing this, I discovered that during certain points in this transition, the bounds of the keyboard view (or its superview, or its layers) were incorrect. For example, in the second screenshot, the bounds would be 320×216, even though they’re clearly 568×162 at that point.

I couldn’t find a way to work around this issue, and so I was freaking out for a few days until I discovered that it didn’t happen on device unless your performance was really slow. With that said, if you don’t add the Apple-sanctioned height constraint, none of this occurs.

Straight-Up API Errors

The UIInputViewController class, as an adherent to UITextInputDelegate, receives several useful callbacks from the text field. You’ll notice that they’re named pretty clearly: selectionWillChange, selectionDidChange, textWillChange, and textDidChange. In fact, none of them actually do those things. The selection methods never gets called at all, and the text methods only get called — get this — when the selection changes or the cursor is moved!

(Incidentally, the UITextInput object that you get back with these methods is crippled. Many of its methods don’t seem to do anything.)

viewWillTransitionToSize is another offender. As of iOS 8, if you use the old willRotateToInterfaceOrientation method, Xcode will tell you that it’s deprecated and that you should be using viewWillTransitionToSize. However, viewWillTransitionToSize never actually gets called! You’re forced to use a deprecated method in one of Apple’s newest UIKit additions.

UITextInputTraits Transgressions

Your UIInputViewController has a mysterious NSObject called textDocumentProxy that serves as the interface between the keyboard and the current text field via the UITextDocumentProxy protocol. (Why is it a nebulous NSObject instead of a UITextDocumentProxy?) Among other things, this protocol lets you access certain attributes of the text field.

Perhaps the most important of these is keyboardAppearance, which tells you if your keyboard should be using dark mode or not. One would expect this value to be correct on keyboard initialization, but no: you actually have to wait for the keyboard to appear on screen before this field populates with the correct value. I have not tested, but I have a hunch this applies to the other input traits as well. To my knowledge, this is not described in the documentation.

The properties of UITextInputTraits may change while the keyboard is still open, if the user switches from one text field to another. This is pretty sensible, if uncommon. What’s not sensible is that the textDocumentProxy object is not KVO compliant, meaning that there’s no easy way for you to observe these changes! The only thing you can really do is poll the object, 60 times a second. (I’m not suggesting that there’s a performance penalty for this, but still… yuck.)

Audio

As mentioned above, you need to enable full access to get any audio going. You would think, at least, that you could call the standard AudioServicesPlaySystemSound function to play the keyboard tock; but instead, you have to do this:

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), {
    AudioServicesPlaySystemSound(1104)
})

And yes, that dispatch_async is necessary; otherwise, your keyboard will simply stop working if full access is disabled.

iPad Woes

This is more sensible than the other issues, but I still think it’s worth mentioning. If you want to sell an iPhone-only keyboard… well, you kind of can’t. True, the app won’t show up in the iPad App Store; but if you install the container app on your iPad, you’ll still be able to install the keyboard in the settings! This is especially a problem if users find your app via your product website rather than through the App Store, since they probably won’t check whether your app is “optimized” for iPad before buying.

The Cruel Mockery of Size Classes

Apple strongly encourages the use of size classes in iOS 8. Seems like such an elegant solution: why worry about device dimensions or even portrait vs. landscape when you can just read the size class and show the appropriate UI? Alas, in the case of keyboards, they’re useless. Aside from the 6+ in landscape, keyboards are all strictly Compact, even though the layout constants for landscape are very different from those of portrait. Even worse: like the 6+, the 6 has those handy side buttons for editing in landscape — but its size class is still Compact, while the 6+ is Regular! And what about the iPad? Its keyboard is sized Regular in both orientations, even though it has exactly nothing in common with the 6+ keyboard in landscape.

Autolayout? Yeah, Right

This is kind of a digression, but I think it fits in here. When I was first implementing my keyboard, I tried to be a good platform citizen. I decided to use autolayout: Apple was strongly recommending it, and multiple screen sizes were coming in quick, so why not? Well… if you’re implementing a keyboard or anything remotely like it, don’t use autolayout!

In learning this technology, I found several places where autolayout was very appropriate. For example, if you’re making a single-screen view with a limited number of static elements — preferably in Interface Builder — it’s a great idea to use autolayout. But if you’re creating something where lots of views are generated dynamically and/or need to be laid out in an orderly fashion, just forget about it. Aside from the fact that you’ll spend your days knee-deep in constraintWithItem:attribute:relatedBy:toItem:attribute:multiplier:constant: initializers and spacer views², you’ll also have to battle bizarre autolayout warnings and auto-resolutions when you decide to make even the tiniest change to your layout. It gives you zero flexibility.

Autolayout can optionally use something called the “visual format language” to create multiple constraints at once. A VFL string might look something like this: |-(2)-[myView(30)]-(2)-|. But every view in such a string must be named. For my implementation, this meant that all those anonymous keys and spacer views suddenly needed to have unique identifiers. It also meant that I couldn’t just write out these strings by hand, but instead had to use Swift’s string interpolation to put the correct names in place. I also had to dynamically combine multiple format substrings into one because I had no way of knowing how many keys my keyboard had ahead of time. In the end, it turned into a completely illegible, unmaintainable mess. Instead of making my life easier, all it did was increase my workload and pollute my codebase. (Again: if you have a single-screen view with just a handful of subviews, this works great. But it doesn’t scale.)

On top of it all, autolayout incurs a significant performance penalty. With my setup, featuring on the order of a hundred views, autolayout took a few seconds longer than just laying everything out in layoutSubviews.

In retrospect, settling on manual layout was certainly the right decision, and I’m not sure why I even spent so long trying to get autolayout working right. With layoutSubviews, there’s no worrying about priorities or inequalities, no seeking out conflicting constraints, no implicit calculations, no linear algebra. It was as if a fog had been lifted from my mind. My layout code shrunk to only a third of what it was before. And as extra validation, soon after I released my keyboard into alpha, somebody asked me if they could lay out their keys in an arc. This was the simplest of changes with layoutSubviews, but made me shudder to think of the horrible contortions that would have been required had I still been using autolayout!

As an aside, I recently encountered a project called Masonry that intends to be a simplified autolayout syntax. Here is an example from their docs:

[view1 mas_makeConstraints:^(MASConstraintMaker *make) {
    make.edges.equalTo(superview).with.insets(padding);
}];

To me, that looks marvelous, and I wish Apple would adopt something similar. Right now, even though autolayout is very powerful, it is completely unsuited for many applications, including most programmatic interface designs.

The What…? Under the Hood

If you examine at the view hierarchy of your keyboard, you’ll find it completely baffling. A view, which is the same as your inputView… added on top of a view… on top of another view… on top of another view… on top of the window, maybe? What are all these views even doing?

User visput on Russian site Habrahabr illustrates this with the following screenshot from his excellent article on iOS keyboard development:

View Hierarchy

In short, I give this framework a rating of NC-17.

Tooling Troubles

On a recent episode of ATP (was it ATP?), the gang talked about how the condition of Apple’s tools is a troubling sign that they might be barging ahead too fast. Believe me: it’s worse than you could ever imagine.

Xcode

Xcode quitting “unexpectedly”, stuck builds, stuck indexing, unresponsive buttons, and the never-ceasing SourceKit crash log blinking boxes of doom have become an hourly ritual for me. It’s gotten to the point where I instinctively reach for the “force quit” button if a task hasn’t completed within a few seconds. (I’ve also force-closed SourceKitService in Activity Monitor out of spite.)

Code completion frequenty stops working for me. I have to perform byzantine tricks to get it working again. (Sometimes, it never really does.) This is infuriating when you Command-Click on some UIKit class to see the header and Xcode tells you that it doesn’t exist, or when you try to call a particularly long method and Xcode fails to find a match.

Offline documentation has been in a state of disrepair for the longest time. Apple may have fixed it in 6.1, but I am loathe to check.

Slow. Scrolling is slow. Code completion is slow. Documentation is slow. Search is slow. Typing is slow. Everything is dog, dog slow. I am not exaggerating when I say that it sometimes takes half a second for my text to show up on the screen! (Albeit, this is with far, far too many browser tabs open, but Sublime keeps chugging on without a problem. And… it’s freaking text entry!)

It’s become a frequent occurrence that I load up an updated version of my keyboard, tap on my keyboard in the globe menu… and crash out back to the default keyboard. I have to either open the container app, force close the current app, press “stop” in Xcode, or do some other weird trick to get it to show up correctly.

A lot of the time, when I try to run the Keyboard target directly, it’ll open up the keyboard and then just sit on “waiting to attach” for eternity. Sometimes I can’t fix this.

Sometimes my dynamic frameworks won’t compile, and I have to press the run button twice in a row for everything to link up properly. Remember the old quip about how insanity is doing the same thing twice and expecting different results? Doesn’t apply to Xcode!

It’s such a shame because I actually, unironically like Xcode. Visual Studio disturbs me on a visceral level. How can I tell people that Xcode is a better-designed IDE when this kind of stuff is still going on? It’s unacceptable.

The Simulator

That smiley… that smug, mocking smiley.

As of Xcode 6.1, you can no longer open 3rd party keyboards in most apps in the Simulator, including your own. (And not just 3rd party keyboards: most system keyboards refuse to show up, too.) Not only does this make debugging a whole lot harder, but it also prevents you from easily making screenshots of your keyboard if you don’t own some of the newer devices. This issue is marked as a bug in Radar, and seeing as how it first appeared in the Xcode 6.1 betas, I cannot fathom how it got through to release.

Fin

There’s no real conclusion. As of iOS 8.1, 3rd party keyboards are functional, but look and feel janky. Programming them is also a horrible pain. I hope Apple fixes this stuff soon. The end.

Thanks for reading! If you’ve found this article or my keyboard project useful, please consider buying something for yourself on Amazon via my affiliate link.

Addendum 2014-11-9: Added paragraphs on visual format language and performance to autolayout section.

There were a number of other interesting ways to accomplish the same goal, including Quartz event taps and .keylayout files. You can check out the code, in various states of completion, in my Github repo. (Warning: gnarly code ahead!) ↩
If you want to have equal spacing between a set of views, you need to add an equally-sized set of “spacer” views between them. This is the technique recommended in the official documentation. ↩

When Apple replaced its Google-powered maps app with a complete in-house rewrite for iOS 6, most users had little good to say about it. It was inaccurate. It lacked public transit directions. The search was paltry, as was the iconography. At best, it could be described as slick, with the pixellated pop-in of previous generations replaced by crisp, swiftly scaling vector lines. But this was not enough to offset the lack of functionality compared to Google’s definitive mapping solution, and so Tim Cook apologized and we all went on with our lives.

It’s now a couple of iOS releases later, and over the past year — especially with OSX support in tow — I’ve been frequently finding myself reaching for Apple Maps before going anywhere near a browser. Gradually, Apple has been tending to its garden: improving its data; getting better business listings; making its icons more contextually meaningful. At the same time, in lockstep, Google Maps has been driving me progressively up the wall. And as someone who has had maps.google.com burned into his fingertips since its inception, I can’t help but see this as building towards a major shift in the balance of power in the mobile sphere.

One of the most frustrating issues with Google Maps is seemingly minor, but hits me every time I use it. When you go to open a map, it initially — silently — loads as a static image. After a few seconds, the UI appears, followed by the actual interactive map. But nothing is done to distinguish the fake image-map from the interactive Javascript map, which means that when I first go to drag the map with my mouse, I am inevitably left with a useless thumbnail dangling from my cursor. Every time. Even worse, the UI widgets appear to be clickable during this image phase, but have absolutely no function! The only thing you can do to avoid driving yourself crazy is wait for the tell-tale pop-in that heralds the interactive map — assuming you didn’t miss it on initial load.

The UI just doesn’t seem to work half the time. Widgets always take a long time to load. Popups frequently overlap each other. Controls often stop working, as does dragging the map, forcing me to use the arrow keys to move around. Zoom takes too long to work and behaves erratically, especially if you use the Ctrl+double-click shortcut. Embedded maps only exacerbate all these issues, breaking more stuff and confining you to a tiny, immobile box. Just trying to use the map feels like a Mexican standoff between yourself, the browser, and Google’s byzantine Javascript code.

Google’s own native iOS app never goes above 15 to 30 frames per second. When I first tried the app on release day on my iPhone 4, I figured the performance was a forgivable issue with the 1.0, or that my phone’s hardware simply wasn’t cutting it anymore. But no: even today, on the flagship redesigned version, with an iPhone 5S on iOS 8, everything still runs with this lag. For a while, I figured, OK, Google didn’t want to give us the full, fluid maps experience on their primary competitor’s platform; whatever. Imagine my shock when I picked up a recent Android device, opened Maps, and found that it had the same 15-30fps bottleneck! On their home turf!

Apple Maps, from the start, has been running at a solid 60 frames per second. It’s no joke: you can feel the smoothness in every scroll, every pinch, every rotation. There’s no longer any pop-in, aside from the initial load: when you zoom in, street lines get more detailed and smooth out instead of reloading, indicative of the updated vector graphics. It was widely rumored that one of Apple’s reasons for moving to their own app was that Google wasn’t giving them access to their full vector data, which they were supposedly already using on Android. If true, why is Google’s native app performance so atrocious, even to this day? Why do we still see tiles? Why do streets still have to unblur as you zoom in? If Google is actually using vectors, how are they using them in such a way that still causes these issues?

Speaking of smoothness: gestures in Apple Maps, both on iOS and via the trackpad on OSX, are a dream to use. Pinch-zooming, rotating, and panning have become so ingrained in my muscle memory that I keep trying to do it to Google Maps in my browser window — only to watch my fonts grow a size too big.

When I learned that Google Maps on iOS supported caching maps for offline use, I got excited. Now here was a great feature that Apple Maps would probably never offer! Well, how’s this for irony? Although Apple doesn’t explicitly allow offline caching, it does, in practice, cache large swaths of map that you’ve recently viewed. I’ve been using my phone offline for the past few months, and in every city I’ve been to, I’ve gotten beautiful offline maps of the area after peeking at the surroundings in Wi-Fi mode. There’s no blur: I can zoom in with no apparent loss of street names or any other detail. Perhaps it’s a bad idea to rely on a cache that may theoretically invalidate at any time, but in practice, it works great.

In Google Maps — an app, I must remind you, that explicitly supports offline mapping— saved maps don’t actually seem to work much of the time. I was unfortunate enough to discover this while walking around in a foreign city: upon opening my saved Google map, I found a blurry mess of pixels with no labels whatsoever. (Fortunately, Apple’s cache saved me from having to ask for directions.) To be fair, sometimes the maps do load, but I can’t seem to trigger this behavior deterministically. Even better, offline maps sometimes “expire” at arbitrary times, rendering them unusable. (The official expiration time — why even have one? — is about a month, but I’ve seen maps expire earlier than that for no reason.) Finally, for reasons I don’t understand, not all areas are cacheable. That’s right: if you try to save a map in Slovenia, you’ll be hit with an “area not available” error, even though you can save maps in Croatia by stepping over the border! What a mess.

So what about the elephant in the room: public transit? The lack of public transit directions on iOS is definitely a deal-breaker for me, and Apple’s kludgy third party solution just doesn’t cut it. (To remind readers: if you select public transit directions in Apple Maps, you are given the option of sending your request to any app that supports the transit directions API, or alternatively searching the App Store for one.) However, with the release of third party extensions, I think Apple has a tremendous opportunity on their hands. Although it’s convenient to have all your public transit directions curated by a central party, it’s hard for one organization to keep tabs on every public transit system in the world. How many bus lines are out there? Thousands? Google Maps mostly works in this regard, but I have on more than one occasion run into situations where the directions were inaccurate, misleading, or missing. Even Google can’t extend its feelers to every little city around the globe.

On the other hand, local transit apps are not only accurate and up-to-date, but can even offer cool features like real-time arrival times and GPS tracking. It’s also pretty easy to find them: Apple already lets you see what apps are most frequently used in an area. But these apps aren’t able to integrate with system-wide services: you have to either open them separately or load them via Apple’s kludgy Maps hook, making them inconvenient for everyday use.

So here’s an idea. What if Apple kept its third party transit direction support, but instead of having public transit directions open up in a separate app, brought that information directly into Maps itself?

Just a year ago, this would have been inconceivable. But today, with third party extension support, it would be a perfect fit with Apple’s strategy. Extensions go through specific, resource-constrained “extension points” to avoid hogging system resources, and Apple explicitly put future extension points on the table in their keynote reveal. How about this? With transit extensions, you could have an app transmit local, up-to-the-minute timetables, GPS markers, and other metadata for public transit services right into any native Maps view!

This isn’t something that Google could implement with its centralized, web-centric approach. But it’s almost obvious with Apple’s app-based infrastructure. All the pieces are already in place; all they need to do is give developers an API for it. I don’t think this would necessarily obviate the need for centralized, curated public transit directions, but it would be a great way to augment and future-proof such an offering.

There are still many problems with Apple Maps. Bookmark management is a nightmare. Getting directions between arbitrary points is nearly impossible. Things like subway stations are poorly delineated. But these are not high level problems; they are easy problems to fix, and Apple has progressively been fixing them. And so, I’m crossing my fingers for an amazing future where I can open Maps, switch over to satellite view, and have a private little “supervillain” moment as I watch the bus and train pins moving around the city, slowly etching out their hard-worn routes, in real-time.

All at a buttery 60fps.

I’m sure bad at this blogging thing. Since I first set out in — technically, July 2013, but let’s say August — I’ve only gotten one week into my journey before hanging up. I’d like to see if I can try again, perhaps this time with a little more success.

Right now, I’m writing this from Dublin, Ireland. In the interim, since my last entry from an actual city, I’ve visited Vancouver, Toronto, Montreal, Quebec City, New York, Boston, Philadelphia, Chicago, New Orleans, Austin, Los Angeles, Barcelona, Paris, London, Cornwall, Bath, Oxford, Cambridge, York, Newcastle, Edinburgh, Amsterdam, Luxembourg, Prague, Berlin, Vienna, Ljubljana, Zagreb, Split, Bologna, Modena, Milan, Florence, Rome, and Turin — plus a number of smaller towns along the way. That’s more than a dozen different countries over the course of the past two years. To the person first setting out on this trip — the person who expected to arrive in London and cautiously venture to other countries only on rare occasion — this list would have been unimaginable. I was nervous. I’d never been alone in a place where the primary language wasn’t English. I wasn’t sure about the logistics. I didn’t even know if I’d be able to tinker with my projects in peace.

But it’s all worked out. I’ve cracked the code. With some trial and error, I’ve figured out how to live affordably and comfortably in different cities around the world. I’ve gotten a lot more bold about venturing to places where I have to resort to broken apologetic phrases in a new language. I’ve discovered many breathtaking sights, incredible architectural wonders, and fascinating local tastes. I’ve pared my belongings down to a bare minimum appropriate for most climates. I’ve worked in many lovely cafés, bars, and apartments. I feel like I understand so much more about the world than when I started.

On the other hand, I’ve also had to face certain facets of myself head-on, with uncertain results. I’ve learned that my impression of different cities around the world was heavily painted by my childhood imagination. The places I’d hoped would bring my soul some peace — a magical sort of quality that I faintly recall in cities like London, Barcelona, and Rome from when I was little — were found to be fairly ordinary in contrast. I’ve found it disheartening to overwrite so much impressionistic imagery in my head with reality — because I know those feelings will never be back. I’ve learned that no matter how lonely I might get at times, there is still no part of me that will seek out others for company. I’ve learned that I can swallow up entire months at a time and wake up on the other end a good chunk older, but with nothing to show for it. All the attributes I hated about myself as a young teen are still there, entrenched, and at this point as much a part of my personality as anything else. I’ve learned that there are parts of me that I constantly have to fight, lest I end up old, unfulfilled, and alone.

I’ve also learned that time moves quickly, and that it’s easy to get stuck in a simple routine. I’ve developed a great, burning fear that prods me almost every waking minute. The fear of aging. The fear of death. The fear of it “being too late”. Every day, I count the fractions of my age. 26 point 0. Point 25. Point 3, repeating. Every day that I’m not doing something productive — which is most days, to be honest — I feel like I’m actively destroying my potential. Other dates have been creeping into my head, too. How old is too old to live in a house with other people? How old is too old to get married? To have kids, if I decide to have them? To have a nice house, friendly neighbors, warm dinner parties? When I was in college, I half-jokingly feared that my study habits — put it off, put it off, then half-ass it on the last day — would translate in broader strokes to the rest of my life. But now I see that this was no joke. This is exactly what happens when you let a negative aspect of your personality fester for years and years.

But these dark thoughts are not a reflection on travel. My journey has neither been a negative experience nor an entirely positive one. I see it as just another page in the book of my life: many new and interesting inputs from the environment feeding into the black box of my mind, allowing me to discover new truths about the world and myself.

So that’s what’s going on in my head on this day, January the 31st, 2015, in the city of Dublin. And now, let’s step back into the past, to Vancouver, as it was during the last few weeks of August of 2013…

(Technical note: from this point on, I will be posting all my blog entries on the beta-blog subdomain of my website. They will be linked from the main site, but I highly suggest reading on beta-blog instead. Eventually, the main site — hosted on Squarespace — will be removed, and the beta-blog page — hosted on Github Pages using a static site generator — will replace it. I will backport all the existing entries before I do that, and all the links should still hopefully work.)

On August 23rd, 2013, my Seattle friends and I boarded the Amtrak Cascades and headed up north in the direction of Vancouver. I couldn’t resist bringing along a small bag of produce and dairy that I’d been using to cook in the hostels, even though it added a few pounds of heft to my already-painful load. (This pattern will be shown to repeat itself throughout my travels.)

The ride was clean and beautiful. We planted ourselves in the observation car for most of the 4-hour trip. Dangerous electric tea was made. I was introduced to a devious card game called Bartok, in which each player adds a new, arbitrary rule during their turn. Every time a player breaks a rule or asks a question, they draw a card. As you might expect, it gets a little bit crazy.

Half an hour from the border, I realized that I was woefully underprepared for my customs interview. What was I doing? Where was I going? Should I have brought some printouts of my itinerary? Did I need to hide my butter?!

The border agent gave my slightly disheveled self a stern look before letting me through. Little did he know of my contraband!

I booked into my hostel, while my friends checked into a hotel in a… slightly seedy part of town. (Given how high Vancouver is rated in terms of life satisfaction, I didn’t even know it had seedy parts!) We had a good laugh observing some friendly neighborhood drug dealers from the hotel room’s 3rd story window.

So… Vancouver! What’s it all about?

Well, it’s a peaceful little city. Stanley Park is lovely to walk through, and it seems like there’s a lot of interesting restaurants and other businesses. (Once place I want to give a shout-out to is Fritz European Fry House. I don’t think the poutine there was “real” — the cheese curds were kind of melty — but it was still some of the best poutine-like stuff that I tasted during my Canadian trip.)

However, much like the last time I visited, it didn’t strike me as a city I wanted to spend too much time in. The architecture was kind of drab, and the whole place had an overbearing “new development” feel. Not cozy. Didn’t warm the heart. I don’t know how else to put it.

However, I’m very thankful for the company I had. The trip wouldn’t have been the same without it!

Onward we go… aboard the VIA Rail.

It’s disappointing to see many of my favorite Apple bloggers devote so much of their time to Apple Watch Edition gossip. How much of it is going to be solid gold? Will it be $5000, $10000, $15000? How much of them will Apple sell in their first quarter? Will they be a hit with the rich and powerful in China?

My question is: why in the least bit should us techies care? Sure — catering to the unfathomably well-off will make an impact on Apple’s fortunes in the long run, and spinning out into a fashion brand might make the company grow at an even more breakneck pace. But I was under the impression that we were Apple fans in the first place because they made best-in-breed products for everyone, not just the elite.

We loved our iPods and iPhones for their sleek design and smooth UI, even when people dismissed them as “expensive toys”. We knew our $2000 laptops were incredible for the price, even while people mocked us for not buying cheap, creaky Windows machines. When Android and Windows users poked fun at our platforms for lacking in free tools, we lauded the benefits of carefully crafted, paid-up-front software. We let our Apple logos shine bright because we were proud to be affiliated with one of the few companies that seemed philosophically bent on setting a new standard for mass-market products.

There’s a good reason why the tech community might have a “shit-fit” if Apple enters the realm of $10000 watches and $2000 bands. Gruber’s word choice makes it sound like a juvenile reaction by the fashion-unconscious. But that’s just the thing. We’re geeks. We believe in the intrinsic value of things. We’ve always made fun of name-dropping headphones and $1000 shirts when the quality couldn’t match the hype. Apple taught many of us that there’s more to the price of an item than just the cost of materials; design can be worth a lot, too. But we’ve been adamant for years that we bought Apple products because they were good, not because they were fashionable. And now, with the Beats acquisition and these gold-encased watches, Apple is showing signs that they no longer want to be bound by intrinsic value.

Conspicuous consumption? Veblen goods? Roped-off areas in Apple stores? Is this is what the indie Mac community is going to talk about now?

An Apple that sells “bling” to billionaires is not a company that many of us could muster any passion about. Maybe Woz had the right idea all along.