OnCrypt for macOS

Problem

OnCrypt existed only on Windows. Mac users in the same companies needed the same protection, and it had to behave exactly like Windows, because both report to the same web dashboard and the same customers use both. That covered the behaviour, the messages, the logs and the Japanese text. The features included:

• encrypting files and folders
• decrypting only after the owner approves on their phone
• secure shredding, USB protection and watched private folders

My role

• Founding developer. I created the Swift project in April 2025 and built most of the early UI and features. I was one of three main developers.
• Windows-parity owner. For most tasks I read the Windows C# code first, then made the Mac app behave the same way.
• Platform investigator. I led the work on macOS-specific problems: Finder right-click integration, sandbox and privacy permissions, and installer failures on a new macOS version.

How I built it

• Swift, SwiftUI and AppKit. SwiftUI for the screens. AppKit where SwiftUI falls short: title bars, alerts and text-field focus. MVVM throughout, with async/await.
• Core features. Encryption, decryption approved from the paired phone, emergency decryption, an offline disaster-recovery mode with a 16-character code, a file shredder, USB protection (including external NVMe and SSD enclosures), private folders and file sharing.
• Encrypted local database. I moved storage from JSON and property files to SQLite (GRDB), then protected it with SQLCipher, with versioned migrations.
• Background service. I ported the Windows service that handles server push events and uploads activity logs to the cloud every 5 minutes.
• Finder integration. Right-click encrypt, decrypt and delete, double-click to open encrypted files, and a custom icon for encrypted files.
• English and Japanese throughout, using the Windows resource files as the source of truth.

Challenges

Making the database encryption verifiable

Some time after the move to SQLCipher, I checked the database file myself and found it could still be opened without a password. There were two hidden causes:

• the encryption code was behind a build flag that was never set
• the one-time migration always failed silently, because it ran inside a transaction

I fixed the flag for every target and rewrote the migration so it:

• runs outside a transaction
• checks that the encrypted copy has every table before retiring the old file
• securely overwrites the old file
• takes a cross-process lock, so the app and its helper tools can’t migrate at the same time

A safer right-click integration

Right-click actions ran through Automator workflow files that users could edit, and their labels couldn’t follow the app’s language. I prototyped and measured four alternatives:

• Finder Sync: blocked in iCloud folders
• Services: couldn’t be localized
• Doing the work inside the extension: the sandbox couldn’t write the output

I chose three thin, signed Finder Action extensions that pass the selected files to a helper app. On the way, I found a trap: if an extension returns an empty result, Finder permanently deletes the selected file. I made sure the extension always returns the original items.

It only broke on one Mac

On one QA machine, right-click always asked the user to log in, and reinstalling failed. Comparing the machines showed the only difference was macOS 27. The system logs proved that the new version blocks the app’s shared data folder for binaries without a matching entitlement. I wrote a root-cause report, a fix plan, and steps to unblock affected machines.

Logs had to match Windows exactly

Mac logs were missing events, used different wording, and had 7 CSV columns where Windows had 14. I compared every log call with the Windows code, feature by feature. Then I added the missing logs and moved to the 14-column format, while still reading old files.

Result

• Mac users get the same protection and the same behaviour as Windows users, in English and Japanese.
• The signed Finder extensions shipped in the version 2.1.0 production release branch. Users can no longer edit the scripts.
• The local database is encrypted, and existing data migrates safely.
• Mac and Windows activity logs now line up in the company’s web dashboard.