ubuntu-appstore-developers team mailing list archive

[Joshua Strobl <truthfromlies@xxxxxxxxx>]

Hello everybody,

I am developing an Ubuntu Touch app as part of the latest showdown and I
have a question regarding payment policies for Ubuntu Touch applications.

After attending the latest dev week session regarding updates to the
Software Store / App Store (thanks Martin), it was brought to my
attention that the Store currently has no paid apps implementation,
although it is something that's being worked on.

My question is: What is Canonical's policy on Ubuntu Touch applications
that may be listed as free (even if advertised as non-free in the
description) that have a method of in-app purchase to essentially
"unlock" the app.

My personal scenario: I am currently developing a service that stretches
across the mobile and desktop market, with data synchronized via an
internal centralized server. This is, in a sense, a paid service, as the
user must pay either per-month or per-year for access to the service
(think of it like Netflix, the app itself is free but you need a Netflix
account and pay for the service).

The payment system IS NOT implemented through the carrier or stores like
the Google Play Store, since there simply isn't a server-side callback
feature on every mobile OS platform to send data that an app purchase
has been made, so it is done through third-parties like Dwolla, Google
Wallet, etc (although if the majority of mobile OS stores had the
callback functionality I might be more willing to use it).

So, the question I pose to Canonical / App Store Developers is: Is there
a policy in place (or to be in place) that disallows developers to list
their application as free, disallows in-app purchases to "unlock" the
app in a sense, and if there is such policy, what are the expected
ramifications for companies like large companies like Netflix that may
want to use third-party payment providers and/or NOT require the
individual to pay for the app (since a single-purchase method poses
issues for subscription-based services). IF there IS NOT a policy in
place, can developers like myself get the go-ahead to implement in-app
purchasing with third-party services so long as we clearly indicate in
the app description the need for an account, subscription, etc? Or can
we get some sort of assurance that some server-side callback feature
will be implemented (if it doesn't exist already, as a new UT developer
I don't know all the details) so when an end-user purchases our app, we
immediately get a server-side POST callback with the necessary
information to appropriately set up the user account on our own services.

Thanks,
Joshua Strobl