Manifest 2

I'm incredibly pleased to announce that Manifest 2 launches today. It's a big update focused on goals and time management, and I think it'll be very useful for freelancers and indie developers in particular.

TIME MANAGEMENT

A lot of freelancers and indie devs like me need to juggle time commitments between multiple projects. Manifest makes it easy to keep sight of the big picture by introducing goals. Simply set how much time you want to spend on each project per week or month, and Manifest breaks the time down into manageable daily goals. Using it during development, I've found goals to be incredibly helpful in managing my daily schedule and making sure all my clients get enough attention.

TODAY TAB

The Today tab tracks all your daily projects, their goals, and your progress. As you track time, Manifest shows your progress for each project and for your day overall. Once you’ve reached your goal for a project, it dims so you know to move on to other things. The Today tab also tallies the day's total time tracked, your projected total time by the end of the day, and whether you're on pace to reach your daily goals.

SMART GOALS (Pro)

Pro users can take advantage of Smart Goals, which make the Today tab even more powerful. Smart Goals automatically adjust when you're ahead or behind schedule, so you'll know if you have extra time to devote to other projects.

For example, suppose my goal is to spend 20 hours per week working on a project for Acme Corp, which would normally break down into a goal of 4 hours per day. By Thursday evening, I've already tracked 18 hours of time. With Smart Goals, Manifest automatically adjusts my Friday goal to 2 hours. Now I know I have time for other things (or happy hour!)

CHARTS AND TIMESHEET

Sometimes it's easier to grasp information visually, so Manifest includes charts tracking your logged time across the current week or month. They're a great way to see patterns in your data. There's also a total time chart that shows a month-by-month indicator of your total time, as well as a projection for the current month.

On the other hand, there's no more familiar way to look at time than that old stand-by, the calendar. Manifest has you covered with the Timesheet. Each day on the calendar shows your total tracked time, and below the calendar is a detailed list of your projects as well as any notes you entered. You can also export your data into CSV format from the Timesheet view.

PROJECT ARCHIVING (Pro)

Manifest can archive your inactive projects to keep things tidy. Archived projects don't show up on the Today tab, but any time you've recorded will still be displayed on your timesheet.

PRICING

Manifest 2 uses a new subscription-based pricing model. For $3.99/month or $29.99/year, you get access to all the Pro features, including Smart Goals, archiving, unlimited projects, and customized data export options.

I wanted to talk a little bit about why I chose to move to a subscription pricing model. There are essentially two reasons. First, subscriptions create sustainable revenue that allow me to spend more time working on Manifest. I love working on Manifest, but I also have to pay the bills around here. Relying on a constant stream of new users probably isn't going to cut it, and means I always have to be concentrating on growth. I'd much rather focus my energy on improving Manifest for a smaller pool of returning users who love the app.

Second, subscriptions make it easier to try out the Pro features to see if they fit your needs. Try a monthly subscription, and if you discover that Pro isn't your thing, you can always cancel. On the other hand, if you enjoy Manifest Pro as much as I do, the annual subscription is a great deal for the whole year.

I've been working on this Manifest update for several months, and I'm really proud of it. I hope you enjoy it as much as I do! Manifest 2 is available now on the App Store. Suggestions and constructive criticism are always welcome - find me on Twitter or email at feedback at tapandtonic dot net. Thanks and enjoy!

Seeking Beta Testers

I'm wrapping up development on a major update to Manifest, my time tracking app for iOS. In order to make sure that the app is stable and easy to understand, I'm looking for beta testers to help put Manifest through it's paces.

The update is focused on setting and reaching goals as you track your time. Manifest is a great app for freelancers and independent developers who need to track time across a number of projects.

If you're interested in joining the beta, please sign up!

Sign up for Manifest Beta

How Apple Can Improve the Apple Watch Without New Hardware

I wrote recently that I've been somewhat disappointed in the first generation Apple Watch. A lot of that has to do with the limitations of the hardware, but a sizable part is related to the software as well. Apple can only release new hardware so often, but they can update the OS much more frequently. Here are a few areas where I think there's room for significant improvement without new hardware.

Context Awareness

