Imagine you created your very first app. You developed the concept, worked tirelessly on the key features, design, tested it and fixed the bugs. The moment has finally arrived and you are ready to share your creation with the world. But how? App stores are a great tool for sharing apps with end users, but each store has its own unique requirements, upload and approval process and for some, such as the Google Play Store, you need to pay a developer registration fee and create an account including a physical address to even get started.

If you are a new developer, trying to bring your first app to market, the learning curve can feel a little steep. Once you have done it the first time, one could argue that the process feels somewhat familiar. However with each new release, each new update for your app, comes additional manual steps to follow. 

So, if you were faced with the choice of navigating the app deployment and upload process with one app store, or doing it several times over with different app stores, with unique requirements and deployment processes, what would you choose? 

For most new Android developers, the answer is simple, just get the app on Google Play and call it a day. And the reality is that the conversation often stops there for many mainstream Android app developers, feeding the monopoly and strengthening the hold Big Tech has on the market. 

F-Droid is of course an excellent FOSS based alternative for those looking for a privacy-focused, community-led app store. But we are not the only app store solution developers could choose from. So what if there was a way to open up the market for new and existing developers by creating some fair and healthy competition? What if we could streamline the app deployment process, making it easier for developers to upload their APK to multiple stores at the push of a button? Well, this is exactly what F-Droid will be focusing on creating, for our initial contribution to the Mobifree project.

User Research to Discover Pain Points and Potential Solutions

To get started we began with a series of user research interviews to gain a deeper perspective on the current challenges developers and alternative app stores have, when it comes to app deployment. We paid particular attention to various compensation models favored by the developers and explored how to incorporate easy payment options into our solution.

The results of the study were clear, developers are interested in listing their app on alternative app stores, but the app deployment and upload process to multiple stores is not straightforward. This results in a centralized market, with the majority of mainstream apps simply ending up on one app store. If we want to decentralize the market, and create more choice for developers and end users, then we need to make it easier for developers to list their app on multiple stores, streamline the update process, and consider developer compensation in our solution as well.

After successfully identifying the pain points, some market research participants pointed out a FOSS-based solution on the market that solves some of them - Fastlane. Fastlane is an open-source platform aimed at simplifying Android and iOS deployment, by helping developers automate their development and release workflow. We had already been exploring how we could potentially use a Fastlane framework for our idea, so when some of our study participants mentioned they were already implementing Fastlane tools to automate their Google Play launches and updates, we took that as a good sign.

However we noticed some limitations within the Fastlane framework. Their main focus is automating the app deployment, upload and review process for the two biggest players - Google Play and the Apple App Store. Our goal is to create a workflow that automatically deploys and uploads to multiple stores simultaneously, helping diversify the market.

In addition to Fastlane´s app upload feature, the Fastlane core team and community have created a nice list of additional plug-ins for developers to further automate various aspects of the app development, screenshot generation, testing, uploading and the updating process.

Once we begin the development process, we will have a clearer idea of how we can lean on Fastlane´s existing framework, for our own solution. 

Accounting for Financial Sustainability

Our aim is to create a solution that is streamlined and straightforward, encouraging a decentralization of the app market in general. But in order to create a solution that will be mainstream enough to make in-roads into the hold Big Tech has on the market, we need to consider how to streamline the payment processes as well, making it easy for developers receive financial compensation. Therefore, we included compensation model preferences in our interviews with developers to gain insight into their values and preferences.

When it came to preferred compensation models such as pay-to-download, in-app payments, donations or subscription-based models, it became clear that the preferred model was highly dependent on the type of app and user base. 

Some developers we interviewed noted a preference towards the old school pay-to-download approach. With this compensation model, users pay a one-time fee to download the app from an app store. The transaction occurs before the users has access to the app.

For app stores like Google Play, this is straightforward as they have their own built in licensing service where distributing and verifying license keys is handled internally and the tool is of course proprietary. 

If we want to create a solution that includes a pay-to-download option for developers who are uploading their apps to multiple app stores simultaneously, integrating with payment gateways like PayPal or Stripe can provide a straightforward approach to handle transactions externally. Users can purchase the app through these gateways and receive a download link or licensing key upon successful payment. Furthermore, to streamline the payment and licensing key distribution process, developers can leverage providers that offer unified APIs. These unified APIs simplify the integration by providing a single point of access to manage payments and distribute licensing keys across various platforms, ensuring a more efficient and cohesive user experience.

After pay-to-download, several developers pointed towards a subscription-based model preference. In this case, they cited regular maintenance and storage expenses they carry as a company, as the reason for their decision. Subscription based compensation models often include a free trial period, then after that time limit has been reached, a payment occurs. We also heard the “freemium” model being used frequently, where some features are free, while others come at a cost. Subscription based models are considered a type of in-app payment, since the transaction is usually repetitive and occurs after the app has been downloaded and installed.

Within the FOSS community, donation-based models are regularly adopted to improve access to technology, while securing financial sustainability of FOSS-based projects. Liberapay is a great FOSS-based example, providing a way to help facilitate regular, reoccurring donation payments, in a similar way to subscription model.

Open Collective offers similar services and is also FOSS-based. However, Open Collective offers more advanced financial management tools for its users, and is geared towards larger projects with more complex needs. Additionally, they are more focused on individually occurring payments, rather than recurring ones. However, this is also an option. Several developers and app stores told us that prefer in-app payment models, because it gives them more freedom and flexibility for developers and end users alike. In many cases in-app payments include an SDK which is built into the APK file. This enables in-app payments to occur. The SDK typically integrates with a payment gateway such as Stripe or PayPal or a service provider. The SDK also includes UI components for payments, supports various payment methods such as credit cards and digital wallets, and also handles the transaction management. Finally we discussed in-app advertising as a potential revenue source. There are of course inherent privacy issues with advertising models that allow user tracking, so the general consensus was that if in-app advertising models are used, they should be done so with caution. Not only are privacy and data protection founding principles for both Mobifree and F-Droid, the use of tracking-based in-app advertising poses a moral dilemma as well. If someone wants to gain access to an app, but does not have the financial means to purchase it, they can use it at a different kind of price - their user data. It should be mentioned that it is possible to include in-app advertising without user tracking. However the lead conversion ratio drops dramatically, so the efficacy of this approach is not nearly as high. 

Making sense of it all

At the end of the day, finding a streamlined approach for app distribution that considers diverse compensation model options for developers and users is a tall order. However motivation and support for the concept is high, from both Mobifree partners, F-Droid contributors and the FOSS community in general.

We are looking forward to taking you on the journey with us as we break ground on this project in the coming months. Stay tuned to our blog for future updates and if you would like to contribute to our project, feel free to reach out at mailto:team@f-droid.org.