DEV Community: Urban

How I release a Blazor app to 8 distribution channels

Urban — Sat, 04 Apr 2026 09:03:06 +0000

OpenHabitTracker is a free, open source app for taking Markdown notes, planning tasks, and tracking habits. One codebase, 8 distribution channels. This is everything I had to figure out to ship it.

The previous articles covered why there are so many entry points and how the shared Blazor component library stays platform-agnostic. This article is about what happens after you write the code - the files you need, the gotchas that aren't documented anywhere, and what you have to do on every release.

Why 8 channels?

Each distribution channel has different requirements that forced a separate entry point:

Microsoft Store - MAUI (net9.0-windows)
Google Play - MAUI (net9.0-android)
Apple App Store - MAUI (net9.0-ios)
Mac App Store - MAUI (net9.0-maccatalyst)
Flatpak (Flathub) - Photino - MAUI has no Linux target
Snap Store - Photino
Docker Hub + GitHub Container Registry - Blazor Server
ClickOnce (Windows direct download) - WPF - for users who don't want the Store
PWA - Blazor WASM

Before your first release (all platforms)

The boring but mandatory stuff - brief because it's all googleable:

Register as a developer on each platform (Microsoft Partner Center $19 one-time, Google Play Console $25 one-time, Apple Developer Program $99/year, Snap Store free, Flathub free, Docker Hub free)
Create your app listing on each store with descriptions, screenshots, privacy policy URL
For Apple: create App IDs, provisioning profiles, and distribution certificates in Apple Developer portal
For Google: create a keystore and keep it safe - you can never change it after the first upload
For Microsoft Store: associate your app in Visual Studio to get the publisher identity values

Version numbers - the cross-cutting problem

Before going platform by platform, the version number problem deserves its own section because it's spread across more files than you'd expect, and one of them has a non-obvious constraint.

Files that contain the version number:

OpenHabitTracker.Blazor.Maui/OpenHabitTracker.Blazor.Maui.csproj - two separate fields
Platforms/Windows/Package.appxmanifest
net.openhabittracker.OpenHabitTracker.yaml
net.openhabittracker.OpenHabitTracker.metainfo.xml
snapcraft.yaml
ClickOnceProfile.pubxml
FolderProfile.pubxml (WASM)
VersionHistory.md

The MAUI .csproj has two separate version fields and they serve different purposes:

<ApplicationDisplayVersion>1.2.1</ApplicationDisplayVersion>
<ApplicationVersion>21</ApplicationVersion>

ApplicationDisplayVersion is the human-readable string shown to users. ApplicationVersion is an integer - Android requires it, it must strictly increment on every release, and it cannot be the version string. If you try to use "1.2.1" as the version code, the Android build fails with:

error XA0003: VersionCode 1.2.1 is invalid. It must be an integer value.

So you maintain a separate integer counter alongside your version string. Every release you bump both.

Microsoft Store (MAUI Windows)

First time: Register at Partner Center, pay the one-time fee, create the app reservation, associate the app in Visual Studio (this fills in the publisher identity values), create an MSIX package. (MAUI Windows deployment docs)

Special file: Platforms/Windows/Package.appxmanifest (schema reference)

<Identity
  Name="31456Jinjinov.578313437ADBB"
  Publisher="CN=63F779A2-C88E-4913-81F0-5E6786C4CD1A"
  Version="1.2.1.0" />

<Capabilities>
  <rescap:Capability Name="runFullTrust" />
  <Capability Name="internetClient"/>
</Capabilities>

The Name and Publisher values come from Partner Center when you associate your app. You can't make them up - they must match exactly what the Store has on record or the upload will be rejected.

runFullTrust is required for MAUI apps because they run as regular Win32 processes, not sandboxed UWP apps.

Every release: Bump Version in Package.appxmanifest, publish:

dotnet publish OpenHabitTracker.Blazor.Maui.csproj -c:Release -f:net9.0-windows10.0.19041.0 -p:SelfContained=true -p:PublishAppxPackage=true

Upload the .msixupload to Partner Center.

Google Play (MAUI Android)

First time: Register at Play Console, pay the one-time fee, create the app, set up the keystore, configure release signing. (MAUI Android Google Play docs)

You can test on an Android emulator before building a release:

dotnet build -t:Run -f:net9.0-android

Special file: Platforms/Android/AndroidManifest.xml

<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <application android:allowBackup="true" android:icon="@mipmap/appicon" android:roundIcon="@mipmap/appicon_round" android:supportsRtl="true"></application>
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.INTERNET" />
</manifest>

This file looks minimal, but every permission your app needs must be declared here. Missing a permission and the feature silently fails at runtime. Adding a permission you don't need can cause Play Store review rejections. (Android permission reference)

Every release: Bump ApplicationDisplayVersion and ApplicationVersion (the integer) in .csproj, publish:

dotnet publish -c Release -f:net9.0-android ...

Upload the .aab to Play Console. The integer ApplicationVersion must be higher than the previous release or the upload is rejected.

Apple App Store (MAUI iOS)

First time: Apple Developer Program ($99/year, covers all Apple platforms), create an App ID, create a distribution certificate, create a provisioning profile, install both on your Mac. (MAUI iOS App Store docs, manual provisioning guide)

Apple requires screenshots at exact pixel dimensions or the submission is rejected. Required sizes:

iPhone 6.7": 1290x2796 or 2796x1290
iPhone 6.5": 1242x2688 or 1284x2778
iPhone 5.5": 1242x2208 or 2208x1242
iPad 12.9" (2nd gen): 2048x2732 or 2732x2048
iPad 13": 2064x2752 or 2048x2732

You can test on the simulator before building a release:

dotnet build OpenHabitTracker.Blazor.Maui.csproj -t:Run -c:Release -f:net9.0-ios

Special file: Platforms/iOS/Info.plist

<key>CFBundleIdentifier</key>
<string>net.openhabittracker</string>
<key>CFBundleDisplayName</key>
<string>OpenHT</string>
<key>ITSAppUsesNonExemptEncryption</key>
<false/>
<key>UIDeviceFamily</key>
<array>
    <integer>1</integer>  <!-- iPhone -->
    <integer>2</integer>  <!-- iPad -->
</array>

ITSAppUsesNonExemptEncryption is the one that catches everyone. If you omit it, Apple holds your submission and asks you to answer export compliance questions every single time you submit. Set it to false if your app doesn't use encryption beyond standard HTTPS (which is exempt). (MAUI Info.plist docs)

The signing config lives in the .csproj in a conditional PropertyGroup, not just in the publish command. (MAUI iOS publish CLI docs)

<PropertyGroup Condition="$(TargetFramework.Contains('-ios')) and '$(Configuration)' == 'Release'">
    <RuntimeIdentifier>ios-arm64</RuntimeIdentifier>
    <CodesignKey>Apple Distribution: Your Name (53V66WG4KU)</CodesignKey>
    <CodesignProvision>openhabittracker.ios</CodesignProvision>
</PropertyGroup>

Every release: Publish, upload .ipa via Transporter or Xcode.

dotnet publish OpenHabitTracker.Blazor.Maui.csproj -c:Release -f:net9.0-ios -p:ArchiveOnBuild=true -p:RuntimeIdentifier=ios-arm64 -p:CodesignKey="Apple Distribution: Your Name (53V66WG4KU)" -p:CodesignProvision="openhabittracker.ios"

Mac App Store (MAUI macOS)

First time: Same Apple Developer account, but separate Mac-specific provisioning profile and a second certificate type for the installer package. (MAUI macOS App Store docs, manual provisioning guide)

Required screenshot sizes for Mac App Store: 1280x800, 1440x900, 2560x1600, 2880x1800.

You can test locally before building a release:

dotnet build OpenHabitTracker.Blazor.Maui.csproj -t:Run -c:Release -f:net9.0-maccatalyst

Special file: Platforms/MacCatalyst/Info.plist

<key>CFBundleIdentifier</key>
<string>net.openhabittracker</string>
<key>LSApplicationCategoryType</key>
<string>public.app-category.productivity</string>
<key>NSHumanReadableCopyright</key>
<string>© 2026 Jinjinov</string>
<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Same ITSAppUsesNonExemptEncryption caveat as iOS. Also LSApplicationCategoryType - the Mac App Store requires a category, the App Store will reject submission without it. (MAUI Info.plist docs)

