Why Do I Have to Pay to Distribute Software I Built Myself?

By Sogo Kim 2026.10.20 14 min read

App Development · Code Signing · Indie Development · Software Distribution · Vibe Coding

A program that runs perfectly well on my computer can be treated as dangerous on someone else’s. Not because the code is broken or contains anything malicious, but simply because nobody can verify who made it. How does an operating system work out where a program came from, and how is a user supposed to decide whether to trust it?

Last year I released my first iOS app under my own name, which meant paying Apple a developer program fee of more than 100,000 won a year (Apple’s list price is $99). Later I built a macOS desktop app and tried to put it on the Mac App Store, but I was stopped at the upload step in Xcode, before the app ever reached review. Those two experiences taught me that building software and getting it into a state where other people can actually use it are entirely different problems.

Distribution Begins Only After You Pay

I had worked on mobile apps at a company, so I already knew that shipping an app required certificates. But I had always worked under the company’s developer account. It wasn’t until I went freelance that I learned what it takes to release an app under my own name: you enroll in the developer program yourself and pay more than 100,000 won every year. Apple gives away Xcode and its other development tools, and a free account lets you build and test apps on your own devices to a degree. To distribute through the App Store, though, you need a paid developer account. Paying didn’t settle everything, either. Certificates, provisioning profiles, and code signing settings were all tangled together, and I spent a good deal of time working through certificate errors. A web service, by contrast, is open to anyone once you deploy your code to a server and point a domain at it. Of course the web needs HTTPS certificates and server costs too, but at least you don’t have to register with an operating system vendor and pay them before you can publish your own website. Mobile apps were different. Finishing the program didn’t mean I could simply put it on other people’s devices.

Tiskofy, Which Only Runs on My MacBook

After that I built a macOS desktop app called Tiskofy. The name doesn’t mean anything. I strung some letters together, and I privately pronounce it “Tiseukopi.” You enter a YouTube URL, and it extracts the video or audio and saves it locally. I built it with the Tauri framework, using React for the interface and Rust for the native operating system features. I knew Rust reasonably well, which is partly why I chose Tauri, and it was my first time using it. What interested me was that I could build the interface with familiar web code and still reach file system and operating system features that a browser can’t easily touch. Development itself went fairly smoothly. The app ran just as I intended on my MacBook, and I still use it whenever I need it. The catch was that it looked like I would be the only person who could ever use it.

The App That Couldn’t Even Clear the Xcode Upload

I was ambitious about it. I even had AI help me make an app icon, and I wanted to list Tiskofy properly on the Mac App Store. But it never got far enough to be rejected. App Review wasn’t the problem; I couldn’t get past the step where Xcode uploads the build for review. I don’t remember the exact error. I recall it having something to do with the FFmpeg-related binaries I had bundled to process video and audio, but without the error logs I can’t say for sure what the cause was. It could have been a signing problem with an executable inside the app, or a conflict with some other build setting. Reading the documentation again now, I see that apps distributed through the App Store have to meet a number of requirements, including code signing and App Sandbox, and that an app bundling separate executables needs those files’ signatures and the bundle structure to be correct as well. At the time I tried to fix the errors without really understanding any of this. I remember certificate-related errors coming back no matter what I changed, but it was a year ago and the details are hazy. In any case, Tiskofy never made it onto the App Store. It runs without any trouble on my own computer, so why does handing it to someone else require so many checks?

What Does Code Signing Prove?

To answer that, I first had to understand what code signing is. Code signing attaches a digital signature to software so that the signer’s identity and the program’s integrity can be verified. It relies on public-key cryptography. A developer has a matched pair of keys, a private key and a public key: the private key creates signatures, and the public key verifies them. When you sign a program, its data is first run through a hash function, which turns input of any size into a fixed-length value; change the input even slightly and you will generally get a completely different result. The developer uses the private key to create a digital signature from that hash, and the user’s computer uses the public key to check that the program’s contents still match what was signed. That is how it is possible to tell whether someone has modified an executable after it was signed. That leaves one problem. Anyone can generate a key pair, so someone writing malware can sign their program just as easily. A valid signature by itself doesn’t tell you whether the signer deserves your trust. Certificate Authorities (CAs) fill that gap. A CA verifies an applicant’s identity through a defined process and issues a digital certificate that binds that identity to the applicant’s public key, and the operating system checks whether a certificate chains back to a CA it trusts. Code signing, in other words, isn’t just attaching a name tag to a program. It is a way of building a chain of trust, so that the system can tell who signed the software and whether it has changed since. A signature is not a safety guarantee, though. Malicious software can carry a valid certificate too. A signature is not a certificate of harmlessness; it is a way to confirm the signer’s verifiable identity and the program’s integrity.

