Subscription for extra features within aprs.fi iOS app

This little warning has been in the aprs.fi iOS help text from the first version of the app - my plan from the beginning has been that some functions will require an additional paid subscription. The time for this is coming soon, and I've lately been spending some time implementing those features. This is likely going to upset some people ("what, I already paid for this app, I need to pay more?!?") so it's probably good to go through the reasons once more.

There is a fairly small number of amateur radio APRS users which are using iPhones or iPads. Androids are quite a bit more popular amongst hams. It will only take a short while until everyone, who ever will buy the app, has done it. After that nobody will pay for the application any more.

The work will not stop there: the application and the backend servers supporting it need to be maintained, upgraded and improved over time – if the application does not get some love and care from its creators at regular intervals, it will soon decay and eventually stop working. This has happened to a few ham and APRS apps already, and I'm not at all surprised about that. Even if the application does not get any new features, someone must keep it going, add support for new iOS versions and iPhone models, fix backend servers, and so on.

This maintenance burden may be difficult to appreciate if you haven't tried doing it yourself. When there's a new iOS version, you need new Xcode to build the app for it, new Xcode requires new OS X version on the laptop, and the app's code will need modifications to compile on the new Xcode due to changes in the programming language and APIs (programming interfaces provided by the operating system). And then there are the backend servers (don't get me started about "serverless").

"What? We need to pay more?!? Greedy bastards!"
Photo of Finnish native "kyyttö" breed of cows (c) myself
2016-06-16 at Sappion luomutila

I do quite some volunteer work as a hobby to support the APRS system (in the form of running aprs.fi itself, contributing free open source software such as aprsc and the aprs2.net backend software, open source APRS symbol graphics, machine-readable APRS device identification database, and a few other bits). I'm already quite busy with everything, and the family, so I decided to make a little bit of money from the iOS app. Due to the relatively small amount of users, it'll probably never pay for all the effort needed (pay-off not really comparable to the daytime job), but at least something. And, to keep the motivation there in the future, it would be nice to have something that is called a sustainable business model - in other words, a little bit of money keeps flowing in the future, too. That's where a subscription payment model comes in handy!

How will it work?

The model will be very simple: There's only a single subscription option, which will enable a set of extra features. Whenever a new feature is added, it may go to the "base" set of features, which are available to all users which have purchased the app. Or, it may go to the "extra" set of features, which are available with the "extra" subscription. If you have the "extra" subscription, you'll have all the features added in the future – there won't be another "pro", "enterprise", or "super" subscription required for those. No per-feature pricing, just the "base" set and the full "extra" set.

Some features going to the "extra" set will seem fairly basic to some, and they will be features that most users hopefully want to have: Messaging, beaconing to APRS-IS, iGate, long and arbitrary time range lookups, soundcard modem, etc. On the other hand, the pricing will be fairly cheap, in my opinion, when compared to the price of an iPhone or any piece of APRS hardware: less than the app purchase price per year, resulting in roughly 50 cents / month price ($0.50 USD / € 0.50). About the same price as a Panini at Starbucks, a bit more than large Caffe Mocha! Subscription period will be 6 or 12 months, and there will be a free trial period in the beginning so that you can try before you pay. I may adjust the price later to one direction, or the other, depending on how it sells.

I hope most users will want the extra set, so that even with this low subscription price I'll still get something. Apple grabs 30% of that for the first year of subscription (like it does for app purchases), and then the taxman grabs another 30-40% of what's left. You pay $6, I get less than $3, and I can buy a couple litres of milk for example. After two years I'd have enough to buy a beer in the pub. Yay.

Some folks will likely ask for a lump sum "lifetime" option for the extra features. It's not good for the sustainable business model – the purchases would end soon, at which point there is no income. Also, it's difficult for anyone to promise that it will actually work for a "lifetime", due to the need for regular maintenance and support from the developer.

When comparing prices of applications one should remember the size of the target audience. Creating and maintaining an application takes roughly as much time for 10, 1000 or 100000 users. This is why some really nice and big apps for the general public can be really cheap, or financed by in-app advertisements: 1€ per user for 100000 users would already make 100000€. This makes apps for smaller audiences (hams with iPhones and interest in APRS) relatively more expensive.

To re-iterate:

• The subscription price will be small (roughly around 50 cents / month), paid through in-app payment.
• There will be a free trial period in the beginning of the subscription, so you'll know what you'll get. Just remember to cancel it before the end of the trial; this is how Apple's subscription trials work.
• It will enable all new features in the future.
• Current features will NOT stop working or require subscription payment – the subscription is optional and you get to keep what you paid for earlier.
• Some future new features will also be included the base feature set, not requiring subscription.

aprs.fi moving to TLS

In an effort to increase security on the web at large scale, web browser vendors and other organisations such as Google are making changes which encourage web sites to move to TLS/SSL encryption. Even web sites which previously did not seem to need it – ones with static content only, and ones without any login / password functionality. This is good and fine – even if it's not a banking web site, it's good that third parties along the network can not observe or modify the content being downloaded. The Chrome web browser has started to label non-encrypted sites with an informative '(i)' symbol which warns the user that "Your connection to this site is not private", and will eventually make those warnings stronger. Google gives better ranking in the search results for https sites.

A real, practical issue right now is that the geolocation Javascript API is no longer available on non-HTTPS sites in recent Android and Chrome versions. This actually broke map center and tracking functionality on the aprs.fi web site.

I wholeheartedly support this movement, it will make the Internet a better place!

These days, with performance-improving developments such as ECDHE, GCM mode AES and hardware accelerated AES, running TLS on a web server is not much of a performance issue any more. Most of the CPU time will be spent on application logic, anyway.

The fun part is that HTTP/2, a new protocol used by modern web browser to access web sites, is only used over TLS/HTTPS – it is not available over plaintext connections. HTTP/2 is faster than older HTTP versions, and a surprising side effect is that a web site may well open up faster over HTTP/2 + TLS than over HTTP 1.1 without the encryption!

Picture not related. I just took it last summer. Kyyttö cows © Sappion luomu.

Before now, aprs.fi has only used TLS/HTTPS for its login and user account management pages. Fairly soon I will have a maintenance break on the aprs.fi servers, upgrade the operating system to the next major release, and install a new version of the aprs.fi software which supports access over both HTTP and HTTPS. To reduce duplicate content (same stuff being available over both HTTP and HTTPS) it will prefer HTTPS and nudge clients that way every now and then, but initially plaintext access should be possible, too. Later on, if there are no surprises, the nudges will gradually become stronger.

There are a few issues which need to be addressed. There are possibly a few Amprnet users accessing this site over amateur radio frequencies. On the other hand, they're then practically surfing the Internet over radio, and probably doing a few requests to other encrypted sites now and then, too, so maybe it's not a big problem for them.

Another thing is that apparently users in China can't access the Google Maps API over HTTPS, so those users would still need the plaintext access for now. I might make the zh.aprs.fi site plaintext only, and bump those users that way, or something along that way. Maybe the Amprnet users can use that, too?