Right now, the Apple Watch does pretty much the same things regardless of the time, your location, the weather, etc. For a "smartwatch," the Apple Watch isn't all that smart. But the Watch has access to a trove of data about you and your habits via your iPhone, and it could take advantage of that data to act smarter. Imagine if the Watch could switch faces based on whether it's a weekday or weekend, or show different complications based on whether there's bad weather in the forecast. WatchOS could automatically re-order your Glances to load the most relevant ones first - for example, showing the MLB Glance first if your favorite team is in a tie game in the bottom of the 9th.

Complications could also improve a lot by including some contextual information. For example, the Timer complication is great when I have a timer running. When I don't, it just sits there displaying "SET" and taking up space. Users could assign priorities to complications, so that another could appear when one has nothing to show. If no timer is running, the weather could appear in its place. Even better, the OS could make some smart decisions about which complications to show. If I'm traveling, I might be more interested to know the current time back home than in the current moon phase. Likewise, if it's Friday afternoon and my schedule is clear for the weekend, I might be more interested to see what tomorrow's weather will be like. Giving developers access to context information could help apps provide context and priority clues to the OS.

Re-Think the App Launcher

Let's face it: The app launcher on the Apple Watch is a mess. The tap targets are too small, even on the 42mm model, and organization is difficult at best. It's a far cry from iOS, where a simple grid of icons has served users well for years. The honeycomb-style app launcher on watchOS feels like Apple prioritized how it looks over how it works. It's possible that the real answer here is to re-think the app model itself on the Watch. But that's a huge change, and there are a few improvements Apple could make without fundamentally re-thinking whether apps make sense on the Watch.

