Ask HN: Help us decide our iOS Framework licensing model | Hacker News Reader

Ask HN: Help us decide our iOS Framework licensing model

9 pointstag26 comments

Hi HN,

We've been working on an iOS Framework called Redbeard and we’re close to release. We’ll be offering developers the ability to download and build apps for 'Simulator only’, completely free. Publishing to the App Store will require the purchase of a license.

This is us: http://www.getredbeard.com (still under construction)

Option 1: A perpetual license based on a one off license fee. Build and publish as many apps as you like.

Pros: - Traditional model and something developers are used to.

Cons: - Piracy, serial keys all over the internet pretty soon. - Very little flexibility in pricing which could potentially result in us launching at a price that is prohibitive for a certain demographic.

Option 2: Licenses are not tied to a particular developer but rather to an App (Via Bundle Identifier). A license is required to publish the app into the App Store. At the point when they’re ready to publish their App they’d log into the Redbeard website and claim the key by entering the App Bundle identifier.

Our thoughts on a tiered pricing model are as follows:

Tier 1: One off App - Cheapest option and perfect for indie Devs. Gives a developer the ability to purchase a one off license. Tier 2: Freelancer - Developer given a bulk allocation of 6 serial keys that they can claim as and when needed for each App project. Tier 3: Agency/Organisations - Larger bulk serial key allocation, 20 serial keys.

Pros: - Prevents Piracy - Allows us to offer a tiered pricing model, as one size never fits all, thus allowing us to target a range of the developer demographic. - Gives us the ability to later adjust tiers based on market demands.

Cons: - Potentially unfamiliar licensing model and thus feels complex. - The need to login to the Redbeard website each time a Key is needed for a new project.

We’d really appreciate any thoughts on this or anything related to our website or framework.

Thanks

Hello! I'm an iOS dev at Smule, and also develop my own apps on the side as an indie. Here's my thoughts:

First, I probably wouldn't use a framework like this unless it was really compelling. There are plenty of free versions of most of those components on cocoapods or github. I'm sure yours are better, but I can just pod install one of those and not have to worry about buying a license and get my task done. Would strongly suggest that you have some way to use parts of the framework incrementally, and maybe have some of them free and others of them "premium".

Also, cocoapods. If I can try out a component from a cocoapod, that means I can probably drop it into my app in 5-10 minutes, then if it's interesting spend a few hours seriously evaluating it. If I have to run some kind of installer, and then start a new app with a strange xcode template, I'm just not going to do it. Maybe that's just me, maybe other devs will.

I would suggest a non-invasive, per-app license, along with an expensive option for the perpetual license for enterprises or very prolific freelancers (or agencies).

Don't do any complicated nonsense with license keys and BS like that. It's a huge headache for you and for the developers, and pirates are going to get around it anyways. Just let anyone link your sdk, and have a way to identify apps that use your components (e.g. print [Trial Version] or something to the console). If someone uses your components on a popular app, check if they have a license and let the lawyers handle it. If small developers use your components just don't worry about it, it's more trouble than it's worth to go after. Offer a very generous discount for small devs to put your logo on their splash screen, that might convert some would-be pirates to organic marketing.

Thanks for the detailed feedback joeld42. Much appreciated. Of course we do feel our Framework is compelling but it's just about getting that across to other devs in a clear manner in our marketing. We've found that whenever we've started a new project and we've needed a particular a set of components, it's been a pain trying to find the correct one to use, ones that have been kept upto date and then also ensuring they all work seamlessly together. Developers will of course have their own coding styles etc and trying to make each one work nicely in our projects is never easy. That's why we've tried to make everything in our framework absolutely consistent. Everything has the same coding style, is fully themable etc

It's a good point on cocoapods. It's something we'll definitely look in to thanks. We'd created the template as a way for newbie devs to have less hassle when trying to get a project started with our framework. I think another point we need to try and get across better on our site is how existing apps can use our framework.

On licensing, yep it'll just be a downloadable file that developers will need to just drop into their project somewhere. That will allow them to build the app to a device rather than just the simulator.

A thought on piracy- don't worry about it. A user is a user and some users can easily afford $1k/yr for their software and others couldn't scrape together $9.99 (think international). You get to count pirates and nonpirates both as users at this early stage in your company, and it's users that make your project worth something (so long as you can accurately count them), not license revenue.

Very few successful app developers will risk the rug being pulled out from under them, which I'm sure you'll retain the power to do. That can either come from breaking their pirated API key and bricking their installed apps or a clean, well-worded time-to-pay-plus-penalties letter from your attorney.

Highly pirated properties from Game of Thrones episodes to Metallica tracks all derive benefits from merchandising and live performances that owe some of their underpinning to popularity through piracy. Since you'll never prevent piracy, might as well anticipate and leverage it into more value for your shareholders.

I'd go with option 2. With tiered pricing, you can attract indie developers with more affordable pricing.

Thanks for the response munirusman. We are also thinking Option 2 but were a little concerned if developers would find the tiered model a little confusing. We didn't want this to become a barrier to them signing up. But I suppose it all depends on how well we explain the pricing to end users.

What is the revenue model based on?

Reply on news.ycombinator.com