Now I’ve finally released Manifest to the world, it feels like a good time for a bit of a retrospective. In no particular order, here are a few thoughts I had during the development process:

Scope Creep

One of my goals for this project was to avoid getting bogged down and ship something on a reasonably quick schedule. I’d say I was only partially successful. Even though my plan was to keep the feature set limited at the outset, I also really wanted Manifest to feel like a complete product. I had to constantly tell myself that I should keep my focus narrow for 1.0 and then focus on adding all these interesting additional features in future updates. It’s easier said than done. I do think I ultimately succeeded, and I have a great backlog of stuff to add in future versions, but I was surprised how difficult it was to keep the scope in check.

Swift

One of my goals for Manifest was to develop an app entirely in Swift, and I succeeded. (All the new code is Swift. I did use a few open-source libraries and small modules I’ve written in the past that remain Objective-C.) All in all, I really enjoyed working with Swift, and I do think it added to the stability of the code. When I go back to other projects in Objective-C, I find myself missing a number of Swift features, particularly Swift’s robust enums, structs, and protocols.

There were definitely a few annoyances. CocoaPods support was shaky at first, but is now much improved with the release of CocoaPods 0.36. Xcode’s SourceKit helper crashes constantly, which messes up all manner of things, and doesn’t always restart quickly or cleanly. Error messages aren’t always clear. At the same time, these things are clearly improving rapidly. Apple introduced a slew of helpful changes with Swift 1.2 and Xcode 6.3 beta, and it’s clear the team is working hard to address problems both with the language and the tools. I suspect changes will start to settle down sooner than many people expect. I probably wouldn’t recommend using Swift in a client project right now, but that day is fast approaching.

I also want to include a shout-out to the Swift team and Chris Lattner in particular for the forthright and comprehensive release notes that accompany changes in Swift. They take the time to give examples alongside syntax changes, as well as provide insight as to why changes were made. It’s a level of transparency that we don’t always see from Apple, and it makes me feel great about the future of the language and the platform.

Design

I like to think I have a decent eye for design, but I’m not an artist by any stretch. Icons are a particular challenge for me, and I’m sure I’m not alone in this regard. I found myself wishing for a service that could match developers with designers who are open to taking on small projects – a handful of icons, or maybe just an app icon. The big-budget design firms are beyond my means, and my project would probably be too small for them anyway. I’m willing to pay a fair price to a designer to help me out where my skills are weaker, but simple Google searches aren’t likely to turn up the kind of freelance or small design shop I need. Is there a service that can help with this kind of thing? What resources to other developers use when looking for design help?

Analytics

I thought about using a number of different analytics packages in Manifest: Mixpanel, Google Analytics, Flurry, Heap, and others. Ultimately, I decided not to use any of them. First and foremost, a lot of these services struck me as a little creepy. They collect a lot more data than I want, and it’s often difficult or impossible to opt out. They also add a dependency, and integrating them well takes time that I could otherwise use to work on new features. Finally, I’m not confident that the data they collect will really lead to a better product. I’d rather solicit feedback directly from users (seriously, I’d love to hear from you on Twitter!) than try to guess what people want based on analytics data. I’m not saying that I’ll never add analytics of any kind, but for now, I just don’t think they’re worth it. I am using Crashlytics, because crash reports are important, but that’s it. (An aside: What in the world happened with the iTunes Connect analytics that Apple announced last year?)

I’m proud to announce that Manifest is now available on the App Store. It’s free to download and try, so go grab a copy now! I’m proud of how the app turned out, and there’s a lot more to come in future updates.

Here’s an overview of a few of my favorite features:

Notification Center Widget

Tracking time is, almost by definition, something you do while in the midst of other tasks. To make that easy, Manifest has a widget that you can install in the Today view of iOS’s Notification Center. (Tap the Edit button at the bottom of the Today view to add Manifest.) You’ll see a list of today’s timers, and you can start and stop them with a simple tap. There’s also an Add Timer button that will launch Manifest so you can set up a new timer.

Quick Timers

I often use the same project and task combinations over and over again. For example, while working on Manifest, I had a project named “Manifest” and a task named “Design.” Rather than create a new timer and manually picking the project and task each time, you can use the Quick Timer menu to re-create a past timer. (Look for the lightning bolt icon in the upper left.) It’s a small thing, but I find it comes in quite handy.

Round Off Time

Like most people, I round my timers off to a nice whole number – in my case, the nearest 15 minutes. Manifest makes that easy. Just swipe from left to right on any timer to round off. You can also customize the interval that your timers round off to on the Settings screen.

There’s also a single, one-time $4.99 in-app purchase to unlock pro features, which includes unlimited projects and tasks, as well as unlimited data import from a CSV file.

Have ideas for new features or improvements to existing ones? Hit up @Manifest_iOS on Twitter. I’d love to hear from you!

I’m happy to announce that Manifest will launch tomorrow, March 19, on the App Store. The app will be a free download, with a one-time in-app purchase to unlock a set of pro features. You can follow @Manifest_iOS on Twitter for updates on the launch, news about new features, tips and tricks, and more. I’ll post a link to the App Store page here tomorrow.

