Skip to main content
Apps

Credda on a desktop, and on a phone

The desktop app is not a viewer wrapped around a web page. It is the whole product, running on your own machine, against the same account and the same record you already use. No installer is published yet. This page says where each build stands, what running one takes, and what works today without waiting.

The desktop app

It runs every screen the phone runs

One shared codebase draws both, so the desktop app is not a smaller version of anything. What the desktop adds is a window big enough to put a list and a detail beside each other, and a browser to sign in through.

Every screen, not a subset

Signing in, your dashboard, the ledger of work you have recorded, your professional record, career verification, sharing, your timeline, the organizations you work with, the workforce console, the what-if view and the coach. None of it was trimmed to fit a second platform, because there is no second platform. It is one set of screens.

One account, one record

The desktop app talks to the same production service the website does, as the same account. A job you recorded on your phone before a shift is on the desktop when you open it that evening. There is nothing to import, no sync switch, and no separate desktop copy that can disagree with the first one.

It reads the window it is in

Narrow, you get the phone layout and its bottom bar. Past 600 points wide the bar becomes a left rail that stays put. Past 840 the ledger splits into a list and a detail pane beside it. The reading column stays capped either way, so a maximized window gives you more record rather than longer lines.

Sign in the way you already do

Email or username and password, or Google. Google opens your normal browser, and the app listens on a loopback port that only your own machine can reach and that closes as soon as the answer comes back. If two-factor is on, it asks for the code from your authenticator or a backup code.

The session key is sealed by the OS

Your token is encrypted on disk with AES-256-GCM, and the key is held in the operating system’s own secret store: Credential Manager on Windows, Keychain on macOS, the Secret Service on Linux. Copying the file off the machine gets you a file. Where no secret store exists, the key falls back to a file only your account can read, which is weaker and is written down as weaker.

A dead network is not a dead screen

Launching with the server unreachable used to show a spinner that never resolved and never explained itself. It now names the failure, offers a retry, and offers a way to sign out, which is the only exit from a session that cannot be checked.

Where each build stands

Five platforms, five different answers

Written per platform rather than as one cross-platform claim, because the honest answer differs by operating system. No row here has a download behind it yet, and none of them shows a button until it does.

Linux

Built and inspected

A Debian package has been built and opened up: credda 1.0.0-1, amd64, 68 MB, with its menu entry and its icon where they belong. The runtime inside it was checked against the list of Java modules the app actually reaches for, because a missing one is silent at build time and fatal the first time somebody signs in with Google. It is not published, and there is no release job to publish it. One file uploaded by hand is a file nobody can replace.

Needs: A Debian or Ubuntu system on amd64. Nothing else: the package carries its own Java runtime.

Windows

Configured, never built

The MSI is set up properly rather than left on defaults. It declares a Start menu group, a desktop shortcut, a directory chooser, and a fixed upgrade code so that installing a later version replaces the earlier one instead of parking it alongside. None of that has been exercised, because no MSI has been built. That needs a Windows machine running the packaging task, and it also needs the signing answered first.

Needs: Windows 10 or later. No separate Java install; the installer carries its own runtime.

macOS

Configured, never built

The DMG declares a real bundle identifier and a dock name, which matters more than it sounds: the identifier is what a signature and an Apple notarization later attach to, and a build that shipped without one could not be signed afterward without becoming a different application. No DMG has been built. Packaging one needs a Mac.

Needs: A Mac. No separate Java install; the app carries its own runtime.

Android

Packages, never launched

The release build compiles, shrinks and packages: a 2 MB app package and a 4.6 MB bundle in the format the store takes. It has never been run on a handset. Nothing in it has been seen on a real screen, so a layout bug or a crash on the first frame is still on the table, and it has not been near Play review. That is a short list of work, not a rewrite, and it is the reason there is no link here.

Needs: Android 8.0 or later.

iPhone and iPad

No app, and no date

There is no iOS app, and no App Store badge here that leads nowhere. The shared code does compile for iOS and then stops: the compiler produces libraries, the framework has never been linked, and there is no Xcode project or entry point for one to be linked into. A Mac, an Apple developer account and that project all have to exist first. When that changes it will be an entry in the changelog before it is a link on this page.

The part that is actually hard

Building an installer is easy. Signing it is not.

An installer with no code signature is not a neutral thing. Windows SmartScreen tells the person that the app is unrecognized and hides the button that runs it behind a second click most people never make. macOS is stricter: Gatekeeper refuses to open an unsigned app at all until it has been signed and notarized through Apple.

Both need certificates issued against the company’s legal identity, and a build machine per operating system to run the packaging on. Neither exists yet. Publishing a download before they do would mean handing somebody a file their own computer warns them about, on a page whose entire subject is records you can check. That trade is not worth one earlier release.

The Debian package has no signing problem, and it is still not here, for a duller reason: nothing builds and replaces it automatically. A binary uploaded by hand is one nobody updates.

Without waiting for any of it

All of this works in a browser today

An app is a faster way into the same record, not a different product. Nothing below is waiting on a build, and a phone browser reaches every one of them.

How you will know when there is something here

Every release is written up in the changelog, and an app going live will be an entry there on the day it happens. There is no signup list on this page, because a list implies a date and we do not have one. To ask about a specific platform, the help center reaches a person fastest.