Word Counter - Writing Productivity App for macOS

The Context

Word Counter was born from my own need as a writer to track daily output. Started in 2014, it was my first commercial Mac app and my introduction to the world of indie development proper.

The app measures writing productivity, helping authors maintain consistent output and reach their goals.

Technical Challenges

Architecture Evolution

• Started with VIPER architecture in Objective-C
• Gradually migrated to MVVM in parts as the app grew
• Partially ported to Swift while maintaining Objective-C interop
• Managed a mixed codebase through multiple macOS and Swift versions
• Started with Cedar BDD-style tests, introduced other test frameworks as time progressed and when XCTest was eventually introduced as a first-party solution

Modular Development Out of Necessity

As a poor student with an underpowered Mac Mini, I didn’t have the resources to compile large codebases for TDD – compilation times would kill my flow. So I developed a different approach: I worked on framework bundles, individual dynamically linked libraries that I could compile and test in isolation. This was not very common back then as iOS hardware limitations in particular made startup times slower when you linked too many libraries. And “too many” wasn’t actually a lot. So I was a bit scared about the outcome for my project on Mac, but it worked really well: Only a small shell app would assemble these components into the actual application.

This constraint-driven architecture turned out to be a blessing:

• Each framework had its own test suite that ran in seconds, not minutes
• Clear module boundaries enforced better separation of concerns, helping me enforce best practices even when I would like to take shortcuts
• I could iterate rapidly on individual features without rebuilding everything
• The architecture naturally supported the VIPER pattern’s module isolation

What started as a workaround for hardware limitations became a principled approach to modular app development that I still advocate today.

For Word Counter specifically, I developed some features as isolated packages that eventually became open source components. This taught me the value of building reusable, well-tested modules that could benefit both my apps and the wider community.

This approach would evolve further in TableFlip, where I used even more framework targets within the app itself. Eventually, this became my standard approach for complicated apps: I’d identify the features and visual UI components I wanted, develop the UI components in isolation as modular pieces, and only integrate them into the app very late in the process. This “late integration” approach meant each component was truly independent and reusable.

Early Swift Adoption

• Began porting during Swift 1.0 days
• Navigated breaking changes through Swift 2, 3, and beyond
• Learned when to port and when to keep stable Objective-C code

Rolling My Own Store

Word Counter was where I first implemented FastSpring integration for selling outside the Mac App Store.

This involved:

• Building a complete license key generation and verification system (which Rich Siegel of Bare Bones Software called the trial every developer has to go through)
• Implementing time-based trials with proper expiration handling
• Integrating everything into the app and making a web front

This FastSpring integration became the foundation for my book “Make Money Outside the Mac App Store”, where I documented everything I learned about selling Mac apps independently. The battle-tested code from Word Counter became the sample implementations in the book, helping other developers escape the App Store’s 30% cut.

Team Dynamics

As my first solo commercial project, Word Counter taught me about the full product lifecycle:

• Customer support and feature requests with a larger customer base and direct contact – which the App Store wouldn’t allow
• Marketing to writers and academics, participating in bundle sales and sponsoring blogs
• Building sustainable revenue through direct sales, upgrade pricing, and customer relationships

Personal Reflections

Word Counter was my app development education:

• Over-engineering with VIPER when MVC would have sufficed; the ‘scene’-like wireframe idea was interesting, but didn’t really fit this project
• The complexity of maintaining mixed-language codebases (to this day!)
• The importance of saying “no” to feature requests
• How to build software that lasts decades, not months

Looking back, I was doing many things for the first time and trying to do them well – but also manually. The VIPER architecture meant wiring everything by hand, maintaining full control over every interaction. It would take years before I’d discover (particularly with Enai) that AppKit actually offers more elegant and robust patterns if you work with its conventions rather than inventing your own. But this early exploration taught me the value of understanding what you’re abstracting before you abstract it.

This app showed me that successful software doesn’t need to be complex. Writers want to write, not fiddle with settings. This “do one thing well” philosophy influences all my work.

Impact

Over the 10+ years, Word Counter has helped thousands of writers:

• NaNoWriMo participants tracking their daily progress
• Academic writers managing dissertation output
• Journalists meeting daily quotas
• Bloggers maintaining publishing schedules

Most importantly, Word Counter proved to me that indie development was viable. Its steady success gave me the confidence in my own products. There was a way to write solid software that doesn’t crash and delights people.