Contents

A Road Behind, A Road Ahead

Three months ago, we published an update on our development progress as well as our roadmap for the next three months and beyond. Now that those three months are over, we want to share the development progress we’ve made in that time, the impact it has on Accrescent going forward, and our next priorities as we shift into a new development cycle.

Progress update

App store API

The first task on our roadmap was developing and migrating to the directory service, or as we now refer to it, the app store API — a massive overhaul to how Accrescent finds apps, calculates app compatibility, fetches app information, and checks for updates. This task has been completed successfully, and while it took longer than expected to implement, we believe that taking the additional time necessary to implement it correctly has resulted in a robust solution that is well-designed and built to last long into Accrescent’s future.

But what does this actually mean for Accrescent? In short, there are three main outcomes: features, stability, and extensibility. We’ll address these one-by-one.

Features

First, the app store API enables a large number of features out of the box which were previously unsupported by Accrescent. These include:

  • Proper app compatibility checks: Accrescent used to detect app compatibility based on only very limited information such as device architecture and screen pixel density, meaning it would sometimes incorrectly determine an app was compatible with a device when it was not, resulting in obscure errors. The app store API takes all1 compatibility specifiers into account, including but not limited to the following, ensuring Accrescent always correctly determines whether an app is compatible:
  • Install-time asset pack support: Accrescent previously had no support for asset packs, meaning that many apps — and games in particular — could not be distributed on Accrescent. The app store API provides support for asset packs with the install-time delivery mode, enabling games and other apps using install-time asset packs to distribute on Accrescent.
  • Install-time feature module support: Accrescent previously had no support for additional feature modules beyond the default, meaning that complex apps containing multiple modules couldn’t be published to Accrescent. Through the app store API, Accrescent now supports feature modules with install-time delivery, expanding Accrescent’s compatibility with multi-module apps.
  • Conditional delivery support: Further broadening Accrescent’s multi-module capabilities, the app store API also supports conditional delivery, so apps on Accrescent can now have features conditionally installed based on device API level and hardware and software features. Please note that country targeting and fine-grained device targeting are not yet supported.

At Accrescent, we believe that alternative app store users and developers shouldn’t have to settle for fewer features than Google Play. And with our new app store API, we’ve made a significant leap in closing the gap between Accrescent’s and Google Play’s feature sets, making advanced app store features accessible to the open source community.

Stability

Second, the app store API marks a significant milestone for Accrescent: a stable API. Until now, Accrescent’s API has been subject to breaking changes, meaning that we would occasionally change how Accrescent worked in ways that would break older Accrescent installations and third-party integrations if they weren’t updated regularly2. But with the new app store API, we’ve committed to stability using Semantic Versioning rules, meaning both that 1) old Accrescent versions will continue working for a very long time and 2) developers can develop third-party clients and integrations without fearing breakage. And to provide even stronger guarantees, we’ve added protovalidate annotations to clarify the API contract and Buf to our CI to ensure breaking changes never make it to production.

A stable API is a mark of maturity for any project, and we believe that offering a stable app store API for Accrescent demonstrates our commitment to making Accrescent a production-ready, stable solution for app distribution on Android.

If you’re a developer interested in using Accrescent’s API, you can find our API docs on Buf and start using the generated SDKs. Or if you’d rather generate the code yourself, you can use our API schema on GitHub freely under the Apache 2.0 license.

Extensibility

Finally, the app store API offers a crucial property for expanding Accrescent in the future: extensibility. The app store API is defined using protocol buffers, an extensible serialization format that allows us to easily add new APIs and change existing APIs without breaking backward compatibility. This property ensures the app store API is future-proof, enabling us to add new features in a backward compatible way, e.g.:

  • Localized app listings
  • Long descriptions
  • App screenshots
  • Delta updates
  • Release channels

and more. For example, below is a sample of the API schema defining an app’s package information. More information can be added in the future without breaking backward compatibility.

// Package information for a given app.
message PackageInfo {
  // The app's version code.
  optional uint64 version_code = 1 [
    (buf.validate.field).required = true,
    (buf.validate.field).uint64.gt = 0
  ];

  // The app's human-readable version name.
  optional string version_name = 2 [(buf.validate.field).required = true];

  // We can add new fields safely! For example:
  // optional string some_new_field = 3;
}

By designing our API to be extensible from the start, we’re ensuring that we can continue innovating and using the app store API far into Accrescent’s future without being held back due to backward compatibility constraints.

App overhaul

Our original plan three months ago was to add more app-visible features after the directory service / app store API migration was complete, e.g., long descriptions, localized app listings, and app listing screenshots. However, we realized at this point in development that the Accrescent app itself was in need of a serious refresh; there were over a dozen unresolved bug reports including unexpected crashes, various UI bugs, and a handful of requested features which had gone unimplemented. So instead of continuing with adding more app-visible features, we instead decided to overhaul the Accrescent app to resolve all known bugs, add a bunch of new features, and enhance its UI to be more snappy, correct, and informative.

