In our ongoing series of interviews with developers and creators in the Apple community, I had the chance to talk with Greg Pierce, founder of Agile Tortoise. Greg makes some of our favorite iOS apps here at MacStories, namely Drafts and Terminology. Greg is also the man behind x-callback-url, an inter-app communication spec that I've been personally researching for the past few months. On Twitter, you can find Greg as @agiletortoise.
The interview below was conducted between May 7 and December 29, 2012.
Federico Viticci: Hey Greg! Could you introduce yourself to the readers who haven’t heard about you or haven’t tried any of your apps before?
Greg Pierce: Well, my name is Greg Pierce. I’m a family man and somewhat accidentally a professional developer living near Fort Worth, Texas. I am President of Agile Tortoise, an indie software company I founded in 2006 – where I split my time between developing my own iOS and web projects, and doing consulting.
Most of your readers would know me best for my word reference app Terminology, and for my newer apps Drafts and Phraseology. While I, sadly, am not a great writer myself, I’ve always had a great love of language and writing and I try to focus on producing simple and useful tools to writers (or anyone else using text and words) that exploit some of the interesting possibilities of the iPad and iPhone.
When I’m not working on my apps, I do Ruby on Rails development – primarily STEMscopes.com, a Texas-based science curriculum resource that serves K–12 schools. This is also an exciting project that is on the cutting edge of the move to replace traditional textbooks with online resources.
FV: How did you get started with programming and development?
GP: In some sense, I was raised to be a programmer. My father was a math major recruited out of college in the early 60’s to work for IBM. He has spent his career (he still contracts for IBM) programming and debugging mainframe systems.
Growing up, we were the first family in the neighborhood to have an Apple II, the first to have an IBM PC, etc. I toyed with these from an early age – but I never intentionally pursued a career in computers. I was active in music, studying and working in the music and arts – and went to grad school studying Ethnomusicology and Folklore.
I have always liked to produce a “product”, however. I wrote music. I was active publishing an independent a print magazine, later a website, on music and the arts (UNo MAS – no longer online, sadly) – and taught myself desktop publishing and web development in the early 90’s.
As it came time to “get a real job”, I found a company that was struggling to move into the computer age and taught myself to program developing systems and workflows for them. I continued to teach myself automation (mostly in Dave Winer’s Userland Frontier) in the late 90’s to keep up the increasingly large content base of the UNo MAS website. I contracted on Userland Frontier projects with Macrobyte Resources for a while, learning a lot from building an early CMS called Conversant with a great team, many of whom are now doing iOS development.
Later I moved to other environments, like Ruby on Rails. When the iPhone SDK came out, I knew it would be a good fit for me – since the mobile space allowed for crafting a personal experience.
FV: So when Apple released the SDK in 2008, you immediately started playing around with it to create iPhone apps?
GP: More or less. I had an iPhone 1 within a couple of months of its original release, and loved it. I wanted to do apps, and started looking at the SDK as soon as it came out – but, I had a full time consulting work, the youngest of my three kids was still a new addition and there wasn’t a lot of spare time to explore. Plus, the learning curve was a lot higher in those early days – both because the immaturity of the platform and the still active NDA.
I still plugged away at, and released my first app, BoxFinder, in September of 2009. BoxFinder was very much an itch-scratching experiment. It’s an app for Letterboxing, an outdoor hobby similar to Geocaching that I do regularly with my family. There was no app for it, so I decided to do one in my spare time. I never marketed the app outside the Letterboxing community, but it was a good way to go through the App Store process and get familiar with the ins and outs.
FV: How did that simple, niche app lead to Terminology, and, eventually, your other apps?
GP: Shortly after BoxFinder, I released a failed app that is no longer in the store, called Tweeku. It was also a niche app, aimed at people writing micro-poetry and haiku on Twitter. The app was far too focused to be successful, but one of the features I wanted to provide in the app was the ability to lookup words and select synonyms and antonyms.
I ended up using a web service in Tweeku, but while researching options I found and fell in love with WordNet, the data source behind Terminology. This was Spring 2010, and another new shiny drew my attention – the iPad. The initial dictionary apps for the iPad were junky, upscaled iPhone apps, so decided to jump in and try to come up with something better. Terminology was released for the iPad in June 2010. The iPad App Store was still not too crowded then, and I was lucky enough to get good press and features from Apple that let the app reach the top 25 on the paid charts. Having a mainstream success like that justified me moving more of work time away from consulting projects to my own apps.
FV: And what does mainstream success look like for an indie developer?
GP: It actually can be a bit daunting. I used “mainsteam” in this case referring to having an app that found an audience that was not a “niche” in the traditional sense. For an indie, catering to a niche can be very attractive – because it limits the scope of your audience. You can get to know them better, it’s easier to identify and target marketing efforts and provide support.
Unfortunately, it’s hard to make a living in the App Store serving a niche. There are exceptions, but the $0.99 app marketplace pushes you toward trying to find something with a broader appeal – along with that comes greater uncertainty about who your users are, where to find them and how to communicate with them.
FV: Is that what you’re trying to do with Drafts – trying to find a bigger audience through the appeal of integration with other apps and services?
GP: “Hoping” to find a bigger audience, for sure. “Trying” might overstate the facts. Ultimately, Drafts was something I wanted to build and hoped other people would like.
App integration on iOS is something I’ve been interested in for a long time. It is something I’ve been pushing for since the early days of Terminology, trying to expand the way it could integrate with other apps with the smoothest possible workflow – within the limitations possible with URL schemes. I’ve done a lot of evangelizing for implementation of URL schemes in apps, including the work I’ve done on the x-callback-url spec. In a way, Drafts was a culmination of these efforts.
FV: Do you think Apple should also provide a better way for apps to communicate with each other’s documents, not just functions?
GP: For me? No.
I would prefer nice ways to provide services/APIs between apps. I don’t think it would be beneficial to iOS moving forward to continue to look back toward the traditional files/folders/documents metaphors of PCs.
I also think that sort of interaction forces apps toward a least-common-denominator because they are all trying to provide compatibility with particular file formats that might limit capabilities they could have in their app that might be better suited to different data structures. It would be incredibly difficult to implement considering iCloud and other sync strategies at time point anyway.
I think one of refreshing features of Drafts is that it frees you from that file/folder metaphor.
FV: You once made Drafts free for a short period of time. Can you share the motivation behind that initiative? What were the results like?
GP: That sale was a spur of the moment decision based on a number of factors. I had never had a free app in the App Store, and have always been curious about how different the download numbers could be.
With Drafts, I have an app with many different use cases. I thought the opportunity around the WWDC Keynote offered a chance to highlight one of those – “Live Tweeting”. I made the app free for about four hours leading up to the start of the Keynote. The sale was only announced by me via Twitter – though naturally it got a lot of retweets.
Was it a success? That’s hard to say. The app got more downloads during those four hours than it had sales in the two months it had been on the App Store. It is my hope that some of those people who downloaded the app will like it and share it with there friends, but I’m not sure my analytics numbers indicate that there was a high level of engagement from the people who got it for free. I think there’s a large group of people who just grabbed it because it was free and may never have given it a chance.
FV: How do you keep a balance between the supported actions users want in Drafts and keeping the app simple and focused?
GP: The list of actions in Drafts has gotten quite long, but in my mind I haven’t added features to the app – I’ve just tried to maintain the best implementation of a single feature, “Flexible Output”.
Drafts’ action list breaks down into two groups, core actions and app actions.
Core actions are baked in via SDKs or Web Service APIs, require more development time to integrate and typically do not leave Drafts when triggered. These include email, messaging, Twitter, Facebook, Dropbox, Evernote and a few others. I’m hesitant to add many of these unless there is strong demand for a particular service. I added App.net because there was that kind of demand.
App actions are URL scheme-based actions that forward drafts to other apps. The list of these is very long and I am generally happy to add requested app actions – just as long as the requested apps have the needed URL scheme support.
Drafts tried to mitigate the problem of the long action list as much as possible. When the app is launched, it builds the action list based on what is available on the device. So if there is an action for an app you do not have installed, it doesn’t get activated, and you don’t see it unless you dig into the action manager. Likewise, if you delete an app, the next time you launch Drafts, it will automatically hide the action.
I’m also working hard on adding more user-created actions. The first set of these is the new Email Actions, and there will be more. This is clearly a power user feature, but allows the app to be extended for individual needs without cluttering the list of actions for others.
FV: This is an interesting subject because it allows me to ask about URL schemes, which is a topic I’ve been researching lately. It seems to me that most developers nowadays implement “basic” URL schemes for launching apps directly, especially after the release of Launch Center Pro by App Cubby, but few of them care to rely on more powerful protocols like x-callback-url.
What’s your take on the current scenario of URL schemes? Do you think that few developers know about better options available, that they fear Apple will implement a better way to share data across apps – therefore making URL schemes “useless” in the near future – or are they just lazy in that they don’t see the opportunities?
GP: What you call “basic” URL schemes are becoming common because there is no effort involved. No code, just a quick entry in an app’s configuration file – which can be done in Xcode’s user interface.
As to why more apps don’t implement more advanced URL schemes, I’m sure that answer varies. While it would be nice if Apple implements better ways for apps to interoperate, I don’t think too many developers are holding their breath. Even if it does come, it will be a major release feature not something that would slip into 6.1 or 6.2, so it’s a ways down the road.
I think most leave URLs out because it is a power user feature. Unless you have specific use cases in your apps where URL schemes make a lot of sense, then the integration may not be worth the extra hassle – or it lands in the “wait and see” feature list for after an app ships, and if enough customers ask for it it gets added. We’re seeing that customer push back in the editor space since Launch Center Pro and Drafts have drawn more attention to the possibilities and customers have come to expect editing apps to have those sort of features.
I certainly wouldn’t label it as “lazy” if an app doesn’t have extensive URL schemes – you have to draw lines somewhere to ship and low-visibility integration features are likely to get the short end of the stick. While developing URL schemes for Terminology, I had a real business incentive to differential the app in the crowded dictionary app space by providing integration, not all apps have similar incentives.
FV: I was looking at Terminology’s URL scheme just the other day – how did x-callback-url come to be with input from Marco Arment? Did you find yourselves wanting to fix the same problem?
GP: Yes, essentially. I blogged about some of the ideas I had for Terminology in late 2010, and Marco noticed the post and had been exploring similar ideas with Instapaper.
I don’t recall all the details of the back and forth, but we exchanged several emails. I think Marco wanted to pursue doing a specification himself and a lot of the ideas and formatting came from him, but I had more time available and offered to follow through on drafting something.
In early 2011, I posted the first x-callback-url spec and around that time released support in Terminology, which Marco was nice enough to utilize in Instapaper. He also implemented x-callback-url in Instapaper in an update soon after.
I’ve had limited time to evangelize the spec, so it’s great to see it getting more uptake in the development community lately. The spec itself doesn’t enable anything that couldn’t be done without it, but I think standardizing the formats and parameters can help make it easier to document and consume services provided by different apps – particularly for power users like yourself interested in automating workflows on iOS.
FV: My question is obvious: do you think there’s more room for automation on iOS in the future? Do you believe there should be?
GP: I hope so. As someone who started programming out of the need to automate daily chores, that’s what I’d like to see. I’m certainly working toward that end in my own apps – I think automation junkies will find a lot to like in the stuff I’m working on for Drafts 3.0 when it’s ready for release.
Automation will look very different on iOS, but it will come. As more power users try to replace desktop computers with iPads, the demand will only go up.
FV: Can you describe your setup? The software and hardware you use on a daily basis on OS X and iOS?
GP: Hardware? I use a 15“ Retina MacBook Pro. More often than not, I’m at my desk at home, docked to a Thunderbolt Display – with standard wireless Apple keyboard and Magic Mouse. I’m still using a ”new iPad (3)", and carry a sporty black iPhone 5.
Software is a more difficult question to answer. So many things. I don’t feel at home on a Mac until it has at LaunchBar and Default Folder X installed. I use Evernote as a catch all, and jot notes and do a lot of basic task management in OmniOutliner. Fantastical, Dropbox, Things are all part of my workflow. Obviously Xcode.
I am having trouble committing to a text editor at the moment. I’ve spent significant time in Sublime Text 2, BBEdit, Chocolat and TextMate 2 in the last month – think it’s likely Sublime will win out, but I haven’t settled in enough to feel at home in it.
Almost all of my couch computing is on the iPad and iPhone now. Reading, feeds, social networks, etc., I try to do more on iOS. Reeder, (Tweet|Net)bot and Instapaper mostly.
I couldn’t possibly list all the little things I use – it would get boring fast.
FV: So no iPad mini for you?
GP: Not yet. I’m sure I’ll get one soon. I need to test my apps on one, and I’m sure I’ll love it – but I’m really quite happy with my iPad 3. The Retina display is so awesome, and I mostly use it around the house so the weight/size aren’t that big a deal to me – so I didn’t run out to get on line.
I’m trying to be somewhat reasonable about new iOS acquisitions as we already are practically tripping over them around our house. Between myself, my wife and our three kids we share three iPads, six iPhones (only two active as phones, the rest testing devices and shared gaming) and two iPod touches.
FV: As a developer and, generally, tech “geek”, it’s easy to lose perspective on how “normal people” use apps and devices nowadays. However, for the same reason you also gain the insight on how people are using your products. Can you tell us any particular stories on how your customers are using your apps?
GP: People are always surprising me, which I love. Particularly with Drafts, which has enough flexibility to fill a lot of needs for different folks. I was just reading a great post by Ben Broeckx about how Drafts finally helped him bridge the gap from pen and paper to electronic notes. Reading something like that makes my day.
I hear from people who use the app exclusively as a place for Twitter drafts, people who use it only for dictating quick thought on the go – and outliers like George Coghill, who setup a workflow with Drafts and Hazel to control the volume on his Mac from iOS. As a geek, I get really excited to hear about my apps fitting into workflows I never imagined.
Possibly my biggest surprise, however, is how my writing app Phraseology has taken on in education. The app incorporates tools to analyze word usage and provides common statistical analysis scores for your texts – and it turns out teachers just love to provide a tools like this to their students, who can get feedback on, say, the grade-level of their writing. This market is far less interested in some of the features Phraseology lacks – particularly Dropbox sync. It’s really great to see teachers posting pictures of their 8th grade class working on essays in the app.
I get regular bulk education discount purchases on Phraseology. Of course I love the sales, but I also get frustrated that I have no way to find out who’s using it and how I might improve the app to meet the needs of educators – but such is the nature of the App Store marketplace.
FV: This is interesting because it’s a topic that I don’t find covered enough on Apple-related news sites. What’s your experience with Apple’s educational discounts program for the App Store?
GP: I imagine it doesn’t get talked about because there isn’t too much to say. Like most things at Apple’s end of the App Store experience, it’s a black box.
Like other sales, I get no information on who bought the apps – I just occasionally see purchases in my sales reports. The education purchases do get separated in the reports. In the case of Phraseology, it usually comes in clumps of about 30–35 on a day – which makes sense since it roughly maps to class sizes in middle school/high school. If I remember correctly, 20 is the minimum number they have to purchase for the discount to kick in.
FV: Looking ahead, where do you think OS X and iOS are headed? How would you like the OSes to evolve in the future?
GP: I think it’s true that we are in a “Post-PC” era.
Desktop computing, at least in the consumer space, is becoming a thing of the past. This means that people are going to be trying to use portable devices to fill more computing roles in their lives. Right now, a “power user” is still likely to need a PC to accomplish a lot of what they want to do. That may be less and less true in time.
There are a lot of advanced users (such as yourself) that are trying to push the envelope of what is possible on iOS – and that’s great. To continue to lead in the tablet space, I think Apple is going to have to respond to that pressure and expand on the SDK in the areas of integration and automation.
What does that mean for OS X? It’s not going anywhere – and will probably continue to nudge toward the iOS-like simplifications seen in Mountain Lion, but I can’t say I expect a lot of new innovation to emerge from OS X.
FV: And without revealing too much, what can you tell us about the future of Agile Tortoise?
GP: I am far more constrained by resources than ideas these days – but I also don’t like to get ahead of myself on public commitments. Short term, I am actively working on Drafts. The next major release is coming along nicely and I’m really excited about bringing more flexibility and power to the app.
After that – I’m not sure. I love to build things, and am going to keep trying to do my best to balance the things I get excited about with marketable app ideas.