Special file: Platforms/MacCatalyst/Entitlements.plist

<dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.network.client</key>
    <true/>
</dict>

App Sandbox is mandatory for Mac App Store distribution. Without it, Apple rejects the submission outright. With it, you must explicitly declare every capability your app needs - in this case network.client for outgoing connections. Miss one and the feature fails silently inside the sandbox. (MAUI macOS entitlements docs)

The macOS signing config in .csproj requires three separate keys (MAUI macOS publish CLI docs):

<PropertyGroup Condition="$(TargetFramework.Contains('-maccatalyst')) and '$(Configuration)' == 'Release'">
    <CodesignKey>Apple Distribution: Your Name (53V66WG4KU)</CodesignKey>
    <CodesignProvision>openhabittracker.macos</CodesignProvision>
    <CodesignEntitlements>Platforms\MacCatalyst\Entitlements.plist</CodesignEntitlements>
    <PackageSigningKey>3rd Party Mac Developer Installer: Your Name (53V66WG4KU)</PackageSigningKey>
    <EnableCodeSigning>True</EnableCodeSigning>
    <EnablePackageSigning>true</EnablePackageSigning>
    <CreatePackage>true</CreatePackage>
    <MtouchLink>SdkOnly</MtouchLink>
</PropertyGroup>

Three different certificate types are involved: Apple Distribution (signs the app bundle), 3rd Party Mac Developer Installer (signs the .pkg installer). The certificate names include your team ID in parentheses - they come from Keychain after you install the certificates from Apple Developer portal.

Every release:

dotnet publish OpenHabitTracker.Blazor.Maui.csproj -c:Release -f:net9.0-maccatalyst -p:MtouchLink=SdkOnly -p:CreatePackage=true -p:EnableCodeSigning=true -p:EnablePackageSigning=true -p:CodesignKey="Apple Distribution: Your Name (53V66WG4KU)" -p:CodesignProvision="openhabittracker.macos" -p:CodesignEntitlements="Platforms\MacCatalyst\Entitlements.plist" -p:PackageSigningKey="3rd Party Mac Developer Installer: Your Name (53V66WG4KU)"

Upload .pkg via Transporter.

Flatpak / Flathub (Photino, Linux)

This is the most involved distribution channel. Flatpak builds happen in a network-isolated sandbox - no internet access during build. Every dependency must be pre-declared.

Photino depends on WebKit. On a fresh Linux machine you need this before the app will run at all:

sudo apt-get install libwebkit2gtk-4.1

First time: Apply to Flathub, fork their template repo, set up the app manifest, pass the linter, get reviewed. (Flathub submission guide) Flathub creates a separate GitHub repository for your app's manifest at github.com/flathub/net.openhabittracker.OpenHabitTracker. You maintain a fork at github.com/Jinjinov/net.openhabittracker.OpenHabitTracker.

Special file: net.openhabittracker.OpenHabitTracker.yaml

The Flatpak build manifest. It references your git repository by tag AND commit hash - both must match:

- type: git
  url: https://github.com/Jinjinov/OpenHabitTracker.git
  tag: 1.2.1
  commit: 233c4b8410756159e14f31dd7a4e3607efa53749

It also handles cross-architecture builds through environment variables:

build-options:
  arch:
    aarch64:
      env:
        RUNTIME: linux-arm64
    x86_64:
      env:
        RUNTIME: linux-x64
build-commands:
  - dotnet publish OpenHabitTracker.Blazor.Photino/... -r $RUNTIME ...

Special file: net.openhabittracker.OpenHabitTracker.metainfo.xml

Flathub validates this file with a linter before merging the PR. It must pass appstream-util validate and flatpak-builder-lint. It contains the app description, release history, and screenshot URLs. A release entry must be added for every version. (AppStream spec)

Special file: net.openhabittracker.OpenHabitTracker.desktop

[Desktop Entry]
Name=OpenHabitTracker
Comment=Take notes, plan tasks, track habits
Exec=OpenHT
Icon=net.openhabittracker.OpenHabitTracker
Type=Application
Categories=Office;

This is the Linux standard for app launchers - how your app appears in GNOME, KDE, etc. The Icon value must match the SVG filename (without extension).

Special file: net.openhabittracker.OpenHabitTracker.svg

Flathub requires an SVG icon, not PNG. This must use the reverse-domain naming convention that matches your app ID.

Special file: nuget-sources.json

The most unique file in the whole project. Because Flatpak builds in a network-isolated sandbox, it cannot download NuGet packages at build time. Every package - including all transitive dependencies - must be pre-declared with its download URL and SHA-512 hash. This file is generated by flatpak-dotnet-generator.py:

python3 flatpak-dotnet-generator.py --dotnet 9 --freedesktop 25.08 nuget-sources.json OpenHabitTracker/OpenHabitTracker.Blazor.Photino/OpenHabitTracker.Blazor.Photino.csproj

The yaml then references it as an offline source:

sources:
  - type: git
    url: https://github.com/Jinjinov/OpenHabitTracker.git
    tag: 1.2.1
    commit: 233c4b8410756159e14f31dd7a4e3607efa53749
  - ./nuget-sources.json
build-commands:
  - dotnet publish ... --source ./nuget-sources --source /usr/lib/sdk/dotnet9/nuget/packages

nuget-sources.json doesn't need to be regenerated every release - only when NuGet packages change.

Every release:

Before opening a PR, validate everything locally. The Flathub linter will catch these too, but it's faster to fix them locally:

desktop-file-validate net.openhabittracker.OpenHabitTracker.desktop
appstream-util validate net.openhabittracker.OpenHabitTracker.metainfo.xml
flatpak run --command=flatpak-builder-lint org.flatpak.Builder manifest net.openhabittracker.OpenHabitTracker.yaml

Do a full local build and run to confirm it works:

flatpak-builder build-dir --user --force-clean --install --repo=repo net.openhabittracker.OpenHabitTracker.yaml
flatpak run --command=flatpak-builder-lint org.flatpak.Builder repo repo
flatpak run net.openhabittracker.OpenHabitTracker

Then submit:

Create a git tag
Get the commit hash: git ls-remote https://github.com/Jinjinov/OpenHabitTracker.git refs/tags/1.2.1
Update tag and commit in net.openhabittracker.OpenHabitTracker.yaml
Add a release entry to net.openhabittracker.OpenHabitTracker.metainfo.xml
Push to your fork (Jinjinov/net.openhabittracker.OpenHabitTracker)
Open a PR to flathub/net.openhabittracker.OpenHabitTracker
The Flathub bot builds and tests it - wait for ✅ Test build succeeded
If the test build fails: push a fix, update the tag and commit in the yaml, then comment in the PR: bot, build net.openhabittracker.OpenHabitTracker
Merge the PR
Sync your fork back from the upstream flathub repo so it stays up to date

Snap Store (Photino, Linux)

First time: Register at snapcraft.io, register the app name, install Snapcraft and LXD. Snapcraft uses LXD to build in an isolated container - you can't build snaps without it:

sudo snap install snapcraft --classic
sudo snap install lxd
sudo lxd init --auto
sudo usermod -aG lxd $USER
newgrp lxd

Special file: snapcraft.yaml (snapcraft.yaml reference)

name: openhabittracker
base: core24
confinement: strict
version: '1.2.1'

parts:
  openhabittracker:
    source: .
    plugin: dotnet
    dotnet-version: "9.0"
    override-build: |
      dotnet publish OpenHabitTracker.Blazor.Photino/OpenHabitTracker.Blazor.Photino.csproj -c Release -f net9.0 -r linux-x64 -p:PublishSingleFile=true -p:SelfContained=true -o $SNAPCRAFT_PART_INSTALL
      chmod 0755 $SNAPCRAFT_PART_INSTALL/OpenHT

apps:
  openhabittracker:
    extensions: [gnome]
    command: OpenHT
    plugs:
      - hardware-observe
      - home
      - removable-media
      - network

plugs are the snap equivalent of Android permissions - they declare what the app can access. (Snap interfaces reference) extensions: [gnome] pulls in GNOME libraries and is required for GTK-based apps (Photino uses WebKit which is part of the GNOME stack).

confinement: strict means the snap is fully sandboxed. During development you use confinement: devmode and then switch to strict for release.

Every release:

snapcraft pack --debug

If the pack fails, clean the build cache and retry:

snapcraft clean openhabittracker
snapcraft pack --debug

