039 iPhreaks Show – Subscription APIs for Recurring Revenue with Manton Reece

Download MP3

Panel Manton Reece (twitter github blog) Ben Scheirman (twitter github blog NSSreencast) Pete Hodgson (twitter github blog) Andrew Madsen (twitter github blog) Jaim Zuber (twitter Sharp Five Software) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:13 - Manton Reece Introduction VitalSource Riverfold Software 01:33 - Subscription APIs and Recurring Revenue 02:25 - How Subscriptions Work 12:10 - In-app Purchases Non-renewing Subscriptions Auto Renewing Subscriptions 16:11 - Verifying Receipts Store Kit 19:32 - Subscription Levels Changing Plans 25:14 - Payments Stripe vs PayPal Picks Eric S. Raymond: The Lost Art of C Structure Packing (Jaim) Torchlight II (Ben) SC2Casts (Ben) after_party (Ben) thebennybox (Ben) Using Receipts to Protect Your Digital Sales (Ben) Using Store Kit for In-App Purchases (Ben) 2 Free (Technical Support Incidents) TSIs (Pete) Bay Area Casual Carpool (Pete) Bay Area Bike Share (Pete) Lucky 13 (Pete) Mike Ash: Friday Q&A 2014-01-10: Let's Break Cocoa (Andrew) The official raywenderlich.com Objective-C style guide (Andrew) Bacon Ipsum (Chuck) David Brady: The Job Hunting Mindset (Chuck) David Brady: The Job Replacement Guide: Why I Have To Write This Book (Chuck) Stripe (Manton) Helios (Manton) Next Week MGPCommandBus with Saul Mora Transcript CHUCK: We got this Man-ton on our show! CHUCK: Hey everybody and welcome to episode 39 of the iPhreaks Show. This week on our panel we have Ben Scheirman. BEN: Hello, from Bayou City. CHUCK: Bayou City? BEN: That’s Houston’s nickname. If we had a Ruby Conference, it would be Bayou City Ruby, and no one would know where it was. CHUCK: Yeah, that’s true. ANDREW: We’d all be in Louisiana. [Chuckling] CHUCK: Why are y’all in New Orleans? JAIM: That would be dirty south [inaudible]. CHUCK: Hey, at least you can go [inaudible]. Anyway –. JAIM: No offense to my New Orleans listeners. CHUCK: [Chuckles] We also have Pete Hodgson. PETE: Good morning from San Francisco! I don’t know what her nickname is; I should look that up. JAIM: Golden Gate City, is that it? PETE: I was tempted to go for Rainbow City, but –. CHUCK: [Laughs] We’re batting two for two this morning. Alright, Andrew Madsen. ANDREW: Hi from Salt Lake City. CHUCK: Jaim Zuber. JAIM: Hello from the Twin Cities. CHUCK: I'm Charles Max Wood from DevChat.tv and this week we have a special guest, and that is Manton Reece. MANTON: Hello from Austin, Texas! Good to be here. CHUCK: Hey, I managed to say that right! Do you wanna introduce yourself for those of us who don’t know who you are? MANTON: Sure. My name is Manton Reece, and I work for a company called VitalSource doing e-book software with Mac iOS12 web development, and I have a little side business called Riverfold Software where I have a number of iOS and Mac apps, web apps. CHUCK: Cool! So we brought you on today to talk about subscription APIs and recurring revenue – is that a thing for iOS? MANTON: That’s a thing for iOS. It depends who you ask what kind of answer you're gonna get about the right way to do that, or whether you should do it. But it’s a thing, I would say. CHUCK: I thought the thing was to write Angry Birds and make millions of dollars. MANTON: That’s one way to do it. The problem with the app store – the great thing and the problem is that you do have these huge hits that make way too much money, but then most of us aren’t that lucky, and even the ones that are lucky have a big hit, you sell a bunch of copies, you quit your job, you say, “This is great” and you do really well. Eventually, your app’s gonna fall out of the top 10 and top 100 and sales are gonna drop off and so you have to do it all over again and get a big launch. So, the subscriptions, the hope is you get a little more recurring revenue,


