Skip to content

FAQ

How does the IzzyOnDroid Repo differ from F-Droid's Repo?

Apart from what is already outlined on the landing page:

F-Droid IzzyOnDroid
App Source compiled from sources provided by the app's dev team APK provided by the app's dev team
Signature signed by F-Droid or, when reproducible builds were established, by the app's dev team4 signed by the app's dev team5
Updates usually within 3-5 days of their release usually within 24h of their release
Trust build process takes care that the APKs correspond to the source code (including checks for possible „suspicious stuff“ that might be „dragged in“; manual signing as well as manual intervention on „failed builds“; reproducible builds (where established) show neither side was "sneaking things in" multiple checks against the provided binaries6, checks with VirusTotal against malware, Reproducible Builds7

Why are some apps available in both repos?

This can have multiple reasons. Some are:

  • app updates happen at a faster pace than F-Droid builds, so for „early birds“, testers and „version junkies“ (oops) it was decided to keep them at IzzyOnDroid
  • due to some difficulties, an app might be (temporarily) unable to be built/updated at F-Droid
  • authors decided to provide their pre-releases with IzzyOnDroid (for testers and „curious users“), while shipping the „stable releases“ with F-Droid
  • for some other reasons, authors decided so (e.g. to make it easier for folks using their apps to „switch over“ from Play Store)
  • for again some other reasons (or the same), we decided so (ui…)
  • why not?

If it's all FLOSS, why there are apps in your repo which are not at F-Droid?

Often comparable reasons:

  • inclusion process at F-Droid.org is stuck, e.g. due to build issues
  • some non-FLOSS dependency (which is among those tolerated at IzzyOnDroid) „sneaked in“ and prevents inclusion/updates at F-Droid
  • some apps simply cannot be built by F-Droid for various reasons (like requiring some GUI process for building, or keys which are not part of the source tree)
  • authors decided they want their app at IzzyOnDroid for other reasons

How can I get my favorite app listed there?

The preferred way is to file an issue. Of course, first make sure the app you wish to add isn't already there. Then, also check it meets the requirements in our Inclusion Policy.

How do get apps updated at IzzyOnDroid?

Our update checker runs daily, walking the source repositories of the apps listed here, looking out for new releases. Usually, apps at IzzyOnDroid are set up with tagged releases for updates. So whenever developers tag a new version, create a release for it, and attach the APK to the new release, our update checker should pick it up within 24 hours from the time the APK was attached.

Note that when the source repository of an app was inactive for a longer period (usually about a year), the app may get „demoted“ to our monthly cycle (to save resources: no use to check daily on repositories having fallen dormant). It will be „promoted“ back to the daily cycle once activity picked up again (and new releases have become available).

And what about app metadata?

For app description and graphics (icon, featureGraphic, screenshots) we strongly suggest developers establish Fastlane structures in the repositories of their apps. They are the ones knowing best which parts need updates – and contributors could help there via pull requests. Those Fastlane trees would then get synchronized whenever a new release is being pulled in.

Other metadata (author name/email, website, URLs for repo, issue tracker etc) are part of the setup at our end, and would currently require reaching out to us to make changes where needed. This will hopefully change soon™, though, when the corresponding metadata files become available via their own git repo, and changes can be performed via pull requests here as well.

Are apps removed from the repo – and when does that happen?

This indeed is the case, and usually happens when the inclusion criteria (see above) are no longer met. So this is especially the case when an app…

  • can no longer count as „free/libre“ (e.g. the license changed, or too many non-free dependencies have been added)
  • started downloading additional binaries without the explicit and informed consent of the user (e.g. by integrating a self-updater that is not strictly opt-in and/or does not clearly outline its implications)
  • is reported (with evidence) for malicious behavior
  • is no longer maintained and reported to be no longer working
  • exceeds the alotted space with no means of remediation (a possible remediation often is switching to a per-ABI build, see the next question on size limits)

Note that becoming available in another F-Droid Repo (e.g. at F-Droid) no longer means it will be „automatically removed“ here. If the size of its APK files stays well inside the limits outlined above, it will usually be kept.

Why is there a size limit for apps?

„Come on, you get a 2 TB disk for less than 100 bucks at Mediamarkt!“ That might be – but ever tried asking the server admin to attach that to the server? Consumer disks are not accepted there. Besides, it’s not just storage, there's much more to it: there's e.g. the transfers between staging, server and mirrors. You need the storage not only once, but multiple times. Then, we send all files through multiple scanners – not all of them are „local“, some of them are „somewhere on the net“. And some of them have API limits. Parts of our services still run on „personal space“, not having gigabit connections to the internet.

We’re working hard on a restructuring here, but that’s a lot of work and will take some time, so no ETA for completion in sight yet. The limit will certainly be increased at one point (as it was increased in the past). But we cannot promise how soon that might be.

The limit isn‘t all bad, though. People don’t always have an eye on the size of their app. So they often only get aware of that when hitting a limit – and then start optimizing. It's no rare case that a 50 MB APK suddenly drops below 30 MB – which then is a win for all. And in rare cases, we indeed do make exceptions – though those must be well reasoned.

Why is there only a single architecture available for some apps?

Some apps are only available with e.g. their arm64 or armeabi variants, though their developers also serve other architectures. This is due to size limitations (see previous question), and happens when the „fat build“ (i.e. the one holding multiple architectures in a single APK) would not fit the per-app size limit1. At this point we need to decide which ABI to take:

  • if it's a niche app (i.e. one not having good alternatives), or especially useful for older devices, we pick armeabi (the 32bit variant) – as our repository strives to help keeping older devices useful as long as possible (keyword: sustainability) and most 64bit devices still support 32bit APKs (exceptions are still very few) – while the opposite can not be said (a 32bit device naturally cannot support 64bit APKs).
  • otherwise, we pick the arm64 (64bit) variant2

If you think the other arch of an app should be here instead of the one that is here, please clarify that with the app developers first. We usually follow their decision on this, and won't switch architectures against their will. And before you ask: architectures other than armeabi and arm64 currently won't be supported here except as part of a „fat build“ including ARM as well.

I'm just a simple, not tech-savy user, how can I support you?

True, there's much time we spend on my open source projects, and server costs have to be considered as well. So if you're just a happy user looking how you can give some „backing“ – you're very welcome to support us at our OpenCollective. Apart from that, support is always welcomed with

  • improving app descriptions / providing missing screenshots3
  • reporting missing/wrong URLs (e.g. if an app's repo moved, or a website/changelog was added)
  • finding and reporting good apps matching above criteria so they can be added
  • reporting „violating” apps as well as such that no longer work so they can be removed
  • filling gaps in the library details

If you’re going on a hunt to report a bulk, please open one issue per app so it will be easier to process. But even if you by accident stumble on a little thing to be improved, your report will be welcome!

  1. This most often happens to apps written using frameworks like Flutter or React Native, as they need to contain „native libraries“ to have Android support those. ↩

  2. with 32bit-only devices getting fewer and fewer, the focus more and more goes towards 64bit here, though ↩

  3. this is ideally done in the app's repository, using Fastlane structures; if needed, we can help there ↩

  4. unless the app was built using „reproducible builds“, cross-updates are not possible ↩

  5. cross-updates are possible; you can e.g. switch to updates from IzzyOnDroid if you originally installed from Play Store or the developers site. Signatures are always pinned at IzzyOnDroid, see Signing Keys here on the website, and Certificates and Signing in our blog ↩

  6. see APK Scans here on this website, and Ramping up security: additional APK checks are in place with the IzzyOnDroid repo in the blog for details ↩

  7. see Reproducible Builds here on our website, and for more also Reproducible Builds, special client support and more in our repo in our blog ↩