Test locally before uploading:

sudo snap install openhabittracker_1.2.1_amd64.snap --dangerous --devmode
snap run openhabittracker

Upload and verify:

snapcraft login
snapcraft upload --release=stable openhabittracker_1.2.1_amd64.snap
snapcraft status openhabittracker

Docker Hub + GitHub Container Registry (Blazor Server)

First time: Docker Hub account, GitHub account (for GHCR), set up the Dockerfile, test the image locally. Authenticate to both registries before pushing:

docker login

echo <GitHubToken> | docker login ghcr.io -u YourUsername --password-stdin

The GitHub token needs write:packages scope. Generate it at GitHub → Settings → Developer settings → Personal access tokens.

Special file: Dockerfile

Multi-stage build - SDK image to compile, ASP.NET runtime image to run. (Docker multi-stage build docs)

FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
WORKDIR /src

COPY ["OpenHabitTracker/OpenHabitTracker.csproj", "OpenHabitTracker/"]
COPY ["OpenHabitTracker.Blazor.Web/OpenHabitTracker.Blazor.Web.csproj", "OpenHabitTracker.Blazor.Web/"]
# ... other projects
RUN dotnet restore "OpenHabitTracker.Blazor.Web/OpenHabitTracker.Blazor.Web.csproj"

COPY . .
RUN dotnet publish "OpenHabitTracker.Blazor.Web.csproj" -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "OpenHT.dll"]

Only copying .csproj files first and running dotnet restore before copying the rest is intentional - it lets Docker cache the NuGet restore layer so rebuilds are fast when only source files change.

Special file: docker-compose.yml

This ships to end users, not just for building. Users run docker compose up with this file. It maps environment variables to appsettings.json values so users can set their credentials without modifying the image:

services:
  openhabittracker:
    image: jinjinov/openhabittracker:latest
    ports:
      - "5000:8080"
    environment:
      - AppSettings__UserName=${APPSETTINGS_USERNAME}
      - AppSettings__Email=${APPSETTINGS_EMAIL}
      - AppSettings__Password=${APPSETTINGS_PASSWORD}
      - AppSettings__JwtSecret=${APPSETTINGS_JWT_SECRET}
    volumes:
      - ./.OpenHabitTracker:/app/.OpenHabitTracker

Every release:

docker compose build
docker tag openhabittracker jinjinov/openhabittracker:1.2.1
docker push jinjinov/openhabittracker:1.2.1
docker tag openhabittracker jinjinov/openhabittracker:latest
docker push jinjinov/openhabittracker:latest

docker tag openhabittracker ghcr.io/jinjinov/openhabittracker:1.2.1
docker push ghcr.io/jinjinov/openhabittracker:1.2.1
docker tag openhabittracker ghcr.io/jinjinov/openhabittracker:latest
docker push ghcr.io/jinjinov/openhabittracker:latest

(GitHub Container Registry docs)

WPF + ClickOnce (Windows direct download)

ClickOnce is for users who want a classical Windows installer experience without going through the Microsoft Store.

First time: Configure publish settings in Visual Studio, set up the bootstrapper. (ClickOnce deployment docs)

Special file: Properties/PublishProfiles/ClickOnceProfile.pubxml

<ApplicationVersion>1.2.1.0</ApplicationVersion>
<PublishProtocol>ClickOnce</PublishProtocol>
<RuntimeIdentifier>win-x86</RuntimeIdentifier>
<SelfContained>False</SelfContained>
<BootstrapperPackage Include="Microsoft.NetCore.DesktopRuntime.9.0.x86">
    <Install>true</Install>
    <ProductName>.NET Desktop Runtime 9.0.0 (x86)</ProductName>
</BootstrapperPackage>

SelfContained=False + the bootstrapper means the installer checks for .NET Desktop Runtime and downloads it if missing. This keeps the installer small.

Every release: Bump ApplicationVersion, publish via Visual Studio ClickOnce, zip the output, FTP upload to the download server.

WASM / PWA (Blazor WebAssembly)