CHUCK: We got this Man-ton on our show!   CHUCK:  Hey everybody and welcome to episode 39 of the iPhreaks Show. This week on our panel we have Ben Scheirman. BEN: Hello, from Bayou City. CHUCK: Bayou City? BEN: That’s Houston’s nickname. If we had a Ruby Conference, it would be Bayou City Ruby, and no one would know where it was. CHUCK: Yeah, that’s true. ANDREW: We’d all be in Louisiana. [Chuckling] CHUCK: Why are y’all in New Orleans? JAIM: That would be dirty south [inaudible]. CHUCK: Hey, at least you can go [inaudible]. Anyway –. JAIM: No offense to my New Orleans listeners. CHUCK: [Chuckles] We also have Pete Hodgson. PETE: Good morning from San Francisco! I don’t know what her nickname is; I should look that up. JAIM: Golden Gate City, is that it? PETE: I was tempted to go for Rainbow City, but –. CHUCK: [Laughs] We’re batting two for two this morning. Alright, Andrew Madsen. ANDREW: Hi from Salt Lake City. CHUCK: Jaim Zuber. JAIM: Hello from the Twin Cities. CHUCK: I'm Charles Max Wood from DevChat.tv and this week we have a special guest, and that is Manton Reece. MANTON: Hello from Austin, Texas! Good to be here. CHUCK: Hey, I managed to say that right! Do you wanna introduce yourself for those of us who don’t know who you are? MANTON: Sure. My name is Manton Reece, and I work for a company called VitalSource doing e-book software with Mac iOS12 web development, and I have a little side business called Riverfold Software where I have a number of iOS and Mac apps, web apps. CHUCK: Cool! So we brought you on today to talk about subscription APIs and recurring revenue – is that a thing for iOS? MANTON: That’s a thing for iOS. It depends who you ask what kind of answer you're gonna get about the right way to do that, or whether you should do it. But it’s a thing, I would say. CHUCK: I thought the thing was to write Angry Birds and make millions of dollars. MANTON: That’s one way to do it. The problem with the app store – the great thing and the problem is that you do have these huge hits that make way too much money, but then most of us aren’t that lucky, and even the ones that are lucky have a big hit, you sell a bunch of copies, you quit your job, you say, “This is great” and you do really well. Eventually, your app’s gonna fall out of the top 10 and top 100 and sales are gonna drop off and so you have to do it all over again and get a big launch. So, the subscriptions, the hope is you get a little more recurring revenue, a little more consistent revenue over the course of the year instead of just one big spike at the beginning. CHUCK: So how did the subscriptions work? Can you actually sell an app as a subscription? MANTON: You can. There's two types of – there's a bunch of different ways to do it, but in terms of in the app store, with in-app purchase, there's two ways: there's a subscription that doesn’t actually renew, where the user subscribes to a certain number of months of your product or your service, and then they have to do it again if they want to. And then there's also what are called auto-renewable subscriptions where they subscribe – and this is what people who are used to Netflix or something like that, or Dropbox, where you subscribe and you get billed every month or every year until you cancel. You can do both of those with the app store, then we can go into that. You can also, of course, take money outside the app store if youre0 careful and you do it in a way that Apple doesn’t mind. PETE: I didn’t even know that you could do that at all. I thought you have to go through the app store for any money, basically. ANDREW: You really have to tiptoe around the guidelines. You can’t have any kind of ‘directing people to your website’ type of functionality. Github had an issue with their app, which was free, and somewhere in there, there was a link to gotogithub.com, and at github.com, if you're not logged in, it prompts you to create an account and pay the money. MANTON: Yeah, that’s right. You just have to be careful about how you do it. You can’t link to – in your app, you kinda almost wanna avoid linking to your website at all, and if you do it definitely needs to be a portion that never links to a way to subscribe and put a credit card in. If Apple is testing your app and they ever see “put your credit card in here to subscribe,” they’ll immediately reject you. They want their 30% cut of the in-app purchase, they won’t allow you to get around that at all. If you're careful, you can do it though if you have someone subscribed outside your app, you can certainly have them log in to your app. When you check in your server and see, is this person actually subscribed – that’s fine. You still have to be kind of careful how you do it, but Apple does allow that. PETE: Okay, so it’s kinda like you're allowed to have someone subscribed and then only allow portions of the app if they’ve subscribed, but you're not allowed to actually ask them to subscribe or direct them towards revenue that won’t go through Apple’s 30%? MANTON: Exactly. ANDREW: Yes. CHUCK: I can totally see though where Github would not really think about this because I think most people use it at the free level – they put open-source software out, and so having something that directs you to their website is just another way to get in. But the fact that you can actually pay for a subscription level to Github is where they have a problem. PETE: Yeah, I'm sure they weren’t planning on trying to sign up a bunch more paying customers through their [inaudible] app. BEN: Yeah, and I mean when you think about it from the other angle of –. I have a paid service on the internet, and I also want a companion iPhone app for my members – that’s perfectly fine, like HBO Go is an example of that. You don’t pay that through the app store, right? You have to have an HBO subscription elsewhere to be able to use that, and there are other things like that. I think Netflix is similar right? You can’t pay through in-app purchases to get Netflix; you have to be a member before even downloading the app. So if you follow along those lines, and you also happen to have some free content for people to try out your service – I don’t know, you still have to tell the line of ‘don’t ask people to sign up ever.’ You just say, “Oh, you need an account for that” and maybe nothing more. MANTON: Yeah, it’s a very fluid definition of what's allowed, what's not allowed, so it helps to have people on the inside of Apple looking at things and saying, “This will work; this won’t work,” if you have that kind of contact info. BEN: And from Apple’s perspective, it’s like they're bringing you customers. For NS Screencast I've been, for a really long time now, trying to work in-app subscriptions into an app that I'm building, and as soon as I got that sort of working, they changed the whole model. However, the way I view it is that I could  take the easy way out and just have an app that lets you sign in with your existing credentials, but if there are people who are gonna legitimately find it through the app store and subscribe in the app store, I’ll totally give Apple 30% of that. And I think you just gotta think of it as a new revenue channel, a new way to get customers. MANTON: Yeah, and it’s not necessarily unfair. I think you're right: Apple deserves a cut if they are allowing users to discover your app, so that’s totally fine, I don’t have a problem with that. I think there also is a tradeoff sometimes, or lately I've been feeling like, “Do you really wanna support every possible way for a user to subscribe?” The way I'm kind of going, and every app is different of course, is to try to focus on one way because one of my apps started with PayPal subscriptions, and then I added in-app purchase subscriptions, and then I added credit card subscriptions, and at some point it becomes a lot to manage – just the different ways. So users sign in, they couldn’t be paid in a few different ways, and how do you want to do things like maybe if they changed the plan they subscribed to or they cancel; there has to be a completely different code to handle all of these cases. So, it just depends on the app. CHUCK: It sounds almost thought that you're recommending just pick one way and go with it. MANTON: Yeah, it kinda depends on the app, so I can’t say which way that is. If I was doing everything over again, I would probably not use in-app purchase, at least the way I'm using it right now, because one of my apps is predominantly has a web service, has a web app – that’s the core part of it and so that’s kind of the native place that each should subscribe, not unlike Netflix or whatever, “Oh that’s not video,” but the same idea. But for other apps, maybe the whole experience is inside your iPhone app and so it just makes sense to use an app purchase, have users subscribed, and have everything nice and clean inside the app. BEN: You can’t discount the ease of you're just one password away from getting money from somebody, whereas the credit card form – I mean I use one password so I've got easy access to credit card members, but I should say my own, not other people’s. Otherwise you have to pull out your wallet; you have to type in the numbers one by one, so – I don’t know. I still think that there is some ease in app purchases for users. PETE: I guess the big differentiate, or the big decision factor would be whether you're just an iOS-only app or if 7you’ve got multiple channels, right? So if you’ve got an Android app and an iPhone app, or an Android and web, then obviously [inaudible] purchases is only gonna help with one of those. MANTON: Exactly what you said, and even on iOS you have kind of – they destroy, as I've mentioned in the beginning, do people have to resubscribe to your service or can you automatically rebuild them? And the way Apple handles that is a little bit weird, but it is possible to [inaudible] your app to take advantage of that, and they –. I don’t know Ben if you finished going through that process or not – I’d be curious to hear how it went – but I know a lot of people, they go through it and they get rejected, and Apple says, “No, you should be a magazine; if you want to do this, you should be a newspaper.” But if you look at the app store guidelines, they do allow you to do this auto-recurring billing for apps like business apps, for any cloud storage-type apps, media apps. Dropbox, for example use this; there's a bunch of other apps that use it. I generally think you kinda have to go through this process where Apple kinda reject it, and kind of appeal it, and kind of say, “No, this is allowed,” but if you do get approved, it’s kind of an interesting API because you have users who subscribed [inaudible] credit card, and like I said, they get billed every month automatically. They get a little email from Apple that says you're about to be billed again for the subscription to such and such an app, and Apple just kind of handles it. PETE: I guess, maybe this is a question for someone inside of Apple rather than you, but I guess I can’t see what category of apps wouldn’t count for that because it sounds like it could be pretty much anything. I mean, yes, they say you should be a magazine or newspaper, but you're saying there's always other apps that could kind of get into that category. What's an example [inaudible] that wouldn’t fit in there? MANTON: I would say actually most apps probably don’t fit the way Apple kinda phrases it. I think their default is to say, you shouldn’t do this. I really think they discourage it because it’s kinda powerful. I mean you don’t want someone – we always hear about people accidentally buying things, or they give their phone, their iPad to their kids and they accidentally spent all this money on SurfBerrys or whatever. To get automatically billed again is even more powerful and I think they don’t want people to abuse it. So there's this kind of specific cases where you have an app that isn’t just a utility app or some kind of productivity app that just does kind of one thing and is kind of stand alone, where the app connects to some kind of cloud service or API or something that is kind of bigger than just the app – I think that’s where subscriptions start to feel kind of right. Users don’t value apps like they used to – 99 cents, free [inaudible], everything for super cheap, but the weird thing is that users still, even with that mindset, they kind of value services and web apps and they kind of –. It’s almost like those have a different set of rules applied to them where you can charge every month for those kinds of things, where it’s very difficult to charge for a small iPhone app every month where people just [inaudible]. BEN: I think the line that Apple draws is if you're selling a service, and you wanna keep selling the service – a good example is ForeFlight. It’s an iOS app for pilots and it does stuff like the pre-flight check, and the maps, and weather, and stations and all this other stuff, but it’s also really expensive – I think it’s like $150 a year. They would not be able to do auto-renewable subscriptions because they're just delivering a service, like a continued service. If you are delivering content regularly, like periodicals, then I believe you're in the green. That’s why I've been pursuing that approach for NS Screencast, since I'm always delivering content, I think I'm in the right there. And if I get rejected, I would certainly appeal to the rules, because it seems like I would fit in there. But yeah, I think the majority of apps that they just have the service, they would have to do a non-renewable subscription, like Dropbox or whatever. MANTON: Yeah, and there's definitely a line in the guidelines about audio and video streaming types of apps – those definitely seem allowed. Again, you may have to go through Apple review a couple of times, but that seems like a pretty clear case or something that needs to be allowed. CHUCK: So what are the different ways that you can do a subscription? I mean, you were talking about in-app purchase; you were talking about some of the other options – what are all of the different options? MANTON: So for in-app purchase, there's two subscription types and you'd go into iTunes connect, and you can define these. One is just, they call it “non-renewing subscriptions,” I think, and it’s just where you subscribe to something, but then you have to prompt the user again next month or in three months to subscribe again. Those are kind of just a normal in-app purchase where you're buying credits in a game or whatever, it’s not that much different. And then that, if you have ever done any in-app purchase before, should be almost exactly the same where the API is a really simple Store Kit; it has kind of a classic, objective-C API where you have a delegate and you say, “Give me the products that are defined and make payment objects submitted into the payment queue and that’ll prompt the user to subscribe and if everything goes right, you get callbacks and say, “This persons subscribed,” or “this transaction finished” – whatever the events are. And that’s fairly straightforward. The auto-renewing subscription is the other type where we have been talking about whether you can get approved or not approved, and the API is pretty similar as well, it’s just a different type in iTunes connect. BEN: There's a difference in the information that’s available, right, between the two? I know that there's a lot of changes with iOS 7 as well, so I don’t know if you have any experience with the new Store Kit APIs? Like for instance, I think it says SK payment receipt use deprecated? MANTON: Right. I've used the new APIs a little bit, so when you get, when one of these transactions goes through, you get this receipt data. Traditionally the best way, especially the subscription service, that you send that data to your server and then you can call back to Apple servers and verify that it’s actually right, so that no one can [inaudible] or whatever, try to get around your app’s subscription, so that’s traditionally how it works. With iOS 7, there are new APIs where you don’t have to d that; you can just verify on the client. I haven’t done the new stuff with subscriptions. My feeling is that you still probably wanna go through your server, especially if you have any of this kind of stuff that were talking about where there is kind of some server component. BEN: You gotta record that transaction on your server anyway, because you gotta be able to authorize the content and give them some sort of token or something so that they can retrieve it later. MANTON: Exactly. I haven’t done too much with iOS 7 except just basic, in-app purchase. Not subscriptions on the client, but it seems like for, especially for auto-renewing subscriptions, it seems like things haven’t changed that much from what I can tell. You still wanna send it to the server, you still wanna do the verification on the server, and check in to see, “Is this user still subscribed?” BEN: I just looked at the docs – SK payment transaction is what you get your call back on your payment observer, I think, and it has a transaction receipt that is now deprecated. And that used to be what you would send to the server – do you know what you need to send to the server nowadays to authorize with Apple on server side? MANTON: Ooh okay, that’s actually – I haven’t looked at that; that’s news to me. BEN: Because it used to be an opaque data structure, and I think now, there's some crytpographically signed data that you can unpack yourself and read all the data locally. And because of the amount of security [inaudible], it’s like encoded in an ASN1 format, so it’s kind of like a key value structure, and so you can use libraries to read those keys and values and then the whole thing is encrypted with PKF-something. There's tutorials on how to unpack all this stuff, but like you said, I wanna do all this stuff on the server; I don’t really wanna do it on the client, because it doesn’t provide me much value to do it on the client. As soon as I determine that, “Yes, you're unlocked,” I'm gonna make a request for protected content and I just can’t trust the client at that point. I have to actually have done the same thing on the server. I am curious to know how the stuff changes in iOS 7. I think I'm gonna have to go watch that [inaudible] video for the fourth time. MANTON: Right, I should really read the new stuff. I didn’t realize that much has changed, but that’s interesting. CHUCK: One thing that I'm curious about, if you send this receipt down to your server, is there a way to verify that? Or do you just trust it because it came from the phone? MANTON: No, you definitely can verify it. There's an API call you can make back to the Apple server from your server, and you send [inaudible] - traditionally, it’s just this opaque database on the receipt. And then you get back more information about the transaction, which presumably you can trust, and you get the recent receipt the user has renewed, just different information about the purchase. PETE: So the basic kind of sequence is, your phone kinda talks to Apple and does all of the actual buying stuff, and then your phone sends this used-to-be opaque, now not opaque, token up to your server, then your server dials home to Apple and say, “Hey, this person on the other end using this phone says they bought something. Did they really buy something?” And Apple comes back to your server and says, “Yup.” Is that basically the –. MANTON: Yes, that’s exactly right. JAIM: One thing we stress on in the WWBC session, and this is kind of the most developer-hostile stance to take I think – hostile’s probably not the right word, maybe unfriendly – so they're [inaudible] using all these open standards for cryptographically signing the content so that you can verify on the device. They don’t provide you any libraries whatsoever to unpack it. And they're like, just Google search and you can find thousand of resources and reading cryptographic library-like documentation is like scratching my eyeballs; it doesn’t sound like fun. And so you look for tutorials out there – the whole point of not providing you with libraries is so that somebody can’t just, like a jail breaker, can’t just find the exact injection vector to compromise that entire subsystem. So if they're looking for a symbol in your running app that they can hijack and do your own code instead and just return ‘true’ or return a fake receipt, they don’t want that ability. So by using any kind of common component, it sort of – if everybody were to ride it on the same boat and used the same exact classes for validating these receipts on the device – then it would sort of negate that whole security, I think. You only have to worry about that for compromised phones, but still it’s not very friendly to somebody who’s not super familiar with all this, the active, transforming, byte erase into something that eventually turns into a dictionary, right? And that’s your pictographic methods. PETE: I've never had a fun time decrypting data. CHUCK: [Laughs] JAIM: I understand the motives, but it is not friendly to the developer, I'll just say that. PETE: I guess eventually, being the open-source hippie that I am, I would hope that some good-quality, open-source library will fill that niche and will be at the same place anyway, right? JAIM: Right, therein lies the problem. Oh, this works. I don’t understand it but it’s on GitHub. [Chuckles] I’ll just bundle it into my application and maybe it does work, but now if everybody’s using the same library that becomes a juicy target for jail breakers. CHUCK: Yup. MANTON: It’s important also for developers – you shouldn’t be scared off from doing this. There are kind of several layers of this and it sounds like your eyes are gonna glaze over, like “Oh, my gosh, all this encryption, all this verification,” but you can start really simply. Just doing the initial Store Kit stuff and doing a request, and getting your app to prompt for an in-app purchase is hardly any lines of code, right? You can do that basic stuff and then start layering in the back end and receive the verification and all that kind of stuff after. You don’t have to sort of tackle everything at once. CHUCK: So have you done much with different subscription levels? You have your basic, and then your ‘I'm super awesome’ and then ‘I'm really super awesome’ levels or whatever. MANTON: First, on the iOS side, I was worried about this whole, “Are they gonna approve me to do the auto-renewing subscriptions?” and so I had two plans – I’ll get to answer your question – I had two plans, but they were monthly and yearly, not like monthly basic and monthly super awesome pro or whatever. And so you can certainly define those. I then switched to renewing subscriptions, auto-renewing, and I just had one sort of basic monthly plan. But on the back end, when I'm accepting regular credit cards, I now do have several plans for some of my products. I haven’t rolled that back into in-app purchase yet, and part of that is just because you have so little control over how this stuff works. You can’t – the user has to cancel, you can’t cancel for them and switch plans – it’s just very difficult to manage how that stuff works, whereas if I'm accepting credit cards myself, I can have multiple plans and at anytime during the month I can switch them to a different plan if they wanna pay for the premium features. It’s just a lot easier to manage. I haven’t quite figured out the right way to do that with in-app purchase without it being just a complete hassle for the user. CHUCK: Yeah, I was wondering about changing plans. MANTON: I think right now you just have to tell them to cancel and then subscribe at another level. [Crosstalk] MANTON: Yes, tell the user. And it’s very clunky – I mean, you can go into iTunes and cancel. It’s just very varied, the way they handle subscriptions, I guess. The user would get this email once a month and it says, “You’ve got these two subscriptions that are gonna renew soon,” and in that email somewhere there's a link to manage the subscriptions, but it’s very outside the app’s control. The app cannot guide the user, walk the user, through this process. CHUCK: So you show them screenshots and say, “We’re sorry, this really sucks.” MANTON: [Chuckles] Right. ANDREW: Does anyone know why Apple might do something like that? Because it seems like it’s really at odds with the usual focus on the user, because it really encourages people to sign up for subscriptions that never get canceled even when they're not using them, which is great for a developer selling subscriptions, but not so good for the user. I'm just wondering if there's any justification or if it’s just them being lazy. MANTON: That’s a great question. I think part of it may be that a lot of this kind of an afterthought, and it started with things like Newsstand magazines, which are a little more focused, kind of narrow [inaudible] case. A lot of it may just be the app store is a little bit clunky to begin with because of the history of, “We used to sell music; now we sell apps” and just the growth and the weight they’ve evolved the app store is not super smooth. I don’t know if there's a grand vision or if it’s just kinda ‘This is an afterthought; it’s not fully-baked in some areas.” PETE: I suspect that anything that involves a service-side component is paying full for Apple to actually just, like you were saying, originally it was for selling music, and then they kind of duct-taped on this kind of selling apps thing and then they're like, oh, subscriptions too, and seems like they have some charges there on the server side. CHUCK: Yup. PETE: It kinda feels like, I think we talked about his earlier, but they don’t really want to do this maybe, like Apple don’t really want to do the subscription thing, but they have to do some element of it because otherwise, they're just not gonna have some of the – Netflix aren’t gonna – or whoever, not Netflix I guess, but some portion of apps are jgonna just go off and do things, web-only or something like that. So they wanna do enough to let these people do it, but they don’t wanna put too much effort into it because they don’t really fundamentally want to allow subscriptions – I don’t know. I'm kind of turning into a conspiracy theorist. [Chuckling] CHUCK: So one question I have going back a little bit to that line where you sent people back to the website to subscribe, if you just do the subscriptions to your website, it sounds like you're saying you can’t tell people to go back to your website to get a subscription, so what do you do? Do you just prompt them for a username and password and hope they're smart enough to figure out to go to whatevertheapp’snameis.com? MANTON: Pretty much, yeah. Like we were saying earlier, it’s very clunky if the user is discovering your app through the app store. It’s not too bad if they read an article online about your app and then they go directly to your website and they decide they want it, and they sign up, and then they download the app – that works okay, but it’s when they find your app in the app store, that’s where it gets a little weird. I think, I don’t know, in my case, and this is probably fairly common, you probably have a lot of downloads from people who have never heard of your app before, and then they give up when it comes to –. I have downloads from people who don’t end up subscribing, and I think that’s okay. That’s just part of the process of if they're checking out the app, they’ve found it for the first time, but maybe it’s a little bit too clunky to go through the whole signup. JAIM: Yeah, [inaudible] which is pretty important. Last year I finished a project with a company that does subscription and they’ve got hundreds and thousands of users. One thing that they did do, they can’t have a link to subscribe, but one thing that did pass is “redeem this code,” “click here to redeem a code,” which kinda isn’t a way of sending you to the website. There's ways you can do it, but it’s not clear. BEN: If it feels like you're being shady, that’s probably against the rules in some way. And you may not get caught, but I don’t know – I feel really uneasy about basing a business decision in which I'm hopefully be making money on hoping Apple doesn’t catch some work around I'm putting in. I don’t know, I'd rather just try to play by the rules and hopefully Apple will not give me grief for submitting an app that uses auto-renewables without being a magazine. And we’ve had to advice our clients the same thing. Another thing people have tried to do is say, “Oh, we’ll just charge 30% more for the in-app purchase,” and you can’t do that either because Apple will go check the pricing of a [inaudible] on your website and have to be exactly the same, or within a penny or whatever. Whatever the price to your [inaudible] it matches to your subscription level. MANTON: Yup, I agree. You wanna play by the rules when you can. There are some funny rules of subscription where, for example, at one point I was rejected because my app store description didn’t spell the stuff out, and they really want you to. And again, I think they're trying to protect the user, just trying to do the right thing so apps won’t abuse this, but they want you to spell it out in the app store description right at the top, like “This user’s  subscriptions, the length of the subscription and such and such is the price. Here’s the privacy policy,” you have to have a little more than you might have for a normal app. BEN: A couple of other things that come to mind just around the topic of payments: there are some apps that allow you to enter in a credit card from the phone. One that comes to mind is Uber, and they are the first ones that I'm aware of that you'd take a picture of your credit card and they would OCR the numbers – you didn’t have to type them in. As far as I know, the guidelines around that is you're buying a physical good, you can completely bypass their in-app purchase stuff, but if you're buying a service or a subscription, you have to use in-app purchases. Does that sound correct to you? MANTON: That sounds correct, because definitely you're not supposed to use in-app purchase for physical goods and so I wouldn’t be surprised if you wouldn’t get approved immediately for something like that, but yeah, that should be allowed because there is no way to do an app purchase for that type of product. Or at least Apple, that’s not the design of in-app purchase. It’s not designed for physical goods; it’s not designed for buying something in Amazon and having it shipped to you. BEN: You mentioned, for your own apps, you’ve been leaning towards just going subscription-only on the web – are you still using Stripe for those? MANTON: I am. I'm a huge, huge fan of Stripe. Like I said, I think in the beginning I started with some PayPal stuff, but there's all sorts of problems with how PayPal deals with subscriptions; it all sometimes kind of randomly suspend accounts; it’s very difficult to manage and get data out of their system. Stripe is excellent. The docs, the API – it’s one of the best web services I've ever used; I'm a huge fan of it, and I'm definitely –. If I could only pick one way to do things, I would pick Stripe for sure. BEN: Yeah, I have to second that. CHUCK: Stripe’s easy. Stripe’s a lot easy. I have a merchant account too, and they're kind of a pain to get, so. PETE: I've never heard anyone say anything bad about Stripe, ever. BEN: Did I tell you how they sent me a t-shirt? I think I've told that story before. CHUCK: Tell it again! BEN: Okay, I’ll tell it again. [Chuckles] So I had a very naïve algorithm for fetching invoices from Stripe. This was before I implemented their web books support. So the idea is when the data changes in there and they send you a web book with all the details in and you're supposed to record the details locally and do whatever you need to do on your app. But I haven’t done that yet, so I was just [inaudible] to download all the invoices every day. That wasn’t such a big deal until a couple of things happened. One, when I was growing in subscribers, and the people who had subscribed kept subscribing, so the invoice number just kept on growing and the other things is I switched from Rescue to Sidekick, when Sidekick uses celluloid and Ruby “threads” to do work in parallel so instead of doing one job at a time with one worker, I was doing 20 at a time, so it was like a shotgun blast against your API. I showed up on their radar, and they're all like, “Hey, can you please stop doing that?” and then they're like, there's a better way of getting your invoices in sync. And so I was like, “Oh okay, it’s been on my list. I wanted to do that.” And he’s like, “Okay, cool. Well I’ll send you a t-shirt for your trouble.” And so that’s how I have a Stripe t-shirt – I was abusing their API. JAIM: Okay, step one: abuse API. Step two: fix it. Step three: t-shirt. Got it. BEN: Yes. CHUCK: Well that sounds a whole lot easier than I thought it’d be. BEN: No, their support has always been super – I'm a big fan of Stripe. I have a lot of people who sort of have been asking me for PayPal support, and I keep saying, “No, no, no, no, it’ll complicate everything” and I don’t really wanna support PayPal. But people tell me that in Europe, it’s far less common for people, especially students, to have credit cards. There are maybe people who actually can’t sign up which is unfortunate and I wish I could support PayPal without adding just gobs of code to my website to handle it, right? Because it’s probably not worth it if it’s only gonna be like 10 or 20 customers. MANTON: So two things to add onto that: I have gotten some pushback from folks in Europe – especially for small transactions – I've heard from some people like, I run the tweetmarker API for timeline position syncing and I have this optional $1 a month subscription, just kind of a simple, small thing, which is fine for most people, but I have heard from some people that their bank charges them so much for such a small transaction, it just doesn’t make any sense, so they want a yearly, bigger, $10 a year or whatever instead of $1 a month, whereas PayPal or something where they wouldn’t have that problem. But the other thing is, I'm in the process now; I strongly discourage you from doing PayPal. I mean, I have to assume it sounds like maybe a lot of people are asking for it, but there are so many hassles with it. I am in the process of just moving everybody away from PayPal. I'm even at the point where I'm gonna make the transition as painless as possible, but if someone doesn’t want to transition like by the end of the year, I'm just gonna turn off that stuff, because it’s really holding back being able to build features into the app for managing your account. So like what I said before, switching between different plans, cancelling, anytime you have to look up payment information, you have completely different code paths. It’s just a hassle. And the Stripe API is just so much better than anything else that if I could, let’s say over the next six months, transition all the PayPal people to stripe, and if some people don’t wanna come along for the ride, that’s okay. It would drastically simplify the back end and allow me to build things a lot more quickly. That’s where I'm coming from. JAIM: Can I add like a FAQ page and say, “Why don’t you support PayPal?” I’ll just say, “Because Manton said.” [Laughter] MANTON: Good work, yeah. Yeah, I mean, every app’s different. I think Marco Roman has written about this too; PayPal, for subscriptions, is a big problem. It’s been years and years and they haven’t made it better. BEN: He made a comment on – last time I heard him talk about this, I think he was making a comment about how there's no way to actually get a list of all your customers? MANTON: That’s right, yeah. BEN: Which is so weird. Like you have to deal with the callbacks and there's no definitive source of information you can go call and ask about. MANTON: That’s right. So you can go to the website and you can kinda page through customers and copy data out, but there's no – seriously, there's no way to automate it, there's no way to just get like an export easily. You can export sort of raw kind of data, but in terms of subscribers and whatnot, it’s very, very painful to deal with. CHUCK: Yeah, I know I have been able to download a CSV of list of people, but yeah. And even that’s not super well-formatted; it is kind of backward. And I think you can get a list of all of your subscribers for everything, but I don’t think you can filter it by the different products you sell. [Crosstalk] BEN: Ultimately, you're gonna wanna have that locally, right? Your system records should be used, especially if you have multiple payment providers. But going through my app, there's just a lot of stuff that just kind of assumes that people have Stripe subscriptions, which made it actually hard for me to give somebody a subscription, because like everybody signing up had to be – had to have an associating Stripe account. So I ended up coming up with a concept of a team, so that way I can have like a company pay for the subscription and have other people be part of the team, so there's already a sort of –. I can point to lots of areas in the code where it’s kinda muddy. It’s like, “Well, is this user a Stripe customer? Or this user part of a team?” and I would have to add a third, or is this person a PayPal subscriber? And I'm already sort of having to do that when I do in-app purchases. I have to have that notion of ‘what type of subscription does this person have?’ I try to avoid as much code complexity for the sake of not introducing bugs in the future and things like that and actually focusing my time on creating content, not managing a subscription system on the web. Especially I don’t know how many people would actually wanna subscribe on PayPal, so it’s hard to know whether that it would even be worth it. CHUCK: Yeah, that makes sense. Are there any other things that we should talk about here with subscription models or revenue sources before we move along? MANTON: That kinda covers the basics, I think. Like I said before, it just depends on the app. I think if you can pick one road to travel down, whether it’s in-app purchase or Stripe, and kind of keep things simple, I think that makes your job easier. Promise of subscriptions, I think, is really great; gaining recurring revenue every month, we can kind of predict how things are going, and you build kind of a sustainable business, hopefully. But it’s really hard. I mean, there's tons of people who have tried this; it’s not kind of a guaranteed success, and I was just thinking the other day about Everpix, which shut down recently, and that was a subscription service that everyone loved. The app was good, the service was great, it was unique, and they still couldn’t quite make it work. It’s hard, but I think there's a lot to this idea, and if you have a good fit in your app, then you can go down this path. I mean, it could be great. CHUCK: Alright, well let’s go ahead and do the picks then. Jaim, do you wanna start us off this week? JAIM: Sure, I've got one pick and early in this year, Eric S. Raymond dropped a blog post or an article called Lost Art of C Structure Packing. It’s kind of a technique for understanding how memory management for the structs, and this was my world in the ‘90s when I started out. I wish I had this back then, but it’s actually a very good read and we’re getting into a world where there's a lot more memory-constrained devices, internet [inaudible], that type of thing, so maybe not that useful for your bread and butter iOS apps, but it’s actually a really cool article if you wanna know how C handles things. So, there it is. CHUCK: Cool! Ben, what are your picks? BEN: I have a handful of picks today. I've been trying to play more games lately, and Torchlight II went on sale over the weekend. I actually already have a copy, but I bought a second copy for my son so that we could play together. The reason why I don’t play this game much is because it’s for windows and – I don’t know, I'm just always on a Mac. Turns out, it actually works totally fine in a VMware Fusion VM. So I've been playing Torchlight II a bit, so that’s found on steam. Also, I've been playing Starcraft II a lot, and if you're a Starcraft II player, you should be checking out SC2Casts.com for just watching the pros and trying to get an idea of strategies that might work and anyway, that’s a lot of fun. Another one is a gem: yesterday, I was sitting down to say, “Dang it, I'm gonna solve this problem and write a gem,” and it turns out, somebody had wrote the gem already, and it was exactly like, exactly what I would have written, which is just so awesome. The gem is called after party, and the idea is – it’s kind of like database migrations, but for post-deployment tasks. So in this particular case, I have to resize a bunch of images, because we have new image sized for our mobile apps, and I need to do that as soon as we deploy and it’s kind of a pain, too, after I remember to run some specific, random[inaudible]. So after party, you define a bunch of risk tests very similar to migrations, and then in Capistrano, you just say, after deploy, run after party, and it will keep track which ones it’s run already. One other pick today is a Youtube user called thebennybox. He’s got a bunch of tutorials on how to create Wolfenstein 3D from scratch, which has been pretty fascinating. I find his sort of tone really obnoxious, but if you can get through the tone of how he presents the content, it’s actually really, really good content. And then my last two picks are the ASCIIwwdc links for the two Store Kit presentations that [inaudible] this year, sessions 305 and 308, which will be relevant to today’s discussion. So I’ll post all of those in the show notes. CHUCK: Awesome. Alright, Pete, what are your picks? PETE: My first pick, which actually I've wanted to ask about during the show, whether this would be relevant, hopefully it will be, fingers crossed for me, is the two free technical support incidents that you get from Apple through every year of your subscription. I think we’ve talked about this in the show before, but don’t forget that I didn’t know that I even had these, but twice a year, you can use a technical support incident and ask Apple for help. I am guessing maybe you could use these to ask Apple whether you could really submit something via subscription, to use a subscription API. Maybe I'm wrong. No one seems to drop me so I'm gonna assume I'm right. ANDREW: They might refer you back to the app store review people. BEN: That’s kind of a separate department, but –. ANDREW: Yeah, that’s actually two incidents per developer program, so if you have a Mac and an iOS developer program, you get four. PETE: Ah, I didn’t know that. Okay, I'm gonna pick it anyway because, why not? I already picked it. My second pick is a double pick for the Bay Areans that may listen to the show. Pick number 1 is the casual carpool; if you don’t know what that is, then Google for Casual Carpool. Pick number 2, or the second half of that pick is the Bay Area Bike Share. This is like kind of a zip car but for bikes, I guess, and it’s run by the city in San Francisco and if you have a place in the Bay Area; $80 a year, and you can pick up a bike whenever you want from loads of places around the city, and ride to somewhere else in the city and drop it off, and it’s free. I mean, you pay $80 a year, and you can use it as much as you want throughout the year for any trip that’s 30 minutes or less. I've been using these two together to do a lot of my commuting, which is awesome, coz it’s free, and I get a little bit of exercise and I just noticed today that they publish all of their data, so I think this is really cool. You can go to a bit of their website and download all of the data of who’s using bikes, when and what their ridership is, which, if you're looking for an interesting kind of side-project to do, big data, then I might be interested too. My last pick is a beer pick: I'm gonna pick Lucky 13 from Lagunitas. It’ actually like a seasonal beer that’s not available until May according to their website, but this is something for you to kind of prepare, get ready for yourself. It’s a typical kind of Lagunitas beer, so it’s pretty high alcohol, it’s pretty malty, pretty healthy, and according to their website, it is 8.9%, so be very careful. It is very, very yummy; it’s actually one of my favorite Lagunitas beers. So, Lucky 13. CHUCK: Awesome. Andrew, what are your picks? ANDREW: I got two picks today. So the first one is from Mike Ashe’s blog; it’s a Friday Q&A post. I know I pick these and talk about them a lot, but I really like them and this is a good one. He did a post called Let’s Break Cocoa, and this is just a blog post about – mostly things you're not actually gonna have caused problems on your app, because you have to go out of your way to do most of these things, but just strange ways that you can break the Cocoa APIs and I thought that it was kind of fun to read and also interesting, because there were things in there that I hadn’t thought of or didn’t know about before. And then my second pick is a new objective-C style guide that raywenderlich.com published and I don’t know how useful these style guides are because a lot of it is subjective, but for a single organization I think it’s important to have a consistent style, and their style guide is quite thorough and I think they make good choices. So I thought it was at least an interesting read to think about and maybe learn some reasons for certain style choices. And those are my picks. CHUCK: Awesome. Alright I've got a couple of picks. One is if you ever have to do a Lorem Ipsum in your project, I think Lorem Ipsum is kind of boring, so instead, the one that I like to use is Bacon Ipsum. You go to baconipsum.com; it’ll generate Bacon Ipsum, and I’ll just read you part of the first paragraph. It’s, “Bacon Ipsum dolor sit amet fat back drumstick pork belly short loin pastrami –” anyway, and it just goes on with a whole bunch of meat terms, so. It’s a lot of fun, so then somebody can smile before they go and then actually put real copy in, so anyway, that’s one pick. And the other pick I have is, my friend David Brady is writing an e-book on how to find the job, and it’s really the job-hunting guide, and it talks about some of the issues that you have finding a job and things like that. And it’s pretty good – he has two posts and I’ll post both of those here. The most recent one he posted yesterday, it’s The Job Hunting Mindset, and the one before it is The Job Replacement Guide, and he just talks about his story and why he feels like he has to write this book and they're both just terrific, so go read them, even if you're not looking for a job at the moment, because they really are just terrific blog posts. So those are my picks. Manton, do you wanna give us your picks? I'm sorry, I'm just having a day today. MANTON: Sure. The first pick, we already talked about a bunch on the show, but I'm gonna pick Stripe API. I really like it, and hope that folks can check it out if you're thinking about doing any server, credit card stuff, managing this kind of stuff for subscriptions; it’s just really well-done. The second is also kinda related to this, I'm gonna pick the Helios project from Matt Thompson, which is kinda just this nice collection of back end stuff for either an app purchase or push notifications, or whatnot. And I was using this just a couple of weeks ago; I was working on some push notifications [inaudible] in my new app, and I found it really handy. He’s got all sorts of code, of course, but in this particular case, there’s just a lot of really nice stuff for, like I said, the only push notifications on the server and then a sort of complement of objective-C stuff on the client side. So that’s Helios. And that’s it. CHUCK: Alright. Well thanks for coming on the show; I really appreciate you sharing your expertise and hopefully people have an idea of what they can do if they want to provide subscriptions or subscription support to their users. MANTON: Thanks for having me.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.