Jeremy Olson is the founder of Tapity and the company's lead designer. Tapity focuses on designing, developing, and marketing mobile applications. Jeremy and his team don't create just any mobile application, they craft software that stands out in a crowded App Store and closely follow Apple's philosophy with respect to design and attention to detail.

Grades, an application for helping students keep track of how they're doing at school, won an Apple Design Award in 2011 and Languages, one of their most popular applications, was an Editor's Choice in 2012 and reached the top charts in the App Store. Tapity currently focuses solely on iOS, and as you'll learn in the interview, this is a deliberate choice.

When I was ten, I wanted to build games and my dad gave me some programming books. I started learning programming and began building some games, mainly for my own pleasure. When I was a teenager, I got into web development and built websites for people.

My first contact with mobile was when I was twelve or thirteen. I really liked the Palm devices of that time and I thought PDAs were the future. At that time, I didn't think about phones as I was twelve and didn't really need a phone. Back then, twelve-year-olds didn't have phones.

I had some PalmPilots and there was this guy that got in touch with me, who was a developer for Palm software. I built a website for him and, because he liked my work, he wanted me to help design one of his apps. That was my first experience with mobile and I really enjoyed it.

For the next six or seven years, I was doing web development and I didn't even think about mobile until it became huge in 2007, when the iPhone came out.

I actually tried. When the iPhone was first introduced, you could only build web apps, so I tried to build a few of those. I even built a website to help people find web apps for the iPhone, an App Store for web apps so to speak.

When the SDK (Software Development Kit) came out in 2008, I tried to jump into that, but the learning curve was quite high coming from web development. At that time, I was also a full-time student and working at a local web development firm. I didn't have a whole lot of time to commit to learning the SDK, but I did try to learn iOS development.

I tried and failed two or three times, got frustrated with it, and eventually gave up. Hopefully that's encouraging to some people.

It's a little bit scary, because things do change quickly and it's a tough market. It's certainly not a get-rich-quick market and there's a ton of competition. The market is changing very quickly and you really have to adapt and evolve depending on how the market changes.

In recent years, there's been a trend for people to download a lot more free apps. I wrote about this on my blog and gave it a somewhat controversial title, Yep, paid apps are dead. It was my response to something Marco Arment wrote about his observations on the App Store.

I've been talking to a lot of people who have top apps in the App Store and the consensus is that the whole paid app market is having trouble, because a lot of people are downloading free instead of paid apps. It's not that people aren't downloading apps, they're just downloading less paid apps.

About a year ago, Languages got to #5 overall in the US App Store. This resulted in a lot of downloads. But talking to people who have recently hit #5 in the App Store, they are getting a fraction of the downloads that Languages received. People still download paid apps, just not in the volume they used to.

That doesn't mean that the App Store is dead. It just means that a lot more people are downloading free apps, they're looking for free alternatives. That's just one example of something where developers have to evolve.

I think we cheated a little bit with the mentality that you can just put an app on the App Store for 99 cents and strike it rich if you're lucky. That's not going to happen anymore. Even if you put an app out on the App Store for 99 cents and it gets to the very top, you still aren't going to get that rich as the volume just isn't there anymore for paid apps.

It is definitely worth experimenting with. Though certain apps don’t lend themselves to a subscription model, especially novelty apps that people are going to use once or twice. There are a few examples of subscription-based models that work—iTranslate comes to mind—but they are definitely difficult to pull off in consumer apps.

That being said, a subscription model is a lot more valuable, because you get recurring revenue. Getting a dollar for an app is just not viable for a business. You need to sell at least 100,000 copies to make it worth your time and that's really hard to do. It's not impossible, but it's difficult to do. A subscription-based model is a good model to experiment with in the App Store.

It was a natural choice, because I've been using Macs since I was a kid, before they were cool. It was therefore natural to do stuff the Apple way and Apple's culture really vibes with our culture as a company. Like Apple, Tapity is all about design. We really care about the details. We really care about polish and making apps that are enjoyable to use, which is in line with Apple's philosophy.

In fact, I'm sure we got a lot of our principles from Apple's philosophy. This also means that it just makes sense for us to build apps for Apple's platform, because they appreciate and feature that in the App Store. And they give Apple Design Awards to companies like that.

We've appreciated that over the years and their culture matches with us, which is why we've stuck with them. And I do have to say that there's something to exclusivity as well. It certainly doesn't hurt our relation with Apple that our apps have been only available on iOS. We have a really good relationship with Apple and that's something I consider a huge asset for us. I'm careful about that.

