Discuss Home · Bootstrapped Podcast · Scribbleton Personal Wiki · HelpSpot Customer Service Software · Thermostat NPS

Is it possible to create a free standalone iOS app and then allow the user to subscribe to the features via App Store subscriptions?


#1

Hello,

I’ve been looking for this on the internet and no one is saying anything. Here is what I want to know: Can I build a standalone iOS app and sell it as a service on the app store using subscriptions? As I understand it, subscriptions are only for content based apps, am I right? If I’m wrong, is it possible to create a free app and then allow the user to subscribe to the features for one year for example? It sounds too good to be true, but I could not find any official document that says that it is not allowed to do that.

Thanks for your answers!


#2

It depends on Apples interpretation of your app.

We have a SaaS web app, with accompanying iOS app, which has been running for the past three years.
When the app was first submitted to the app store it was rejected because it didn’t implement subscription based IAP (they looked at our website and saw subscription payments). We then implemented subscription IAP and the app was approved. About 12 months later, after submitting an update, it was then rejected again… because it used subscription IAP for a non content based app.

Granted, this is just one example but I wouldn’t rely on this as a revenue stream.

Does this app have a web app component or is it just a native mobile app?


#3

Just a native app. I’m not planning a web component.


#4

Apple’s overview https://developer.apple.com/in-app-purchase/In-App-Purchase-Guidelines.pdf seems to say such auto-renewing subscriptions to an app’s features are not allowed, because the content is not episodic in nature (page 7). You might be able to get away with non-renewing, but I would suggest having a backup business plan in case Apple rejects your app.

Have you looked at consumable IAP? That is one way to tie use of the app to the user continuing to spend money.

IIRC, even free apps have to provide some minimum functionality without additional purchase to be allowed on the store.

Can you share more about your app? Is there no low-price/standard IAP competitors already on the store? With a subscription model, your app could appear to be the expensive option in the minds of people used to the one-time purchase, use forever model.


#5

That PDF was the resource I was looking for, thank you.

What I was thinking was a really a plain simple native app where the user subscribes to the feature. By reading the PDF you linked it is clear for me that that model won’t work.

The app is a kind of project management software for event managers. Another option I can think of is selling the app with a certain number of projects available, and then selling the ability to create more projects. Maybe that can count as a consumable. Do you know an example of such an app?


#6

I don’t, not as consumable. There are products which sell features as IAP; perhaps the best known is Paper: http://mac.appstorm.net/general/opinion/when-in-app-purchases-arent-bad/ Other apps such as Pod Wrangler offer limited functionality for free, and then an IAP to unlock all the rest of the functionality: “The app comes standard with ability to subscribe to up to 5 shows. A simple in-app purchase unlocks unlimited subscriptions, removes ads and enables push notifications.”

Subscriptions are certainly viable for SaaS project management: http://saasmarkets.com/the-top-5-saas-based-project-management-tools/

I would suggest investigating the existing project management apps in the App Store and see if your proposed business model would make your app competitive.

You might want to open a new topic and ask, but my uninformed opinion is that for project management, you would be much better off making a SaaS app with a responsive web site.


#7

Thanks a lot for your answer. I’ll check that up and review my business model.


#8

This seemed relevant: http://www.marco.org/2013/12/02/auto-renewable-subscriptions

“I recently wrote that I wouldn’t use auto-renewable subscriptions again after extensive experience with both non-renewing in Instapaper and auto-renewing in The Magazine. A lot of developers have asked me to elaborate, especially as Apple has gradually allowed some apps to use them outside of Newsstand.”


#9

Take a look at calm.com’s iOS app, they have something that sounds similar to what you are asking about.


#10

Great resources, thanks. The calm app has really the same business model that I want… it’s really a SaaS for iOS


#11

Yes, you can use IAP to sell a subscription based iOS app. I have an iOS app and a Mac Store app that use this approach.

There are two types of IAP subscriptions available - auto-renewable subscriptions and non-renewable subscriptions.

My understanding is that for non-content based apps, you need to use the non-renewable subscription.

So that’s what I do. I sell a 12-month “premium subscription” as an IAP in my app.

That allows me to have my app on the App Store for free (which nets it many more downloads than it would as a paid app). A small percentage of the users purchase the subscription. It’s been less than 12 months, so I don’t know how well people will buy the next subscription when theirs expires.

There’s other benifits to this approach. When people sign up for the subscription, it’s a chance to capture their email address (must be an optional field though). Finally I can get some info on who my customers are :smile:

Anyway, depending on what your subscription unlocks will depend on whether it will be approved or not. My subscription removes advertisements, backs up the users content to the “cloud” (my server where I can do some analytics on how they’re using the app), enables printing, gives them “premium support”.

So it’s not a bad way to go. Probably better than having separate “lite” and paid versions of your app.


#12

I was wondering if you had any interesting data to report on this, now that it’s been more than a year since this post?

How did renewals go, and did you do any special in-app tricks to soften the user prior to renewal, like showing stats of their usage to prove that they are getting value from the premium features?


#13

I actually haven’t done much analysis to work out how many people have renewed on iOS / Mac. I’m using parse.com as the backend, and it’s a bit hard to get the data out to do run queries on it. Since I don’t work on the app anymore, I haven’t been too fussed about it’s performance. It’s just making some passive income for me.

I have three versions of the app - Web version, iOS version and Mac. The web version makes the most money, followed by iOS and then Mac. The problem with the iOS / Mac versions are that you are totally dependent on your app store rankings.

Over time your ranking keeps dropping, and you see less and less downloads. Whereas the web version kind of maintains it’s level of traffic much easier.

I’ve had some complaints about the subscription on the iOS version. No too many though - mainly just from a few people who had originally downloaded the app prior to their being a subscription. It’s not enough to worry about.

I think subscriptions in App Store apps are pretty good way to go for monetising the app - but maintaining your search ranking is the issue and because of that I don’t tend to recommend to anyone that they base a business around selling apps on the App Stores, because it’s just too hard.

But otherwise I’m happy though with amount of email addresses I’m getting out of my subscription - and I plan on using this list to market my next product to (web app / SaaS), so in that sense I am happy I’m getting something out of it still (as well as the small amount of passive income).


#14

It does sound like an interesting business model for apps. No matter how you do it, there’ll always be complaints. Unless it free to buy, and ad free with all features.

App Store rankings is a full-time job to maintain. Constant updates is necessary, it’s almost like a blog on it’s own that needs fresh content all the time.