Document & Pro Apps
Multi-window, multi-document software with the keyboard shortcuts, drag-and-drop and undo stack a Mac user expects without being told.
macOS app development — native Mac software in Swift and SwiftUI, notarised and shipped on the Mac App Store or direct.
BothmadeFileEditViewWindowmacOS
swift · swiftui · appkit
Your app — built for the Mac
All Files
Recents
Shared
Tags
Archive
Software that belongs on a Mac — keyboard-first, properly windowed, and signed and notarised so it opens without a warning.
Project anatomy
Capabilities
Menu Bar & Background Tools
Small utilities that live in the menu bar and stay out of the way — the kind of app people forget is running until it saves them a job.
Internal Business Tools
Desktop software for the work a browser tab is wrong for: local files, hardware, long-running jobs, and data that should not leave the building.
Signing, Notarisation & Updates
Developer ID signing, Apple notarisation and a working update channel — so it opens without a warning and stays current after launch.
Shared Code With iOS
Where you already have an iPhone or iPad app, the model and business logic come across rather than being written twice.
Connected systems
Stack
A Mac app is not a website in a window, and the ones that are get spotted immediately: the keyboard does nothing, the window will not split, and the file menu is decorative. We build in Apple's own frameworks — Swift and SwiftUI, dropping to AppKit where the platform still expects it — because that is what makes an app feel like it belongs on the machine rather than like a page someone wrapped. The rest of the stack below is what gets it from a build on one laptop to something a stranger can download and open without seeing a warning.
Frameworks
SwiftUI for the interface, AppKit where the Mac still has the better answer — toolbars, sidebars and window management are older than SwiftUI and it shows. Mixing them is normal on this platform, not a compromise.
- Swift
- SwiftUI
- AppKit
- Combine / async-await
Data & System
The parts a desktop app has that a web app does not: real files, real folders, and work that keeps running while the window is closed. Sandboxed by default, so what it can reach is a decision rather than an accident.
- SwiftData / Core Data
- FileProvider
- Background tasks
- App Sandbox
Shipping
Signed with a Developer ID and notarised by Apple, which is the difference between an app that opens and one macOS refuses with a scary dialog. Distributed on the App Store or straight from your own site — whichever suits how you sell.
- Developer ID signing
- Notarisation
- Sparkle or App Store updates
- TestFlight
Delivery pipeline
How a project runs
Every project runs the same way, whatever it is being built on. The scope and the price are agreed before anything starts, and the schedule below is the one written into the agreement — not a description of how things usually go.
Scope and price, fixed
Before anything is built
You get a written scope and a number that does not move. Changes after that are handled as a change order — priced, signed, and added to the schedule — rather than absorbed quietly and argued about at the end. Nothing is billed by the hour, so a slow week is our problem rather than your invoice.
Payment 1 — 50%
On signing, before work begins
The deposit starts the work. The remaining two payments are tied to things you can see happening rather than to dates in a calendar, so a schedule that slips does not become an invoice that arrives anyway.
Design, then your decision
5 business days to review
Designs are presented for review, and you get 5 business days to approve them or come back with changes. We send a reminder before that window closes. If it passes without an answer the design counts as approved and the next payment falls due — and we tell you the day that happens rather than letting you find out from an invoice.
Payment 2 — 25%
On design approval
Build starts once the design is settled, so the thing being built is the thing you signed off. Approving the design is what releases this payment, which is why the review window above matters more than it looks.
Payment 3 — 25%
When the project is ready to launch
The final payment falls due when the build is finished and tested, not when it goes live. Invoices are payable within 14 days and count as late 7 days after that; you are reminded on the day each one is due rather than chased out of nowhere a month later.
Launch and handover
30-day warranty from launch
Going live transfers everything: source code, accounts, credentials, domains. You own it outright — there is no licence to keep paying. Anything that breaks within 30 days of launch is fixed at no cost, because it is a defect rather than a new request.
Before we begin
Questions
macOS apps start at £12,500. Menu bar utilities, document apps and internal tools are all normal shapes; the configurator on the pricing page prices the specific one you have in mind.
Either, and the choice changes the build. The App Store handles payment and updates but sandboxes what the app can reach. Direct distribution allows far more — file system access, background agents, system-level tools — and means signing, notarising and shipping updates yourself. Worth settling before the design, because it decides what the app is allowed to do.
A large amount of it, if both are planned together. SwiftUI and Swift packages let the model layer, networking and business logic be written once, while each platform keeps the interface it should have. Retrofitting that split onto an app built for one platform is considerably more work than starting with it.
Yes, and it is often the better answer. A desktop app that talks to your own systems, signed for your team and distributed directly, avoids both App Store review and the compromises of squeezing an internal workflow into a browser tab.
Fixed scope, fixed price, agreed in writing before anything starts. You pay 50% on signing and the rest against two milestones you can see reached — design approval, then ready to launch. Nothing is billed by the hour, and the number does not move unless the scope does, in which case it is a signed change order rather than a surprise.
You do, outright. Source code, accounts, credentials and domains all transfer at launch, and there is no licence to keep paying for. If you want to take the code to another studio afterwards, nothing here stops you.
Anything that stops working within 30 days of going live is fixed at no cost — that is a defect, not a new request. After that, ongoing cover is a monthly care plan you can start or stop whenever; it is optional and is not needed for the work to be yours.
Designs are presented for review and you get 5 business days to approve or send changes, with a reminder before the window closes. If it passes with no answer the design counts as approved and the next payment falls due — you are told the day that happens.
Open a channel
The Mac is where the work happens.
If your people spend their day in a browser tab that was never meant for it, that is a desktop app waiting to be written.