In our ongoing series of interviews with developers and creators in the Apple community, I recently had the chance to talk with Manton Reece, the founder of Riverfold Software and developer of Wii Transfer, Tweet Library, and Tweet Marker. When he’s not developing new features for his apps, Manton writes at manton.org. You can follow him on Twitter as @manton.

The interview below was conducted between January 18 and May 2, 2012.

MacStories: Hey Manton! Could you introduce yourself to the readers who haven’t heard about you or haven’t tried any of your apps before?

Manton Reece: Sure, my name is Manton Reece and I’m a Mac and iOS developer from Austin, Texas. I build e-textbook software for VitalSource and in 2006 I founded Riverfold Software with my first indie Mac app, Wii Transfer. My two main products are Clipstart, for managing videos on the Mac, and Tweet Library, an iOS app for archiving and collecting tweets. Most recently I launched Tweet Marker, a syncing web service for Twitter apps.

MCSTR: What are the circumstances that led you to start your own company? When, and how, did you decide you wanted to become an independent developer?

MR: It was almost an accident that I started Riverfold. I’ve always worked on side projects, though often it’s just to build something I need for myself, or a small tool released as freeware. But in 2006 the Nintendo Wii had just been released, and over a few weekends I built this app to make it easier to convert movies to a format that could play on the new console. At the last minute, I decided to charge for it, and I reused the domain name from a previous, unfinished web project of mine.

People bought the app, but the most surprising thing to me – and what really opened my eyes about the business of software development – is that sales were fairly consistent over those first few months. I could tell that the Mac had a very healthy software market for independent developers.

And there’s nothing like feedback from paying customers to get you excited about building and improving apps. I don’t think I would have been nearly as inspired to do anything after that if I hadn’t decided to make it a paid app at that initial release.

MCSTR: You mention paying customers and that is a topic I care about deeply, especially when it comes to software development and independent realities such as the iOS and OS X third-party ecosystem. I’m a firm believer that software should be paid for, if anything to support the people behind an app and the costs that maintaining something people use – even a silly utility – bring to developers - e.g. website-related costs, employees, marketing, etc.. However, recently the trend seems to be that of “free models” – we see dozens of new apps and services pop up every day asking users for nothing but a signup. Unfortunately, some of these business aren’t usually sustainable, and unless they find a way to make money after the initial signup rush, they end up being acquired and shut down or they run out of money themselves and are forced to shut down anyway.

While this is very true for online services, I’m seeing the same trend in the App Store as well. Developers invest time in an app thinking that “just making it free” will help them gather users (and figure out a business plan) along the way, but then when the money isn’t there and the users are tired by the lack of support the app ends up discontinued and abandoned in the App Store.

What are your thoughts in regards to free Vs. paid software and establishing a loyal customer base that isn’t afraid of paying for new apps and upgrades?

MR: I think you have to start with a clear idea of what problems you are solving for people. The risk with free apps is that ads – or in-app purchases, or however you’re eventually going to make money – might get in the user’s way. Charging directly for the solution (the app itself) is much more straightforward to me.

Just giving software a price sends a message that this is something interesting and worth paying for. In turn, customers who buy the app should feel like they’ve invested in it – that they’re going to keep the app installed and it’s going to be actively developed. This leads to a stronger relationship between developer and customer. Especially for higher-priced apps, every sale is important, so every customer matters.

Free and very cheap apps have redefined what “expensive” means in the App Store. But only mainstream apps work at that scale, and we can’t all be in the top 10. So developers need to set a price that is fair and work hard to live up to it. We have to provide excellent support. I focus less on aiming for a big hit and more on making the app better with each release.

Having said that, with Tweet Marker I fell into exactly the trap you mentioned above: it was completely free until I released Tweet Marker Plus, an optional subscription with additional features. I’ve also received donations from both third-party Twitter developers and users, which helped take away some of the stress of hosting costs, but it’s important to me that it become sustainable on its own.