First time: Set up IIS with the URL Rewrite module (required for SPA routing - without it, any direct URL that isn't the root returns 404). (Blazor WASM IIS hosting docs)

Special file: wwwroot/manifest.json (web app manifest spec)

{
  "name": "OpenHabitTracker",
  "short_name": "OpenHT",
  "id": "./",
  "start_url": "./",
  "display": "standalone",
  "background_color": "#808080",
  "theme_color": "#808080",
  "icons": [
    { "src": "/icons/icon-512.png", "type": "image/png", "sizes": "512x512" },
    { "src": "/icons/icon-192.png", "type": "image/png", "sizes": "192x192" }
  ]
}

This makes the app installable as a PWA. display: standalone hides the browser chrome. Without the 512px icon, Chrome won't offer the install prompt.

Special file: wwwroot/service-worker.published.js

The dev version (service-worker.js) is a stub that always fetches from the network. The published version caches all .dll, .wasm, .js, .css, and asset files on first install for offline support. (Blazor PWA docs)

const offlineAssetsInclude = [ /\.dll$/, /\.pdb$/, /\.wasm/, /\.html/, /\.js$/, /\.json$/, /\.css$/, /\.woff$/, /\.png$/, /\.jpe?g$/, /\.gif$/, /\.ico$/ ];

Special file: Properties/PublishProfiles/FolderProfile.pubxml

<PublishUrl>C:\inetpub\wwwroot</PublishUrl>
<DeleteExistingFiles>false</DeleteExistingFiles> <!-- NEVER SET IT TO true! IT WILL DELETE C:\inetpub\wwwroot FOLDER! -->

The danger comment is real. DeleteExistingFiles=true in a publish profile pointed at C:\inetpub\wwwroot will delete the entire folder and everything in it before copying the published output.

Every release: Publish to folder (directly to C:\inetpub\wwwroot), then FTP upload to the server.

The result

8 channels, roughly 15 special files, one codebase. The most time-consuming part on every release is keeping the version number consistent across all these files. The most time-consuming part on the first release is Apple - not because it's hard once you understand it, but because the documentation is scattered and the error messages are unhelpful.

Flatpak is the most technically interesting because of the offline build sandbox and the nuget-sources.json workflow. Flatpak has good official documentation for .NET at docs.flatpak.org/en/latest/dotnet.html - but it still took me a while to put all the pieces together for a real app with many dependencies.

OpenHabitTracker is open source - all the files shown here are in the repo.

How I use the same Blazor code for WASM, Windows, Linux, macOS, iOS, Android without a single #if

Urban — Sun, 29 Mar 2026 08:33:00 +0000

OpenHabitTracker is a free, open source app for taking Markdown notes, planning tasks, and tracking habits. It runs on Windows, Linux, macOS, iOS, Android, and as a web app - all from a single shared Razor component library. This article explains how.

In a previous article I covered the architecture but skipped the actual code. This is the code.

Why so many entry points?

Each store or distribution method has its own requirements:

MAUI -> Microsoft Store, Google Play, App Store, Mac App Store
Blazor WASM -> web / PWA
Blazor Server -> Docker self-hosting
Photino -> Linux (Flatpak, Snap) - MAUI simply has no Linux target
WPF + ClickOnce -> Windows direct download, classical installer experience outside the Store

The entry points exist because the distribution channels demanded them.

Once you accept that you need six entry points, the question becomes: how do you stop the shared component library from knowing about any of them?

The pattern

Every platform difference is hidden behind an interface. The shared OpenHabitTracker.Blazor library defines the interface and a default (usually no-op) implementation. Each entry point registers its own implementation via DI. The shared library consumes the interface and never knows which platform it's running on.

There is not a single #if in OpenHabitTracker.Blazor.

Let's go through each interface.

IOpenFile / ISaveFile

File picking is the most dramatic example. In a browser, you cannot open a native file dialog programmatically - the user must click a file input element. In every other platform, you call the OS dialog directly.

The interface:

public interface IOpenFile
{
    RenderFragment OpenFileDialog(string css, string content, Func<string, Stream, Task> onFileOpened);
}

It returns a RenderFragment - the implementation decides what HTML to render and how to wire the file picker. The component consuming it just renders whatever comes back.

WASM - must use a hidden <InputFile> wrapped in a <label>:

public class OpenFile : IOpenFile
{
    const long _maxAllowedFileSize = 50 * 1024 * 1024;

    public RenderFragment OpenFileDialog(string css, string content, Func<string, Stream, Task> onFileOpened)
    {
        return builder =>
        {
            builder.OpenElement(0, "label");
            builder.AddAttribute(1, "class", css);
            builder.OpenElement(2, "i");
            builder.AddAttribute(3, "class", "bi bi-box-arrow-in-right");
            builder.CloseElement();
            builder.AddContent(4, " ");
            builder.AddContent(5, content);

            builder.OpenComponent<InputFile>(6);
            builder.AddAttribute(7, "class", "d-none");
            builder.AddAttribute(8, "OnChange", EventCallback.Factory.Create(this, async (InputFileChangeEventArgs args) =>
            {
                Stream stream = args.File.OpenReadStream(maxAllowedSize: _maxAllowedFileSize);
                await onFileOpened(args.File.Name, stream);
            }));
            builder.CloseComponent();

            builder.CloseElement();
        };
    }
}

WinForms - a <button> that opens System.Windows.Forms.OpenFileDialog:

public class OpenFile : IOpenFile
{
    public RenderFragment OpenFileDialog(string css, string content, Func<string, Stream, Task> onFileOpened)
    {
        return builder =>
        {
            builder.OpenElement(0, "button");
            builder.AddAttribute(1, "class", css);
            builder.AddAttribute(2, "onclick", EventCallback.Factory.Create(this, async () =>
            {
                OpenFileDialog openFileDialog = new()
                {
                    Filter = "JSON|*.json|TSV|*.tsv|YAML|*.yaml|Markdown|*.md|Google Keep Takeout ZIP|*.zip"
                };

                if (openFileDialog.ShowDialog() == DialogResult.OK)
                {
                    await onFileOpened(openFileDialog.FileName, openFileDialog.OpenFile());
                }
            }));
            builder.OpenElement(3, "i");
            builder.AddAttribute(4, "class", "bi bi-box-arrow-in-right");
            builder.CloseElement();
            builder.AddContent(5, " ");
            builder.AddContent(6, content);
            builder.CloseElement();
        };
    }
}

MAUI - FilePicker.PickAsync():

public class OpenFile : IOpenFile
{
    public RenderFragment OpenFileDialog(string css, string content, Func<string, Stream, Task> onFileOpened)
    {
        return builder =>
        {
            builder.OpenElement(0, "button");
            builder.AddAttribute(1, "class", css);
            builder.AddAttribute(2, "onclick", EventCallback.Factory.Create(this, async () =>
            {
                FileResult? result = await FilePicker.PickAsync();

                if (result != null)
                {
                    Stream stream = await result.OpenReadAsync();
                    await onFileOpened(result.FileName, stream);
                }
            }));
            builder.OpenElement(3, "i");
            builder.AddAttribute(4, "class", "bi bi-box-arrow-in-right");
            builder.CloseElement();
            builder.AddContent(5, " ");
            builder.AddContent(6, content);
            builder.CloseElement();
        };
    }
}

Photino - mainWindow.ShowOpenFile():

public class OpenFile(PhotinoWindow mainWindow) : IOpenFile
{
    private readonly (string Name, string[] Extensions)[] _filters =
    [
        ("JSON", [".json"]),
        ("TSV", [".tsv"]),
        ("YAML", [".yaml"]),
        ("Markdown", [".md"]),
        ("Google Keep Takeout ZIP", [".zip"])
    ];

    public RenderFragment OpenFileDialog(string css, string content, Func<string, Stream, Task> onFileOpened)
    {
        return builder =>
        {
            builder.OpenElement(0, "button");
            builder.AddAttribute(1, "class", css);
            builder.AddAttribute(2, "onclick", EventCallback.Factory.Create(this, async () =>
            {
                string[] paths = mainWindow.ShowOpenFile(filters: _filters);

                if (paths.Length == 1)
                {
                    FileStream stream = File.OpenRead(paths[0]);
                    await onFileOpened(paths[0], stream);
                }
            }));
            builder.OpenElement(3, "i");
            builder.AddAttribute(4, "class", "bi bi-box-arrow-in-right");
            builder.CloseElement();
            builder.AddContent(5, " ");
            builder.AddContent(6, content);
            builder.CloseElement();
        };
    }
}

Four completely different implementations. One interface. The Backup page that renders the import button doesn't know which it gets.

ISaveFile follows the same pattern: WASM triggers a JS download via SaveAsUTF8, WinForms/WPF use SaveFileDialog, MAUI uses CommunityToolkit.Maui's FileSaver, Photino uses mainWindow.ShowSaveFile().

IAuthFragment - the null object pattern

OpenHabitTracker supports optional sync with a self-hosted server. Native desktop and mobile apps (WinForms, WPF, Photino, MAUI) need a login UI to connect to it. WASM is already the web app. Blazor Server IS the server - it handles its own auth via ASP.NET Identity middleware, not through this interface.

So the null object default covers WASM and Blazor Server:

public class AuthFragment : IAuthFragment
{
    public bool IsAuthAvailable => false;

    public Task<bool> TryRefreshTokenLogin() => Task.FromResult(false);

    public RenderFragment GetAuthFragment(bool stateChanged, EventCallback<bool> stateChangedChanged)
        => builder => { };
}

The real implementation is registered on WinForms, WPF, Photino, and MAUI:

public class AuthFragment(IAuthService authService) : IAuthFragment
{
    public bool IsAuthAvailable => true;

    public Task<bool> TryRefreshTokenLogin() => authService.TryRefreshTokenLogin();

    public RenderFragment GetAuthFragment(bool stateChanged, EventCallback<bool> stateChangedChanged)
    {
        return builder =>
        {
            builder.OpenComponent<LoginComponent>(0);
            builder.AddAttribute(1, "StateChanged", stateChanged);
            builder.AddAttribute(2, "StateChangedChanged", stateChangedChanged);
            builder.CloseComponent();
        };
    }
}

The settings page checks IsAuthAvailable and conditionally renders the sync section. No #if, no platform checks - just a boolean on an injected interface.

IPreRenderService - one line that solves SSR

Blazor Server pre-renders pages on the server before the WebSocket connection is established. During that phase, calling JS interop throws an exception. The fix:

public interface IPreRenderService
{
    bool IsPreRendering { get; }
}

Default (all non-server platforms):

public class PreRenderService : IPreRenderService
{
    public bool IsPreRendering => false;
}

Blazor Server:

public class PreRenderService(IHttpContextAccessor httpContextAccessor) : IPreRenderService
{
    public bool IsPreRendering { get; } =
        !(httpContextAccessor.HttpContext?.Response.HasStarted == true);
}

One property. One line. The rest of the shared library guards JS calls with if (!preRenderService.IsPreRendering) and works correctly on all platforms.

ILinkAttributeService - a Photino-only problem

Photino runs Blazor inside an embedded WebView. When a user clicks an external link in a Markdown note, the WebView tries to navigate itself instead of opening the system browser. The fix is a JS call that adds a custom onclick handler to all external links.

Default (everyone else - no-op):

public class LinkAttributeService : ILinkAttributeService
{
    public Task AddAttributesToLinks(ElementReference elementReference)
        => Task.CompletedTask;
}

Photino only:

public class LinkAttributeService(IJSRuntime jsRuntime) : ILinkAttributeService
{
    public async Task AddAttributesToLinks(ElementReference elementReference)
    {
        await jsRuntime.InvokeVoidAsync("addAttributeToLinks", elementReference);
    }
}

When a user clicks an external link in a Markdown note, Photino's WebView would navigate itself instead of opening the system browser. addAttributeToLinks finds all <a href> elements with http:// or https:// URLs and replaces their click behavior with an onclick that calls DotNet.invokeMethodAsync('OpenHT', 'OpenLink', url). That invokes the [JSInvokable] OpenLink method in Photino's Program.cs, which does Process.Start(new ProcessStartInfo(url) { UseShellExecute = true }).

The full chain: user clicks link → JS intercepts → .NET interop → system browser opens.

The shared library calls AddAttributesToLinks after every Markdown render. On every other platform, it does nothing.

IAssemblyProvider - router wiring

Blazor's router needs to know which assemblies contain page components. This differs between entry points:

Default (desktop - pages only in the shared library):

public class AssemblyProvider : IAssemblyProvider
{
    public Assembly AppAssembly { get; } = typeof(IAssemblyProvider).Assembly;
    public Assembly[] AdditionalAssemblies { get; } = [];
}

WASM and Blazor Server (entry point assembly also contains pages):

public class AssemblyProvider : IAssemblyProvider
{
    public Assembly AppAssembly { get; } = typeof(IAssemblyProvider).Assembly;
    public Assembly[] AdditionalAssemblies { get; } = [typeof(AssemblyProvider).Assembly];
}

IDataAccess - the deepest split

The storage layer is where the platforms diverge most fundamentally. The interface covers the full CRUD surface for every entity type. Behind it are three completely different backends:

IndexedDB (WASM) - browser storage via DnetIndexedDb
SQLite via EF Core (WinForms, WPF, Photino, MAUI, Blazor Server) - local database file
HTTP API client (remote sync) - calls a self-hosted Blazor Server instance

The Blazor Server entry point also needs ASP.NET Identity for JWT authentication, which means its user table has a different schema than the plain SQLite UserEntity. IUserEntity bridges this:

public interface IUserEntity
{
    long Id { get; set; }
    string UserName { get; set; }
    string Email { get; set; }
    string PasswordHash { get; set; }
    DateTime LastChangeAt { get; set; }
}

UserEntity implements it for SQLite. ApplicationUser (ASP.NET Identity) implements it for Blazor Server. The service layer works with IUserEntity and doesn't know which it gets.

What the entry points look like

Each Program.cs calls the same four shared registrations, then adds a few lines of platform-specific DI:

// shared - every platform calls these four
builder.Services.AddServices();
builder.Services.AddDataAccess();
builder.Services.AddBackup();
builder.Services.AddBlazor();

// platform-specific - only these lines differ
builder.Services.AddScoped<IOpenFile, OpenFile>();
builder.Services.AddScoped<ISaveFile, SaveFile>();
builder.Services.AddScoped<INavBarFragment, NavBarFragment>();
builder.Services.AddScoped<IAssemblyProvider, AssemblyProvider>();
builder.Services.AddScoped<ILinkAttributeService, LinkAttributeService>();
builder.Services.AddScoped<IPreRenderService, PreRenderService>();
builder.Services.AddScoped<IAuthFragment, AuthFragment>();

Every class name in the platform-specific block is a different type - same interface name, different namespace. That's the entire surface area of platform divergence.

The result

The shared OpenHabitTracker.Blazor project - the one that contains all Razor components, pages, and layouts - has zero #if directives for platform differences. It consumes interfaces, renders RenderFragment values it receives, and checks boolean properties on injected services. It has no knowledge of IndexedDB, OpenFileDialog, FilePicker, Photino, or ASP.NET Identity.

This is my third rewrite of this app in Blazor. The first two taught me what not to do. The third time, the architecture finally felt right.

OpenHabitTracker is open source - all the code shown here is in production.

OpenHabitTracker vs Habitica, Loop Habit Tracker, Streaks, and Everyday

Urban — Sun, 22 Mar 2026 09:00:18 +0000

This article compares OpenHabitTracker with four popular alternatives: Habitica, Loop Habit Tracker, Streaks, and Everyday. Not to declare a winner, but to help you figure out which one fits how you actually work.

🖥️ Platforms

The first question is always: does it run on my device?

	OpenHabitTracker	Habitica	Loop	Streaks	Everyday
Windows	✅	🌐 browser only	❌	❌	🌐 browser only
Linux	✅	🌐 browser only	❌	❌	🌐 browser only
Android	✅	✅	✅	❌	✅
iOS	✅	✅	❌	✅	✅
macOS	✅	🌐 browser only	❌	✅	✅
Web / PWA	✅	✅	❌	❌	✅

Loop is Android only - there is no official iOS version. Streaks is Apple only - no Android, no Windows, no Linux. Habitica works in the browser on any platform but has no native desktop app. Everyday comes close to full coverage but skips Windows and Linux.

OpenHabitTracker is the only one in this list with a native app on Windows and Linux, alongside Android, iOS, macOS, and a PWA.

💰 Price and business model

	OpenHabitTracker	Habitica	Loop	Streaks	Everyday
Free tier	unlimited	unlimited	unlimited	❌ no free tier	3 habits only
Paid tier	none	$4.99/month	none	~$5 one-time	~$30/year or $100 lifetime
Ads	❌	❌	❌	❌	❌

A few things worth noting:

Habitica's subscription is cosmetic only - the core RPG features are completely free
Loop has no in-app purchases whatsoever
Streaks is a one-time purchase with no ongoing cost
Everyday's free tier caps you at 3 habits, which is enough to try it but not enough to actually use it

OpenHabitTracker is free with no habit limit, no subscription, and no ads.

🔒 Privacy and data storage

This is where the differences get more significant.

	OpenHabitTracker	Habitica	Loop	Streaks	Everyday
Account required	❌	✅	❌	❌	✅
Data stored	on your device	cloud	on your device	device + iCloud	cloud
Open source	✅	✅	✅	❌	❌
Optional self-hosting	✅	❌	❌	❌	❌

Habitica and Everyday require an account and store your data on their servers. If either service shuts down, your data goes with it. Loop and Streaks keep everything local, which is good for privacy but means no sync between devices. Streaks syncs via iCloud, so it stays within Apple's ecosystem.

OpenHabitTracker stores data locally with no account required. For anyone who wants to sync across devices without relying on a third-party cloud service, there is a Docker image that runs a self-hosted server. Any native version of the app - desktop or mobile - can log in to your own instance and sync, so your data travels across devices through infrastructure you control.

Habitica and Loop are both open source, which means anyone can read the code and verify what it does. Streaks and Everyday are closed source.

📅 Habit tracking features

	OpenHabitTracker	Habitica	Loop	Streaks	Everyday
Streak tracking	❌ by design	✅	✅	✅	✅
Interval-based urgency	✅	❌	❌	❌	❌
Habit strength algorithm	❌	❌	✅	❌	❌
Flexible schedules	✅	✅	✅	✅	✅
Weekly stats	✅	❌	✅	❌	❌
Apple Health integration	❌	❌	❌	✅	❌
Gamification	❌	✅	❌	❌	❌
Reminders	✅	✅	✅	✅	✅
Habit limit	none	none	none	24	3 (free)

The biggest philosophical difference is in the first two rows.

Four out of five apps use streak counters. Miss a day, your streak resets to zero. OpenHabitTracker was designed around a different idea: instead of tracking streaks, it tracks time elapsed since your last completion and compares it to the habit's desired interval. A habit with a 10-day interval that's 2 days overdue shows at 120%. A habit with a 4-day interval that's also 2 days overdue shows at 150% - because relative to its schedule, it's more urgent. Missing one day doesn't reset anything, it just shifts the percentage a little.

Loop takes a similarly forgiving approach with its habit strength algorithm - consistency builds up a score gradually, and missing days dips it gradually rather than wiping it out entirely.

Streaks integrates with Apple Health, so habits tied to steps, exercise, or sleep can complete automatically based on what your iPhone or Apple Watch already tracks. Nothing else in this list does that.

Habitica's gamification is either the main reason to use it or the main reason not to - completing habits earns XP, gold, and gear, and you can go on quests with other players.

📝 Notes and tasks

This is a category most habit trackers don't have at all.

	OpenHabitTracker	Habitica	Loop	Streaks	Everyday
Notes	✅ Markdown	❌	❌	❌	❌
Tasks	✅	✅ To-Dos	❌	❌	❌

Habitica has a to-do list as part of its task system, but it's tied to the RPG mechanics - completing a to-do gives your character XP. Loop, Streaks, and Everyday are habit-only apps.

OpenHabitTracker combines Markdown notes, tasks, and habits in one place. If you want to keep your daily notes, your task list, and your habit tracker in the same app without switching between three different tools, it's the only option in this comparison that supports all three.

🌍 Languages and customization

	OpenHabitTracker	Habitica	Loop	Streaks	Everyday
Languages	20	22	~10	~10	~10
Themes	26	limited	limited	limited	limited
Dark mode	✅	✅	✅	✅	✅

OpenHabitTracker is available in:

English, German, Spanish, Slovenian, French, Portuguese, Italian, Japanese, Chinese, Korean, Dutch, Danish, Norwegian, Swedish, Finnish, Polish, Czech, Slovak, Croatian, and Serbian.

It ships with 26 themes in both dark and light modes, which is more than any of the alternatives. Habitica has the edge on language count thanks to its large community of volunteer translators.

⌨️ Accessibility and keyboard navigation

	OpenHabitTracker	Habitica	Loop	Streaks	Everyday
Keyboard navigation	✅	✅ partial	➖ N/A	✅ VoiceOver	❓ unknown
Screen reader support	✅	⚠️ partial	⚠️ partial	✅ VoiceOver	❓ unknown

Streaks has the strongest accessibility track record in this list. VoiceOver is explicitly supported on iOS and macOS, the App Store accessibility declarations are fully filled out, and the developer has a reputation for being very responsive to blind users.

Habitica has partial keyboard navigation - Tab key navigation is documented and works across the web client, and ARIA labels were added to habit and task controls in 2023.

Loop has addressed accessibility issues when reported - color contrast, touch target sizes, missing content descriptions, and respecting the system reduce motion setting.

OpenHabitTracker follows the ARIA menu pattern in the sidebar - arrow keys move between items. The habit calendar follows the ARIA grid pattern:

← → arrow keys to move between days
↑ ↓ arrow keys to move between weeks
Home and End for the start and end of a week
Page Up and Page Down to switch months

Every button has a descriptive ARIA label. The layout uses semantic HTML landmarks. Focus moves into sidebars when you open them and returns to where you were when you close them.

🏁 Which one is right for you

Habitica - if you want gamification and accountability through a community. The RPG mechanics are unlike anything else and the core features are free.
Loop Habit Tracker - if you are on Android and privacy is the priority. Open source, completely free, stores everything locally, and the habit strength algorithm is one of the most thoughtful approaches to streak tracking available.
Streaks - if you are deep in the Apple ecosystem and want seamless Health integration. The one-time price is fair and automatic completions via Apple Watch are genuinely useful.
Everyday - if you want something visual and beginner-friendly across mobile and web. Just be aware of the 3-habit limit on the free tier.
OpenHabitTracker - if you want a free, open source habit tracker that runs natively on every platform, skips the streak counter in favor of interval-based urgency, keeps your data on your device, and can optionally sync across all your devices through a self-hosted Docker instance.

🌐 openhabittracker.net
📱 PWA: pwa.openhabittracker.net
💻 Source: github.com/Jinjinov/OpenHabitTracker

OpenHabitTracker is more user friendly now with better UI

Urban — Sat, 21 Mar 2026 21:37:15 +0000

OpenHabitTracker is a free, open source app for taking Markdown notes, planning tasks, and tracking habits. No account required, no ads, no subscription - all your data stays on your device.

It runs on Windows, Linux, Android, iOS, macOS, and in the browser as a PWA.

A cleaner, more configurable interface

The app now lets you hide the fields you don't use. Don't care about priorities? Turn them off. Don't use categories? Hide them. The settings are simple toggles and they make a real difference to how much visual noise you're dealing with day to day.

Notes, tasks, and habits each have their own background color, so you can tell at a glance what type of item you're looking at without reading the label.

There's also a filter to hide completed tasks, which keeps the list focused on what's still pending.

Weekly summary

Tasks and habits both have an optional stats panel showing your week at a glance - how many you completed, how much time you spent, and whether you're keeping up with your habits or falling behind.

Keyboard navigation

The menu sidebar follows the ARIA menu pattern - arrow keys move between items, no mouse needed. The habit calendar supports the full ARIA grid pattern: arrow keys to move between days, Home and End for the start and end of a week, Page Up and Page Down to switch months.

When you open a sidebar, focus moves into it automatically. When you close it, focus returns to where you were. It sounds like a small thing but it's the difference between an app that feels under control and one that constantly loses your place.

Accessibility

Every interactive element has a proper ARIA label. The layout uses semantic HTML landmarks - <nav> and <main> - so screen readers can navigate the page structure without hunting through the content. Decorative icons are hidden from assistive technology. Toggle buttons correctly reflect their state with aria-expanded. The active page in the navigation is marked with aria-current. The app is fully usable without a mouse.

20 languages, 26 themes

Besides English, German, Spanish, and Slovenian, the app is now also available in French, Portuguese, Italian, Japanese, Chinese, Korean, Dutch, Danish, Norwegian, Swedish, Finnish, Polish, Czech, Slovak, Croatian, and Serbian.

It ships with 26 themes in both dark and light modes.

Data can be exported and imported as JSON, YAML, TSV, or Markdown. Google Keep notes can be imported from a Google Takeout ZIP.

For the self-hosting community, there's a Docker image that runs a Blazor Server instance. Besides accessing it in the browser, any native version of the app - Windows, Linux, Android, iOS, macOS - can log in to your instance and sync, so your data follows you across devices without going through anyone else's servers.

Web: openhabittracker.net
PWA: pwa.openhabittracker.net
Source: github.com/Jinjinov/OpenHabitTracker

nas-sync-script-builder generates a bash script for one-way, no-deletion NAS sync using rsync and lsyncd

Urban — Thu, 29 Jan 2026 16:08:38 +0000

nas-sync-script-builder: a small tool for a very specific NAS problem

Most backup and sync tools assume one of two models:

Mirroring: source and destination must be identical
Backup systems: versioned, snapshot-based, or cloud-oriented

There is a common use case that falls between these models and is poorly served by existing tools:

Keep a NAS continuously updated from a local machine, one-way, while preserving existing files on the NAS.

This is the problem nas-sync-script-builder exists to solve.

The niche it fills

The target scenario:

A Linux workstation or server
One or more local disks (often NTFS or mixed filesystems)
A NAS (Synology or any SMB-compatible device) as a sink
Files flow local → NAS only
Existing NAS files remain untouched

Many tools approximate this behavior, but none provide it directly:

rsync requires careful flag management
lsyncd is powerful but tricky to configure
Backup tools (Borg, Restic, Duplicati) are versioned or snapshot-based
NAS vendor tools enforce mirroring or proprietary agents

What’s missing is a safe, repeatable way to set up:

Incremental initial sync
Continuous real-time sync
Systemd-aware mounts
Persistent credentials

How it works

nas-sync-script-builder is a configuration generator, not a daemon.

It provides:

A Python GUI (and optional CLI) for configuration
Automatic detection of eligible local partitions via UDisks2
A generated Bash script that:

Installs required packages (rsync, lsyncd, cifs-utils)
Creates local and NAS mount points
Configures CIFS mounts using systemd automounts
Writes a managed /etc/fstab block
Performs an initial one-way sync with rsync
Configures lsyncd for continuous updates
Handles systemd dependencies, logs, and inotify limits
Is safe to re-run at any time

The Python tool exists to make this setup explicit, reviewable, and reproducible.

Who this is for

Linux users with a NAS needing continuous updates
Users migrating from Windows disks to a NAS
Anyone who wants controlled, append-only sync without snapshot or backup tools

Project links

How to create a Blazor app for WASM, Windows, Linux, macOS, iOS, Android

Urban — Thu, 19 Sep 2024 14:08:16 +0000

Hey everyone!

I got a few messages asking me how I created my free, open source habit tracker app OpenHabitTracker so I decided to write a post about it.

You can see the source code on GitHub.

Why Blazor

I wanted to create an app that would work on as many platforms as possible and share as much code as possible between all platforms.

I compared all cross platform C# frameworks that were available:

Framework	First Release	UI Technology	Windows	macOS	Linux	Android	iOS	Web (WASM)
.NET MAUI	May 2022	XAML	Yes	Yes	No	Yes	Yes	No
Blazor	Sep 2019	HTML + CSS	Yes	Yes	Yes	Yes	Yes	Yes
Avalonia	Feb 2015	XAML	Yes	Yes	Yes	Yes	Yes	Experimental
Uno Platform	Sep 2018	XAML	Yes	Yes	Yes	Yes	Yes	Yes
Xamarin.Forms	May 2014	XAML	Yes	No	No	Yes	Yes	No

Xamarin was replaced by MAUI and MAUI doesn't support Web - that left Avalonia (with poor web support at that time), Uno and Blazor.

I have used a few open sourced project managed by volunteers and it did not have the best experience, so I wanted to choose a project backed by a company.

I was working with WPF for 5 years and in that time I found out that I really don't like XAML, so I was really happy when Blazor came out.

My first Blazor project was only with WASM and Windows through WebView2 in WinForms / WPF. When Maui Blazor Hybrid was announced I knew that Blazor was a good choice.

How I started

I started by creating a project from every Visual Studio Blazor project template in a single solution and then I started to move all the files that were the same into a shared library.

At first, I had only a single shared library, but later I split it into OpenHabitTracker of type <Project Sdk="Microsoft.NET.Sdk"> that holds the core classes and to OpenHabitTracker.Blazor of type <Project Sdk="Microsoft.NET.Sdk.Razor"> that holds the razor files. This way the logic is separated from the UI and the razor files contain few lines of C# code which is a good thing because Visual Studio editor for razor files can behave strangely at times, especially with @code blocks. The editor behaves better if you have your C# code in .razor.cs code behind files, but you can just go one step further and have the C# code in a separate library.

At first, I had only my razor components and razor pages in the shared library, I didn't move App.razor, _Imports.razor, MainLayout.razor, JsInterop.cs, jsInterop.js, app.css into the shared library, but later I figured out that you can move all files except Program.cs and index.html into the shared library - if there is any platform specific behavior, you can solve it with C# interfaces - even if you need platform specific razor UI, you can still solve it with interfaces and methods that return a RenderFragment. All .css and .js files can be in the shared library and then included to platform specific projects in index.html with _content/OpenHabitTracker.Blazor/... for example <link rel="stylesheet" href="_content/OpenHabitTracker.Blazor/app.css" />.

How I chose the frameworks

I started comparing all the frameworks that support Blazor on desktop and mobile:

Windows only:

WPF: works great with Microsoft.AspNetCore.Components.WebView.Wpf NuGet
WinForms: works great with Microsoft.AspNetCore.Components.WebView.WindowsForms NuGet

Windows, Linux, macOS:

Photino Blazor: works great with Photino.Blazor NuGet
Electron.NET: works with ElectronNET.API NuGet - long compile times, very large builds, slow startup, opens the GUI window AND a terminal
Chromely: works with Chromely NuGet - long compile times, slow startup, opens the GUI window AND a terminal - GitHub repo was archived by the owner on Jan 16, 2023

Windows, macOS, iOS, Android:

MAUI: works with several Maui NuGet packages and dotnet workloads: android, ios, maccatalyst, maui-windows, see https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-workload

To support WASM, Windows, Linux, macOS, iOS, Android you need at least:

Blazor WASM
Maui
Photino Blazor

I develop on Windows with Visual Studio 2022 and my startup project is usually OpenHabitTracker.Blazor.Photino because it compiles and starts much faster than OpenHabitTracker.Blazor.Wasm or OpenHabitTracker.Blazor.Maui.

Saving user data

I took a look at the different options for storing user data:

Technology	Size Limit	Data Lifetime	Storage Format	Security
Cookies	~4 KB	Configurable	String	HttpOnly, Secure
Session Storage	5-10 MB	Session-based	String	Isolated to tab
Local Storage	5-10 MB	Persistent	String	Shared across tabs
WebSQL	5 MB+	Persistent	Relational DB	Deprecated
IndexedDB	Hundreds of MB	Persistent	Key-Value (Objects)	Same-origin
Cache Storage (SW)	Large	Configurable	HTTP responses	Origin-bound
File System Access API	Device-dependent	Persistent	Files/Blobs	Requires Permission

Because I wanted a large, persistent storage that does not require prompting the user for permission and is not deprecated I chose IndexedDB:

https://github.com/wtulloch/Blazor.IndexedDB - TG.Blazor.IndexedDB NuGet - awkward, not user friendly, abandoned project
https://github.com/Reshiru/Blazor.IndexedDB.Framework - Reshiru.Blazor.IndexedDB.Framework NuGet - wraps TG.Blazor.IndexedDB NuGet, making it much nicer to work with - but it has a huge flaw: it always loads all data - you don't have the ability to load only some objects - repository has been archived by the owner on Jan 26, 2021
https://github.com/amuste/DnetIndexedDb - DnetIndexedDb NuGet - works well enough

I made two mistakes:

I chose Reshiru.Blazor.IndexedDB.Framework and I even fixed a few things and created https://github.com/Jinjinov/IndexedDB.Blazor (don't use it, it has the same problem)
I used IndexedDB on desktop and mobile - it works, but I think SQLite is a better option.

I switched to DnetIndexedDb for the browser and to EF Core + SQLite for desktop and mobile.

The user interface

At first, I wanted to write all CSS on my own, but I soon realized that using Bootstrap is not that bad and saves you a lot of time.
That proved to be a good decision when I decided to implement themes and discovered that Bootswatch offers 26 themes for Bootstrap.

I decided to use a free UI library, so I took a look at what was available:

Library	Features	First Release
Blazorise	Bootstrap, Bulma, AntDesign, Material	June 2019
MudBlazor	Material Design components	April 2020
AntDesign Blazor	Inspired by Ant Design	March 2020
MatBlazor	Material Design components	February 2019
BlazorStrap	Based on Bootstrap 4/5	April 2019
Blazor Bootstrap	Bootstrap 5 components	June 2021

In my previous Blazor project, I used the Blazorise UI library because it had the most controls at the time and because it abstracts the CSS to C# enums and classes - that way it was really easy to switch from Bootstrap 4 to Bootstrap 5. The owner of the project is really responsive to ideas and requests (if you are reasonable and show some initiative). Later I found out that I don't actually need any complex components in my project, so now I use only Bootstrap 5.

In my previous Blazor project, I used Font Awesome icons and Google Fonts, but now I use embedded font files and Bootstrap Icons because I think they work better with Bootstrap 5.

In my previous Blazor project, I used CDN to get the CSS, JS and fonts from the web, but I found out that this makes the app noticeably slower. Now I include all CSS, JS and fonts into the project and the app is much faster. The app is around 2 MB larger because of all the included resources, but at 20 MB for the whole app that is only 10% more - for a much faster UI.

Feel free to ask any questions! :)