That's not to say that we won't build apps for Android. However, I wouldn't want to build an Android app unless I was using Android myself, because I realize that the experience is different. As a designer, I need to empathize with the users of my app and, if I'm using a completely different platform, then how can I design for users of that platform? It's not a small thing for us to do. We feel that it's a real commitment.

One thing that's tempting on mobile is to jump straight into the code. You've got an idea for an app and you start building it. That can work in some cases, but a designed approach is going to generally work a lot better.

One of the challenges is not realizing that it requires a design process. It needs to be designed and that includes a number of things. Let me walk you through our design process at Tapity.

We start by breaking the app into three categories, strategic design, interaction design, and visual design. These all happen at different moments during the design process, but you need a start on one to start the rest.

During the strategic design process, we really try to get to know our users by creating personas. You don't have to go overkill, but empathize with your users as much as possible by learning as much about them as you can. Any people you can talk to about your ideas for an app can help with this.

We create personas or fictional characters that represent characteristics of users that we feel we should capture. For example, Sarah is a lawyer who tracks her hours by six minute increments and we basically fill out what her life is like to put ourselves in her mind. When we're talking about a feature, it's not "Users would like this." It's "What would Sarah like?" and "What would Sarah think about this?"

During the strategic phase, we go through their experience with and without the app. If this app were magic, how could it help them in their day-to-day experience? We then discuss what we can really do for them by going over what's realistic. At the end of this phase, we end up with a definition of 1.0.

We then enter the interaction design process. At Tapity, we don't make it very formal. A lot of people create formal wireframes and we did this with clients, because we believed that they needed a more formal approach. However, we felt that we got stuck in that phase, because people would nitpick the wireframes when you really shouldn't. Wireframes are only used to get the interactions down.

These days, we use whiteboards to map the whole app out. It's a rough sketch of the app, which we iterate on. Whiteboards make this very easy and quick. We use an app, Pop, that lets us take pictures from our sketches and link them together to get an idea of how the app will look and feel.

Of course, interaction design continues as you're getting into visual design, because you iterate a ton once you actually see how it's going to look.

The intersection between interaction and visual design is crucial. Visual design informs interaction design and vice versa so you can’t completely disconnect the two. Visual design is really where we iterate the most. It's probably not as efficient as iterating interaction design, but it gives you a more complete picture of what's going on.

The right direction is hard to define. I appreciate the fact that they did something radical and I think that's cool. It's always fun when things gets shaken up a bit, whether you like it or not. It provides new challenges and it makes it so that new players can come onto the scene that are doing innovative things that the established players can't catch up to or are too slow to do.

In general, I like iOS 7. Especially in the beginning, there were certain things I didn't like. I know a few people at Apple and they're definitely open to feedback. But the general direction is set. It's going to mature over time, but I think it's a good new direction that mixes things up and gives us new challenges.

As with any new platform or any new design direction, people tend to do exactly what Apple does. When iOS was first released and the SDK became available, everything looked exactly like Apple's apps. But then, over time, things matured and people started experimenting, creating novel experiences by iterating on Apple's designs. That's what needs to happen with iOS 7.

I've seen some apps that start to go in that direction, but I think the vast majority, as they're scrambling to fit into iOS 7, take a very conservative approach by doing what Apple is doing. But that's not even what Apple wants.

You'd think Apple wants everything to look like their apps, but they know that if everything looks the same it's going to be boring. I've talked to people at Apple about this. They want diversity and they know that it will come eventually, it just takes some time.

Based on my own experience, a big factor is going to be the drive to do it. If you don't have the drive to do it, then you're not going to do it. Like I said, I failed a couple of times learning iOS development, because the learning curve is fairly steep.

For me, that happened when I had the idea for my first app. It wasn't just a vague "I want to learn iOS development." It was "I want to build this thing and and I'm going to do whatever it takes to build it."

Instead of telling yourself "I'm going to learn iOS development.”, tell yourself "I'm going to build this product and I'm going to learn iOS development to do it." And that, I think, gives you the drive to keep going.

It also makes learning iOS development a lot more concrete. It's not just "That's how you create a table. But I don't know if I need a table.” Instead, it's "I'm trying to build this app and I need a table. Okay. This is how you build a table and I put it in my app."

The first prototype of Grades was nothing more than a bunch of tutorials hacked together, bent and twisted to do my will. After I learned the principles and learned how to do things properly, I trashed the prototype and rewrote the app. Having the app as a way to apply the tutorials and apply the things I was learning really made it a lot
easier and it made me learn quicker.

It was a pleasure. You can follow me on Twitter and I regularly write on Tapity's blog about iOS development, marketing, and design.