MCSTR: This reminds me of an old Marco post from 2009 in which he talks about the virtual existence of two App Stores: a mainstream one for $0.99 and free apps/games that you usually see in the Top Charts, and an “App Store B” for apps with “complexity and depth, narrower appeal, longer development cycles, and developer maintenance over the long term.”

Your iOS app, Tweet Library, is based on a mainstream web service but it’s targeting more advanced users with tweet curation and other archiving and filtering features. How has co-existing with $0.99 App Store hits and Angry Birds worked for you so far? Did the App Store bring casual, less tech-savvy you weren’t expecting to Tweet Library?

MR: I love that “two App Stores” post by Marco. It may be even more true today than when he wrote it, because of the “free + in-app purchase” apps which seem to exist in another world entirely.

At $9.99, customers have to go out of their way to find Tweet Library, so it has fewer casual users on average than the rest of the App Store. My customers seriously care about Twitter and about what happens to their tweets. I don’t sell as many copies as a $2.99 Twitter app, but I think even among the niche market of Twitter apps there is room for a few winners. It was also exclusively for the iPad, where apps have traditionally had higher prices.

For Tweet Library 2.0, I’m moving to the iPhone and iPod Touch too, so I’m eager to see whether those customers embrace it. Universal apps are great, but they can be tricky to price since not everyone will have both an iPhone and an iPad. I’m polishing every part of the app that I can, to make sure that it can stand alongside the quality of some of the truly great iPhone Twitter apps out there.

MCSTR: And what kind of challenges did you encounter in porting Tweet Library from iPad to iPhone? The iPad seems to be a much better fit for “content consumption” in this regard, whereas I see the iPhone as a “catch-up device”, especially for news and social networks. How is Tweet Library for iPhone going to take advantage of the smaller screen and the different usage scenarios?

MR: Designing first for the iPad and then slimming down the interface was a lot of fun. When doing the reverse – porting from the iPhone to the iPad – you can take some shortcuts to scale everything up, maybe move the tab bar to a pane on the left side of the screen, and have something that mostly works. But starting as iPad-only forces a rethinking of the UI. Flipboard is one example of a popular iPad app that handled this transition very well.

The iPhone is a modal device. You have essentially one thing on the screen at a time. The biggest challenge in Tweet Library was to no longer assume that all the main parts of the interface would be visible at once. And, where possible, to connect the different screens so the user doesn’t feel trapped or lost. I tried to make the navigation consistent and to avoid stacking modal views that obscure where you are in the app.

Your “catch-up device” comment is exactly right. If you see a tweet that you want to add to a collection, it was cumbersome to wait until you were at your iPad to do that. Even if customers don’t use Tweet Library as their primary client, they should be able to switch over to Tweet Library for a few minutes to save a tweet. Tweet Marker sync is an important part of making this work, since it can restore the scroll position between apps even on the same device.

MCSTR: You mention Flipboard as an app that handled the transition from iPad to iPhone well – are there any other apps, both on the iPhone and iPad, that you think succeeded in using their own interface principles and “rules” without relying too much on established conventions?

MR: Most of the apps I use on a regular basis seem to follow a pretty standard iOS design. My favorites are more about subtle additions within Apple’s UI guidelines rather than completely new rules.

For example, Reeder and Instacast use a dual-purpose toolbar that has both actions like “add” and “reload”, as well as a custom control for quickly filtering the list between unread, all, or starred items. It’s not something you will see in many apps, but it’s easy to understand and builds on the traditional toolbar without adding clutter.

Or the slide-out navigation in Facebook and Path 2.0. That’s a natural extension of the iOS back button, but quicker to return from and provides some context about where you are in the app. These conventions are obviously “new” but still feel at home in iOS.

MCSTR: I’d like to go back to Tweet Library again – in the 2.0 version, you’ve implemented a new feature that allows users to send tweets to a collection on Storify.com.

Why Storify? And do you think Tweet Library has room to integrate other services that leverage Twitter streams as a curation platform?