Notarization and Gatekeeper on macOS

Beyond code signing, macOS has a process called notarization. Put simply, it is Apple’s automated check of software that a developer submits, looking for known malicious content and code signing problems. If the software passes, Apple issues a notarization ticket. Gatekeeper, the macOS security feature, checks things like the code signature and notarization status when you first open a program downloaded from the internet, and a program that fails the required checks may trigger a warning or be blocked from launching. If code signing tells you who signed a program and that it hasn’t changed since, notarization tells you that Apple has run an automated security check on it. It also matters whether you distribute through the Mac App Store or hand out an installer yourself, because the requirements differ. Apps listed on the Mac App Store go through Apple’s submission and review process and don’t need a separate Developer ID notarization. Apps distributed outside the store are generally signed with a Developer ID certificate and notarized so that Gatekeeper will trust them. A common format for direct distribution on the Mac is the DMG, a disk image that users open before dragging the app inside it to their Applications folder. But building a DMG and getting the app inside it through the security checks are separate matters. Things get more complicated when an app contains executables of its own. A program like Tiskofy that relies on an external tool such as FFmpeg may need to sign not only the app itself but also the executables embedded in it. For notarization outside the App Store, the app must also enable a security feature called Hardened Runtime, which makes attacks such as injecting code or tampering with memory while the program is running harder to pull off. So it isn’t enough to show who made the program; it also has to meet a set of conditions that protect it while it runs. Builds for the App Store have their own requirements covering the signing of embedded executable code, App Sandbox, and bundle structure. Since I have no error records from that time, I can’t tell which rule Tiskofy actually failed to meet. What looked like a single program during development turned out, at distribution time, to be a set of executables and settings that each have to be verified.

Windows EXE Files Aren’t So Different

Windows applications use a similar security model. I haven’t distributed a Windows program myself, so this part is based on Microsoft’s official documentation. If you’ve downloaded an unfamiliar EXE file from the internet, you may have seen a “Windows protected your PC” warning. It comes from a security feature called Microsoft Defender SmartScreen. As I understand it, the warning doesn’t necessarily mean the program is malicious; it can also appear for programs that are unsigned or haven’t yet built up enough reputation. Traditionally, signing an executable on Windows has meant getting a code signing certificate from a certificate authority. The two best-known types are the Organization Validation (OV) certificate, which verifies an organization’s identity, and the Extended Validation (EV) certificate, which involves a stricter identity check. These certificates use the same public-key trust model as the HTTPS certificates on websites, but for a different purpose: an HTTPS certificate verifies a server’s identity and protects traffic between the browser and the server, while a code signing certificate verifies who signed an executable and that it is intact. You don’t always have to buy a commercial certificate to distribute a Windows program, though. If you submit an app to the Microsoft Store as an MSIX package, Microsoft signs the validated package itself, so the developer doesn’t need a commercial code signing certificate. Submitting an MSI or EXE installer to the Store requires you to sign it yourself with a trusted certificate. And if you distribute an EXE from your own website, signing isn’t strictly required, legally or technically, but an unsigned program is much more likely to trigger SmartScreen warnings, which puts it at a disadvantage with ordinary users. Even a valid certificate doesn’t guarantee that the warning will disappear. SmartScreen weighs several signals, such as how widely a program is used and whether security problems have been found in it before. A newly released program can therefore still trigger a warning, even if it was built safely, simply because there isn’t enough information yet to judge it. EV certificates used to be promoted as a way to avoid the warning immediately, but according to Microsoft’s documentation they no longer guarantee that. On both Windows and macOS, in the end, there are extra steps between building a program and distributing it in a form people can trust.

So Why Does It Cost Money?

