StoreKit With and Without RevenueCat

I was recently chatting with Tyler Hall about his experience implementing subscriptions with and without RevenueCat. His perspective was really interesting, so I asked if he was up for a Q&A.

Tyler has been working with StoreKit since it was introduced in 2009 and first started shipping on Apple’s platforms back in the Mac OS X Tiger days. Tyler has built many apps for clients and employers over the years, including work with Lonely Planet, CNN, USA Today, and various startups. He’s also released quite a few apps of his own and built several highly rated open source projects.

Here’s the full conversation, lightly edited for clarity:

Q: You recently mentioned that one of your clients hired you to build an app with both IAP and subscriptions. How long did it take you to build this for them?

The initial build-out of the StoreKit logic took about two full-time 40 hour weeks. And that was with my own experience building IAP in other apps – including my own. It could have been done faster, but the intent was to make it generic enough so that new offerings could be rolled out with minimal fuss. 

I was the only mobile developer at the company. Android IAP wasn’t even attempted. I don’t know how much time was spent doing server-side validation logic by the one NodeJS engineer.

Q: You also mentioned that you were able to leverage code you’d previously written to save them time. If you were implementing the same thing from scratch, what would your estimate have been?

That’s tough to say. I don’t perceive working with Apple’s StoreKit APIs as the hardest part of implementing features like this – I say this waving my hands – but basically you just read the docs and do it. The really tricky parts are all the ephemeral and undocumented (or poorly documented) quirks around Apple’s bizarre infrastructure. If someone was starting from scratch, how in the world would they figure out the hoops you have to jump through to test App Store Sandbox accounts correctly? Or the accelerated sandbox subscription events that (at least the first time I built this stuff) rarely adhered to the barely documented specs? And god help the first time developer building a Mac app.

I saw a joke on Twitter a while back that went: Half of Apple’s documentation is online. The other half is only available in WWDC videos. And the other 90% is only available talking to an engineer in the labs.

Q: What infrastructure did you set up for server-side receipt validation?

Node / Postgres running on AWS.

Q: Who manages the server-side infrastructure day-to-day?

The one server dev was responsible for everything. If something went down at 2 am, he got paged. While I may have had pertinent experience and know-how to help out in a crisis, I didn’t actually have access to login and firefight on my own.

Q: When the App Store was down for roughly 5 hours on January 24th of this year, who responded to the incident for that app?

I had been gone for seven months at that point so I can’t say. I’m sure it would have been the same guy. But, I’d wager that at many resource-constrained companies like this one, no one even noticed.

Q: If that client ended up needing integrations, like sending data to Facebook, AppsFlyer, Mixpanel, Slack, etc., how long do you think that would take?

Extremely simple integrations like pinging a Slack channel are typically a single HTTP request inserted into whatever queue and/or notification system you already have in place. That’s not much work.

Deeper integrations depend on where you’re sending the data. I know with my own backend infrastructure for my own software biz, I’ve added new hooks in as little as a few hours up to a week to “do it right”.

Q: If that client wanted charts or other tools to analyze the data, how long do you think that would take?

Oh, god. I wouldn’t want to even attempt that in-house. If I couldn’t find an easy to drop-in SaaS or open source solution, I’d prefer nightly exports to Excel or writing SQL by hand over implementing charts and analysis tools myself.

Q: In your experience having worked on IAP and subscriptions for years, how much maintenance do apps generally require over time to find and fix client-side bugs, server-side bugs, and other issues that come up?

Not counting infrastructure outages, in my experience, the work comes in annual cycles as everyone has to react to whatever Apple announces in June, build and prepare to do a big update that Fall, and then quickly triage and work around whatever Apple breaks with the first public release that wasn’t caught in the beta cycle.

Q: What are the top reasons for and against using RevenueCat that you’d discuss with clients?

Cost, time to market, and domain expertise.

I am wholeheartedly in favor of paying for tools that make life easier. Even with my own, tiny, one-person software company I happily pay for the software and services that work better than anything I could build myself and save me time.

And as for time to market and domain expertise, I’ve been working in Apple’s ecosystem for 14 years and using StoreKit since it was announced. There’s simply no way I could build anything as reliable and easy to use as your SDK that also comes with your knowledge and experience in the app payments arena.

Assuming I paid myself my full freelance rate to build this logic into a new app, the $1,500 [per year, $119/mo] RevenueCat plan equates to two and a half work days of billable time. Why would I build it myself? That said, I know there are good open source StoreKit wrappers out there, but I haven’t given them a serious look in years. Maybe they compare favorably? But they won’t come with the server infrastructure or support.

Q: You mentioned on Twitter having used RevenueCat recently for a personal project. How did that go?

I just double-checked my commit logs:
March 11, 2020 at 10:02:06 PM CDT Starting RevCat integration.
March 11, 2020 at 10:14:36 PM CDT layout
March 11, 2020 at 10:55:48 PM CDT Purchase UI sorta complete.
March 11, 2020 at 11:23:20 PM CDT Free trial info.

From installing the RevenueCat SDK to making my first successful sandbox purchase and having the app’s UI react accordingly, it took 1h 21m. Is the work done? Of course not. There’s still a ton of cleanup and niceties to add. But to literally be able to make a financial transaction and verify the purchase receipt from scratch in under ninety minutes? Wow.