Date Arithmetic in Swift

Since Manifest is a time tracker, it does a fair amount of date arithmetic. Cocoa has excellent support for creating and manipulating dates, but it's not a very lightweight API. To make things easier, I wrote a small Swift wrapper that lets you do things like this:

let tomorrow = NSDate() + 1.day()
let lastYear = NSDate() - 1.year()

I've released it as a small open source project, which you can grab on GitHub. More detailed documentation is available there as well. Suggestions and feedback welcome!

Introducing My New App: Manifest

I'm happy to say that I can now give some more details about the new app I've been working on. It's called Manifest, and it's a time tracking app.

As I discussed in my original post about the app, Manifest was largely born out of a desire to work with new tools like Swift. Likewise, the choice of what kind of app to build is the result of my own needs. I often need to track how I spend my time while working on client projects, and other apps don't quite suit my workflow. People often tell authors to write what they know, and I think the same goes for software developers.

One of the things I've really enjoyed about this project is how many ideas I've come up with for future features. I have the launch feature set mostly locked down, but there's a long list of stuff I want to add in later updates. I take that as a great sign that I've picked an interesting project, and that I'll be able to keep making the app better for users.

While it's not finished yet, it's coming along quite nicely. I hope to be in beta very soon, with a release date not long after that. If you're interested in getting notified when Manifest is released, I've created a low-volume mailing list you can join below.

My New App as a Kindling Project

Ned Batchelder:

Kindling projects are meant to fill this gap: simple enough that a new learner can take them on, but with possibilities for extension and creativity. Large enough that there isn't one right answer, but designed to be hacked on by a learner simply to flex their muscles.

Ned is mostly talking about new programmers, but this is quite similar to what I had in mind when I started my current app project. The idea was to get some experience working with Swift as well as a few other technologies that I haven't worked with extensively in the past. Even though I'm not new to programming, we're all relatively new to Swift. So far, the project has been a great success in that regard. Having something substantial to work on has really given me a feel for Swift's strengths, weaknesses, and challenges. (More details on those in a future post.)

As the app gets closer to completion, I've also been thinking about goals in terms of downloads and revenue. I'm not going to share exactly what those goals are, at least not yet, but I do have some. (I'm keeping them modest, at least for the time being.) Charles Perry's recent post about App Store revenue gives me some hope that they could be achievable:

There’s a lot money circulating in the ecosystem, and a developer operating at indie scale only needs a little bit of it. It seems that even with the revenue curve tilted so heavily towards the big hits, the shape of the App Store still allows room for sustainable businesses to develop in the long tail.

This "kindling project" isn't just about learning a new language or new frameworks; it's also about learning more about the App Store. How might different pricing strategies affect revenue? What will the trend in sales be over time? This project is an opportunity to do some hands-on research.

Video and iOS Rotation Lock

One result of iOS 8's size classes is that lots more apps support landscape orientation, and I have a confession to make: It drives me bonkers. I almost never want to use my phone in landscape. It used to be that most apps only supported portrait orientation, so it was no problem if you tilted the phone a little too far. It might send a rotation message to the app you were using, but the app would just ignore it. That means I could read Twitter while lying on the couch without worrying that the screen would suddenly rotate if I tilted a couple of degrees too far. In iOS 8, I find myself more and more tempted to use the rotation lock feature.

In fact, I leave auto-rotation enabled for one simple reason: video. Most video fits far better in landscape orientation than in portrait. The iPhone's screen is perfectly shaped for wide-aspect video in landscape. Unfortunately for me, iOS won't rotate video into landscape orientation unless it can rotate the whole OS into landscape. Put another way, if I use rotation lock to keep the phone in portrait orientation, that applies to video as well. That means video gets letterboxed into a postage stamp-sized area in the center of my screen.

I see how the behavior makes intuitive sense; it's the easiest to understand and doesn't require any weird special cases. iOS simply presents all interface elements so that they're oriented right-side-up relative to the device.

But video is a special case. It's displayed full-screen, so you don't have to worry about other interface elements. (There are elements like player controls, but they hide automatically after a few seconds.) It's far more likely to be sized for a landscape-oriented screen. People often rotate their phone to watch a video, then rotate back to portrait. If you have rotation lock enabled, there are quite a few extra steps involved: Open Control Center, disable rotation lock, close control center, then repeat the process to re-enable rotation lock after the video ends.

One way to deal with this would be for iOS to automatically present full-screen, landscape video in landscape orientation, regardless of the device orientation. Opening a video with the device in portrait orientation, the video would at first appear to be "sideways." Just as they do now, most people would simply turn their device to see it in the proper orientation. I don't think it would be all that confusing.

Alternatively, iOS could ignore the rotation lock setting for full-screen video playback. Users could leave rotation-lock enabled, but video players would still auto-rotate with the device as though rotation lock were off. When the video ended, the phone would revert to it's rotation-locked orientation. Nothing would change about the way things work with rotation lock off. In other words, video would auto-rotate even with rotation lock enabled.

Of course there are a few edge cases and gotchas to both of these solutions, but they'd both be an improvement over the status quo. Especially given how wonky activating Control Center can be, there should be an easier way to deal with video playback orientation then turning rotation lock on and off all the time.

Thoughts on Video Content

David Smith, a (local!) iOS developer I really admire, recently started doing a series called As I Learn WatchKit documenting his experiences developing for the Apple Watch. He's also been experimenting with video posts, which got me thinking about video as a medium for conveying information in general. (Most of my thoughts about video could be applied to audio as well.)

I'm really of two minds about this. On one hand, video can be great for demonstrating things visually that are hard to describe in words. (The old adage "A picture is worth a thousand words" exists for a reason.) Video can also help to present complex topics, because information is conveyed relatively slowly in a structured narrative. (I'm imagining a great lecture by a talented professor, for example.)

