Appteka is an open source Android store whose central question is who you trust

A store where the catalogue comes from the users

Appteka is described as a free, open-source Android app store where users can discover, download, and share applications, and the README spells out the model in one sentence: upload your own apps, explore creations from developers worldwide, and engage with the community through real-time discussions.

That is the defining characteristic. Most app distribution for Android runs through a gatekeeper with a review process, a developer account and a signing requirement. Appteka removes the gatekeeper and replaces it with a community, which moves the risk from the platform to the person installing.

The feature list is a typical store's feature list applied to that model. Browse and download, with the README claiming hundreds of thousands of free Android apps. Upload your own applications. An APK extractor that pulls APKs from installed apps, including system apps. Real-time chat for discussing apps and games. User profiles that track uploads, downloads and activity. Ratings and reviews, favorites, a full dark theme, and an explicit no root required line, which tells you the extractor works on an ordinary device rather than requiring a rooted one.

The application is distributed three ways: through appteka.store, through IzzyOnDroid under the package name com.tomclaw.appsend, and as an APK from the GitHub releases page. That last one matters for anyone who wants to read the code before installing it, and it is also how a self hosted or fork deployment would start.

The architecture is MVP inside Clean Architecture

The README describes the architecture as Clean Architecture principles with the MVP pattern, and then lists the layers, which is the most useful part of the document for a developer considering a fork.

The Activity or Fragment acts as a router and implements the navigation interface, which is the standard way to keep Android framework types out of the layers below. The Presenter is the presentation layer and is framework-agnostic for easy testing. The View is pure UI rendering with no business logic. The Interactor holds the business logic, uses the repository pattern and does the data caching. The Converter does the data mapping between layers, and the ResourceProvider gives the framework-agnostic layers access to Android resources.

That last piece is the one that distinguishes a serious implementation from a folder structure. A View and a Presenter that are free of Android types can be unit tested on the JVM, and the ResourceProvider is the seam that lets them ask for a string without importing the framework, which is exactly the kind of arrangement that makes a test suite cheap.

The presence of both Clean Architecture and MVP is worth noting without treating it as a contradiction. The two are often used together, with Clean Architecture supplying the layering of domain, data and presentation and MVP organising the presentation layer into view, presenter and interactor. The naming here is a little unusual, since the interactor sits inside the MVP list, but the effect is the same, a core that can be tested without an emulator.

A conventional modern Android stack

The tech stack table is the kind of list that tells you the age and the intent of a project without much prose.

The language is Kotlin, with a badge for Kotlin 2.3, and the minimum platform is API 23. The user interface is Material Design 3 with AndroidX. Dependency injection is Dagger 2, the reactive layer is RxJava 3 with RxKotlin and RxRelay, and the networking is Retrofit 3 with OkHttp 5. Image loading is Simple Image Loader, and the RecyclerView handling is Konveyor. The build is Gradle with ProGuard.

Every one of these is a current choice for a new Android application, and none of them is unusual, which is the point. A community store that wants people to build clients for it, or to fork and run their own, needs a stack that a developer arriving today will already know.

Two of the entries are worth a second look. Simple Image Loader is a deliberately small library rather than one of the large general purpose image loaders, which suits an application that shows a lot of app icons from a remote catalogue. And Konveyor for RecyclerView is a Kotlin-native alternative to the traditional Android list approach, with the usual trade that the list behaves slightly differently from the platform default and that a developer expecting the platform behaviour has to learn the difference.

The repository also carries an .abstruse.yml file, which is the configuration for Abstruse CI, so the build runs on continuous integration, plus a fastlane/ directory for the store listing and screenshots, and a gradle/ directory with the wrapper.

Building it takes a recent Android Studio and a signing config

The build requirements are specific enough to plan around: Android Studio Ladybug or newer, JDK 17, and an Android SDK with API 37.

The build itself is the standard Gradle wrapper invocation:

# Clone the repository
git clone https://github.com/solkin/appteka-android.git
cd appteka-android

# Build debug APK
./gradlew assembleDebug

# Build release APK (requires signing config)
./gradlew assembleRelease

And the output lands in app/build/outputs/apk/.

The comment on the release target is the important line, because it is the step that separates a build you can run from a build you can distribute. A release APK requires a signing config, so anyone who forks this to run their own catalogue has to supply their own key, and the key is what makes an APK installable and updateable. A fork that changes the package identity, which a self hosted store would, is installed as a different app rather than as an update of the original, and a user has to uninstall the other one first.

The gradle.properties, settings.gradle and build.gradle files at the root are the places where the application id, the version and the build variants are decided, and they are the files to look at first for a deployment that differs from the official one.

Nine languages and an open contribution path

The localisation table lists nine languages, with English as the default and the codes for Russian, Arabic, Chinese, Farsi, Hindi, Kurdish, Brazilian Portuguese and Vietnamese.

That list is a better indicator of who uses the platform than any feature description, and it lines up with the community channels. The project is run by the Appteka team, the copyright statement runs from 2016 to 2026, and the README asks for contributions in four specific forms: reporting bugs and requesting features through issues, submitting pull requests with improvements, helping with translations, and improving the documentation.

The release history fits the same picture. The versions are v22.0 on 2026-07-27, v22.1 on 2026-07-28 and v23.0 on 2026-08-13, so a major version every few weeks with a patch following immediately, and the last push to the repository was on 2026-10-12.

For an adopter, the practical consequence is that a fork is a supported way to run this, rather than an unsupported hack. The code is GPL, the build is a Gradle wrapper invocation, the localisation is already set up for nine languages, and the store listing and screenshots are managed with fastlane. What is not in the repository is the server side, since the catalogue, the accounts, the chat and the antivirus scanning all sit behind the API that the client talks to.

The trust problem is the real design issue

The Security and Disclaimer section is the part of the README to read twice, and it is unusually direct.

All uploaded applications are automatically scanned by a built-in antivirus system powered by three independent antivirus engines. So the platform does not simply accept whatever is uploaded and let it be. And then the disclaimer: Appteka is a community-driven app exchange platform where users can freely upload applications, and the Appteka team is not responsible for user-generated content. While security scanning and content moderation are in place, the advice is to take appropriate safety precautions, verify the source, and check reviews and ratings before installing.

That is an honest description of a risk that cannot be fully engineered away. Three scanners and a moderation process reduce the probability of a malicious upload, and the project does not claim more than that. The liability is placed on the person installing, and the mechanism for that is the community layer, which is why the ratings, the profiles, the download counts and the real-time discussion are not decoration but the actual trust infrastructure of the store.

The alternative to a community catalogue is the curated model, where a small number of publishers submit through a review process and the platform is accountable for what it serves. The difference in approach is that the curated model shifts the verification cost to the operator and the community model shifts it to the crowd. The first is slower and more predictable, the second is faster and puts the judgement on the user, and the README's own warnings are the clearest statement of which one this is.

The store also publishes a terms of service, a DMCA policy and a contacts and donations page, which is the minimum a platform that accepts arbitrary uploads from the public needs to have in place.

Editorial conclusion

Appteka suits a developer who wants to publish an Android application without a store account, and a user who prefers a community catalogue run by people they can see, and who is comfortable judging an app from its reputation on the platform. It does not suit an organisation that needs a curated, signed and centrally accountable source of applications, and it is the wrong choice for a device where an untrusted APK would be unacceptable. Verify first how the antivirus scanning of uploads is configured in your own deployment, read the terms of service and the DMCA policy before hosting content, and expect that the trust burden of a community store lands on the person installing, not on the platform.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. solkin/appteka-android on GitHub