What Led Me to Creating OpenHabitTracker and Lessons Learned

Urban — Fri, 06 Sep 2024 14:06:48 +0000

OpenHabitTracker is a free, ad-free, open-source habit tracker app that works on Windows, Linux, Android, iOS, macOS, and as a web app. You can find the source code on GitHub.

The Journey to Creating OpenHabitTracker

I used Google Keep for a long time, but the more I used it, the harder it became to organize my notes. I tried using labels a few times, but without much success.

Then, I began using OneNote to keep track of tasks that weren’t done daily (like cleaning the windows in all rooms or taking the car to the car wash). In the note, I listed a dozen tasks along with the dates they were last completed, but soon I found myself wishing for a tool that could better manage this.

Google Calendar is good for repeating tasks, but finding out when you last completed a particular task can be bothersome—you have to search through previous weeks or months. Most habit tracker apps are great for tracking streaks, but if you miss a task, they fall short. You know you didn’t do it, but you don’t know when you last did it, how much time has passed since, or what the average repeat interval is compared to your desired repeat interval.

This is why I decided to create my own app.

My Programming Background

I wrote my first program in September 1989, during primary school, using QBasic, and I've been programming ever since. For the first 15 years of my programming career, I worked with game engines—writing my own for my university thesis, working on an in-house engine at one company, and using Unity at another. I had almost no experience with UI, UX, HTML, CSS, JS, SQL, or any other web technologies or databases.

