What you are buying
Mac apps for sale are sold through two very different channels, and the channel shapes what you acquire. An app on the Mac App Store moves between developer accounts through Apple's app transfer process, but Apple's criteria exclude some apps, including Mac apps that have used the sandbox environment and share an Application Group Container Directory with other Mac apps. An app sold directly from the developer's website usually takes payments through a provider like Paddle, Lemon Squeezy, or Stripe, issues license keys from its own server, and delivers updates through a framework such as Sparkle.
Direct-distribution apps carry signing obligations that matter at handover. Apple's Developer ID page explains that Gatekeeper checks for a Developer ID certificate on software distributed outside the Mac App Store and that only the team's Account Holder can generate that certificate. Sparkle verifies updates with an EdDSA key whose public half is embedded in the shipped app; its documentation asks developers to keep the private key safe, and says that if it is lost, new updates can still be signed for Developer ID apps through key rotation, which can change either the code signing certificate or the EdDSA key in one update but not both. A buyer therefore needs a carefully sequenced first release under their own Developer ID.
What to check before making an offer
Confirm the distribution channel and eligibility
Find out whether the app is sold on the Mac App Store, directly, or both. For App Store apps, check Apple's transfer criteria, including the sandbox container rule for Mac apps. For direct apps, list the payment provider, license server, and download hosting.
Plan the signing and update key handover
Get the Sparkle EdDSA private key and confirm it matches the public key in shipped builds. Plan the first update under your own Developer ID certificate using Sparkle's key rotation rules. A mistake here can stop existing users from receiving updates.
Review the license system and upgrade policy
Understand how license keys are generated, validated, and deactivated, and whether old versions phone home. Ask how many perpetual licenses are outstanding and what upgrade pricing has been promised. Past promises of free lifetime updates are a cost you inherit.
Check macOS compatibility work
Ask when the app was last tested on the current macOS release and Apple silicon. Review use of private APIs, deprecated frameworks, or kernel and system extensions. Each annual macOS release can require maintenance work.
Separate upgrade spikes from steady sales
Paid-upfront Mac apps often see revenue spikes around major version launches and sales events. Ask for at least a year of monthly revenue split by new licenses, upgrades, and subscriptions so a single launch month is not mistaken for the run rate.
How these businesses are valued
Mac apps often mix business models: perpetual licenses with paid upgrades, subscriptions, and App Store purchases. Perpetual-license revenue is lumpier and more dependent on shipping new versions than subscription revenue, so buyers usually lean on owner earnings over a longer period rather than annualizing a recent month. The SBA's income approach, which projects revenue adjusted for risk, fits this better than a revenue multiple.
Price in the technical continuity risk specific to the platform. The cost of moving signing certificates and update keys, keeping pace with annual macOS releases, and honoring outstanding upgrade promises should come off the top of what you offer. For App Store apps, remember that revenue shown before fees overstates proceeds; use the app store fee calculator. RevenueBug verifies revenue from connected providers but does not appraise apps.
Model a range with the SaaS valuation calculator, then work through the buyer due diligence checklist.