This overhaul was a major success, closing 25 GitHub issues, adding ~20 new features, fixing 16 reported bugs along with other unreported bugs, and implementing multiple miscellaneous enhancements to Accrescent’s UI and installation logic. As a result, Accrescent is now faster, smoother, more robust, and more featureful than ever before, laying a solid foundation for future development. If you want to see the full list of changes, see the GitHub release pages for Accrescent 0.27.0, 0.28.0, and 0.28.1.

/posts/road-behind-road-ahead/closed-issues-sample.png
A small sample of GitHub issues closed in the Accrescent app overhaul.

While the app overhaul did delay some anticipated short-term roadmap items such as more detailed app listings, we believe that prioritizing a correct and long-term sustainable codebase was the right move and will drastically benefit development in the future just as it benefits users today. In fact, since the overhaul, we’ve already been able to implement a few new features and fix new bugs at a much faster rate than before.

What’s next?

The app store API migration and Accrescent app overhaul have resulted in many immediate benefits for Accrescent users. They further set the stage for future Accrescent feature additions by providing a solid app codebase to build on and an extensible API with backward compatibility guarantees. However, while directly benefiting users installing apps from Accrescent, our most recent work has not resulted in many improvements for app developers. Therefore, our next development cycle will be focused primarily on improvements for developers who publish their apps to Accrescent. We plan on working on three major projects: an app publishing API, an Accrescent CLI, and a new app publishing format we tentatively call a reproducible app bundle.

App publishing API

The most frequent feature request we receive from app developers by far is an app publishing API. For some background, app developers on Accrescent currently have to upload app updates manually through the Accrescent web console. While straightforward, this process can be cumbersome especially for developers working on a team or making frequent app releases. Providing an app publishing API would enable developers to submit app updates to Accrescent automatically in their app publishing pipelines or with custom bots or scripts, reducing developers’ maintenance burdens and making it much easier for them to provide their apps on Accrescent.

We plan to develop several pre-release versions of an app publishing API for developers to test and provide feedback on before eventually committing to a stable API.

Accrescent CLI

To help app developers and others interact with Accrescent resources, we plan to develop an Accrescent CLI as the first item of our developer tool suite. This CLI will be initially developed to facilitate use of the app publishing API, giving Accrescent app developers a simple tool that will allow them to manage their apps on Accrescent without needing to make API calls directly.

As developer needs grow, we plan to expand the capabilities of the Accrescent CLI to include app packaging, Accrescent client simulation, and other features.

Reproducible app bundles

Accrescent currently accepts app uploads in a file format called an APK set. This behavior allows us to accept developer-signed apps, ensuring that even if Accrescent’s servers are hacked, Accrescent can’t serve malicious app updates — unlike other app stores such as Google Play and F-Droid 3. However, the APK set format has some notable issues, namely:

  • Developer unfamiliarity: App developers are not accustomed to interacting with APK sets directly. Most are instead familiar with app bundles, which are used by Google Play, and monolithic APKs, which are used by most other app stores. Developers have to use Google’s bundletool command-line tool to generate APK sets, requiring them to install and learn additional tools that are not required by other app stores.
  • Large size: APK sets can sometimes be much larger than their corresponding app bundles, especially for apps designed to work on older versions of Android. This size can be a hinderance to app developers by costing them time and bandwidth and making app uploads more likely to time out.

To resolve these issues, we have put together an initial design for a new app publishing format we tentatively call a reproducible app bundle. This publishing format would have all of the benefits of app bundles (such as developer familiarity and smaller size compared to APK sets) while preserving developer signatures, keeping Accrescent’s security properties intact. It would also be vendor-neutral, enabling other app stores and developers to adopt it as their app publishing format.

We plan to finalize this new publishing format, implement libraries which support handling it, and integrate support for it into Accrescent’s servers, app publishing API, and CLI.

Conclusion

Accrescent has been making steady progress in the last few months. While priorities shifted from what we originally expected, the result is that Accrescent now stands on an even stronger foundation than before. We introduced a stable app store API, added tens of features, and fixed all known app bugs to bring a stable app store experience to our tens of thousands of users worldwide. And now we plan to continue that work by improving the experience of our app developers one step at a time, building an open source app distribution platform they can rely on for years to come.

But we can’t do that work alone. Accrescent is free and open source, and it is possible only because of donations from our generous supporters. We owe our thanks to the 187 current and past GitHub Sponsors and many cryptocurrency donors who have made this work possible as well as our enthusiastic community. So to all of our supporters: thank you!

If you like what you’ve seen in this blog post and want to help us do more, please consider visiting our donation page and supporting us; every dollar helps. If you can’t donate but still want to help, share this post with others to spread the word. You can always email sponsor@accrescent.app with donation questions or for other sponsorship arrangements.

You can be sure to catch future Accrescent updates on this blog or on our social media accounts. And until then, you can be sure we’ll be working hard to bring even more features, stability, and rock-solid design to Accrescent, the open source community, and the Android app ecosystem as a whole.


  1. That is, all technical compatibility specifiers. There are ways to specify an app as incompatible for non-technical reasons such as geographic locale, but Accrescent does not yet support these. ↩︎

  2. In practice, this was done only a few times in the four years Accrescent has existed. ↩︎

  3. F-Droid reproducible builds are an exception. However, the majority of apps on F-Droid do not support reproducible builds. ↩︎