First Attempt: Daily Checklist and Tracker

On July 24, 2016, I started working on Daily Checklist and Tracker using PHP and MySQL. I managed to create a simple website with a task list and three types of tasks:

Tasks to be done ASAP, with measured duration
Tasks to be done once on a specified date, saving the time when they were finished
Tasks with a repeat interval

It had all the features I missed in Google Keep, but nothing else. The design was awful—or rather, there was no design at all, not even "programmer's art"—making it unusable.

Lesson learned: User interface and user experience are as important as the features. You have to learn some design.

Second Attempt: Priority Task List

On December 24, 2017, I started working on Priority Task List using Vue.js, CouchDB, and PouchDB. I consider it a vast improvement over my first attempt. It had a menu, help section, and allowed you to group tasks into categories. Each task displayed the time elapsed since it was last completed and the number of times it was completed. It also had an automatically computed priority that changed with time and a priority factor that determined how quickly the priority increased.

This time, I paid more attention to UI, but I had no experience with responsive design. The website had a mobile-first design—perhaps mobile-only design—with just one layout for all screen sizes. It had every feature I wanted, presented on screen the way I wanted, but the user experience was still lacking. You can still try it out here.

Lesson learned: Even if you learn some design and create the UI the way you want, it might not create a good user experience.

Third Attempt: What Should I Be Doing Right Now

