Guy and Rene talk to Paul Haddad of Tapbots about coding on NeXT, deploying Tweetbot and Netbot on multiple platforms, for multiple services, pricing for scarcity, in-app purchases, push notifications, iCloud sync, and his beef with AppKit. This is Debug.
Here's the audio, again, in case you missed it. And now, for the first time, here's the full transcript! (Yes, we're doing transcripts now!)
Debug 2 transcript: Paul Haddad of Tapbots
Guy English: Hi, my name's Guy English, and this is the second episode of Debug.
Rene Ritchie: I'm Rene Ritchie, and joining us today is Paul Haddad from Tapbots, who you might know from a fine collection of small, automated iPhone apps like Waitbot, Calcbot, Tweetbot, and now Netbot. How are you, Paul?
Paul Haddad: I'm all right. How about yourself?
Rene: Very good, thank you. The way we usually like to break the ice, get started, have the first round poured is to ask you how you got involved in Mac / iOS development.
Paul: You have to go back...Oh God, it's a little bit over 20 years ago, when I first saw a NeXT station. I was in college at the time and went into their bookstore / computer store thing, and I saw one of the black and white NeXT stations. I started playing with it, and I knew I had to have one. Begged, borrowed, and stole and got one. Pretty much started coding on them from there and followed that throughout my career.
Rene: What was it like coding on a machine like that back then when it wasn't the biggest, most popular brand on the planet?
Paul: It was interesting. Unless you consider it turning into Mac OS and iOS, it never really became popular at all, but it was definitely better than anything out there from a user perspective, which is where I first got into it. There was nothing else like it. There was high-resolution display, multi-tasking. All the stuff that we take for granted now didn't exist really back then unless you were talking about really, really high-end workstations. This was the first operating system where it was friendly, easy to use, and a complete package.
If you went and you looked at the little Macs back then with their little, tiny screens and the PCs with, I don't even remember, VGA graphics or something ridiculous like that, this was a completely different experience. It's very much like what we're used to today, although obviously a lot slower back then.
Guy: When I was doing prep for this show, I went on the Tapbots site, I looked you up, I read a bunch of your blog posts, and everything. I ended up back at an old site with your resume on it.
Paul: [laughs]
Guy: One of your first gigs that you list is writing an object-oriented wrapper that worked on NeXTSTEP and Windows 3.1.
Paul: That was actually my first real job. I didn't...
Guy: That's crazy. Sorry, just for the audience, Windows 3.1 is a segmented memory model 16-bit, and NeXT is like an actual, modern operating system. That's a big challenge.
Paul: Yeah, it was way back...To be honest, I didn't write the wrapper. I just had to work with it. A consulting company came up with it for a small company. The kind of stuff you'd never see happen, I would think, today. It was for something really boring, reinsurance contract management. Compared to coding for Windows, it was so much easier and better stuff to do. [crosstalk]
Guy: I'm sure. It shocked me, the difference between those two platforms and that you would try to support them with one approach.
Paul: If I recall, and this, like I said, was way back then, the coding would happen on the NeXT machines, and the executables would run on Windows. It used the Stepstone compiler and all sorts of craziness. It was an interesting time. [crosstalk]
Guy: Yeah, a little bit. So you ended up doing contracting a few years and then finally got into iOS.
Paul: Yeah. I had real jobs, contracting jobs. At some point I decided that I just don't like going into an office and just went that route where I would mostly do contract work for different companies. Golly, four or five years ago, I don't even remember, the iPhone first started, they first started letting people write applications for it. Mark [inaudible 05:154] , my partner, and I were both working at Oakley and we were just in the middle of some big, hairy project. It was a Sunday or something like that and we were both really burnt out, talked, and said why don't we create an application? Went back and forth on it a little bit and decided to do something simple to track our weight, or at least that we thought was simple back then, and went back and forth.
Somehow WeightBot and TapBot was borne out of that.
Guy: Were you into the Jailbreak scene at all? Were you excited when the phone itself came out or were you more into after the SDK got released?
Paul: Neither. I didn't buy the phone when it first came out. It wasn't so much that the phone wasn't cool, which it certainly was. I'm kind of cheap and I hate paying for recurring services like data plans and things like that. I was perfectly happy with the cheap, pay as you go phone. I kept that until I couldn't do that anymore.
Guy: What was compelling about the iPhone? Or was it just that time marched on and you figured that you didn't want to get left behind?
Paul: Once I actually got the phone and the API was actually opened and I got to play with it a little bit it definitely was cool. Before that, certainly it was something that I was keeping an eye on but I just didn't feel the need to get one, which is strange because I've gotten every single device since then.
Guy: I've got a giant stack right next to me.
Paul: Yeah. I've been doing some iCloud stuff this week and I have like six different devices hooked up at the same time trying to deal with conflict management and all that fun stuff.
Guy: I'm sure. If it wasn't 11:00 AM I'd send you a beer or something. Why WeightBot? I have a line of questions about the whole bot theme. What was the initial impetus behind WeightBot? Was it because it was simple and you thought you could do it? Was it like scratching an itch kind of thing?
Paul: I could be totally wrong on this. It was probably because I was trying to lose some weight and I wanted something to track with it and we figured, like I said, it would be a fairly simple app. You put in a weight every day and keep track of it, or at least it would have been simple before Mark got his hands on it and came up with this insane concept of a robot with noises and all sorts of flicking actions.
Guy: Which is now the TapBot's trademark.
Paul: Correct. If it would have been a real simple weight tracking app, it never would have gotten anywhere. As much as I may make fun of him for coming up with crazy stuff, it seems to work for us.
Guy: I think I bought it the day it came out purely, not purely, largely because of the design and the attention to detail and the approach to it. That TapBot aesthetic has worked well across your entire line. It's branded you, not just with sticking bot at the end of everything, but it's down to the icon, it's down to the look and feel of the applications themselves, that metal look. It's very opinionated.
Paul: Yeah. We've actually talked about should we do an app without that branding, for lack of a better word, but we just haven't yet because it just works for us. Especially these days, getting anything going in the App Store is very hard. We found something that works for us, so do we stick with it, or do we go crazy and do something completely different?
Guy: Yeah. I'm sure I've said this before. Not to your face, though. [laughter]
Guy: It's a little heavy for me, it feels like. Like a little bit overwrought, especially with the sounds and all that. I love the attention to detail. It's amazingly well implemented, it's beautiful. I love it for what it is, but it feels a little bit heavy for me. That said, TapBot and Tweetbot and Weightbot, I basically use them all multiple times a day, all of the time. You're certainly not losing a customer. It's not really detracting from my experience at all.
Paul: We've heard the heavy comment often.
Guy: I feel like maybe I'm being an old man. I feel like maybe Delicious Library came out, and I'm grumbling because it should just be a list view or regular icon view, rather than being the bookshelf. I feel maybe I'm getting a little bit overly conservative.
Rene: Is there a line between...You have an incredible design language. It's a very good differentiator for you, can instantly tell a Tapbots app, but at the same time, you now carry that design with you everywhere. It might be a mixed blessing for you sometimes.
Paul: Yeah. Like I said, we've talked about doing something different. We just haven't quite gotten there yet. Everything we've looked at has felt right going into this same look and feel, for whatever reason.
Guy: Mm-hmm. Definitely everything looks correct. I can open up any Tapbots app and feel like this, it's a consistent work of art. Every attention to detail has been paid, and the little characters all fit in. Everything's great.
Paul: It's interesting to see. In the last version of Tweetbot, we made some changes in the icons which was supposed to make it a little bit lighter. We get a ton of people saying they love it. We get a ton of people saying they hate it. It's like, "Argh," you know?
Rene: You've almost made the apps into characters for people. They're getting an attachment to it because of the identity you've given them.
Guy: I think it's a great idea, by the way. Definitely character-driven apps are...
Paul: You've got to do something to stand out in the marketplace, right? There's thousands of apps released every week. If you don't have something that stands out, it's just going to get buried.
Guy: Oh, yeah. The fact that you can cross play the brand is amazing. I love that when you launch a Tapbots app, it's got the serial number stamped into it. It's great, great little touches, you know?
Rene: It's interesting. I don't want to bring up the skeuomorphic word, because it's horribly overused. Weightbots could have been a very dry, very list-driven app. There are hundreds of those kinds of apps, but you made it fun. You made the actual usage of the app an enjoyable experience, which makes you want to use it more often.
Paul: Right. That was definitely the plan for Weightbot. It's kind of boring to track your weight. We wanted to do something where it would make it somewhat fun, where you'd feel a sense of accomplishment putting in your weight every day. That's where that all came from.
Guy: Would you say that Convertbot is the one that goes furthest along that access?
Paul: Yeah. I think we both feel like it may have gone a bit too far in that direction.
Guy: Because of the dial UI?
Paul: Yeah. The dial, it's great and it's fun, but it's not the most efficient way to pick currencies to switch from. It's kind of a tricky one. Especially now that we have the iPhone 5 coming out, stretching that app just doesn't seem to work right. It doesn't feel right because it's so heavily around that wheel, and the wheel is tuned to the screen ratio of the original iPhone.
Guy: Right. Just for listeners who haven't seen it, it looks almost like an iPod click wheel that you can turn around and dial your different units, and press the middle button to select them.
Paul: Right. If you want to go with the UI heaviness, that's probably one where we may have gone a little too far.
Guy: I'm pretty sure you guys put out a blog post explaining exactly how you did this, or at least the iterations you did to get to it. From the nerd perspective, I find that really fascinating. [laughs]
Paul: Yeah. That was all Mark, I guess kept notes during that design, and showed how the wheel came to look or why those dimensions were chosen and all that good stuff.
Rene: What's it like for you when you get some of these designs back from Mark, and you have to implement the physics, and you have to implement the scrolling? You have to make what he designs feel...I can't say real world-like, but feel correct on an iOS device?
Paul: Sometimes I'll just look at it and just shake my head, and curse him out in my head and go, "Ugh, how am I going to implement this?" It's always interesting to see. We'll often go back and forth once he does come up with a design, with me saying, "This is impossible." Or, "This is going to take to long to do, and can we switch this around?" Kind of go back and forth a while to try to figure out just exactly what we can do with those designs.
Guy: I think it really worked for you, because you're one of the few teams that I can think of, small teams that works so consistently well together. Every app is very polished. It's not very sharp edges. Everything's very consistent between app to app. You have a company voice that is very distinct. Given that there's two of you, you'd think that it could go one way or the other sometimes. It seems that you guys put out what you wanted to put out. It doesn't seem that you...Not half-assed stuff, but it doesn't seem that you haven't been happy with any of the stuff that you've put out so far.
Paul: Yeah. I think a lot of that is how we work. We try to keep to our areas of expertise. I can't draw a circle to save my life. Mark can't code, and so we try to keep our responsibilities separate. Anything design-related, even if I don't particularly agree with it, it's Mark's decision to make. That seems to work well. We'll collaborate together, but at the end of the day, design is his area. The user interaction is his area. He has the final say on that stuff.
Rene: What happens when you're working on something like Netbots? You already have Tweetbot on both iOS and iPad, and then you're bringing out Netbot, which is a variant of that, it's still going to be iPhone and IPad, but now you're doing a different service and you're hitting ADN. Is that challenging? To keep an app sane on two different platforms, and then two different services as well?
Paul: It will be interesting to see as it progresses. The apps were separated once I started working on that Netbot. It's not all the same code base. Obviously one was copied from the other and then I went in and made all sorts of changes to get Netbot working on the different service. Fortunately a lot of it was architected purely by luck, so that it was some what easy to switch from the different services. It will be interesting to see as it progresses.
I've been making changes on one, and then going to the other, making the same changes there, keeping up that way. It will be interesting to see as both services and both apps fork more and more away from each other.
Guy: It's not like a shared library that you use between the two?
Paul: Well, we definitely have a common library that's used between all the different apps that have generic classes that we use. Like, our Alert Panel and our different types of buttons, et cetera. That's all shared between all the different apps, but the code itself that talks to Twitter, to ADN, the code that displays all the different view's for different app's are completely separate at this point.
Guy: You've been remarkably positive in all of your expressions. Like there's a lot of, and this is not to disparage anyone, but there's two lines of thought. There's one, people either act positive about the app store being screwed up in various ways, or positive about various business things, or people complain. I don't mean that in a bad way. They outline the realities that their business's have to face and point out where things are tough.
You guys seem to have always been positive. Is that a conscious thing, or is that just a personal attitude?
Paul: Probably a little bit of both. Regardless of what happens with the app store and Twitter, we're really just two guys that got together and started a company and were successful at it. We don't have to work for some large corporation doing really boring stuff.
Guy: You're living the dream.
Paul: Yeah.
Guy: You can take a few hurdles, right?
Paul: Right. Nothing that's happened in the past year has been particularly bad. Every year has been better, let's say revenue wise, than the year before. So, there's really not that much to complain about.
Guy: It's en vogue to wail on Twitter, because frankly they've been doing some weird stuff, and that directly affects, what I imagine is, a large portion of your business, but It's water off a ducks back. I read your blog post again last night. You seem very positive about it?
Paul: Yeah. They've definitely said what they're going to say and have made the moves that they're going to do. They could have been a lot worse.
Guy: That's a great attitude.
Paul: For whatever reason they've decided that, at least for now, they could change their minds at any point, that they don't want new Twitter clients coming out. The existing ones, they've structured in such a way that most of the existing ones will be able to continue for at least a couple years.
Guy: Yeah, you've got a long runway, given how early you were on the platform, I imagine?
Paul: Right. So did some of the other clients as well that have been around for a while. It's just new clients, or clients that have just launched that can have issues with that. With those restrictions.
Guy: I just realize we talked to Lauren last week. This is basically the Twitter developer podcast. Maybe we can get Craig on next week. So, Netbot, the App.net client, was because you wanted to do it? Rather than being a reaction to the Twitter stuff?
Paul: Yeah. We wanted to see where the service would go. There's definitely a lot of support associated with doing a client like that, but the original merge port over from Twitter to ADN wasn't particularly difficult. We had a lot of people asking for it, so we figured, "Why not?" We had a Tweetbot for Mac coming out, and I had some time in my hand to do something, so I went off and did that.
Rene: What was that like? You weren't as early as Twitterific or Tweety, so they probably had a more mature API for you to write against. ADN, you were there almost from the beginning. Was there a large difference in writing against those two services?
Paul: The API's are somewhat similar. It actually seems like the ADN-API is somewhat better in a lot of ways. Probably because they don't have a lot of baggage.
Guy: I prefer, looking it over. I've implemented a little bit of both, like what you guys have, but the ADN one seems to be informed. Where Twitter sort of took some missteps.
Paul: Right, but then again, it's a lot easier to do something like that once you see what mistakes made by the previous people coming before you [?] .
Guy: Oh, yeah. I'm not saying that to knock Twitter in any way. You can definitely learn from what other people have done. Do you have a preferred service? Which one do you fire out first, Netbot or Tweetbot?
Paul: I alternate actually between the two. In the morning when I wake up, I'll sometimes do Netbot, sometimes I'll Tweetbot, skim through my timeline and go from there. I don't necessarily go with one or the others, as far as what I first open or last open at night.
Guy: Do you use them differently?
Paul: Yeah. I think at this point, for Tweetbot or Twitter, I'm mostly doing a lot of support stuff. Answering Tapbot's, on the rare occasion answering Tweetbot accounts. On ADN I mostly do my little geeky tech posts, or complain about whatever is bugging me at that particular moment.
Guy: I basically do the same thing too. Except I don't do support. I'm more of a jackass on Twitter. I just crack jokes all the time.
Paul: I didn't say I was particularly good at support. I probably shouldn't do it, and all the Tweetbot stuff. For the most part it's done by someone else.
Guy: You guys have a support guy?
Paul: [inaudible 25:00] guys.
Guy: Right. Sorry. I knew that, Ash.
Paul: Yeah. Otherwise, nothing would ever get answered.
Guy: I'm sure, yeah. With the number of app's you've got, and their broad appeal, I'm sure you've got a lot of people who need support.
Paul: Yeah.
Guy: With that in mind. Does the Netbot stuff have a lower support per user class, than say, Tweetbot?
Paul: Well, it depends. The Netbot users are definitely more advanced than the average Twitter user. Which I think everybody would expect. There's definitely more changes going on with the ADN-API than the Twitter API. So while there's less technical support, as far as answering questions on ADN, there's the other side of technical support. Which is implementing new features and adapting the changing API's.
Guy: Maybe you can't say, but do you work closely with Dalton and those guys?
Paul: Yeah. We'll talk to them, and they've often asked, "Is there any particular API you would like to see us work on next?" We'll ask questions about, "What do you guys have coming up in the pipeline?" They're pretty open with everybody about that stuff too. It's definitely a [inaudible 26:36] experience.
Guy: That's great. Do you ever foresee the net stuff taking over your Twitter stuff? Not in terms of global popularity, but in terms of where your revenue or attention is going to be spent?
Paul: Not at this point. The user base of ADN is just so small now compared to Twitter, that I would expect something else would overtake Twitter and ADN, before ADN overtakes Twitter. We're known for Tweetbot now because we've been focusing on that for the last couple years, but like you mentioned before, we've done other app's and we're going to be doing other app's.
Guy: Do you have any plans? I mean, don't spill the beans.
Rene: Yeah, no spoilers.
Paul: Yeah, no spoilers. We're revising one of our existing app's now with some new stuff. We'll figure out something completely different to do sometime next year. We'll come up with something.
Rene: You do one of my favorite things on ADN and Twitter, where you post some of the support requests you get from people who pirated your apps. And on ADN it's even funnier, because it's such a small user base.
Guy: And they paid $50.00 just for the privilege of being there. I guess it's like $36.00 or something now.
Rene: Is that just for catharsis, or does that actually help you curb that practice?
Paul: No. They don't care. They literally don't care about any of that stuff. They certainly aren't following me if they're pirating the app. At least the vast majority aren't. It's just blowing off steam or having fun with it.
Guy: Does it get to you, or do you just roll your eyes and think [inaudible 26:36] ?
Paul: Well, here's the thing. For the most part I don't care about pirating, other than having some fun with it. Except now when people are pirating the app, it's actually taking away tokens that we only have a limited supply of. While normally I would say, "Those people were never going to buy the app anyway so I'm going to have a little fun with it, but I'm not going to waste a lot of time dealing with it." Now, there's a different situation going on.
Guy: Right. That whole argument that you can make a copy of software and it's infinite and nobody loses anything is out the window, because there's a finite limit of tokens out there.
Paul: Right. So we have to be a little more aggressive with curtailing those limits. Curtailing those guys from using pirated versions of the app, because it literally is costing us potential future money.
Guy: Again, with a very positive tone, you wrote a piece about the pricing of Tweetbot after the token limit came in. Can you talk about that a little bit?
Paul: For Tweetbot iOS, we have a fairly large number of tokens. We've been selling it for, I think, 18 months prior to the new limits coming into place.
Guy: Is that it? Wow, it feels like forever, iOS moves fast, man.
Paul: Yeah, it does. But, if you can imagine, assuming we kept it at the same rate, we'd still have at least 18 months to go after that. Whereas, on the Mac side it's quite different, where fortunately we had that public alpha and beta, we were able to get over the 100,000-token limit before the cutoff.
Guy: That's great. I hadn't heard that. That's good news.
Rene: Was that you being prescient, like you just had a sense that you should get that thing moving faster than you might have otherwise?
Paul: Yeah. We definitely felt like something was happening. There were a few blog posts coming in from Twitter, throughout that time. We just felt that it's going to be a lot harder to shut down a client that's out there than one that's not.
Guy: There was "a tremor in the Force".
Paul: Yeah. But, we definitely didn't have any inside knowledge of what exactly was going to happen, because if we did, we would have structured things a little bit different. We came out, I guess, as well as we could from that situation. But, we definitely don't have an unlimited number of tokens available on the Mac side, and that impacted what we could do on the pricing side of things.
Guy: You charge 20 bucks for Tweetbot for Twitter, on the Mac.
Paul: Yes.
Guy: That used to be a reasonably low-priced Mac software pricing tier. These days you have to make an argument in support of that being a fair price. How do you feel about the downward pricing pressure? I know on iOS, they're not cheap, but they're certainly way cheaper than you would have expected, traditionally, from Mac stuff. Was that a warning to you when you started with Tapbots, or was that something you just rolled with?
Paul: No, because back then, there wasn't this downward pressure. When we first started it was very soon after apps first came out, so there really wasn't a history of what pricing should be for the applications. With the App Store, you would see a lot more volume than anything you would ever see on, the Mac side, for example, back then. The pricing on iOS is what it is. I know a lot of people seem to complain about it. But I think the volume you see on there pretty much overwhelms any of the pricing concerns.
On the Mac side, again, it's a little bit different. I think the big pricing issue on Mac, right now, is Mountain Lion being $20, which everybody compares every other piece of software to.
Rene: Which is heavily hardware-subsidized, that $20 price.
Paul: Right. I almost wish they would have Mountain Lion be free instead of charging that $20, because then you wouldn't be comparing the two. You don't pay for iOS upgrades, at least, not anymore. I wish they would do the same on the Mac side.
Guy: I feel like I've had this conversation with so many developers that putting something at $20 puts an upper-end on the complexity of your software. Everybody can say, "You're not as complex as the operating system, so, why would I pay $20?" It's like an apples and oranges comparison.
Rene: That's their place.
Paul: They make it anyway. When people complain about price, that's the number one thing I would hear is, "This is as much as I paid for the operating system." I'm like, "No, you actually probably paid a couple of grand for the hardware that ran the operating system that subsidized that $20 price."
Guy: What are you going to do, write a long email, "Here's, actually, how the financials break down"?
Rene: "Here's what Numbers charges. Here's what Aperture charges."
Paul: I, definitely, would wish either Apple would make it free, or maybe, just remove it from the top charts. It would give a little more room to other people, so that they don't go and see Mountain Lion for $20 every time they go into the App Store.
Guy: I see them do that for all their apps. I understand why they don't, because I think the App Store tries to be, "Here's just the raw numbers. We're not going to mess around with it." But Top Paid is just full of Apple stuff, constantly, it's impossible to break in. Well, not impossible.
Paul: It's impossible to beat Mountain Lion on Top Grossing. It's undoable. I have a rough idea of what they make there on a daily basis, and it's insane.
Rene: Make Mountain Lion an app purchase for Lion and just get it off there.
Paul: Do something. I would, actually, just prefer it be free at this point. I know relative to any other developer they're making a ton of money every day on there, but, it's got to be beans compared to what they're making on Macs and iPhones.
Guy: You can tell they dropped it to $20 in order to encourage rapid adoption.
Paul: Right. Make it free, and then there's no rapid adoption problem, because everybody's just going to upgrade to it. Make a bunch of developers happy.
Rene: Was there a lot of math going into figuring out the $20, or did it just feel right? Did you go, "There's a scarcity of resources, we only have so many tokens, we have to be able to develop it and support it going forward for X number of years, a bunch of fancy math inserted there, this is the price," or was it more of a gut feel?
Paul: There was some math, and there was a lot of gut feel for, "What's the most we can charge and not lose a ton of customers, and still support the app," like you just mentioned. It was definitely a lot of back-and-forth on what exactly we should charge for the app, because even if we're charging more than we would want to, it's better for the people who buy the app, long-term if we, actually, make money off the app and continue to support it, and don't run out of tokens in a couple of days.
Rene: Different than the iOS version, you actually handed off development of the Mac version. What was that like? A lot of developers say that their apps are their babies, and you gave this one to a babysitter for awhile.
Paul: It's not for awhile, because Todd Thomas, who's working on it, is still working on it. All the Mac code is stuff he wrote. The low-level code that actually talks to Twitter is shared between the iPhone, iPad, and Mac versions, and that's all the stuff that I wrote. But, I just didn't have time to get into the Mac side of things, and spend a year doing that, and still supporting Tweetbot, and keeping it updated. It's just not something one person, I don't think, code-wise could handle.
Along with, every time I start looking at AppKit after having done UIKit for awhile, it's just not something I can handle, for whatever reason. I did it for years before. But after being on the iPhone side for awhile, it's just not pleasant to go back to.
Guy: What's your beef, to be blunt about it? We were talking before we started recording. Paul's been doing this for a long, long time since, basically, the beginning of NeXT, pre-OPENSTEP, right?
Paul: Yeah, NeXTSTEP.
Guy: Pre-Foundation? Pre-NS String, when everything used to take a character pointer?
Paul: It was before NSObject. If you go way back, it was, actually, Object.
Guy: Yeah. It was just Object at that point. NX code and all that? All of the crazy, deprecated stuff you see in AppKit, like NX Color and all that, Paul probably dealt with that at some point.
Paul: I've blocked it off my memory.
Guy: I'm going to make you bring it up now. A lot of people that basically came to Apple development with the iPhone and iOS, take one look at AppKit and find it primitive, and don't want to deal with it anymore. Even knowledgeable people, who know what they're doing, just don't want to deal with it. But, you've got a ton of experience with AppKit. My position is that often AppKit is doing a lot of things that UIKit can't do. That's less true with each release of iOS, but I think you'd probably agree with me that certainly all the text stuff was, until recently, like night-and-day better on AppKit. What's your beef with it? Is it the sales?
Paul: It hasn't really been upgraded, at least not from what I can see, since UIKit started taking off. It's just stagnated along. They bolt on layers here and there. But, if you get in there and you try to make a customized UI with buttons, with different backgrounds, and try to animate stuff, it just doesn't work right. There are a lot of bugs in it.
Guy: Yeah, just yesterday, I was trying desperately to tint a button. Not desperately.
Paul: You kind of have to go in, and rewrite it all yourself. After you're used to UIKit where it seems to be the case where you're looking at Twitter versus ADN-APIs, like we were talking about earlier. UIKit learned a lot of mistakes from AppKit. I would love to see a unified kit, App-UIKit, whatever you call it, that merges the two.
Guy: Do you think it's possible?
Paul: I don't know. They can, definitely, do it like the Carbon to AppKit transition, where they just said, "AppKit's legacy now. UIKit is new. It takes awhile before all the features that were available in AppKit are now available in UIKit. But, it's the future." Eventually, a few releases down the road, it gets deprecated, and everybody forgets about it, unless you have to run an app that was only updated 10 years ago, or something like that.
I would like to see it either get a lot of love, where you can do animations as quickly as you can do them on UIKit and things work right or as expected, or just toss the whole thing out, and start something fresh.
Guy: ...as much as AppKit. Everything is layerbacks. Even when the density was such where they needed a sub-pixel add-on type of thing, and besides, you could take it to a device and it would break anyway. But AppKit has all of these affordances to account for its history, and to account for the variability of hardware. Do you think if you bolted everything that was required of AppKit into UIKit, UIKit would be as straightforward and effective as it is now?
Paul: That's a good question. They definitely added on stuff to UIKit. Like you mentioned before, the text system for UIKit was very basic at the start, and they seem to have done a pretty good job of putting in functions throughout the different iOS versions to improve that and make it more like what you can do on AppKit. I think if they did it right, if they took their time, it definitely could be done in a way where it wouldn't be this ugly behemoth that didn't make any sense. It would take awhile, and probably, five years from now, we're all going to be complaining that UIKit is now not the cool stuff because some other kit came out for some other Apple device that has yet to be dreamed of.
Guy: The Twitter app, like Loren did a cross-platform, UIKit, sort of thing, and Sean wrote Chameleon, which was their sort of UIKit on the Mac thing, how did you guys approach the same problem, point a Twitter client from the iOS to the Mac?
Paul: We used AppKit, believe it or not, as much as I don't really care for it, and this was, actually, mostly my decision, which was maybe a bad decision.
Guy: I don't think so.
Paul: But, we wanted to make sure we could use the text system, and all that good stuff that AppKit provides, but on the other side animations aren't as smooth as they could be, and we have to deal with layers causing problems in some places where they don't cause problems on UIKit doing those same type of things. There's no UIKit-clone framework for Tweetbot, it's all AppKit-based.
Guy: There are two approaches to writing cross-platform UI code. At one point, and I'm sure you know this, NeXT used to run on Windows, so you used to be able to compile it. You'd have all the Display PostScript and all that, and it would fake drawing the windows inside a Display PostScript context.
Paul: Yellow Box?
Guy: At one point they were shipping it, weren't they?
Paul: I don't know if they ever actually did, but maybe they did. It was awhile back.
Guy: Before the Apple XGeN, right?
Paul: Yeah.
Guy: I thought you could compile NeXT stuff onto Windows NT. Whatever.
Paul: They used to have the OPENSTEP that ran on four different hardware platforms.
Guy: That's probably what it was.
Paul: That's different from what I think was Yellow Box.
Guy: I do know that if you'd look in the headers, maybe not now, but in earlier OS X releases, there was an NSWindow, Windows extension. There'd be an "ifdef" and there'd be an "hwin" to get a Windows window-pointer out of your NSWindow thing. There's that approach, where you basically just plunk your kit on top of some other base APIs. Then, there's the other approach where it's, "I'm going to rewrite the UI later." It seems like you took the latter. Is that out of experience, or is it just because you felt that going with the platform UIKit would be easier than fighting against it and trying to impose your own UIKit view?
Paul: As much as I don't care for AppKit, I think it's the least-worst choice to write an application in for the Mac, because it is the native UI for the system. I don't like applications that are ugly ports from other platforms, like Java-based UIs and stuff like that. We're big believers in making the application feel right for the device, for the operating system. It's one of the reasons why we won't port to Android. We're not going to take our UI and our feel and just move it over there and have it run the same way, because it's just not something that we feel is the right thing to do, as people.
Guy: I think that goes back to what you were saying about the Convertbot and the iPhone 5 screen, in that you designed that app very specifically for a certain-sized screen, and now that it's changed, it's problematic to recapture that feel on the larger screen.
Paul: We could definitely stretch out the top and the bottom but does that really make any sense? Is that something that we would be proud of?
Guy: You could just give it a big Imax-style chin on the monitors.
Paul: That makes it somewhat tough, that we care so much about how these apps work and feel. Where if we'd used something like TWI or Chameleon, maybe it would have made the process of porting a bit easier, but are we then losing out on some of the nice things that AppKit provides that are behind the scenes and that you just subliminally notice?
Guy: Stuff like accessibility. Like when you do your own sort of interface kit, you lose a lot of stuff that comes with the system, like being able to select text and run a service on it, maybe. Weird, little things. Like, edge cases that just drop away.
Paul: Right. Then, as Apple upgrades the operating system, new features probably don't work quite right, if you're using those things. A perfect example, going back to the twUI, it's all fuzzy now. Why is it fuzzy? Because it's using their own UI, crazy layer-backed stuff that's not AppKit. When they moved to the retina screens, it wasn't ready for it. Now the app looks fuzzy to everybody.
Guy: I'm sure that bugs Lauren, but I didn't want to ask about it. [laughter]
Guy: It's not his problem anymore.
Paul: I'm sure that's something that could be fixed in a fairly simple manner, but if it was written with AppKit, it probably would have just worked.
Guy: Exactly, You were saying that five years from now, maybe there will be some other kit that we all wish UIKit worked like. You've been doing NeXT stuff for a long time now. I've been working in the field for 6 years. I've been doing it for maybe 15, doing programming on the side and doing tools for work and all that. Do you ever worry you're going to get blindsided by a different platform?
Paul: No, I don't. A few years back, before the iPhone came out and the Mac stuff was waning or at least not as popular as today, I spent quite a bit of time doing Ruby and Ruby on Rails type of stuff. I'm not terribly worried about it. If it, for some reason, dies out, there's always something else I can jump into. Fortunately, I really like the Mac stuff, the Objective-C libraries, and think it's the best stuff out there. It took a while, but at least the last five years, it's been really great.
Guy: Definitely. It used to be, and this was a different time too, there were more operating systems around in general. I don't want to say I experimented in my youth but... [laughter]
Guy: I used to use OS/2 and Windows NT and Classic Mac, and that's how I came to find out about all the NeXTSTEP stuff and all that. These days, I find myself, because I work and I work on Apple technologies. I sometimes wish that I would go and maybe check out what it's like to program on Windows Phone 8. Every now and then I'll go read through the docs, but I don't actually practice it. Is that-that's not something you care about. That's just...
Paul: If any of those platforms besides the Android actually take off in some way I'll definitely take a look at them. I refuse to look at Android just because I have a rational hate of Java and all things Java related. But I certainly, if Windows 8 sold more than a couple phones a week I probably would be interested in taking a look at it.
Rene: On the flipside, some people like John Syracuse have been critical or maybe hypercritical about objective-C and its future when compared to the higher-level languages and the way that you can develop for more, I don't want to say more modern, but more recent devices. Maybe like Windows Phone or maybe some of the stuff that Microsoft is doing with C#. Do you see the same kind of limitations in objective-C and are there directions that you hope that Apple takes it beyond what they're doing now?
Paul: I really like the way, actually, Apple has been handling objective-C where every year they're making some significant but not overwhelming change to it. They've recently added the whole, what was it? The new memory stuff?
Guy: The boxing.
Paul: Boxing, but the new memory stuff, what's it?
Rene: ARC.
Paul: ARC. Yeah. In there, which really changes a lot of how one writes an application.
Guy: Have you ever-sorry. Have you seen apps been using that?
Paul: Nope. Nope. I mean it would be nice to, but it would involve a lot of going back and changing classes that have been working for years now. It's not something...
Guy: I can't stop writing retain release, like I cannot do it. I've got to break that habit, but... Anyways, sorry Craig [inaudible 55:22] , go on.
Paul: It's not something I have a problem with myself, since I've been doing it long enough that I can retain release in my sleep. But it's great for new developers. On the other hand they added block recently which I used pretty much all over the place. I've even almost got the syntax memorize for how to write a block without copying and pasting it from somewhere else. I like the way they're improving the language without throwing it all out and starting from scratch. Which...
Guy: It certainly seems that from '97 to almost 2007 nothing changed and then for the past five years we've been getting pretty big improvements.
Paul: Right. You can almost see it's a yearly cycle and a lot of those improvements they make it so it will run on a previous version of the OS, which is great as well. Is it as fancy as whatever new JVM based languages they're coming up with? Probably not. The language is only half the issue. Even less than half the issue. It's the frameworks that go around and I don't think there's anything anywhere near as mature that works as well as foundation in UI kit.
Guy: You can say that, begrudgingly.
Paul: I guess it doesn't have all the whiz bang features but it's been improving at a good, sustainable pace. If you look at something like Ruby on Rails as a counterexample, they add new whiz bang features to it, to the framework, every dot release and it gets to a point where if you haven't kept up-to-date with each and every one of those releases and you go back and try to update an app you almost have to toss the whole thing out and start over to deal with whatever new features they decided had to be added without any regard to previous working code.
Guy: Incremental improvement without churn. You don't have to toss everything out.
Rene: No rip and replace.
Guy: One thing I find heartening in retrospect, but at the time I was annoyed by it, not annoyed, I'd written a large app using Garbage Collection, which was dumb because it used a lot of graphics, too, and a lot of the graphics stuff didn't end up being properly garbage collected, and then they abandoned it. It was a little concerning. Because under Garbage Collection you could write retain and release and it was a no-op, I'd been doing that anyway because I couldn't break the habit, so it wasn't that much a pain in the ass to switch back to the regular.
In retrospect, I kind of like that because they went a direction and within a year, year and a half, maybe two, they just ditched it and they went to Arc, which I find to be a very compelling argument they are taking the stewardship of objective C and their platform seriously and they won't commit long term to something they don't think will work.
Paul: Yeah. Garbage Collection is definitely an interesting edge case where, for whatever reason, they decided it wasn't working and they just reversed course and went a completely different direction. Fortunately, I don't think it impacted too many people. Like you said, you're writing release and retain code anyway. I don't think I've ever used it.
Guy: Very, very few. Very few third party developers used it.
Paul: It's nice that it's consistent improvements and course corrections, if needed, year after year as opposed to waiting three or four years and tossing in a bunch of stuff and breaking backward compatibility. Everything seems to be pretty compatible with everything that came beforehand.
Rene: Is there a direction you'd like to see them keep going with those iterations?
Guy: I definitely would love to see blocks just everywhere. Go in and make sure that any operation that takes any amount of time has a completion block. Stuff like TableView updates. When you go in and you do some animated UITableView updates, there really should be a completion block so you know, "Hey, we're done with the graphical side of this." If you need to do something else, continue on. I love to see them just making sure, "Hey, everything any kind of animation, any kind of long-running operation, has some kind of block or some kind of call back to it." Also, the GCD stuff is awesome. I love to see them keep going with that, making sure it's more well-defined.
When you make a call using GCD, you should know, "Is it coming back in the same thread that called it? Is it coming back in a different thread?" have all that stuff documented. I love to see that stuff happen.
I've been playing, like I said earlier, with iCloud this week. I'd love to see them improve those APIs. They're currently way too hard to use, at least the document-based side of iCloud.
Guy: Are you using the UI document stuff, or are you using the stuff from Foundation that UI document builds upon?
Paul: Right now for Tweetbot and Netbot we use the key-value style API for...
Guy: That in my experience works reasonably well.
Paul: When it works, it works reasonably well. The API is certainly very simple to use. It's great for what it should do. It sometimes, for whatever reason, refuses to work.
Guy: Can you explain a failure case to me?
Paul: It just doesn't work. [laughter]
Paul: The API is very simple. You set a value and you read a value. When you set the value, it should go up to the Cloud.
Guy: I'm trying to think, there's no...Do they have an error reporting API on that? I don't think so. It just looks like user defaults, right?
Paul: Yeah, it's literally a copy of user defaults with some notifications of when things change. For some reason...
Guy: There's no way to query for an error, and there's no notification that you get an error.
Paul: Yeah, and I literally have some devices that it just refuses to work on. I'll set the value. I can watch the traffic coming out from that machine. It just never goes up anywhere. It just stays there. You have no idea, obviously as a developer, you have no idea that anything wrong is happening, because you get no call backs or anything.
Guy: You think it's on the back end?
Paul: No, it's definitely on...There's probably back end problems as well, but this is definitely on the device itself. I'm watching traffic to and from it. As I set a value, it just won't go anywhere. It just stays on the device. There's no network call out to the iCloud servers doing whatever they do.
Guy: Is this some kind of timeout thing?
Paul: No, I just...
Guy: I don't know. I'm trying to debug your [inaudible 01:04:10] .
Paul: I've sent tons of logs over to Apple, but still haven't gotten a response of what's happening. It's been happening since 5.x, it's not a new 6.0 type problem. It's just [inaudible 01:04:26] API for whatever reason, sometimes on some devices, refuses to work and then, once in a while, it will start working again on the same device for no rhyme or reason. It's probably the number one support issue we have with the Tweetbots is sometimes iCloud stuff doesn't work.
Guy: It's frustrating because it's not something you can dig into and fix. That's for simple API.
Paul: The document-based API is much, much more complicated. It does seem to work more reliably, though, for whatever reason. It's very complex API-wise. There's a lot of different failure cases that you have to handle. Everything is asynchronous and some of those asynchronous operations don't have call backs to them, or not, at least, easy call backs. It's just much more complex of an API than I think it should be. It probably explains why so many people have problems with it.
Guy: If you can say, which Apps are you using that in?
Paul: We're actually looking at doing some stuff in Calcbot with that.
Guy: Oh, interesting.
Paul: For example, it would take the tape on one device and synch it across multiple different ones.
Guy: That's cool. That makes sense.
Paul: Once we have that working, we'll probably go in and look at getting it working on Tweetbot for stuff like graphs, as an example, where your graphs could by synched between different devices, where it's not that thing where you're possibly talking about, "Yeah, 140 character graph, that's no big deal," but you an image, or several images, that may go along with it. That stuff doesn't really fit into that key-value API that's simple to use. You need to do something like the document-based API where you're dealing with large files.
Guy: No, I think that's exactly the right thing to do. They call it the [inaudible 01:06:56] API, right? Just the idea of having all your drafts transparently everywhere that you've got Tweetbot seems like a great idea. Oddly, I don't think anybody's going to....
Paul: [inaudible 01:07:05] pretty complex.
Guy: I'm sure. I'm sure the amount of work you put in, you'll not get enough kudos. People will just notice that the draft's there and they'll be like, "Oh, cool." You'd be a month of blood, sweat, and tears to make that work.
Paul: Yeah, it's been a good week, plus just getting this tape going back and forth between different devices. I ended up rewriting it three or four different times just to deal with different API issues/limitations.
Guy: What's your policy in terms of supporting the most recent operating system? I ask that because let's say iCloud never gets fixed on iOS 6, but for some reason it works on iOS 7. Would you just move to iOS 7? Would you limit that feature to iOS 7? What's the policy?
Paul: My overall view is that you should support the two latest major OS versions.
Guy: Yeah, I think that's common.
Paul: I think Apple's actually almost forcing you to do no more than that. You can't build an App for the iPhone 5 that works on 4.1. The 4.2 SDK stopped supporting deployment for iOS 4.2 and earlier. Something like that. Apple's almost forcing you to only do the most recent two OS versions, under iOS.
Guy: Yeah. With iOS, they're definitely dragging everybody along. Users and developers alike. They're just dragging people along. I think they see each device as having a two year life span. Maybe not the 3G. That must have been longer. But sorry, I cut you off. Go ahead.
Paul: You can probably count on two years of updates, up until the point they stop selling that particular device. I would expect, actually, the 3GS to get at least iOS 7, possibly iOS 8. But I wouldn't expect much more than that.
Guy: I'd be surprised by iOS 8. Only because I think they'll just be... [inaudible 01:09:39] .
Paul: That one is an edge device. It's been selling for so long. But I definitely think you shouldn't expect much more than two years worth of updates from the time they stop selling the device.
Guy: That makes sense.
Rene: The thing that's interesting with Apple is that it has so few features of iOS 6, but it still supports iOS 6. Apple's point of view is that it wants it to be binary compatible, so that when you write apps against iOS 6, those can all run on the install base of iPhone 3GS devices. When you look at things like Windows Phone, which loses binary compatibility after one generation, that becomes key for their market.
Paul: The Windows stuff is kind of ridiculous, at this point. They're still selling the Nokia something or other.
Rene: 900.
Paul: And then three months later, it's obsolete. Because it won't run Windows Phone 8. What are they thinking? Android's even worse than that. It's nice that Apple has a fairly consistent story there.
Rene: For a user, yes they're upset they don't get Siri, for example. But if they couldn't bind new apps, that becomes a big problem, especially for a device that was being sold, up until fairly recently. The binary compatibility is the layer that they try to move forward the most.
Guy: Paul, we talked about AppKit, UIKit and iCloud. All of these things, basically, are under one guy. They're all under Federighi now. Do you think that makes a difference? Do you think we're going to see more cross-pollination or a tighter coupling of this stuff?
Paul: I have no idea. To me, the whole way that Apple works is a black box. I certainly have no inside knowledge of what happens there, other than every year they come out and announce cool features or not so cool features, as the case may be. I hope they start getting a little more aggressive with iOS. The last couple versions have been somewhat lackluster. The devices have gotten better and better, but the OS, I won't say it's getting stale. But it could use some cool new features, here and there. I'd love to see apps being able to tie in to Siri somehow.
Guy: I looked at that. That's really hard to do. Do you just mean launching them? Providing a service is tough.
Paul: Yeah. But there's got to be ways to do it. I don't know enough about how Siri works down low and that kind of level, to be able to say what can be done.
Guy: The problem is disambiguation, basically. If you just put a list of keywords in your PList and you've got three apps, you've got Twitterific, Tweetbot and Twitter for the Twitter app, what happens when you say, "Send a tweet," or, "read my replies to me"?
Rene: "Do you want to send that tweet to Tweetbot, to Twitterific or to tweet, press the button."
Paul: You could set a default service. You can have a default mail service, like you do on Mac. I don't see why you couldn't have that on...
Guy: It's an interesting problem to look at.
Rene: I still think though, they're doing that as partner plays. They're not going to give out the revenue they can get from brokering deals with the Yelps and the Ticketmaster companies, just to provide a free way for apps to do it.
Paul: Possible. But if Google goes in and starts opening that up, they might not have a choice. If some other operating system starts integrating those cool features and they're not, just because they might lose some revenue, they're not going to stand for that.
Rene: The bigger problem with the Siri stuff right now is, for example, Google's doing on-device voice parsing, which makes the experience much faster. Anything that doesn't have to go to the cloud doesn't go to the cloud. I can set an alarm. I can do all sorts of things and never have to worry about the cloud being a point of failure. Siri sends everything to the cloud, still. Google Now is also doing all the predictive stuff. Where it knows where you are, it knows where your appointments are and it starts providing information, even before you ask, where Siri is still a query, response engine. They're already falling behind in several of those areas that Google excels in. They should get a move on on that stuff.
Paul: Yeah. That's what I said. I would hope that the future OS's are going to be a little more aggressive with cool new features that we can't even imagine today. The last few versions haven't quite done that.
Guy: Yeah. They've solidified a lot of stuff, but they haven't really leaped forward in any way.
Paul: For iOS 6, what were the killer, must-have features. Maps, I guess.
Rene: The kids got Facebook, Paul. Come on.
Paul: Yeah. That's true. More account stuff, which is actually pretty nice but will take a while to go through all the different applications to start using that stuff.
Guy: Where do you sit with the Twitter integration in iOS? Does that help you at all? Does that run parallel to you? When they start introducing things like Twitter integration, Facebook integration, built-in reading lists, are those things that you look at to add value or do they take away a layer from your business?
Paul: All that stuff they've added is great. Especially being able to launch Tweetbot on a new machine and not have to enter in your passwords, because it's using the Twitter integration stuff to get all that, is pretty cool. None of that stuff has impacted us in any negative sense. I'd love to see them add in the reading list API, because right now there's no API for it, on iOS. We keep getting requests for that.
Guy: It seems like a gimme. It seems like they could implement a URL scheme and just make it work.
Paul: They added it into Mac OS. It's a little bit hidden in there.
Guy: They did?
Paul: Yeah. It's in there. I didn't know about it.
Guy: Where? [inaudible 01:16:31] workspace or something?
Paul: It's in the sharing API.
Guy: Oh wait, I did see that. Sorry.
Rene: One of the things I also wanted to ask you about is that you've resisted doing in-app purchases. A huge swath of the iOS economy has gone into in-app purchases. Some people have done it in Twitter applications for multiple accounts or to get rid of ads. You basically buy Tweetbot, you get Tweetbot. Was there ever any discussion about, "Hey, we could do photo filters or make mute filters an in-app purchase"?
Paul: No. Not seriously. The one area where we talked about it was for push notifications. But we were able to...
Rene: Because of the server expense or because you thought that it would drive...
Paul: Because of the server expense side of things. We thought it would be a lot more involved, cost-wise, then it ended up being. And it would have been if I'd outsourced the push stuff, which was our original plan. But then I ended up just writing it all, writing it on server. It's a point where it doesn't cost enough to justify charging an IAP for it.
Guy: I imagine you have a lot of traffic on that. But you don't need a big, heavy-duty?
Paul: Yeah. I want to say we're almost to our billionth push notification. Some time soon.
Guy: What are you running on, a 386?
Paul: No, it's a Xenon. I don't know. Something we rent.
Rene: It's not a hacked Xbox. Paul No. But it's not a crazy machine either, with 36 cores or anything ridiculous like that. It's a normal-sized server that is enough to handle the traffic and then some.
Guy: So unless you're doing Tweetbot level traffic, you're fine with just a basic server to handle push notifications?
Paul: We were even fine with a basic server.
Guy: That's good to know.
Paul: At least the way we're doing it, it's not that intensive of resources.
Guy: Yeah. What are you, using Web Objects?
Paul: [laughs] I used to really love Web Objects.
Guy: I know. I was talking to Lauren about it last week. I wanted to bring it up with you, because you actually did it, professionally.
Paul: Until they switched to Java and then I almost immediately lost all interest in it.
Guy: Did you hear last week's show? Lauren got Objective-C running on servers.
Paul: It's doable. The server stuff, I just stick with Ruby, just because it's pretty easy to use on there. But yeah, a while back Web Objects would run on servers and was Objective-C based and was all fun to use.
Guy: Yeah, it used to be awesome.
Paul: Then they started doing Java wrappers around Objective-C classes and all sorts of crazy stuff. Now, I think they should just take it out back and shoot it.
Guy: They have, right? It doesn't ship anymore. They still use it, but nobody else does.
Paul: Nobody uses it, but something still exists.
Guy: The store. iTunes Store runs it and a bunch of their other stuff uses it. The Apple Store uses it.
Paul: And their iTunes Connect back-end still uses it, which is probably why it's so bad.
Guy: Probably. [laughs] Wait, just fact-check me from last week. I said that they moved to Java because they wanted to run on app servers. There was something about cross-platform, right? You would know. I fumbled through it.
Paul: The reason was that Java was becoming really big, back when they made that choice. Objective-C, it was a lot harder to find developers who knew the language. At that point, I believe Web Objects was their big product. They were charging...
Guy: It was like 999 bucks or something.
Paul: No, they were charging more than that. I think they were charging like $50,000 or something like that. It was their big, money-making product. They probably had a bunch of corporate clients who said, "We can't find Objective-C guys. This is great, but we only have Java developers. We can find Java developers. Port it over to Java for us."
Guy: The irony now is there's like 100 WebObjects guys in the world that know what they're doing, and that's about it.
Paul: Yeah.
Guy: Oops.
Paul: Ruby on Rails works, or one of the offshoots of that works well enough that there's no point in going through the whole craziness that is WebObjects at this point.
Rene: The iPad has now gone smaller. You were wondering if at some point Apple would go bigger. Is that an actual problem that you would like them to solve?
Paul: No, I don't think they're going to go bigger. I actually more meant it's possible that the 10.1 inch iPad Maxi goes away, and they go and focus on the smaller one instead. At least from my personal experience, I much prefer the new, smaller one from a carry-around, play-with standpoint versus the old one. The only thing I prefer on the older one is browsing the web because of the bigger screen. Other than that, it's like this lumbering dinosaur. I compared it to the MacBook Pro 17 inch, where they just got rid of it.
Rene: The battleship
Guy: I watch a lot of video on my iPad, so I prefer the larger. It's like a portable TV for me. I'll go sit outside on my deck and watch TV on my iPad, so I prefer the larger one. I was not going to buy a Mini on account of the one X screen, but then when I actually saw one... It's pretty good. It's really good. I'm pretty sure I'm just going to go out and buy one as soon as I get my druthers together to do so. I do agree that it feels amazing. The build quality is great. The screen is way better than I thought it was going to be.
Rene: It feels like what's next.
Guy: I agree with you, Rene. You had a piece about not expecting a Retina screen, and I wouldn't, for at least the next rev.
Rene: It's one of those things that Apple's still bound by the laws of physics and the laws of economics. If you put a Retina display on it, it becomes an iPad 4. For people who don't want to carry a laptop, the iPad 4, the large size iPad Maxi still makes a lot of sense because it gives them a lot more area to be productive with, whether it's using the iWork apps or it's typing or anything like that. But if you have a ton of other Apple and iOS devices, the Mini really is a sweet spot now.
Paul: We'll see how it progresses. The MacBook Pro 17 had a lot of fans, me included, but it went away too even though they could probably still sell them today. They just sell so many more of the smaller devices. It'll be interesting to see. I definitely like the Mini better with the exception that I wish it had some more memory in it, like the newer iPads, the 1 gig versus the 512. Other than that, I don't miss Retina. I don't really miss the extra speed that the iPad 4 has.
Rene: It feels more like a mass-market device. When you hold it, it feels like that next breakthrough product.
Paul: I just wish it was a bit cheaper, but what are you going to do?
Guy: Wait a year. [laughter]
Guy: What do you want to see? Either in terms of software, besides killing AppKit... [laughter]
Guy: ...or hardware, is there something that you're...That sort of fanboy, Apple insider, I'm going to refresh the page until I read all the rumors on this kind of thing. Is there something you're excited about coming up or are you just pleased with the current iteration?
Paul: I'll answer that with two different hats on. From my business person hat, I would love to see cheaper iOS devices. I want to see the better iPod Touch, the 32 gig down to the $200 mark. I would love to see the iPad Mini down at the $250 mark. From my geek hat on, my personal hat, I'm really excited to see a 16-core Mac Pro with modern insides, as opposed to the current two-, three-year-old version that's out there.
Rene: You'd stick with the Mac Pro and not go iMac?
Paul: Ew, no.
Rene: [laughs]
Paul: No, I run a Mac Pro now. I'm not going back to those little, slow iMacs.
Rene: [laughs]
Guy: You know what? I did that for years. I was always on the Pro side of stuff. Then I bought an iMac Core i7, one of the earlier ones, because my Mac Pro was dying. It was old, and there was no update in sight. I figured, "Well I'll buy this 27-inch iMac," with a Core i7 and I forget what else. "I can use it as a screen when I eventually buy my new Mac Pro." But the iMac was just fast enough, and it was awesome, and I kept using it. I'm not sure I would go back to a Pro.
Paul: It is fast enough, but once you're running with the old 12-core Mac Pros, which is what I run, and you stick a bunch of SSDs inside, and... [laughter]
Rene: Some racing stripes on the back.
Paul: Put a couple monitors to it. I don't necessarily need it, but I really like it and want the latest and greatest and even better version that comes out next year.
Guy: Can't blame you for being into hot rods. Rene : Jardine has the cars. You have the computers.
Paul: He definitely...I still drive a 10 year-old minivan. [laughter]
Paul: I'll [inaudible 01:27:41]
Rene: It's got the racing stripes though.
Paul: No, but I actually got a bunch of paint on it from the side where I scraped against the garage. [laughter]
Paul: I'll spend the money on cool toys and hardware, not car stuff.
Rene: [laughs] Car stuff. If people want to find out more about you and more about Tapbots, where can they reach you?
Paul: Go to tapbots.com or follow me on probably best App.net these days, and @pth is the user name.
Rene: You went for a different user name on App.net than Twitter.
Paul: Definitely shorter, and I like the pth.
Guy: Got to go with the three letter [inaudible 01:27:40] .
Rene: Guy's a huge fan of the three letter name.
Paul: It's much easier to type, and you can reply to more people with the shorter names. Longer reply tweet or post.
Rene: Guy, where can we find you?
Guy: I'm @gte on Twitter and App.net, and my website is kickingbear.com.
Rene: You can find me @reneritchie or you can find me on iMore or just look up Debug on iTunes and subscribe. Paul, thank you very much for joining us. That was awesome.
Paul: Sure, Renee.
Guy: Paul, it's been great. Thanks a lot.
Paul: Nice meeting you, Guy.
Guy: You too. Take care.
Debug 2 transcript: Paul Haddad of Tapbots
Guy English: Hi, my name's Guy English, and this is the second episode of Debug.
Rene Ritchie: I'm Rene Ritchie, and joining us today is Paul Haddad from Tapbots, who you might know from a fine collection of small, automated iPhone apps like Waitbot, Calcbot, Tweetbot, and now Netbot. How are you, Paul?
Paul Haddad: I'm all right. How about yourself?
Rene: Very good, thank you. The way we usually like to break the ice, get started, have the first round poured is to ask you how you got involved in Mac / iOS development.
Paul: You have to go back...Oh God, it's a little bit over 20 years ago, when I first saw a NeXT station. I was in college at the time and went into their bookstore / computer store thing, and I saw one of the black and white NeXT stations. I started playing with it, and I knew I had to have one. Begged, borrowed, and stole and got one. Pretty much started coding on them from there and followed that throughout my career.
Rene: What was it like coding on a machine like that back then when it wasn't the biggest, most popular brand on the planet?
Paul: It was interesting. Unless you consider it turning into Mac OS and iOS, it never really became popular at all, but it was definitely better than anything out there from a user perspective, which is where I first got into it. There was nothing else like it. There was high-resolution display, multi-tasking. All the stuff that we take for granted now didn't exist really back then unless you were talking about really, really high-end workstations. This was the first operating system where it was friendly, easy to use, and a complete package.
If you went and you looked at the little Macs back then with their little, tiny screens and the PCs with, I don't even remember, VGA graphics or something ridiculous like that, this was a completely different experience. It's very much like what we're used to today, although obviously a lot slower back then.
Guy: When I was doing prep for this show, I went on the Tapbots site, I looked you up, I read a bunch of your blog posts, and everything. I ended up back at an old site with your resume on it.
Paul: [laughs]
Guy: One of your first gigs that you list is writing an object-oriented wrapper that worked on NeXTSTEP and Windows 3.1.
Paul: That was actually my first real job. I didn't...
Guy: That's crazy. Sorry, just for the audience, Windows 3.1 is a segmented memory model 16-bit, and NeXT is like an actual, modern operating system. That's a big challenge.
Paul: Yeah, it was way back...To be honest, I didn't write the wrapper. I just had to work with it. A consulting company came up with it for a small company. The kind of stuff you'd never see happen, I would think, today. It was for something really boring, reinsurance contract management. Compared to coding for Windows, it was so much easier and better stuff to do. [crosstalk]
Guy: I'm sure. It shocked me, the difference between those two platforms and that you would try to support them with one approach.
Paul: If I recall, and this, like I said, was way back then, the coding would happen on the NeXT machines, and the executables would run on Windows. It used the Stepstone compiler and all sorts of craziness. It was an interesting time. [crosstalk]
Guy: Yeah, a little bit. So you ended up doing contracting a few years and then finally got into iOS.
Paul: Yeah. I had real jobs, contracting jobs. At some point I decided that I just don't like going into an office and just went that route where I would mostly do contract work for different companies. Golly, four or five years ago, I don't even remember, the iPhone first started, they first started letting people write applications for it. Mark [inaudible 05:154] , my partner, and I were both working at Oakley and we were just in the middle of some big, hairy project. It was a Sunday or something like that and we were both really burnt out, talked, and said why don't we create an application? Went back and forth on it a little bit and decided to do something simple to track our weight, or at least that we thought was simple back then, and went back and forth.
Somehow WeightBot and TapBot was borne out of that.
Guy: Were you into the Jailbreak scene at all? Were you excited when the phone itself came out or were you more into after the SDK got released?
Paul: Neither. I didn't buy the phone when it first came out. It wasn't so much that the phone wasn't cool, which it certainly was. I'm kind of cheap and I hate paying for recurring services like data plans and things like that. I was perfectly happy with the cheap, pay as you go phone. I kept that until I couldn't do that anymore.
Guy: What was compelling about the iPhone? Or was it just that time marched on and you figured that you didn't want to get left behind?
Paul: Once I actually got the phone and the API was actually opened and I got to play with it a little bit it definitely was cool. Before that, certainly it was something that I was keeping an eye on but I just didn't feel the need to get one, which is strange because I've gotten every single device since then.
Guy: I've got a giant stack right next to me.
Paul: Yeah. I've been doing some iCloud stuff this week and I have like six different devices hooked up at the same time trying to deal with conflict management and all that fun stuff.
Guy: I'm sure. If it wasn't 11:00 AM I'd send you a beer or something. Why WeightBot? I have a line of questions about the whole bot theme. What was the initial impetus behind WeightBot? Was it because it was simple and you thought you could do it? Was it like scratching an itch kind of thing?
Paul: I could be totally wrong on this. It was probably because I was trying to lose some weight and I wanted something to track with it and we figured, like I said, it would be a fairly simple app. You put in a weight every day and keep track of it, or at least it would have been simple before Mark got his hands on it and came up with this insane concept of a robot with noises and all sorts of flicking actions.
Guy: Which is now the TapBot's trademark.
Paul: Correct. If it would have been a real simple weight tracking app, it never would have gotten anywhere. As much as I may make fun of him for coming up with crazy stuff, it seems to work for us.
Guy: I think I bought it the day it came out purely, not purely, largely because of the design and the attention to detail and the approach to it. That TapBot aesthetic has worked well across your entire line. It's branded you, not just with sticking bot at the end of everything, but it's down to the icon, it's down to the look and feel of the applications themselves, that metal look. It's very opinionated.
Paul: Yeah. We've actually talked about should we do an app without that branding, for lack of a better word, but we just haven't yet because it just works for us. Especially these days, getting anything going in the App Store is very hard. We found something that works for us, so do we stick with it, or do we go crazy and do something completely different?
Guy: Yeah. I'm sure I've said this before. Not to your face, though. [laughter]
Guy: It's a little heavy for me, it feels like. Like a little bit overwrought, especially with the sounds and all that. I love the attention to detail. It's amazingly well implemented, it's beautiful. I love it for what it is, but it feels a little bit heavy for me. That said, TapBot and Tweetbot and Weightbot, I basically use them all multiple times a day, all of the time. You're certainly not losing a customer. It's not really detracting from my experience at all.
Paul: We've heard the heavy comment often.
Guy: I feel like maybe I'm being an old man. I feel like maybe Delicious Library came out, and I'm grumbling because it should just be a list view or regular icon view, rather than being the bookshelf. I feel maybe I'm getting a little bit overly conservative.
Rene: Is there a line between...You have an incredible design language. It's a very good differentiator for you, can instantly tell a Tapbots app, but at the same time, you now carry that design with you everywhere. It might be a mixed blessing for you sometimes.
Paul: Yeah. Like I said, we've talked about doing something different. We just haven't quite gotten there yet. Everything we've looked at has felt right going into this same look and feel, for whatever reason.
Guy: Mm-hmm. Definitely everything looks correct. I can open up any Tapbots app and feel like this, it's a consistent work of art. Every attention to detail has been paid, and the little characters all fit in. Everything's great.
Paul: It's interesting to see. In the last version of Tweetbot, we made some changes in the icons which was supposed to make it a little bit lighter. We get a ton of people saying they love it. We get a ton of people saying they hate it. It's like, "Argh," you know?
Rene: You've almost made the apps into characters for people. They're getting an attachment to it because of the identity you've given them.
Guy: I think it's a great idea, by the way. Definitely character-driven apps are...
Paul: You've got to do something to stand out in the marketplace, right? There's thousands of apps released every week. If you don't have something that stands out, it's just going to get buried.
Guy: Oh, yeah. The fact that you can cross play the brand is amazing. I love that when you launch a Tapbots app, it's got the serial number stamped into it. It's great, great little touches, you know?
Rene: It's interesting. I don't want to bring up the skeuomorphic word, because it's horribly overused. Weightbots could have been a very dry, very list-driven app. There are hundreds of those kinds of apps, but you made it fun. You made the actual usage of the app an enjoyable experience, which makes you want to use it more often.
Paul: Right. That was definitely the plan for Weightbot. It's kind of boring to track your weight. We wanted to do something where it would make it somewhat fun, where you'd feel a sense of accomplishment putting in your weight every day. That's where that all came from.
Guy: Would you say that Convertbot is the one that goes furthest along that access?
Paul: Yeah. I think we both feel like it may have gone a bit too far in that direction.
Guy: Because of the dial UI?
Paul: Yeah. The dial, it's great and it's fun, but it's not the most efficient way to pick currencies to switch from. It's kind of a tricky one. Especially now that we have the iPhone 5 coming out, stretching that app just doesn't seem to work right. It doesn't feel right because it's so heavily around that wheel, and the wheel is tuned to the screen ratio of the original iPhone.
Guy: Right. Just for listeners who haven't seen it, it looks almost like an iPod click wheel that you can turn around and dial your different units, and press the middle button to select them.
Paul: Right. If you want to go with the UI heaviness, that's probably one where we may have gone a little too far.
Guy: I'm pretty sure you guys put out a blog post explaining exactly how you did this, or at least the iterations you did to get to it. From the nerd perspective, I find that really fascinating. [laughs]
Paul: Yeah. That was all Mark, I guess kept notes during that design, and showed how the wheel came to look or why those dimensions were chosen and all that good stuff.
Rene: What's it like for you when you get some of these designs back from Mark, and you have to implement the physics, and you have to implement the scrolling? You have to make what he designs feel...I can't say real world-like, but feel correct on an iOS device?
Paul: Sometimes I'll just look at it and just shake my head, and curse him out in my head and go, "Ugh, how am I going to implement this?" It's always interesting to see. We'll often go back and forth once he does come up with a design, with me saying, "This is impossible." Or, "This is going to take to long to do, and can we switch this around?" Kind of go back and forth a while to try to figure out just exactly what we can do with those designs.
Guy: I think it really worked for you, because you're one of the few teams that I can think of, small teams that works so consistently well together. Every app is very polished. It's not very sharp edges. Everything's very consistent between app to app. You have a company voice that is very distinct. Given that there's two of you, you'd think that it could go one way or the other sometimes. It seems that you guys put out what you wanted to put out. It doesn't seem that you...Not half-assed stuff, but it doesn't seem that you haven't been happy with any of the stuff that you've put out so far.
Paul: Yeah. I think a lot of that is how we work. We try to keep to our areas of expertise. I can't draw a circle to save my life. Mark can't code, and so we try to keep our responsibilities separate. Anything design-related, even if I don't particularly agree with it, it's Mark's decision to make. That seems to work well. We'll collaborate together, but at the end of the day, design is his area. The user interaction is his area. He has the final say on that stuff.
Rene: What happens when you're working on something like Netbots? You already have Tweetbot on both iOS and iPad, and then you're bringing out Netbot, which is a variant of that, it's still going to be iPhone and IPad, but now you're doing a different service and you're hitting ADN. Is that challenging? To keep an app sane on two different platforms, and then two different services as well?
Paul: It will be interesting to see as it progresses. The apps were separated once I started working on that Netbot. It's not all the same code base. Obviously one was copied from the other and then I went in and made all sorts of changes to get Netbot working on the different service. Fortunately a lot of it was architected purely by luck, so that it was some what easy to switch from the different services. It will be interesting to see as it progresses.
I've been making changes on one, and then going to the other, making the same changes there, keeping up that way. It will be interesting to see as both services and both apps fork more and more away from each other.
Guy: It's not like a shared library that you use between the two?
Paul: Well, we definitely have a common library that's used between all the different apps that have generic classes that we use. Like, our Alert Panel and our different types of buttons, et cetera. That's all shared between all the different apps, but the code itself that talks to Twitter, to ADN, the code that displays all the different view's for different app's are completely separate at this point.
Guy: You've been remarkably positive in all of your expressions. Like there's a lot of, and this is not to disparage anyone, but there's two lines of thought. There's one, people either act positive about the app store being screwed up in various ways, or positive about various business things, or people complain. I don't mean that in a bad way. They outline the realities that their business's have to face and point out where things are tough.
You guys seem to have always been positive. Is that a conscious thing, or is that just a personal attitude?
Paul: Probably a little bit of both. Regardless of what happens with the app store and Twitter, we're really just two guys that got together and started a company and were successful at it. We don't have to work for some large corporation doing really boring stuff.
Guy: You're living the dream.
Paul: Yeah.
Guy: You can take a few hurdles, right?
Paul: Right. Nothing that's happened in the past year has been particularly bad. Every year has been better, let's say revenue wise, than the year before. So, there's really not that much to complain about.
Guy: It's en vogue to wail on Twitter, because frankly they've been doing some weird stuff, and that directly affects, what I imagine is, a large portion of your business, but It's water off a ducks back. I read your blog post again last night. You seem very positive about it?
Paul: Yeah. They've definitely said what they're going to say and have made the moves that they're going to do. They could have been a lot worse.
Guy: That's a great attitude.
Paul: For whatever reason they've decided that, at least for now, they could change their minds at any point, that they don't want new Twitter clients coming out. The existing ones, they've structured in such a way that most of the existing ones will be able to continue for at least a couple years.
Guy: Yeah, you've got a long runway, given how early you were on the platform, I imagine?
Paul: Right. So did some of the other clients as well that have been around for a while. It's just new clients, or clients that have just launched that can have issues with that. With those restrictions.
Guy: I just realize we talked to Lauren last week. This is basically the Twitter developer podcast. Maybe we can get Craig on next week. So, Netbot, the App.net client, was because you wanted to do it? Rather than being a reaction to the Twitter stuff?
Paul: Yeah. We wanted to see where the service would go. There's definitely a lot of support associated with doing a client like that, but the original merge port over from Twitter to ADN wasn't particularly difficult. We had a lot of people asking for it, so we figured, "Why not?" We had a Tweetbot for Mac coming out, and I had some time in my hand to do something, so I went off and did that.
Rene: What was that like? You weren't as early as Twitterific or Tweety, so they probably had a more mature API for you to write against. ADN, you were there almost from the beginning. Was there a large difference in writing against those two services?
Paul: The API's are somewhat similar. It actually seems like the ADN-API is somewhat better in a lot of ways. Probably because they don't have a lot of baggage.
Guy: I prefer, looking it over. I've implemented a little bit of both, like what you guys have, but the ADN one seems to be informed. Where Twitter sort of took some missteps.
Paul: Right, but then again, it's a lot easier to do something like that once you see what mistakes made by the previous people coming before you [?] .
Guy: Oh, yeah. I'm not saying that to knock Twitter in any way. You can definitely learn from what other people have done. Do you have a preferred service? Which one do you fire out first, Netbot or Tweetbot?
Paul: I alternate actually between the two. In the morning when I wake up, I'll sometimes do Netbot, sometimes I'll Tweetbot, skim through my timeline and go from there. I don't necessarily go with one or the others, as far as what I first open or last open at night.
Guy: Do you use them differently?
Paul: Yeah. I think at this point, for Tweetbot or Twitter, I'm mostly doing a lot of support stuff. Answering Tapbot's, on the rare occasion answering Tweetbot accounts. On ADN I mostly do my little geeky tech posts, or complain about whatever is bugging me at that particular moment.
Guy: I basically do the same thing too. Except I don't do support. I'm more of a jackass on Twitter. I just crack jokes all the time.
Paul: I didn't say I was particularly good at support. I probably shouldn't do it, and all the Tweetbot stuff. For the most part it's done by someone else.
Guy: You guys have a support guy?
Paul: [inaudible 25:00] guys.
Guy: Right. Sorry. I knew that, Ash.
Paul: Yeah. Otherwise, nothing would ever get answered.
Guy: I'm sure, yeah. With the number of app's you've got, and their broad appeal, I'm sure you've got a lot of people who need support.
Paul: Yeah.
Guy: With that in mind. Does the Netbot stuff have a lower support per user class, than say, Tweetbot?
Paul: Well, it depends. The Netbot users are definitely more advanced than the average Twitter user. Which I think everybody would expect. There's definitely more changes going on with the ADN-API than the Twitter API. So while there's less technical support, as far as answering questions on ADN, there's the other side of technical support. Which is implementing new features and adapting the changing API's.
Guy: Maybe you can't say, but do you work closely with Dalton and those guys?
Paul: Yeah. We'll talk to them, and they've often asked, "Is there any particular API you would like to see us work on next?" We'll ask questions about, "What do you guys have coming up in the pipeline?" They're pretty open with everybody about that stuff too. It's definitely a [inaudible 26:36] experience.
Guy: That's great. Do you ever foresee the net stuff taking over your Twitter stuff? Not in terms of global popularity, but in terms of where your revenue or attention is going to be spent?
Paul: Not at this point. The user base of ADN is just so small now compared to Twitter, that I would expect something else would overtake Twitter and ADN, before ADN overtakes Twitter. We're known for Tweetbot now because we've been focusing on that for the last couple years, but like you mentioned before, we've done other app's and we're going to be doing other app's.
Guy: Do you have any plans? I mean, don't spill the beans.
Rene: Yeah, no spoilers.
Paul: Yeah, no spoilers. We're revising one of our existing app's now with some new stuff. We'll figure out something completely different to do sometime next year. We'll come up with something.
Rene: You do one of my favorite things on ADN and Twitter, where you post some of the support requests you get from people who pirated your apps. And on ADN it's even funnier, because it's such a small user base.
Guy: And they paid $50.00 just for the privilege of being there. I guess it's like $36.00 or something now.
Rene: Is that just for catharsis, or does that actually help you curb that practice?
Paul: No. They don't care. They literally don't care about any of that stuff. They certainly aren't following me if they're pirating the app. At least the vast majority aren't. It's just blowing off steam or having fun with it.
Guy: Does it get to you, or do you just roll your eyes and think [inaudible 26:36] ?
Paul: Well, here's the thing. For the most part I don't care about pirating, other than having some fun with it. Except now when people are pirating the app, it's actually taking away tokens that we only have a limited supply of. While normally I would say, "Those people were never going to buy the app anyway so I'm going to have a little fun with it, but I'm not going to waste a lot of time dealing with it." Now, there's a different situation going on.
Guy: Right. That whole argument that you can make a copy of software and it's infinite and nobody loses anything is out the window, because there's a finite limit of tokens out there.
Paul: Right. So we have to be a little more aggressive with curtailing those limits. Curtailing those guys from using pirated versions of the app, because it literally is costing us potential future money.
Guy: Again, with a very positive tone, you wrote a piece about the pricing of Tweetbot after the token limit came in. Can you talk about that a little bit?
Paul: For Tweetbot iOS, we have a fairly large number of tokens. We've been selling it for, I think, 18 months prior to the new limits coming into place.
Guy: Is that it? Wow, it feels like forever, iOS moves fast, man.
Paul: Yeah, it does. But, if you can imagine, assuming we kept it at the same rate, we'd still have at least 18 months to go after that. Whereas, on the Mac side it's quite different, where fortunately we had that public alpha and beta, we were able to get over the 100,000-token limit before the cutoff.
Guy: That's great. I hadn't heard that. That's good news.
Rene: Was that you being prescient, like you just had a sense that you should get that thing moving faster than you might have otherwise?
Paul: Yeah. We definitely felt like something was happening. There were a few blog posts coming in from Twitter, throughout that time. We just felt that it's going to be a lot harder to shut down a client that's out there than one that's not.
Guy: There was "a tremor in the Force".
Paul: Yeah. But, we definitely didn't have any inside knowledge of what exactly was going to happen, because if we did, we would have structured things a little bit different. We came out, I guess, as well as we could from that situation. But, we definitely don't have an unlimited number of tokens available on the Mac side, and that impacted what we could do on the pricing side of things.
Guy: You charge 20 bucks for Tweetbot for Twitter, on the Mac.
Paul: Yes.
Guy: That used to be a reasonably low-priced Mac software pricing tier. These days you have to make an argument in support of that being a fair price. How do you feel about the downward pricing pressure? I know on iOS, they're not cheap, but they're certainly way cheaper than you would have expected, traditionally, from Mac stuff. Was that a warning to you when you started with Tapbots, or was that something you just rolled with?
Paul: No, because back then, there wasn't this downward pressure. When we first started it was very soon after apps first came out, so there really wasn't a history of what pricing should be for the applications. With the App Store, you would see a lot more volume than anything you would ever see on, the Mac side, for example, back then. The pricing on iOS is what it is. I know a lot of people seem to complain about it. But I think the volume you see on there pretty much overwhelms any of the pricing concerns.
On the Mac side, again, it's a little bit different. I think the big pricing issue on Mac, right now, is Mountain Lion being $20, which everybody compares every other piece of software to.
Rene: Which is heavily hardware-subsidized, that $20 price.
Paul: Right. I almost wish they would have Mountain Lion be free instead of charging that $20, because then you wouldn't be comparing the two. You don't pay for iOS upgrades, at least, not anymore. I wish they would do the same on the Mac side.
Guy: I feel like I've had this conversation with so many developers that putting something at $20 puts an upper-end on the complexity of your software. Everybody can say, "You're not as complex as the operating system, so, why would I pay $20?" It's like an apples and oranges comparison.
Rene: That's their place.
Paul: They make it anyway. When people complain about price, that's the number one thing I would hear is, "This is as much as I paid for the operating system." I'm like, "No, you actually probably paid a couple of grand for the hardware that ran the operating system that subsidized that $20 price."
Guy: What are you going to do, write a long email, "Here's, actually, how the financials break down"?
Rene: "Here's what Numbers charges. Here's what Aperture charges."
Paul: I, definitely, would wish either Apple would make it free, or maybe, just remove it from the top charts. It would give a little more room to other people, so that they don't go and see Mountain Lion for $20 every time they go into the App Store.
Guy: I see them do that for all their apps. I understand why they don't, because I think the App Store tries to be, "Here's just the raw numbers. We're not going to mess around with it." But Top Paid is just full of Apple stuff, constantly, it's impossible to break in. Well, not impossible.
Paul: It's impossible to beat Mountain Lion on Top Grossing. It's undoable. I have a rough idea of what they make there on a daily basis, and it's insane.
Rene: Make Mountain Lion an app purchase for Lion and just get it off there.
Paul: Do something. I would, actually, just prefer it be free at this point. I know relative to any other developer they're making a ton of money every day on there, but, it's got to be beans compared to what they're making on Macs and iPhones.
Guy: You can tell they dropped it to $20 in order to encourage rapid adoption.
Paul: Right. Make it free, and then there's no rapid adoption problem, because everybody's just going to upgrade to it. Make a bunch of developers happy.
Rene: Was there a lot of math going into figuring out the $20, or did it just feel right? Did you go, "There's a scarcity of resources, we only have so many tokens, we have to be able to develop it and support it going forward for X number of years, a bunch of fancy math inserted there, this is the price," or was it more of a gut feel?
Paul: There was some math, and there was a lot of gut feel for, "What's the most we can charge and not lose a ton of customers, and still support the app," like you just mentioned. It was definitely a lot of back-and-forth on what exactly we should charge for the app, because even if we're charging more than we would want to, it's better for the people who buy the app, long-term if we, actually, make money off the app and continue to support it, and don't run out of tokens in a couple of days.
Rene: Different than the iOS version, you actually handed off development of the Mac version. What was that like? A lot of developers say that their apps are their babies, and you gave this one to a babysitter for awhile.
Paul: It's not for awhile, because Todd Thomas, who's working on it, is still working on it. All the Mac code is stuff he wrote. The low-level code that actually talks to Twitter is shared between the iPhone, iPad, and Mac versions, and that's all the stuff that I wrote. But, I just didn't have time to get into the Mac side of things, and spend a year doing that, and still supporting Tweetbot, and keeping it updated. It's just not something one person, I don't think, code-wise could handle.
Along with, every time I start looking at AppKit after having done UIKit for awhile, it's just not something I can handle, for whatever reason. I did it for years before. But after being on the iPhone side for awhile, it's just not pleasant to go back to.
Guy: What's your beef, to be blunt about it? We were talking before we started recording. Paul's been doing this for a long, long time since, basically, the beginning of NeXT, pre-OPENSTEP, right?
Paul: Yeah, NeXTSTEP.
Guy: Pre-Foundation? Pre-NS String, when everything used to take a character pointer?
Paul: It was before NSObject. If you go way back, it was, actually, Object.
Guy: Yeah. It was just Object at that point. NX code and all that? All of the crazy, deprecated stuff you see in AppKit, like NX Color and all that, Paul probably dealt with that at some point.
Paul: I've blocked it off my memory.
Guy: I'm going to make you bring it up now. A lot of people that basically came to Apple development with the iPhone and iOS, take one look at AppKit and find it primitive, and don't want to deal with it anymore. Even knowledgeable people, who know what they're doing, just don't want to deal with it. But, you've got a ton of experience with AppKit. My position is that often AppKit is doing a lot of things that UIKit can't do. That's less true with each release of iOS, but I think you'd probably agree with me that certainly all the text stuff was, until recently, like night-and-day better on AppKit. What's your beef with it? Is it the sales?
Paul: It hasn't really been upgraded, at least not from what I can see, since UIKit started taking off. It's just stagnated along. They bolt on layers here and there. But, if you get in there and you try to make a customized UI with buttons, with different backgrounds, and try to animate stuff, it just doesn't work right. There are a lot of bugs in it.
Guy: Yeah, just yesterday, I was trying desperately to tint a button. Not desperately.
Paul: You kind of have to go in, and rewrite it all yourself. After you're used to UIKit where it seems to be the case where you're looking at Twitter versus ADN-APIs, like we were talking about earlier. UIKit learned a lot of mistakes from AppKit. I would love to see a unified kit, App-UIKit, whatever you call it, that merges the two.
Guy: Do you think it's possible?
Paul: I don't know. They can, definitely, do it like the Carbon to AppKit transition, where they just said, "AppKit's legacy now. UIKit is new. It takes awhile before all the features that were available in AppKit are now available in UIKit. But, it's the future." Eventually, a few releases down the road, it gets deprecated, and everybody forgets about it, unless you have to run an app that was only updated 10 years ago, or something like that.
I would like to see it either get a lot of love, where you can do animations as quickly as you can do them on UIKit and things work right or as expected, or just toss the whole thing out, and start something fresh.
Guy: ...as much as AppKit. Everything is layerbacks. Even when the density was such where they needed a sub-pixel add-on type of thing, and besides, you could take it to a device and it would break anyway. But AppKit has all of these affordances to account for its history, and to account for the variability of hardware. Do you think if you bolted everything that was required of AppKit into UIKit, UIKit would be as straightforward and effective as it is now?
Paul: That's a good question. They definitely added on stuff to UIKit. Like you mentioned before, the text system for UIKit was very basic at the start, and they seem to have done a pretty good job of putting in functions throughout the different iOS versions to improve that and make it more like what you can do on AppKit. I think if they did it right, if they took their time, it definitely could be done in a way where it wouldn't be this ugly behemoth that didn't make any sense. It would take awhile, and probably, five years from now, we're all going to be complaining that UIKit is now not the cool stuff because some other kit came out for some other Apple device that has yet to be dreamed of.
Guy: The Twitter app, like Loren did a cross-platform, UIKit, sort of thing, and Sean wrote Chameleon, which was their sort of UIKit on the Mac thing, how did you guys approach the same problem, point a Twitter client from the iOS to the Mac?
Paul: We used AppKit, believe it or not, as much as I don't really care for it, and this was, actually, mostly my decision, which was maybe a bad decision.
Guy: I don't think so.
Paul: But, we wanted to make sure we could use the text system, and all that good stuff that AppKit provides, but on the other side animations aren't as smooth as they could be, and we have to deal with layers causing problems in some places where they don't cause problems on UIKit doing those same type of things. There's no UIKit-clone framework for Tweetbot, it's all AppKit-based.
Guy: There are two approaches to writing cross-platform UI code. At one point, and I'm sure you know this, NeXT used to run on Windows, so you used to be able to compile it. You'd have all the Display PostScript and all that, and it would fake drawing the windows inside a Display PostScript context.
Paul: Yellow Box?
Guy: At one point they were shipping it, weren't they?
Paul: I don't know if they ever actually did, but maybe they did. It was awhile back.
Guy: Before the Apple XGeN, right?
Paul: Yeah.
Guy: I thought you could compile NeXT stuff onto Windows NT. Whatever.
Paul: They used to have the OPENSTEP that ran on four different hardware platforms.
Guy: That's probably what it was.
Paul: That's different from what I think was Yellow Box.
Guy: I do know that if you'd look in the headers, maybe not now, but in earlier OS X releases, there was an NSWindow, Windows extension. There'd be an "ifdef" and there'd be an "hwin" to get a Windows window-pointer out of your NSWindow thing. There's that approach, where you basically just plunk your kit on top of some other base APIs. Then, there's the other approach where it's, "I'm going to rewrite the UI later." It seems like you took the latter. Is that out of experience, or is it just because you felt that going with the platform UIKit would be easier than fighting against it and trying to impose your own UIKit view?
Paul: As much as I don't care for AppKit, I think it's the least-worst choice to write an application in for the Mac, because it is the native UI for the system. I don't like applications that are ugly ports from other platforms, like Java-based UIs and stuff like that. We're big believers in making the application feel right for the device, for the operating system. It's one of the reasons why we won't port to Android. We're not going to take our UI and our feel and just move it over there and have it run the same way, because it's just not something that we feel is the right thing to do, as people.
Guy: I think that goes back to what you were saying about the Convertbot and the iPhone 5 screen, in that you designed that app very specifically for a certain-sized screen, and now that it's changed, it's problematic to recapture that feel on the larger screen.
Paul: We could definitely stretch out the top and the bottom but does that really make any sense? Is that something that we would be proud of?
Guy: You could just give it a big Imax-style chin on the monitors.
Paul: That makes it somewhat tough, that we care so much about how these apps work and feel. Where if we'd used something like TWI or Chameleon, maybe it would have made the process of porting a bit easier, but are we then losing out on some of the nice things that AppKit provides that are behind the scenes and that you just subliminally notice?
Guy: Stuff like accessibility. Like when you do your own sort of interface kit, you lose a lot of stuff that comes with the system, like being able to select text and run a service on it, maybe. Weird, little things. Like, edge cases that just drop away.
Paul: Right. Then, as Apple upgrades the operating system, new features probably don't work quite right, if you're using those things. A perfect example, going back to the twUI, it's all fuzzy now. Why is it fuzzy? Because it's using their own UI, crazy layer-backed stuff that's not AppKit. When they moved to the retina screens, it wasn't ready for it. Now the app looks fuzzy to everybody.
Guy: I'm sure that bugs Lauren, but I didn't want to ask about it. [laughter]
Guy: It's not his problem anymore.
Paul: I'm sure that's something that could be fixed in a fairly simple manner, but if it was written with AppKit, it probably would have just worked.
Guy: Exactly, You were saying that five years from now, maybe there will be some other kit that we all wish UIKit worked like. You've been doing NeXT stuff for a long time now. I've been working in the field for 6 years. I've been doing it for maybe 15, doing programming on the side and doing tools for work and all that. Do you ever worry you're going to get blindsided by a different platform?
Paul: No, I don't. A few years back, before the iPhone came out and the Mac stuff was waning or at least not as popular as today, I spent quite a bit of time doing Ruby and Ruby on Rails type of stuff. I'm not terribly worried about it. If it, for some reason, dies out, there's always something else I can jump into. Fortunately, I really like the Mac stuff, the Objective-C libraries, and think it's the best stuff out there. It took a while, but at least the last five years, it's been really great.
Guy: Definitely. It used to be, and this was a different time too, there were more operating systems around in general. I don't want to say I experimented in my youth but... [laughter]
Guy: I used to use OS/2 and Windows NT and Classic Mac, and that's how I came to find out about all the NeXTSTEP stuff and all that. These days, I find myself, because I work and I work on Apple technologies. I sometimes wish that I would go and maybe check out what it's like to program on Windows Phone 8. Every now and then I'll go read through the docs, but I don't actually practice it. Is that-that's not something you care about. That's just...
Paul: If any of those platforms besides the Android actually take off in some way I'll definitely take a look at them. I refuse to look at Android just because I have a rational hate of Java and all things Java related. But I certainly, if Windows 8 sold more than a couple phones a week I probably would be interested in taking a look at it.
Rene: On the flipside, some people like John Syracuse have been critical or maybe hypercritical about objective-C and its future when compared to the higher-level languages and the way that you can develop for more, I don't want to say more modern, but more recent devices. Maybe like Windows Phone or maybe some of the stuff that Microsoft is doing with C#. Do you see the same kind of limitations in objective-C and are there directions that you hope that Apple takes it beyond what they're doing now?
Paul: I really like the way, actually, Apple has been handling objective-C where every year they're making some significant but not overwhelming change to it. They've recently added the whole, what was it? The new memory stuff?
Guy: The boxing.
Paul: Boxing, but the new memory stuff, what's it?
Rene: ARC.
Paul: ARC. Yeah. In there, which really changes a lot of how one writes an application.
Guy: Have you ever-sorry. Have you seen apps been using that?
Paul: Nope. Nope. I mean it would be nice to, but it would involve a lot of going back and changing classes that have been working for years now. It's not something...
Guy: I can't stop writing retain release, like I cannot do it. I've got to break that habit, but... Anyways, sorry Craig [inaudible 55:22] , go on.
Paul: It's not something I have a problem with myself, since I've been doing it long enough that I can retain release in my sleep. But it's great for new developers. On the other hand they added block recently which I used pretty much all over the place. I've even almost got the syntax memorize for how to write a block without copying and pasting it from somewhere else. I like the way they're improving the language without throwing it all out and starting from scratch. Which...
Guy: It certainly seems that from '97 to almost 2007 nothing changed and then for the past five years we've been getting pretty big improvements.
Paul: Right. You can almost see it's a yearly cycle and a lot of those improvements they make it so it will run on a previous version of the OS, which is great as well. Is it as fancy as whatever new JVM based languages they're coming up with? Probably not. The language is only half the issue. Even less than half the issue. It's the frameworks that go around and I don't think there's anything anywhere near as mature that works as well as foundation in UI kit.
Guy: You can say that, begrudgingly.
Paul: I guess it doesn't have all the whiz bang features but it's been improving at a good, sustainable pace. If you look at something like Ruby on Rails as a counterexample, they add new whiz bang features to it, to the framework, every dot release and it gets to a point where if you haven't kept up-to-date with each and every one of those releases and you go back and try to update an app you almost have to toss the whole thing out and start over to deal with whatever new features they decided had to be added without any regard to previous working code.
Guy: Incremental improvement without churn. You don't have to toss everything out.
Rene: No rip and replace.
Guy: One thing I find heartening in retrospect, but at the time I was annoyed by it, not annoyed, I'd written a large app using Garbage Collection, which was dumb because it used a lot of graphics, too, and a lot of the graphics stuff didn't end up being properly garbage collected, and then they abandoned it. It was a little concerning. Because under Garbage Collection you could write retain and release and it was a no-op, I'd been doing that anyway because I couldn't break the habit, so it wasn't that much a pain in the ass to switch back to the regular.
In retrospect, I kind of like that because they went a direction and within a year, year and a half, maybe two, they just ditched it and they went to Arc, which I find to be a very compelling argument they are taking the stewardship of objective C and their platform seriously and they won't commit long term to something they don't think will work.
Paul: Yeah. Garbage Collection is definitely an interesting edge case where, for whatever reason, they decided it wasn't working and they just reversed course and went a completely different direction. Fortunately, I don't think it impacted too many people. Like you said, you're writing release and retain code anyway. I don't think I've ever used it.
Guy: Very, very few. Very few third party developers used it.
Paul: It's nice that it's consistent improvements and course corrections, if needed, year after year as opposed to waiting three or four years and tossing in a bunch of stuff and breaking backward compatibility. Everything seems to be pretty compatible with everything that came beforehand.
Rene: Is there a direction you'd like to see them keep going with those iterations?
Guy: I definitely would love to see blocks just everywhere. Go in and make sure that any operation that takes any amount of time has a completion block. Stuff like TableView updates. When you go in and you do some animated UITableView updates, there really should be a completion block so you know, "Hey, we're done with the graphical side of this." If you need to do something else, continue on. I love to see them just making sure, "Hey, everything any kind of animation, any kind of long-running operation, has some kind of block or some kind of call back to it." Also, the GCD stuff is awesome. I love to see them keep going with that, making sure it's more well-defined.
When you make a call using GCD, you should know, "Is it coming back in the same thread that called it? Is it coming back in a different thread?" have all that stuff documented. I love to see that stuff happen.
I've been playing, like I said earlier, with iCloud this week. I'd love to see them improve those APIs. They're currently way too hard to use, at least the document-based side of iCloud.
Guy: Are you using the UI document stuff, or are you using the stuff from Foundation that UI document builds upon?
Paul: Right now for Tweetbot and Netbot we use the key-value style API for...
Guy: That in my experience works reasonably well.
Paul: When it works, it works reasonably well. The API is certainly very simple to use. It's great for what it should do. It sometimes, for whatever reason, refuses to work.
Guy: Can you explain a failure case to me?
Paul: It just doesn't work. [laughter]
Paul: The API is very simple. You set a value and you read a value. When you set the value, it should go up to the Cloud.
Guy: I'm trying to think, there's no...Do they have an error reporting API on that? I don't think so. It just looks like user defaults, right?
Paul: Yeah, it's literally a copy of user defaults with some notifications of when things change. For some reason...
Guy: There's no way to query for an error, and there's no notification that you get an error.
Paul: Yeah, and I literally have some devices that it just refuses to work on. I'll set the value. I can watch the traffic coming out from that machine. It just never goes up anywhere. It just stays there. You have no idea, obviously as a developer, you have no idea that anything wrong is happening, because you get no call backs or anything.
Guy: You think it's on the back end?
Paul: No, it's definitely on...There's probably back end problems as well, but this is definitely on the device itself. I'm watching traffic to and from it. As I set a value, it just won't go anywhere. It just stays on the device. There's no network call out to the iCloud servers doing whatever they do.
Guy: Is this some kind of timeout thing?
Paul: No, I just...
Guy: I don't know. I'm trying to debug your [inaudible 01:04:10] .
Paul: I've sent tons of logs over to Apple, but still haven't gotten a response of what's happening. It's been happening since 5.x, it's not a new 6.0 type problem. It's just [inaudible 01:04:26] API for whatever reason, sometimes on some devices, refuses to work and then, once in a while, it will start working again on the same device for no rhyme or reason. It's probably the number one support issue we have with the Tweetbots is sometimes iCloud stuff doesn't work.
Guy: It's frustrating because it's not something you can dig into and fix. That's for simple API.
Paul: The document-based API is much, much more complicated. It does seem to work more reliably, though, for whatever reason. It's very complex API-wise. There's a lot of different failure cases that you have to handle. Everything is asynchronous and some of those asynchronous operations don't have call backs to them, or not, at least, easy call backs. It's just much more complex of an API than I think it should be. It probably explains why so many people have problems with it.
Guy: If you can say, which Apps are you using that in?
Paul: We're actually looking at doing some stuff in Calcbot with that.
Guy: Oh, interesting.
Paul: For example, it would take the tape on one device and synch it across multiple different ones.
Guy: That's cool. That makes sense.
Paul: Once we have that working, we'll probably go in and look at getting it working on Tweetbot for stuff like graphs, as an example, where your graphs could by synched between different devices, where it's not that thing where you're possibly talking about, "Yeah, 140 character graph, that's no big deal," but you an image, or several images, that may go along with it. That stuff doesn't really fit into that key-value API that's simple to use. You need to do something like the document-based API where you're dealing with large files.
Guy: No, I think that's exactly the right thing to do. They call it the [inaudible 01:06:56] API, right? Just the idea of having all your drafts transparently everywhere that you've got Tweetbot seems like a great idea. Oddly, I don't think anybody's going to....
Paul: [inaudible 01:07:05] pretty complex.
Guy: I'm sure. I'm sure the amount of work you put in, you'll not get enough kudos. People will just notice that the draft's there and they'll be like, "Oh, cool." You'd be a month of blood, sweat, and tears to make that work.
Paul: Yeah, it's been a good week, plus just getting this tape going back and forth between different devices. I ended up rewriting it three or four different times just to deal with different API issues/limitations.
Guy: What's your policy in terms of supporting the most recent operating system? I ask that because let's say iCloud never gets fixed on iOS 6, but for some reason it works on iOS 7. Would you just move to iOS 7? Would you limit that feature to iOS 7? What's the policy?
Paul: My overall view is that you should support the two latest major OS versions.
Guy: Yeah, I think that's common.
Paul: I think Apple's actually almost forcing you to do no more than that. You can't build an App for the iPhone 5 that works on 4.1. The 4.2 SDK stopped supporting deployment for iOS 4.2 and earlier. Something like that. Apple's almost forcing you to only do the most recent two OS versions, under iOS.
Guy: Yeah. With iOS, they're definitely dragging everybody along. Users and developers alike. They're just dragging people along. I think they see each device as having a two year life span. Maybe not the 3G. That must have been longer. But sorry, I cut you off. Go ahead.
Paul: You can probably count on two years of updates, up until the point they stop selling that particular device. I would expect, actually, the 3GS to get at least iOS 7, possibly iOS 8. But I wouldn't expect much more than that.
Guy: I'd be surprised by iOS 8. Only because I think they'll just be... [inaudible 01:09:39] .
Paul: That one is an edge device. It's been selling for so long. But I definitely think you shouldn't expect much more than two years worth of updates from the time they stop selling the device.
Guy: That makes sense.
Rene: The thing that's interesting with Apple is that it has so few features of iOS 6, but it still supports iOS 6. Apple's point of view is that it wants it to be binary compatible, so that when you write apps against iOS 6, those can all run on the install base of iPhone 3GS devices. When you look at things like Windows Phone, which loses binary compatibility after one generation, that becomes key for their market.
Paul: The Windows stuff is kind of ridiculous, at this point. They're still selling the Nokia something or other.
Rene: 900.
Paul: And then three months later, it's obsolete. Because it won't run Windows Phone 8. What are they thinking? Android's even worse than that. It's nice that Apple has a fairly consistent story there.
Rene: For a user, yes they're upset they don't get Siri, for example. But if they couldn't bind new apps, that becomes a big problem, especially for a device that was being sold, up until fairly recently. The binary compatibility is the layer that they try to move forward the most.
Guy: Paul, we talked about AppKit, UIKit and iCloud. All of these things, basically, are under one guy. They're all under Federighi now. Do you think that makes a difference? Do you think we're going to see more cross-pollination or a tighter coupling of this stuff?
Paul: I have no idea. To me, the whole way that Apple works is a black box. I certainly have no inside knowledge of what happens there, other than every year they come out and announce cool features or not so cool features, as the case may be. I hope they start getting a little more aggressive with iOS. The last couple versions have been somewhat lackluster. The devices have gotten better and better, but the OS, I won't say it's getting stale. But it could use some cool new features, here and there. I'd love to see apps being able to tie in to Siri somehow.
Guy: I looked at that. That's really hard to do. Do you just mean launching them? Providing a service is tough.
Paul: Yeah. But there's got to be ways to do it. I don't know enough about how Siri works down low and that kind of level, to be able to say what can be done.
Guy: The problem is disambiguation, basically. If you just put a list of keywords in your PList and you've got three apps, you've got Twitterific, Tweetbot and Twitter for the Twitter app, what happens when you say, "Send a tweet," or, "read my replies to me"?
Rene: "Do you want to send that tweet to Tweetbot, to Twitterific or to tweet, press the button."
Paul: You could set a default service. You can have a default mail service, like you do on Mac. I don't see why you couldn't have that on...
Guy: It's an interesting problem to look at.
Rene: I still think though, they're doing that as partner plays. They're not going to give out the revenue they can get from brokering deals with the Yelps and the Ticketmaster companies, just to provide a free way for apps to do it.
Paul: Possible. But if Google goes in and starts opening that up, they might not have a choice. If some other operating system starts integrating those cool features and they're not, just because they might lose some revenue, they're not going to stand for that.
Rene: The bigger problem with the Siri stuff right now is, for example, Google's doing on-device voice parsing, which makes the experience much faster. Anything that doesn't have to go to the cloud doesn't go to the cloud. I can set an alarm. I can do all sorts of things and never have to worry about the cloud being a point of failure. Siri sends everything to the cloud, still. Google Now is also doing all the predictive stuff. Where it knows where you are, it knows where your appointments are and it starts providing information, even before you ask, where Siri is still a query, response engine. They're already falling behind in several of those areas that Google excels in. They should get a move on on that stuff.
Paul: Yeah. That's what I said. I would hope that the future OS's are going to be a little more aggressive with cool new features that we can't even imagine today. The last few versions haven't quite done that.
Guy: Yeah. They've solidified a lot of stuff, but they haven't really leaped forward in any way.
Paul: For iOS 6, what were the killer, must-have features. Maps, I guess.
Rene: The kids got Facebook, Paul. Come on.
Paul: Yeah. That's true. More account stuff, which is actually pretty nice but will take a while to go through all the different applications to start using that stuff.
Guy: Where do you sit with the Twitter integration in iOS? Does that help you at all? Does that run parallel to you? When they start introducing things like Twitter integration, Facebook integration, built-in reading lists, are those things that you look at to add value or do they take away a layer from your business?
Paul: All that stuff they've added is great. Especially being able to launch Tweetbot on a new machine and not have to enter in your passwords, because it's using the Twitter integration stuff to get all that, is pretty cool. None of that stuff has impacted us in any negative sense. I'd love to see them add in the reading list API, because right now there's no API for it, on iOS. We keep getting requests for that.
Guy: It seems like a gimme. It seems like they could implement a URL scheme and just make it work.
Paul: They added it into Mac OS. It's a little bit hidden in there.
Guy: They did?
Paul: Yeah. It's in there. I didn't know about it.
Guy: Where? [inaudible 01:16:31] workspace or something?
Paul: It's in the sharing API.
Guy: Oh wait, I did see that. Sorry.
Rene: One of the things I also wanted to ask you about is that you've resisted doing in-app purchases. A huge swath of the iOS economy has gone into in-app purchases. Some people have done it in Twitter applications for multiple accounts or to get rid of ads. You basically buy Tweetbot, you get Tweetbot. Was there ever any discussion about, "Hey, we could do photo filters or make mute filters an in-app purchase"?
Paul: No. Not seriously. The one area where we talked about it was for push notifications. But we were able to...
Rene: Because of the server expense or because you thought that it would drive...
Paul: Because of the server expense side of things. We thought it would be a lot more involved, cost-wise, then it ended up being. And it would have been if I'd outsourced the push stuff, which was our original plan. But then I ended up just writing it all, writing it on server. It's a point where it doesn't cost enough to justify charging an IAP for it.
Guy: I imagine you have a lot of traffic on that. But you don't need a big, heavy-duty?
Paul: Yeah. I want to say we're almost to our billionth push notification. Some time soon.
Guy: What are you running on, a 386?
Paul: No, it's a Xenon. I don't know. Something we rent.
Rene: It's not a hacked Xbox. Paul No. But it's not a crazy machine either, with 36 cores or anything ridiculous like that. It's a normal-sized server that is enough to handle the traffic and then some.
Guy: So unless you're doing Tweetbot level traffic, you're fine with just a basic server to handle push notifications?
Paul: We were even fine with a basic server.
Guy: That's good to know.
Paul: At least the way we're doing it, it's not that intensive of resources.
Guy: Yeah. What are you, using Web Objects?
Paul: [laughs] I used to really love Web Objects.
Guy: I know. I was talking to Lauren about it last week. I wanted to bring it up with you, because you actually did it, professionally.
Paul: Until they switched to Java and then I almost immediately lost all interest in it.
Guy: Did you hear last week's show? Lauren got Objective-C running on servers.
Paul: It's doable. The server stuff, I just stick with Ruby, just because it's pretty easy to use on there. But yeah, a while back Web Objects would run on servers and was Objective-C based and was all fun to use.
Guy: Yeah, it used to be awesome.
Paul: Then they started doing Java wrappers around Objective-C classes and all sorts of crazy stuff. Now, I think they should just take it out back and shoot it.
Guy: They have, right? It doesn't ship anymore. They still use it, but nobody else does.
Paul: Nobody uses it, but something still exists.
Guy: The store. iTunes Store runs it and a bunch of their other stuff uses it. The Apple Store uses it.
Paul: And their iTunes Connect back-end still uses it, which is probably why it's so bad.
Guy: Probably. [laughs] Wait, just fact-check me from last week. I said that they moved to Java because they wanted to run on app servers. There was something about cross-platform, right? You would know. I fumbled through it.
Paul: The reason was that Java was becoming really big, back when they made that choice. Objective-C, it was a lot harder to find developers who knew the language. At that point, I believe Web Objects was their big product. They were charging...
Guy: It was like 999 bucks or something.
Paul: No, they were charging more than that. I think they were charging like $50,000 or something like that. It was their big, money-making product. They probably had a bunch of corporate clients who said, "We can't find Objective-C guys. This is great, but we only have Java developers. We can find Java developers. Port it over to Java for us."
Guy: The irony now is there's like 100 WebObjects guys in the world that know what they're doing, and that's about it.
Paul: Yeah.
Guy: Oops.
Paul: Ruby on Rails works, or one of the offshoots of that works well enough that there's no point in going through the whole craziness that is WebObjects at this point.
Rene: The iPad has now gone smaller. You were wondering if at some point Apple would go bigger. Is that an actual problem that you would like them to solve?
Paul: No, I don't think they're going to go bigger. I actually more meant it's possible that the 10.1 inch iPad Maxi goes away, and they go and focus on the smaller one instead. At least from my personal experience, I much prefer the new, smaller one from a carry-around, play-with standpoint versus the old one. The only thing I prefer on the older one is browsing the web because of the bigger screen. Other than that, it's like this lumbering dinosaur. I compared it to the MacBook Pro 17 inch, where they just got rid of it.
Rene: The battleship
Guy: I watch a lot of video on my iPad, so I prefer the larger. It's like a portable TV for me. I'll go sit outside on my deck and watch TV on my iPad, so I prefer the larger one. I was not going to buy a Mini on account of the one X screen, but then when I actually saw one... It's pretty good. It's really good. I'm pretty sure I'm just going to go out and buy one as soon as I get my druthers together to do so. I do agree that it feels amazing. The build quality is great. The screen is way better than I thought it was going to be.
Rene: It feels like what's next.
Guy: I agree with you, Rene. You had a piece about not expecting a Retina screen, and I wouldn't, for at least the next rev.
Rene: It's one of those things that Apple's still bound by the laws of physics and the laws of economics. If you put a Retina display on it, it becomes an iPad 4. For people who don't want to carry a laptop, the iPad 4, the large size iPad Maxi still makes a lot of sense because it gives them a lot more area to be productive with, whether it's using the iWork apps or it's typing or anything like that. But if you have a ton of other Apple and iOS devices, the Mini really is a sweet spot now.
Paul: We'll see how it progresses. The MacBook Pro 17 had a lot of fans, me included, but it went away too even though they could probably still sell them today. They just sell so many more of the smaller devices. It'll be interesting to see. I definitely like the Mini better with the exception that I wish it had some more memory in it, like the newer iPads, the 1 gig versus the 512. Other than that, I don't miss Retina. I don't really miss the extra speed that the iPad 4 has.
Rene: It feels more like a mass-market device. When you hold it, it feels like that next breakthrough product.
Paul: I just wish it was a bit cheaper, but what are you going to do?
Guy: Wait a year. [laughter]
Guy: What do you want to see? Either in terms of software, besides killing AppKit... [laughter]
Guy: ...or hardware, is there something that you're...That sort of fanboy, Apple insider, I'm going to refresh the page until I read all the rumors on this kind of thing. Is there something you're excited about coming up or are you just pleased with the current iteration?
Paul: I'll answer that with two different hats on. From my business person hat, I would love to see cheaper iOS devices. I want to see the better iPod Touch, the 32 gig down to the $200 mark. I would love to see the iPad Mini down at the $250 mark. From my geek hat on, my personal hat, I'm really excited to see a 16-core Mac Pro with modern insides, as opposed to the current two-, three-year-old version that's out there.
Rene: You'd stick with the Mac Pro and not go iMac?
Paul: Ew, no.
Rene: [laughs]
Paul: No, I run a Mac Pro now. I'm not going back to those little, slow iMacs.
Rene: [laughs]
Guy: You know what? I did that for years. I was always on the Pro side of stuff. Then I bought an iMac Core i7, one of the earlier ones, because my Mac Pro was dying. It was old, and there was no update in sight. I figured, "Well I'll buy this 27-inch iMac," with a Core i7 and I forget what else. "I can use it as a screen when I eventually buy my new Mac Pro." But the iMac was just fast enough, and it was awesome, and I kept using it. I'm not sure I would go back to a Pro.
Paul: It is fast enough, but once you're running with the old 12-core Mac Pros, which is what I run, and you stick a bunch of SSDs inside, and... [laughter]
Rene: Some racing stripes on the back.
Paul: Put a couple monitors to it. I don't necessarily need it, but I really like it and want the latest and greatest and even better version that comes out next year.
Guy: Can't blame you for being into hot rods. Rene : Jardine has the cars. You have the computers.
Paul: He definitely...I still drive a 10 year-old minivan. [laughter]
Paul: I'll [inaudible 01:27:41]
Rene: It's got the racing stripes though.
Paul: No, but I actually got a bunch of paint on it from the side where I scraped against the garage. [laughter]
Paul: I'll spend the money on cool toys and hardware, not car stuff.
Rene: [laughs] Car stuff. If people want to find out more about you and more about Tapbots, where can they reach you?
Paul: Go to tapbots.com or follow me on probably best App.net these days, and @pth is the user name.
Rene: You went for a different user name on App.net than Twitter.
Paul: Definitely shorter, and I like the pth.
Guy: Got to go with the three letter [inaudible 01:27:40] .
Rene: Guy's a huge fan of the three letter name.
Paul: It's much easier to type, and you can reply to more people with the shorter names. Longer reply tweet or post.
Rene: Guy, where can we find you?
Guy: I'm @gte on Twitter and App.net, and my website is kickingbear.com.
Rene: You can find me @reneritchie or you can find me on iMore or just look up Debug on iTunes and subscribe. Paul, thank you very much for joining us. That was awesome.
Paul: Sure, Renee.
Guy: Paul, it's been great. Thanks a lot.
Paul: Nice meeting you, Guy.
Guy: You too. Take care.
