# DioHub: an unofficial GitHub mobile client built in Flutter

> DioHub is a community-built GitHub client for phones, written in Dart with Flutter and published under GPL-3.0. It covers issue and pull request timelines, code browsing, search and deeplinks, but it is a single-maintainer project whose public builds are development releases, which shapes who should install it and who should build it from source.

**namanshergill/diohub** — An open-source unofficial GitHub mobile client, that aims to deliver the ultimate GitHub experience on mobile devices.

- Repository: https://github.com/namanshergill/diohub
- Website: https://github.com/NamanShergill/diohub
- Stars: 981 · Forks: 43
- Language: Dart
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/namanshergill-diohub

## A third-party GitHub app and what unofficial actually means here

DioHub exists because the mobile experience GitHub ships for phones leaves something to be desired for people who live in their repositories. The README describes it as an open source unofficial GitHub mobile client built to deliver what it calls the ultimate GitHub experience on mobile devices, and the repository is a Dart and Flutter project with platform folders for android, ios, linux, macos and windows.

The word unofficial is doing real work in that description. It means the project is not affiliated with GitHub, it is not published by GitHub, and it depends on GitHub's own interfaces, in this case through the GraphQL API, to function. The repository topics list graphql, and the top level contains a .graphqlrc.yml file and a dependencies directory, which is consistent with a client that consumes a GraphQL schema rather than only the REST endpoints.

For a user, that has two consequences. The first is that there is no support relationship with the platform: when GitHub changes an API field, the client breaks, and only the DioHub maintainer can fix it. The second is that the app works with your account credentials. The build instructions require registering a GitHub OAuth application, which means the app authenticates as you and holds a token scoped to whatever the app requests. That is standard for a third-party GitHub client, and it is also the reason an unofficial client deserves the same scrutiny as any other app you grant repository access to.

The README is direct about the project's own pace. Asked whether the project is dead, the answer is no, with a large update in progress, slow because the author works on it in his free time, and an expectation of a few development releases in the coming months plus a full Play Store and App Store release once everything is ready.

## What the app covers and where its coverage stops

The feature list in the README is the best available description of what the client does, and it is a longer list than a casual look at the screenshots would suggest.

The centre of gravity is review work. There are comprehensive timelines for issues and pull requests, with the ability to view and reply to review comments, which is the part of GitHub that most web clients handle badly and the part that a native app can improve on with push notifications and offline drafts. Repository information is fully accessible, including pinned issues and issue templates, so a contributor can see what a project expects before opening anything.

Search gets attention too, with context based filter suggestions and query helpers. The app also handles GitHub deeplinks completely, so a link shared into the app opens the right repository, issue or pull request rather than a browser tab. Code browsing supports browsing at a specific commit, viewing the commit history of a single directory, and syntax highlighting. There are commit and patch viewers, a user and home activity timeline, and full GitHub Flavored Markdown rendering.

Two features are worth a second look because they are where implementations are usually partial. The first is theming, with a completely customisable colour palette and fonts that can be shared between devices, which is more of a design investment than a hard feature. The second is caching, described as caching for partial offline support. Partial is the operative word. The README does not claim full offline operation, and it does not describe a sync model, a conflict resolution rule or a cache size limit, so the honest reading is that recently viewed content is available without a network connection while writes still require one.

The roadmap points to a feature roadmap issue and a deeper README as the next documentation steps, which tells you the current README is treated as a draft by its own author.

## Building from source: Flutter, submodules and a GitHub OAuth app

The build path is documented and requires a few things that a normal user of an app would never touch. The first step is installing Flutter, and the second is creating a GitHub OAuth application whose authorization callback URL is set to the custom scheme the app registers:

```text
auth.felix.diohub://login-callback
```

The repository uses Git submodules, so the checkout needs them initialised before anything will compile:

```bash
git submodule update --init
```

Credentials go into a file you create yourself under lib/app called keys.dart, holding the client id and client secret that GitHub generated for your OAuth application:

```dart
class PrivateKeys {
  static const clientID = '<ClientID of the app from the previous step>';
  static const clientSecret = '<ClientSecret of the app from the previous step>';
}
```

The placeholder text in that snippet is the README's own, and the file is not checked in, so every person who builds the app registers their own OAuth application rather than sharing the author's. The cost of that model is that the registered callback URL has to match the scheme in the app, which is why the README is specific about the exact string to paste.

After the keys file exists, the dependencies are fetched and the project built:

```bash
flutter pub get
```

A pubspec.yaml and a pubspec.lock are both present at the top level, and the lock file means a build can be pinned to the exact dependency versions the author used. The presence of a dedicated cleanup_build_history.sh script at the repository root suggests the author has had to clean up build artefacts in the history, which is worth knowing before you fork.

The release section of the README says the current build is published on Google Play under the package com.felix.diohub, and that the latest apk can alternatively be downloaded from the releases page. The Telegram group linked from the README is where discussion happens, which for a single-maintainer project is the closest thing to a support channel that exists.

## Reading the release tags: dev builds, a Play Store listing and a long tail

The tag list is unusual enough to need a careful reading. The published releases include v1.0.0-dev.2049 from 2026-04-16, v1.0.0-dev.2 from 2025-12-30 and v1.0.0-dev.1 from 2023-12-20. A build number of 2049 inside a dev tag, with a second dev tag numbered 2, suggests a counter that runs continuously rather than a version that increments cleanly, so these tags should not be read as a semantic version series. What they reliably indicate is that the project has never left the development pre-release line.