MR: There’s room to add more curation platforms if they help Tweet Library customers do more with their tweets. Storify was a great first choice because it’s so well designed and already popular. A couple other curation web startups have come and gone, either sold or just abandoned. So I want to be careful that I’m adding services that I would personally use myself and that will stick around.

Publishing to tweetlibrary.com will still be the default. It’s important to me that there is always that “official” site for hosting collections of tweets. But Storify is great too, with a richer web interface than what I provide today. What I realized is that I should think of Storify not as competition for my own curation app, but as a feature in it. That way it helps one of the goals of Tweet Library: to make tweets more accessible.

MCSTR: Have you ever thought of providing more features or a richer interface on the Tweet Library website?

MR: Yes. A web interface has a lot of potential both for existing iOS customers who want to access their collections from a desktop web browser, and also to new users who might never purchase the iOS versions of Tweet Library. But it also has the same questions of sustainability we talked about with Tweet Marker. I wanted to focus on launching the iPhone version first before committing to any other platforms.

MCSTR: I’d like to talk about your general thoughts on iOS and the Apple ecosystem. How has iOS 5 worked for you so far? And what do you think will be coming next with, say, iOS 6?

MR: iOS 5 is so good I’m requiring it for Tweet Library 2.0. I do wonder how long Apple can maintain this pace of major OS and hardware upgrades every year, though. Maybe OS releases should follow Apple’s pattern for hardware, where we only get a major redesign once every two years, and an incremental or under-the-hood change in the off-years.

Having said that, I’d like to see more hooks for developers to connect apps together in iOS 6. Right now we have a very rudimentary, one-way system of passing URLs or files between apps. It hasn’t changed much since the original iPhone OS. You should be able to send events to other apps running in the background and get a response, without forcing that other app to come to the front.

Also: more advanced multitasking on the iPad. The full-screen nature of iOS apps is important for focus, but these devices are being used for real work. You could include a view from a background app (like a chat window or file upload progress) as an overlay on the current app, or directly into Notification Center, allowing quick access without completely switching away.

Of course you can take this too far. You don’t want to lose what is great about the simplicity of iOS.

MCSTR: You mention better communication between apps, and that is something I’ve been writing about a lot. I hope a future iOS will bring better integration between apps without forcing users to rely on URLs and the multitasking tray, which becomes annoying when you’re constantly switching between multiple apps.

You also note iPads are being used for real work. Is this something you’ve been experimenting with as well? Or maybe it’s a little too early for a software developer to get real work done on an iPad?

MR: It’s too early for Mac and iOS developers, but some of what I do is web development, mockups, and writing. For those, you can definitely make the iPad work. All my drafts for blog posts, release notes, and anything longer than a single email goes into Simplenote, so that I can start or finish it from any device.

I think there is still room for improvement in Subversion and Git clients for iPad. I couldn’t find one that fit my needs exactly. But I keep a copy of the Tweet Marker source on Dropbox, just in case I need to access it. I’ve also found Panic’s Prompt SSH client indispensable for connecting to servers.

MCSTR: What are your thoughts on Mountain Lion?

MR: It looks very good. I’m happy to see the same kind of Twitter integration from iOS 5 also come to the Mac. And I view Gatekeeper as a statement from Apple that they won’t abandon apps that don’t fit into the Mac App Store.

The Mac App Store is about to become even more restrictive, now that apps are required to run in a controlled, sandboxed environment without full access to the system. This is a major change for some apps. I plan to remove my app Clipstart from the store because of it, so I will depend on Gatekeeper to provide a good user experience for customers launching the app on Mountain Lion.

MCSTR: Do you think it would be possible for Apple to “fix the sandbox” and make it easily approachable by developers who need their apps to work with entitlements?

MR: No, I don’t think it’s possible to make it easy for any but the most basic apps. It’s very telling that of Apple’s own apps, only TextEdit and Preview are actually sandboxed. It’s difficult to take an app that was designed for a more open environment and then lock it down without removing features.