This is what puzzled me most when I first joined Apple’s developer program. The development tools are free, so why does handing the result to someone else cost extra? Running a certificate-based trust system must cost real money. A CA has to verify applicants’ identities, operate systems that let anyone check whether a certificate is still valid, and keep a way to revoke certificates and stop trusting them when a private key leaks or a certificate is abused. Still, not every fee paid to distribute software is the same kind of fee. Apple’s annual fee is closer to the cost of access to App Store distribution and a range of developer services than the price of a single certificate. A commercial code signing certificate on Windows, by contrast, is more clearly payment for identity verification and for issuing and managing the certificate. In addition to selling certificates, Microsoft offers a cloud-based code signing service called Azure Artifact Signing (previously Trusted Signing). According to Microsoft’s documentation, the basic plan starts at $9.99 a month. But a low price doesn’t mean anyone can use it. As of October 2026, individual developers can use the service only in the United States and Canada, so an individual developer in South Korea can’t simply sign up and may have to consider a certificate from another certificate authority to sign software for direct distribution. An expensive certificate isn’t mandatory on every operating system or for every distribution method. Still, an individual developer who wants to offer an installer from their own website runs into identity verification, code signing, and platform-specific security policies. I fully understand the need to protect users from malicious software. A program from an unknown source that can read or modify files on a user’s computer and launch other programs is dangerous. But the burden of getting through these procedures is very different for an individual who has just built a first program and for a company that has been shipping software for years. And buying a certificate and signing a program doesn’t earn software trust automatically, either. Proving who you are and building software that people can actually trust are separate problems.

The Barrier AI Lowered, and the One It Didn’t

With advances in AI, many more people now build programs through so-called vibe coding. Even someone without much development experience can describe the feature they want in plain language, tweak the code the AI writes, and end up with a program that really works. I think desktop applications are an especially good tool for solving the big and small problems of everyday life. They can run without a server, they can process data right on the user’s computer instead of sending it elsewhere, and they can use file system and operating system features. Batch-converting files, automating repetitive chores, and tidying data in a particular format are typical examples. Writing such programs used to take considerable development knowledge, but with AI’s help they can now be built with far less time and effort. But trying to distribute or sell what you’ve built starts a very different set of problems. AI can do much of the work of packaging a program as an EXE or a DMG, and it can write the commands for code signing or fix build settings. Registering a developer account, getting your identity verified, and qualifying for the certificates and signing services you need won’t be solved by writing code well, though. The code AI can write for you and the procedures in which a real person or organization proves who they are are separate problems. Add operating-system-specific build environments, CPU architectures, bundled binaries, automatic updates, license management, and payment systems, and you start to see how many steps lie between making a personal tool and selling a software product. I ran into that gap with Tiskofy. AI helped me a great deal in building the program, but I never solved the problems that came up when I tried to distribute it. Looking back, what I had finished was a working program, not a product ready to ship. As AI brings more people into building software, I suspect more of them will meet this problem for the first time.

The Freedom to Build and the Responsibility to Distribute

Of course, even if I had solved the Xcode upload problem, I can’t say Tiskofy would have been accepted onto the App Store. An app that extracts video or audio from YouTube can raise copyright or platform terms-of-service questions depending on how it is used, and it would also have to be checked against App Review guidelines. The wall I hit back then was only one of several gates on the way to distribution. I believe code signing and notarization are essential. A program that runs on a user’s computer can reach operating system features far more widely than a website can, and letting executables of unknown origin run with no verification at all carries real risk. But who should operate that system of trust, by what standards it decides which programs to trust, and who should bear the cost are separate questions worth thinking about. The web also depends on browser security policies and the certificate authorities’ chain of trust, so it is not a lawless space either, but publishing a website and distributing a binary that will run on someone’s own computer involve different kinds of verification and responsibility. With AI lowering the barrier to software development, I expect more people who aren’t professional developers to try to sell programs they built to solve their own problems. In that process, understanding distribution, security, and systems of trust will matter as much as the ability to write code. Making a program easier to build has not made it any easier to hand to someone else. Tiskofy is still installed on my MacBook. I never listed it on the App Store and never sold it to anyone, but it does what I need it to. At first I assumed that finishing a program meant I could give it to anyone. But distributing software turned out to be more than handing over a finished file. It meant thinking about where the file came from, who is responsible for it, and what reason users have to trust it. AI has lowered the barrier of time and technical skill needed to make a program, but it doesn’t take responsibility for the program you make. Finishing a program and turning it into a product that other people can trust and use remain two different problems.