That matters for anyone considering installation rather than building. The README's own answer to the question of whether the project is dead notes that a large update has been in progress for a while and that the author expects a few development releases in the coming months, with a full store release once everything is ready. The Play Store badge in the README links to a listing under the com.felix.diohub package identifier, so a published build exists for Android, but the phrasing of the surrounding text treats the store release as still ahead.

The repository is not archived, and the last push was on 2026-07-12. The gap between the last push and the newest release tag is about three months, which suggests development continued after the last tagged build, and it means the code on the development branch is ahead of any downloadable build.

For a user, the practical rule is simple: treat the published builds as pre-release software, read the changelog.md before updating, and expect the application to change shape between builds rather than to receive compatibility patches.

## Where DioHub is the wrong choice

The most obvious wrong choice is putting a sole dependency on a third-party client for a repository you maintain at work. A client that depends on GitHub's GraphQL schema breaks when the schema changes, and a client maintained by one person in his free time can stop at any time. The README is candid about the pace, and the repository layout, with a single author and a personal support link, points the same way. For a work machine, the official clients and the web interface remain the safer base.

The second wrong choice is a security-sensitive account. The app authenticates through a GitHub OAuth application that the user registers, and it holds a token that carries the account's access. A mobile client that also offers code browsing, patch viewing and deep links is a rich target, and the repository ships a PrivacyPolicy.md, which tells you the author has thought about disclosure, but it does not replace a review of what the app stores on the device and whether the token is kept in the platform's secure storage.

The third wrong choice is a fully offline workflow. The caching is described as partial offline support and no more, and the README does not document queued writes or a background sync, so a reviewer who needs to work through a long list of pull requests on a train is looking at a tool that will show recent content and stop there.

A fourth consideration is the platform scope. The repository carries android, ios, linux, macos and windows directories, so a desktop build is technically in the tree, but the README describes a mobile client and points at the Play Store and the App Store. Desktop support is not something the documentation claims.

Finally, licence compatibility. GPL-3.0 is a strong copyleft licence, which suits a community client distributed as an application, but it is the wrong licence for a company that wanted to fold the client into a proprietary internal tool without releasing the combined work.

## Licence, privacy and what it costs to keep a fork alive

The licence is GPL-3.0, the one strong copyleft licence in common use. For an end user installing a build, it means the source is available and any distributed modification must be released under the same terms. For an organisation that wants to modify the app and ship it internally as part of a proprietary product, the copyleft obligation extends to the combined work, which is a constraint that has to be checked before any fork goes into a product.

This description covers the published licence terms, not legal advice.

The maintenance question for a fork is different from the maintenance question for a user. A user can update from the Play Store or the releases page and accept whatever the author ships. A fork has to absorb the whole stack: the Dart source under lib/, the assets, the fonts directory, the platform projects, the GraphQL configuration and the dependency lock file. When the app moves to a new GraphQL schema, a fork has to regenerate and reconcile the client code, and the author does that work in his own repository on his own schedule.

Two repository artefacts help with that. The changelog.md records what changed, and roadmap.md sits at the top level as the project plan. The private keys file is not in the repository, so a fork has to register its own OAuth application, which is a five minute job but a step that is easy to forget and produces a confusing login failure if it is missed.

The homepage of the project points at the GitHub repository itself rather than a separate site, and the README asks readers to watch the releases section for dev builds and to use the Telegram group for discussion. There is no published stability policy, no support matrix for Android or iOS versions, and no documented data retention policy beyond the PrivacyPolicy.md file, so a fork inherits those gaps along with the code.

## Conclusion

Install DioHub if you want a phone client for GitHub that is not the official app and you are willing to accept an unofficial, single-maintainer project, and build it from source if you need to audit the OAuth handling or patch the client yourself. Do not use it as the only way to reach a production repository, and do not expect store-grade release discipline, since the newest published tags are development builds such as v1.0.0-dev.2049 from 2026-04-16. Before installing, check the OAuth scopes it requests against your account, and read the PrivacyPolicy.md in the repository, because the app holds credentials that grant access to your GitHub account.

## FAQ

### What is DioHub and what is it built with?

DioHub is an unofficial open source GitHub client for mobile devices, written in Dart with Flutter. The repository has platform folders for android, ios, linux, macos and windows.

### How do I build DioHub from source?

Install Flutter, create a GitHub OAuth application with the authorization callback URL set to auth.felix.diohub://login-callback, run git submodule update --init, create lib/app/keys.dart holding the client id and secret, then run flutter pub get and build the project.

### Can I use DioHub offline?

Only partially. The README lists caching for partial offline support and does not describe queued writes or a background sync, so recently viewed content is available without a connection while anything that changes data still needs one.

### Is DioHub available outside the development builds?

The README links to a Google Play listing under the com.felix.diohub package and to apk downloads on the releases page. The author describes a full Play Store and App Store release as still upcoming, and the published tags include development builds such as v1.0.0-dev.2049 from 2026-04-16.

### What licence does DioHub use and can I put it in a commercial app?

The repository is licensed GPL-3.0. That is a strong copyleft licence, so a modified or combined version distributed as a product generally has to be released under the same terms, which is why a proprietary internal fork needs its own licence review.

## Sources

- [License: GPL-3.0](https://github.com/namanshergill/diohub/blob/development/LICENSE)
- [namanshergill/diohub on GitHub](https://github.com/namanshergill/diohub)
- [Project website](https://github.com/NamanShergill/diohub)
- [README](https://github.com/namanshergill/diohub/blob/development/README.md)
- [Releases](https://github.com/namanshergill/diohub/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/namanshergill-diohub