The mistake Apple made was forcing developers to adopt something that wasn’t fully capable when Lion shipped. Better entitlements and APIs will help, but sandboxing should probably remain an optional technology for the foreseeable future.

MCSTR: How about Gatekeeper? Do you think that model could ever be brought to iOS, allowing installation of apps from other sources? And do you believe that, ultimately, the goal is to “lock down OS X” by forcing apps coming exclusively from the Mac App Store?

MR: If you had asked me that a couple years ago I would have answered absolutely yes, there should be a way to build and distribute apps without requiring Apple’s approval. I didn’t even want to develop for the iPhone at first because I felt so strongly that the closed nature of the device and App Store was a bad idea. I still believe it should be much more open.

But it has been a while since we’ve had any high-profile rejections. Most developers have accepted that how we distribute iOS apps is probably not going to fundamentally change. I’d love to see something like Gatekeeper for iOS, but it doesn’t seem likely right now unless Apple is forced to do it.

On the Mac it’s a different story. With the variety of apps allowed in the store shrinking, the Mac would be crippled without direct distribution of apps that Apple won’t approve.

MCSTR: Have you had a chance to try the new iPad?

MR: I have tried the new iPad. The new screen is fantastic. I still feel like my iPad 2 is practically brand new, so to get such breakthrough hardware so soon says something about how fast Apple is iterating on the iPad.

MCSTR: And do you think that, with time, the size of app downloads will turn out to be an issue Apple will have to figure out somehow?

MR: I don’t think this is a big issue for most apps. It’s true that apps with completely custom UIs – especially if they have background textures and gradients that don’t compress well – will be significantly bigger now that the iPad has a Retina screen. But there are many apps (like mine) that already share almost all resources between iPhone and iPad. Those apps hardly increased in size at all.

Apple could certainly be more clever and efficient about what part of an app is downloaded to each device. Innovation comes to the App Store slowly, though. It sounds like they have already picked your first suggestion: just bumping up the maximum size for 3G downloads.

MCSTR: What are the iOS and Mac apps that have intrigued you (both because of design and features) the most lately?

MR: For iOS, the iPad version of iPhoto. Although some of the gestures are a bit difficult to discover, the core parts of the app are very strong. I may even prefer it over the Mac’s iPhoto. Instagram also continues to impress. The latest design refresh is great work. Likewise for Sparrow for iPhone.

On the Mac, my primary apps haven’t changed much in years. BBEdit, Transmit, Acorn, Xcode. This year I’ve added Flint, a very nice Campfire client, and Gitbox, which fits perfectly into my workflow. I’ve been impressed with its clean, focused interface. It doesn’t try to do too much.

MCSTR: How has the launch of Tweet Marker Plus gone so far, and can you give us an idea of features coming in the future?

MR: It’s off to a great start. I’ve already been able to roll out a few new features, such as saved filters and archiving your own tweets, and I have a nice list of new ideas from subscribers. The main next step is to continue to improve the search options, so you can show specific date ranges from your timeline. This becomes pretty important as your archived timeline in Tweet Marker Plus grows to cover weeks and months of tweets from your friends.

MCSTR: What are you expecting from WWDC 2012?

MR: Like in 2011, I expect this year’s WWDC to focus on software. We’ll see what iOS 6 looks like, and we’ll get a final build of Mountain Lion. iCloud will be a major theme of the conference again. Hopefully there will be some clarity around sandboxing, too; the new deadline for requiring sandboxed apps in the Mac App Store is about a week before WWDC starts.

MCSTR: What’s next for Riverfold Software?

MR: I think I’m on the right path with Tweet Library and Clipstart. For the rest of the year I’ll be working on new features for both. I’m also excited to deal with the growing archive of tweets that are indexed and searchable in Tweet Marker Plus. Some of my Tweet Marker Plus customers already have over 100,000 tweets stored in their account. I want to do more to let users filter those tweets, to find the stuff that matters.