On September 16, 2018, I started working on What Should I Be Doing Right Now using Vue.js, CouchDB, and PouchDB. I had an exciting new idea: users could write JavaScript code to determine which task should be done next, based on which tasks were marked as done on a list. The website would take the JavaScript as a string and execute it in code, allowing users to determine what they should do next based on their own rules and a list of tasks with checkboxes.

It was a fun experiment, but not very useful in day-to-day life. You can still try it out here.

Lesson learned: Sometimes, you have to test your ideas, even if they don’t prove to be the best.

Fourth Attempt: What Should I Be Doing

On May 12, 2019, I started working on What Should I Be Doing using PHP and the Google Reminders API. I had another exciting idea: using the existing Google Reminders API to work with Google Reminders and add missing features to a website. Since I couldn’t find a PHP wrapper for the Google Reminders API, I decided to write one myself (Google Reminders PHP) and also created one for JavaScript (Google Reminders JS).

However, this took most of my time, and the website itself didn’t progress. I didn’t add any features beyond listing the reminders you have in Google Calendar and Google Keep.

Lesson learned: Don’t start projects where you’ll spend more time writing missing libraries than working on the project itself.

Fifth Attempt: The Last Time

I became interested in Microsoft Blazor with the release of .NET Core 3.0 and started learning it. On October 4, 2020, I began working on TheLastTime using Blazor with .NET Core 3.1. With the release of .NET 5 on November 10, 2020, I upgraded the project to .NET 5. This was my first Blazor app, and I thoroughly enjoyed working on it—using C# on the client side gave me IntelliSense in Visual Studio, which wasn't available with JavaScript.

