

Ask HN: Help us decide our iOS Framework licensing model - tag2

Hi HN,<p>We&#x27;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 &#x27;Simulator only’, completely free. Publishing to the App Store will require the purchase of a license.<p>This is us: http:&#x2F;&#x2F;www.getredbeard.com (still under construction)<p>Option 1:
A perpetual license based on a one off license fee. Build and publish as many apps as you like.<p>Pros:
- Traditional model and something developers are used to.<p>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.<p>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.<p>Our thoughts on a tiered pricing model are as follows:<p>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&#x2F;Organisations - Larger bulk serial key allocation, 20 serial keys.<p>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.<p>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.<p>We’d really appreciate any thoughts on this or anything related to our website or framework.<p>Thanks
======
joeld42
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.

~~~
tag2
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.

------
mchannon
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.

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

~~~
tag2
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.

------
brudgers
What is the revenue model based on?

