Installing and the first launch

1Which file to download

Every file is listed on the download page, and older versions stay on the Releases page. Usually you want the Microsoft Store version on Windows and arm64.zip on a Mac. On a PC without the Store, use -setup.exe.

There is no Intel (x86_64) build, and no Linux build. Windows also needs the WebView2 runtime, which is already present on Windows 11 and on up-to-date Windows 10; where it is missing, the installer fetches it. The Microsoft Store version does not: on such a PC, use the installer or install the WebView2 runtime first.

2Installing on Windows

The Microsoft Store version installs from its Store page. Microsoft signs it, so none of the warnings below appear.

Apart from the Store version, pictkura is not code-signed on Windows — a signing certificate costs money. Nothing is broken; clearing the warnings below lets the app run normally.

2.1  Installing -setup.exe

There is no UAC prompt, because it installs into your own user profile rather than the whole machine. Depending on your Windows settings, you will see one or two prompts:

Two exceptions, both where it does something machine-wide on your behalf:

2.2  Installing the MSI (this one also prompts for UAC)

1. SmartScreen — when you open the downloaded MSI, not at download time. You may see "Windows protected your PC." Click More info, then the Run anyway button that appears. SmartScreen judges each downloaded file, so clearing one MSI does not cover the next release, and the same file can prompt again on another PC. Within one PC and one file, it usually stops asking after you have run it once.

2. User Account Control (UAC) — next, Windows asks whether to allow an app from an unknown publisher to make changes, and shows Publisher: Unknown (because it is not signed). Click Yes. This prompt appears every time you install.

2.3  The portable ZIP

No install is needed, but the first time you run the extracted pictkura.exe, the same SmartScreen prompt may appear. Click More info → Run anyway.

2.4  Smart App Control (all but the Store version)

If Smart App Control is on — it can be, on a clean install of Windows 11 — it may block an unsigned app outright, with no "Run anyway" to click. This applies to every file downloaded from this site, since it judges the code, not how it reached you.

There is no way around it from the installer or portable side: try the Microsoft Store version, which Microsoft signs, or use a PC without SAC. Switching SAC off does lift the block, but it is one-way — Windows cannot turn it back on without a reinstall — so we do not suggest it just to run this app.

2.5  The Defender quarantine (both shipped builds cleared)

Defender has taken a pictkura executable as Trojan:Win32/Bearfoos.A!ml out of three builds so far: 0.2.6 (2026-09-02), a 0.2.7 build being tested before release (09-03 and 09-04), and the shipped 0.2.7 (09-06). The !ml suffix marks it as a machine-learning guess, not a match against a known threat, and it fires readily on unsigned executables.

Two of those were builds you could download, and both detections were reported to Microsoft as false positives and removed: the files do not meet their criteria for malware. 0.2.6 on 2026-09-02 (removed the next day, #105) and 0.2.7 on 2026-09-06 (removed the same day, #121). In the 0.2.6 episode -setup.exe was quarantined too, as Bearfoos.B!ml, but only the executable was submitted — there too, the removal reached the one file that was reported.

The remaining build was never published — what people could download at the time was still 0.2.6. Two files out of that one build were quarantined separately, and only one of them was reported and withdrawn; the other was quarantined again after the withdrawal came through. That is how it became clear that a removal reaches one file at a time.

The 0.2.7 downloads were pulled on 2026-09-06 and are back, byte for byte the same files. The published SHA256SUMS.txt has not changed since the first release, so a copy downloaded before the pause still checks out.

If a copy was already taken from you: your photos and your library are untouched. What gets cleaned out is %LOCALAPPDATA%\pictkura\; the database and the settings live under %APPDATA%\, a different tree. Once the definitions are current (the commands are below), installing again puts the executable back — checked on the machine it actually happened to. Reinstalling before that just gets the new copy taken as well. If the installer objects, %LOCALAPPDATA%\pictkura\uninstall.exe is still there; run that first.

This is not a promise that it will not happen again. The verdict is delivered from the cloud rather than by a definition you can pin down, and it has happened on two shipped builds and once in testing. A removal covers the one file that was reported — for 0.2.7 that is the installer's payload. The MSIs and the portable ZIP each carry a different byte string that the removal does not reach, though neither has ever been quarantined. Since the removal the installer has been run on a freshly installed Windows with the current definitions and nothing fired, but that is one machine on a handful of days, not proof of anything. Issue #121 is closed, but the account is kept there. If it happens to you, the definition version and the time it fired are the useful things to add to it — and the issue gets reopened if the detection comes back.

A machine whose definitions are still old can go on quarantining it. Microsoft's own advice is to drop the cached detections and fetch the current definitions, from a command prompt run as administrator:

cd /d "c:\Program Files\Windows Defender"
MpCmdRun.exe -removedefinitions -dynamicsignatures
MpCmdRun.exe -SignatureUpdate

The block is for the Command Prompt (cmd.exe). The /d is what makes cd cross to C: when your prompt is sitting on another drive. In PowerShell, drop the /d and write .\MpCmdRun.exe on the other two lines — PowerShell does not look in the current directory.

Updating the definitions stops the detection, but it does not bring back a file that was already taken. Once the definitions are current, installing pictkura again puts it back — that is the quickest way out. (Reinstalling before that just gets the new copy taken as well.) The quarantined copy is also still listed under Protection history in Windows Security.

The whole account, including how to check what you downloaded, is in issue #121 (the 0.2.6 episode is #105).

3Starting it on macOS

The macOS build is not signed with an Apple Developer ID, so Gatekeeper stops the first launch. The app is not damaged: Gatekeeper reports that it cannot check who signed it.

First, move pictkura.app to wherever you want to keep it (/Applications, say). This is not just tidiness: launched from where it was unzipped, macOS copies the app into a read-only temporary location and runs it from there (App Translocation).

macOS 15 (Sequoia) and later

Double-clicking shows a dialog saying macOS "could not verify pictkura is free of malware," offering only Move to Trash and Done. Nothing there lets you continue, so:

That line only appears after a blocked double-click, so keep the order.

macOS 11 to 14

Right-click (or control-click) pictkura.app → Open → Open in the dialog.

Any version (Terminal)

xattr -dr com.apple.quarantine /path/to/pictkura.app

Only the first launch needs this; afterwards it opens by double-clicking. The same block happens whether the app ships as a .zip or a .dmg — the archive format has nothing to do with it.

4First steps after installing

Once it opens, add the folder your photos live in with Browse… at the bottom left. To bring photos off a card, insert it and press Import from USB at the top. The destination folder and the way shots are filed by date are both chosen on that screen.

Every screen is walked through in the manual, and what the app does and does not do is listed in the specification.

5Uninstalling

Unless you only used the Store version, settings and the index remain. Their locations are listed under Where data lives. Your photos are never touched.