Many thanks to the folks who helped beta test the app. Your feedback was incredibly valuable and definitely improved the final product!

The New MacBook

I don’t have a whole lot to say about the new MacBook. For users who prioritize size and weight, it looks like a great choice. I’d even go so far as to recommend it to most people I know. It sounds like a great general purpose computer. But it’s not for me. I need the greater processing power, RAM, and screen real estate in the MacBook Pro. (I do think the updated 13″ Retina MacBook Pro sounds appealing. I have a first-gen 13″ rMBP and like it quite a lot.)

Apple Watch

When the Apple Watch was first announced last fall, I wasn’t quite sure what I thought about it. As time as passed, I’ve gotten more excited to try one, and I’d say I’m cautiously optimistic about its potential.

I’m not sold on the idea of the Watch as a messaging device, at least not for text or voice. Who wants to be dictating messages aloud to their watch? Part of what makes texting so appealing is that you can do it in public without other people overhearing your conversation. (For example, I don’t recommend using Apple Watch to gossip about the crazy mustache on the guy in front of you in the airport security line.)

One feature that did catch my eye was the ability to activate Siri without pressing a button. It’s something I can imagine using all the time. For example, I often use Siri to set timers while I’m cooking, but sometimes my hands are dirty and I don’t want to mess up my phone. With the Watch, I should be able to simply say, “Hey Siri, set a timer for 10 minutes.” No fuss, no muss. (Literally.)

A friend asked me yesterday why he’d need an Apple Watch. The simple answer is, he doesn’t. Nobody does. I don’t think we’ll get a good handle on how useful (or not) the Watch will be until we’ve had a chance to try them out for a bit. At minimum, it fulfills the roles of a traditional watch and step tracker in one package. (I’ve already replaced my Jawbone Up24 once under warranty, and the replacement is starting to break down as well.) Some of the features will be duds, and others will be unexpected hits. Much like the iPhone, a lot will also hinge on what developers do with it.

Fortunately for me, it’s pretty easy to justify taking a chance on the Apple Watch. As a developer, I need to get a feel for what it’s like to use the Watch so I can make good recommendations to clients. (I already have people asking about developing Watch apps – a good sign for the platform, I think!) Although I’m tempted by the stainless steel model, my plan is to go for an entry level Apple Watch Sport this time around. If I find that I use the Watch a lot in my daily life, I might spring for stainless next time around. (I’m assuming the Watch will be updated on an annual schedule like the iPhone and iPad. I also imagine they’ll make some significant hardware strides in the first few years.) I have fairly small wrists, so I’m almost certain the 38mm model will be the way to go.

HBO Now

I’ve often criticized HBO for failing to sell it’s service directly to consumers instead of through cable companies. They remedied that failure with HBO Now, and I commend them for it. Now people who want HBO’s content can get it regardless of whether they’re interested in everything else that comes along with cable TV. (And, importantly, it’s now possible to get HBO content without having to talk to your cable company. I’m looking at you, Comcast.)

However, I don’t think it brings us all that much closer to a world where we all save money through “cord cutting.” The reason is simple: bundling. Cable companies could always adjust their pricing so that it’s impossible to save a significant amount of money by dropping TV service. It’s not hard to imagine a pricing model where cable TV and internet together cost, say, $120/month, but internet alone costs $100. This probably sounds familiar to anyone who’s ever been pitched adding “digital phone service” that they’re never use as a way to save money with a three-service bundle. Sure, we may soon be able to cut the TV cord, but I doubt we’ll save much money doing it. (Like many Americans, I have almost zero choice when it comes to TV and Internet service at home.)

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!

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.

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.

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.

Developing in Swift can often mean dealing with multiple levels of optional unwrapping. It’s messy and it’s annoying. Colin Eberhardt’s post got me thinking about better ways to deal with this, and he has some suggestions that work without modifying the language.

I think it’s worth making some tweaks to how optional unwrapping works, and I have two suggestions. Here’s an example of a fairly common scenario:

var a: Int? = 1
var b: Int? = 2
var c: Int? = 3

if let realA = a {
    if let realB = b {
        if let realC = c {
            let sum = realA + realB + realC
            println("Sum: \(sum)")
        }
    }
}

Unwrapping gets pretty cumbersome. The first problem is this deep nesting. Many times you don’t really want to do anything if the optional is nil, you just want to handle the case where all of the variables have a value. Why not allow if-let to include multiple terms, the way you might with any other if statement, like so:

var a: Int? = 1
var b: Int? = 2
var c: Int? = 3

if let realA = a && let realB = b && let realC = c {
    let sum = realA + realB + realC
    println("Sum: \(sum)")
}

Secondly, it’s often irritating to come up with another name for the unwrapped variable, and you sometimes even see developers do things like if let a = a. In this case, the name a represents the unwrapped optional inside the if statement. Why not allow the language to do something like this:

var a: Int? = 1
var b: Int? = 2
var c: Int? = 3

// Equal to if let a = a && let b = b && let c = c
if let a && let b && let c {
    let sum = a + b + c
    println("Sum: \(sum)")
}

It keeps the functionality of optionals in place, and adopts some of Swift’s conciseness, while making the code less leggy. I’ve filed a Radar that you can dupe if you agree.