If anything, a tiny display like a watch is most suited to something like a simple grid. The Watch would be a great place to use the same predictive technology that iOS uses to suggest apps on the search screen. Imagine that clicking the crown presented you with a grid of apps based on a number of contextual clues, like your current location or how recently you launched the app. I'm guessing the most Watch owners only use a handful of apps at most, so chances are good that the first screen would contain the app you're looking for. (This is the app you're looking for.) If you're looking for something more, you could swipe through additional pages of apps ordered however you like, much like iOS.

Make Better Use of Hardware Buttons

How often do you really want to send a drawing or heartbeat to someone using your watch? If you're like me, almost never. On a device that has only two physical buttons, it certainly seems like a waste to devote one of them to a communication panel that almost always goes unused. At the very least, I'd like to see Apple let users assign that button to another function. Alternatively, it could bring up another menu (perhaps Glances?) that might be used more frequently. The same goes, at least in part, for the crown itself. Fixing the app launcher would help make it feel like clicking the crown at least opens something useful.

More Watch Faces

Watch faces are one of the most fun aspects of the Apple Watch. The face is the part of the watch I see the most, and a new face can make it feel Iike a new device. I have a few faces that I use often, ranging from a Modular face with lots of data to a minimal utility face that feels more stylish.

Unfortunately, there aren't as many faces as I'd like. Apple added a few new ones when watchOS 2.0 came out, but most weren't faces that I'd use regularly. So far, watch faces haven't been opened up to third party developers, and I think I understand why Apple is proceeding cautiously on that front. But if Apple is going to keep watch face development to themselves, I wish they'd help us out and release a few new ones! They've refreshed the lineup of Apple Watch bands every six months or so, and it'd be great if faces were on a similar schedule. There are so many styles, colors, fonts, and configurations to work with that it's hard to believe they're out of ideas.

Ultimately, a lot of the limitations of the first Apple Watch relate to the hardware. The CPU is too slow and/or the battery too small for the watch to be as snappy and responsive as I'd like. At the same time, a few software updates can go a long way. I hope Apple has enough of an open mind about the Apple Watch as a platform to re-think some things about how it works. Even with the same limited hardware, it could be a much more useful device with a few relatively small changes.

Considering an Xcode for iPad Pro

Lately I've been giving some thought about what it would take for me to be able to replace my laptop with an iPad. I do most of my day to day work at a 5K iMac. I only use the laptop for work when I'm traveling or need a change of scenery. For example, yesterday we had some beautiful weather here in Washington, DC, so I spent some time working at an outdoor table at Starbucks.

An iPad wouldn't need to be as fast or capable as my desktop computer, but there is one big requirement: Xcode. As an iOS developer, I spend a huge amount of time in Xcode. Without it, I can't get very much work done on the iPad. Fortunately, there have been rumblings lately that Apple is developing a version of Xcode for the iPad. I hope that's true, and I gave some thought to some of the areas Apple would have to tackle in order to pull it off.

Text Editing

Of course, a lot of time in Xcode involves manipulating code via a text editor. This is probably the easiest thing to get right. There are many capable text editors on iOS today, and there's no reason Apple couldn't build one into Xcode.

Interface Builder

Many apps are laid out using storyboards in Interface Builder. Developers can drag and drop interface elements and set up constraints that define how they relate to one another visually. It's a great (and occasionally frustrating) tool that offers a ton of fiddly options and settings. Interface elements can be large or very small – as small as 1 pixel in length or width.

At first I thought this might be a deal-breaker for Xcode on the iPad. Manipulating tiny UI elements with precision isn't something that wide fingers are good at in the same way that a mouse is. Sure, zooming and panning could help, but that seems like it might be time consuming and unwieldy. Then I realized there's another solution: the Apple Pencil. I don't think it'd be required, but the Pencil might be ideally suited for this task. Just like making a detailed drawing, developers could use the Pencil to edit small elements with precise detail. Panning and zooming would still be an option for developers who don't own a Pencil.

File Handling

There's no getting around it: Developing apps involves working with a lot of files. You've got source code files, storyboards, icons and images, database schema, and more. Not only do developers need to organize the files within their project, they often also need to add them from other sources. For example, a designer might send me an updated set of icons for an app I'm working on. I need to import those into Xcode, replacing the existing set or adding them as necessary. That means Xcode for iPad needs robust support for moving files into (and out of) the app, something that iOS apps haven't always been good at.

There's also the question of where project files will be stored. I'm still not comfortable using iCloud Drive for critical applications. Other document storage providers like Dropbox don't always support two-way editing, so opening files in an app creates a copy instead of modifying the file in place. Xcode could store project files within the app's local storage, but that means it's totally siloed away from editing by other apps. None of these are ideal, but I suspect we'll have to live with it.

Source Control

Related to file handling is the issue of source control. Any developer worth their salt keeps every code base in a source control repository. Xcode on the Mac supports Git and Subversion repositories, but the support has never been that great. It always felt like source control was tacked on to Xcode almost as an afterthought. My guess is that we'll be stuck with Apple's implementation, but hopefully Xcode for iPad will give Apple a chance to re-think the feature from the ground up. I have no doubt that Apple realizes source control is critical to app development, and without a command line to fall back on, I have my fingers crossed that they'll build a great source control tool on iOS.

Command Line

Speaking of the command line, source control isn't the only part of development commonly accessed that way. Tons of apps make use of tools like Cocoapods or fastlane when building apps. These aren't just conveniences; In many cases, they're critical parts of the development process. A lot of apps simply can't be built without them. This might be the trickiest part of putting Xcode on the iPad. Let's be honest: Apple isn't going to give us command line access to iOS. Even if it did, a lot of command line developer tools rely on modifying data across application bundles in a way that isn't possible on iOS.

I imagine Apple will tackle this through a combination of new tools and keeping the Mac as a backup. There are some interesting hints that Apple is working on their own implementations of some commonly used command line tools. Over time, those could be integrated into Xcode for iPad. It wouldn't be quite the same as using the command line, and a developer's options would be more constrained, but it's better than nothing.

At the same time, the Mac is still out there. For things that simply can't be done on the iPad, developers could open up their project on the Mac. At least at the outset, Xcode for iPad won't be a complete replacement for its Mac cousin, and nearly all developers will still have a Mac to work with.

Assumptions

Presumably, Xcode for iPad would only be capable of producing iOS apps. There's just no way Apple is going to build some kind of "Mac simulator" for the iPad, and even if it did, the user interface to Mac apps would be unworkable. Mac app development is going to stay on the Mac.

At the same time, I'm assuming that Xcode for iPad would be limited to the 12.9" iPad Pro. There's probably not a technical reason that it couldn't run on the new smaller iPad Pro, but I just don't think a 9.7" screen will be enough space. Heck, I don't really feel comfortable in Xcode on the Mac unless I have a big screen like the 27" display on my iMac!

The larger iPad Pro is probably also the only iPad with sufficiently advanced hardware to run Xcode. Even on a powerful Mac, Xcode can really get your CPU working hard and consumes a lot of RAM. It's possible the 9.7" iPad Pro could run Xcode as well, but its 2GB of RAM (vs. the 4GB in the larger iPad Pro) might be too small. Either way, compile times will be slower than on a modern Mac. The A9X is a fast CPU for a mobile device, but it's a lot slower than the CPU on a new iMac or even MacBook Pro.

Opportunities

If all this sounds like a lot of contortions to go through just to build apps on the iPad, there are some distinct advantages as well. The most obvious is portability. When I travel, I don't always want to bring a laptop with me, especially if I'm not planning on doing work. Yet I often do bring my laptop, in case a work emergency arises that I need to address. Having Xcode on my iPad would probably give me enough of a safety net in those situations that I could leave the laptop at home.

It would also be incredibly convenient to run iOS apps on the same device I'm using to build them. Imagine running your app in split-screen mode with Xcode. The iOS Simulator on the Mac is pretty good for what it is, but nothing beats running an app on the real hardware.

In recent press events, Apple has presented the iPad as a PC replacement and a place to do serious work. Building a version of Xcode for iPad is a tall order, but also creates opportunities to re-think some of Xcode's UI for new devices. If Apple is serious when it says the iPad is the future of personal computing, it makes sense to tackle Xcode sooner or later. I'm looking forward to seeing what they come up with.

A Small Defense of Apple's In-App Purchase Rules

From time to time I hear some complaining within the iOS ecosystem about Apple's rules about in-app purchases. Of particular note is the requirement that digital products must be made available through the in-app purchase system. Companies can also sell the product through their own web sites, but IAP must be an option the price must be the same in both places.

The restriction means that it's not possible to do things like buy books through the Kindle app. Amazon doesn't want to pay Apple's 30% cut on IAP sales, and I don't believe the IAP system is even equipped to handle a catalog of Amazon's size. Instead, users have to navigate over to Amazon's web site (without a link from the app, mind you) and buy the book there, then re-open the Kindle app.

It's a fair criticism, but I've also run into a few situations where I'm glad Apple's rule exists. I'm a baseball fan (let's go Red Sox!) and for the last few seasons I've subscribed to MLB's excellent MLB.TV streaming service. When I first signed up a couple of years ago, it wasn't possible to sign up via in-app purchase, so I created my account through the MLB website.