The app had a good design, a friendly UI, and was a pleasure to use—this was the first time I found myself daily using a program I had created. Using the app helped me significantly reduce procrastination and develop a few habits that I had struggled with before. The app worked on the web with Blazor WASM and on Windows with WinForms and WPF, where I used WebView to host Blazor. Most of the Blazor code was shared between all three projects.

The app included all the features of my Priority Task List project, such as habit tracking and task grouping by categories. Additionally, it introduced new features: custom categories, advanced Search, Filter, and Sort options for customizing your view, and 26 Bootswatch themes for Bootstrap. The app also supported user data export/import in JSON and YAML formats and allowed users to back up JSON to Google Drive.

However, the NuGet library I used for IndexedDB reloaded everything on every change. At first, this wasn’t an issue, but after a year, the app became so slow that it was unusable. It was clear that I needed a better library for IndexedDB, but since it was so deeply integrated into my code, I realized that a complete rewrite would be faster. You can try it out here.

Lessons learned:

When using third-party libraries, it pays off to get to know them better, especially if they are not widely used or are developed by a single person.
Using abstractions and interfaces is considered best practice in C# for a reason—don’t ignore them.

Sixth Attempt: Ididit!

On April 15, 2022, I started working on Ididit using Blazor with .NET 6. With the release of .NET 7 on November 8, 2022, I upgraded the project to .NET 7. I aimed to make the app truly cross-platform, so in addition to WASM, WinForms, and WPF, I also explored Microsoft MAUI, Chromely, Electron.NET, and Photino.

Using Blazor with Chromely and Electron.NET proved to be difficult and slow, and both libraries were too bloated for my needs. Photino allowed me to create a Linux version of the app. With MAUI, I could develop Android and iOS versions and publish them to the Google and Apple stores. I also published the MAUI version to the Microsoft Store and didn't bother with WinForms and WPF versions.

I decided to implement all the features from TheLastTime and more, all at once. However, this approach caused the design to suffer—the UI wasn’t polished, and the app became bloated with features. The app combined notes, tasks, and habits into one bloated list. I added nested categories and a category tree, which proved to be unnecessary as I never used the feature myself.

The app also had a few good improvements:

Markdown support for notes
User data export/import in TSV and Markdown in addition to JSON and YAML
Import Google Keep notes by uploading the ZIP file produced by Google Takeout
Localization to English, German, Spanish, Slovenian, and Czech

Because I wanted to write as little platform-specific code as possible, I thought using IndexedDB on desktop through WebView was a good idea. However, it didn’t work as well as using the platform's native file access. I also programmed file open/save for user data export/import with JavaScript on all platforms, and while it worked on web and desktop, it didn’t perform well on mobile. Although I used abstractions and interfaces this time, I didn’t structure the code independently enough. You can try it out here.

Lessons learned:

If you’re rewriting a project from scratch, don’t add all the features and ideas you had before at once—first rewrite the proven features, then start adding new ones.
Sometimes, it’s better to write platform-specific code rather than force a platform-independent solution, even if it’s possible.
Writing interfaces for their own sake is as bad as not writing them—if you suspect you might need a different implementation, plan for it when writing the interface.

Seventh Attempt: OpenHabitTracker

On November 14, 2023, I started working on OpenHabitTracker using Blazor and .NET 8, which was released on that day. This time, I decided to take all the good parts of my first Blazor app, TheLastTime, and combine them with the good aspects of Ididit while fixing its problems:

The app has a good design and polished UI.
IndexedDB is used only for WASM, while SQLite with EF Core is used for desktop and mobile.
User data export/import is done with native file open/save dialogs on each platform.

I also introduced new improvements:

All HTML, CSS, and JS files are now embedded, so the app doesn’t depend on an internet connection.
Categories have been simplified—they are no longer nested, so there’s no need for a tree.
Notes, tasks, and habits are now in separate lists, which can also be sorted by priority.
Search, Filter, and Sort features have been improved.
Added a Trash feature so deleted items can now be recovered.
All 26 themes now also work in dark mode.

Introducing OpenHabitTracker: A Free, Open Source, and Privacy-Focused Habit Tracker

Urban — Sat, 31 Aug 2024 07:54:02 +0000

I’m excited to announce the launch of OpenHabitTracker, a powerful, free, and ad-free habit tracking tool designed with privacy and flexibility at its core. Whether you're managing daily tasks, building new habits, or organizing notes, OpenHabitTracker offers a robust solution that respects your privacy and adapts to your needs.

You can start using it today by visiting OpenHabitTracker.

Why OpenHabitTracker?

In a world where most productivity apps are either paid, ad-supported, or intrusive on your privacy, OpenHabitTracker stands out as a true alternative. Here’s why:

Free and Ad-Free: Enjoy the full range of features without being interrupted by ads or paying for premium upgrades.
Open Source: The entire project is open source, meaning the code is transparent, and contributions from the community are welcome.
Privacy Focused: Your data stays with you. All user data is stored locally on your device, ensuring that your personal information remains private and secure.

Cross-Platform Availability

OpenHabitTracker is accessible across multiple platforms, making it convenient to use whether you're at your desk or on the go. It’s available on:

Windows
Linux
Android
iOS
macOS
Web App

No matter what device you use, your habits and tasks are always within reach.

Key Features

OpenHabitTracker comes packed with a range of features designed to help you stay organized and productive:

Markdown Support: Write detailed notes with full Markdown support, making it easy to format your content.
Organize with Categories and Priorities: Structure your tasks, notes, and habits using customizable categories and priority levels.
Advanced Search, Filter, and Sort: Quickly find what you’re looking for with powerful search, filtering, and sorting options.
Data Export/Import: Easily export your data in various formats including JSON, YAML, TSV, and Markdown. You can also import notes directly from Google Keep, making it seamless to switch over.
Customization with Themes: Choose from 26 different themes, and switch between Dark and Light modes to suit your environment and preference.
Localized Experience: OpenHabitTracker is localized in English, German, Spanish, and Slovenian, making it accessible to a broader audience.

A Tool for Everyone

Whether you're a student, professional, or anyone looking to improve productivity, OpenHabitTracker is designed to be a versatile tool that adapts to your needs. Its flexibility, privacy-first approach, and wide range of features make it a powerful choice for anyone serious about habit tracking and task management.

Get Started Today

Ready to take control of your habits and tasks? Visit OpenHabitTracker and download the app on your preferred platform. With OpenHabitTracker, you can build better habits, organize your life, and do it all with the confidence that your data is yours and yours alone.

If you have any feedback, suggestions, or would like to contribute to the project, feel free to get involved through our open source community. Let's build something great together!