Delta Icons: a pastel vector icon pack for Android, in three build flavors

What Delta Icons is: an icon pack that is also an app

Delta Icons is an icon pack for Android, and the repository is called Delta-Icons/android with a homepage at delta-icons.github.io. The repository description is short, an icon pack for Android, but the package identity tells you more: the Play Store entry is published under the application ID website.leifs.delta, and the F-Droid entry under website.leifs.delta.foss.

The distinction between an icon pack and an ordinary app matters on Android. An icon pack has to be installed and applied before the launcher will use it, and the pack needs an application of its own to carry the artwork and to hand the launcher the icon mapping. That is why the project ships as an app rather than as a loose folder of PNG files.

The design direction is visible in the repository topics, which include pastel-colors and vectors alongside icon-pack, android, customization and f-droid. Vector artwork is the more consequential of those two. A vector icon scales to any density without resampling, which matters on the wide range of screen sizes and font scales an Android device can be set to, and it is why an icon pack like this can look sharp on a device the author never tested.

The repository also carries a hacktoberfest topic, which tells you the artwork is community contributed rather than drawn by a single designer. That fact has consequences for consistency and for the licence question below.

Three flavors with three application IDs

The README lists the build flavors explicitly, and each one is a separate application with a separate ID.

The gplay flavor is the Google Play version. The foss flavor is described as the FOSS version, Google-free. The fossdc flavor is the FOSS version with a dynamic clock. The identifiers follow that scheme:

website.leifs.delta
website.leifs.delta.foss
website.leifs.delta.fossdc

Why the separate IDs rather than one app with a setting? The answer is stated in the README and it is practical rather than ideological. The fossdc build replaces the static clock icon with a dynamic one, and dynamic clocks require a higher level of Android API and are not widely supported in launchers. The author explains the reasoning directly: the aim is to support the feature without sacrificing users on old phones, which is exactly what shipping it inside the same application would do, because installing the icon pack would force the higher API requirement on everyone.

So the split is a compatibility decision made on behalf of users. The cost is that the dynamic clock lives in an app you have to install separately, and that it is distributed through a different channel from the other two.

Where the dynamic clock variant comes from and where you can get it

The fossdc flavor is only available from the Releases section on GitHub, which the README states explicitly. The other flavors are distributed through the usual app stores, and the README links each of them.

The Google Play build is linked through the Play Store listing for website.leifs.delta. The FOSS build is linked through F-Droid, under website.leifs.delta.foss. Obtainium links are provided for all three, each one carrying a filter regular expression that selects the right APK flavour from the GitHub release assets, plus for the fossdc entry an apkFilterRegEx that matches the dynamic clock build and a description of it as the FOSS flavor with a dynamic clock.

There is also a separate section of beta links, tucked behind a collapsible summary in the README. The beta Obtainium entries add an includePrereleases setting and extend the APK name filter with a beta marker, so a user who wants to try an in-progress build can have Obtainium pull the pre-release asset rather than the stable one.

The naming scheme the filters rely on is visible in those URLs. Release assets follow the flavour, the version and a build number, in the shape delta-gplay for the Play build, delta-foss for the FOSS build and delta-fossdc for the dynamic clock build, each followed by the version digits and an APK extension, with the beta assets carrying an extra beta marker in the name.

That structure matters because Obtainium and F-Droid both work by watching a release feed and picking the asset that matches a pattern. Change the naming scheme and the automatic updates stop.

What the repository tree contains

The top level of the repository shows a conventional Gradle Android project with some extra directories that give away how the artwork is managed.

The app/ directory holds the application module, and the build is driven by build.gradle with settings.gradle, gradle.properties and the bundled Gradle wrapper scripts gradlew and gradlew.bat, so a build does not depend on a Gradle version already present on the machine. The gradle/ directory holds the wrapper configuration.

resources/ is the directory that matters most for an icon pack, since that is where the artwork and the launcher metadata live. metadata/ holds the descriptive files that stores and the F-Droid repository read, which is how the same project appears with the right title, description and screenshots in the Play Store, in F-Droid and in an Obtainium entry. contribs/ is there for community contributions, which lines up with the hacktoberfest topic and with a pack that keeps growing.

There is also CONTRIBUTING.md, which is the file to read before submitting artwork, and .github/ for the workflow configuration. The .idea/ directory shows the project has been opened in IntelliJ-based tooling.

One oddity in the repository metadata is worth noting for anyone searching for this project. The primary language recorded for the repository is Python, while the tree is a Gradle Android project. The Python classification does not describe the application itself, and it is a reminder that the language field in repository metadata is an automatic classification rather than a description of what you will be building.

The licence question, which is the part to read first

The repository does not use a licence that GitHub can classify. The licence field records a custom licence with a pointer to the LICENSE file, and the file itself is LICENSE.md at the root of the tree.

For an icon pack this is more than a formality, because the thing being licensed is artwork. A pack that ships thousands of individual icons has contributors with different expectations about attribution, reuse in other projects, modification, and whether the icons can be redistributed in a commercial product. A permissive open source licence answers those questions by default. A custom one answers them in whatever way the author chose, and you cannot know the answer without reading LICENSE.md.

The README also notes that the author is open to discussing uses that the licence does not cover, which is a reasonable signal but not a permission. Until you have read the file and know what it grants, treat the artwork as not licensed for reuse.

This matters more for an icon pack than for a typical library. A dependency is usually consumed indirectly, while icon artwork gets copied into screenshots, themes, wallpapers, tutorials and derivative packs, which is exactly the range of uses a licence has to anticipate.

Limits: launcher support, beta churn and the absence of a support policy

Three constraints are visible in what the README documents.

The first is launcher support for the dynamic clock. The README is explicit that dynamic clocks require a higher level of Android API and are not widely supported in launchers. On a device whose launcher does not implement dynamic icons, the fossdc build installs and works, but the clock will not animate. That is a feature that degrades quietly rather than announcing itself, so it is worth checking your launcher before installing the more awkward of the two FOSS builds.

The second is release churn. The tagged releases are v2.20.0 on 2026-10-01, v2.21.0-beta.1 on 2026-10-11 and v2.21.0-beta.2 on 2026-10-18, and the last push to the repository was on 2026-10-18. Development is clearly current, but two of the three most recent tags are betas, and the README provides separate beta links with pre-release filtering. A user following the beta channel will get a new build every week and should expect the icon set to shift between versions.

The third is documentation. The README covers downloads, the flavors and the distribution channels, and stops there. There is no changelog, no migration guide and no stated support policy for older Android versions beyond the dynamic clock note. For an app that people install onto a personal device and then forget about, that is a reasonable amount of documentation, but it does mean you will be reading the release notes on GitHub rather than a manual.

For comparison, the F-Droid listing is the most conservative choice available: it tracks the stable FOSS build, it carries a separate package identifier from the Play version, and it is the channel least likely to change underneath you.

Editorial conclusion

Install Delta Icons if you want a coherent pastel icon set on an Android device and you prefer a vector pack over a raster one, and pick the gplay flavor if you are comfortable with the Play dependency or the foss flavor if you are not. Do not expect the dynamic clock in the fossdc build to work everywhere, since it needs a higher Android API level and launchers that do not support it will simply not show it. Verify first which launcher you use supports dynamic icons, and read LICENSE.md before you repackage or redistribute any of the artwork.

Frequently asked questions

Official sources

1. Delta-Icons/android on GitHub
2. Issues
3. Project website
4. README
5. Releases