MLB automatically renews your subscription every year, and this year I wasn't so sure I wanted to keep my subscription, so I logged onto the website to cancel. I had to hunt around a bit, but I finally found a cancellation form. But I ran into a little snag: Submitting the form always seemed to fail with a mysterious error. (That's actually an improvement over previous years, when there was no cancellation form and you had to hunt for a phone number hidden in a block of fine print to end your subscription.) I had to email MLB's customer support in order to confirm and complete the cancellation.

A little time went by, and lo and behold, the baseball gods seduced me again. This time I decided to sign up through the Apple TV, since that's where I watch most games anyway. The process was as simple as picking the subscription period I wanted. To access MLB.TV on other devices, I can just use the Restore Purchases button instead of having to enter my MLB login credentials. Even better, now I know that if I want to cancel, all I have to do is disable auto-renewal in my iTunes account. MLB won't be involved at all, so I don't have to worry that their systems will mysteriously fail. An added bonus is that I have one fewer place to update my credit card information if my number changes.

In this case, Apple's rules on in-app purchases led me to have a better experience. Signing up was far easier than entering my contact and billing information on MLB's web site, and I don't have to log in to each device separately. While Apple's billing system isn't always perfect, I personally have never had trouble with it, and I trust Apple more than most other big companies. Apple says that their priority is to create good experiences for their customers, and this is one case where their restrictions on in-app purchases did just that.