On the other, text has a lot of advantages over video. It's searchable, and if you're looking for a specific piece of information, it's easy to skip right to it. Most people also read more quickly than the spoken word, meaning it's possible absorb more information quickly in written form. You can also skim the text to see if it's what you're looking for before spending the time to absorb the whole thing.

I often finding myself referring to ASCIIwwdc when I need to refer to Apple's WWDC sessions. The sessions are fantastic, and in general I highly recommend watching the videos, but there are times when I just need to grab a quick snippet of information. Without searchable text, I'd be stuck scanning through sessions looking for what I need. Moreover, I'll often use the text as the starting point to see if a particular session covers what I think it covers, so I don't accidentally spend an hour watching the wrong one.

Similarly, I sometimes find myself clicking on a link on the Washington Post web site, only to discover it's a piece of video content. When that happens, I'll usually close the tab. With text, I often want to scan the start of the article before I'm sure I want to read the whole thing in detail. With video, there's no good way to do that, and so I bail out unless it's a topic I'm extremely interested in.

On the whole, I think I enjoy audio and video most for two kinds of content: narrative (e.g. movies or documentaries) and discussion (e.g. a podcast). In both cases, the experience of watching or listening to the content is usually as much the point as the content itself. For example, a big part of why I enjoy listening to ATP is the back-and-forth between Marco, John, and Casey. It wouldn't be as much fun in written form, and I think would lose a lot of the nuance conveyed by hearing their actual voices. But even in that case, I've occasionally found myself wishing for a transcript of ATP shows to refer back to a particular point.

Of course, a transcript isn't practical in most cases - they're time-consuming and/or expensive to generate. A companion article would usually be needlessly duplicative. So, what to do in cases where you want to use video? I suggest providing a short outline of the video's contents. Key terms helps with search, and an outline lets users do a quick scan of the content before committing to watching the whole thing. Even better, the outline could contain rough time indices, so it's possible to skip to a particular section of the video. In many ways, the outline would function similarly to the show notes published by some podcasts. Hopefully, that would give viewers the best of both worlds without generating too much overhead for the video producer.