Marco.org

I’m : a programmer, writer, podcaster, geek, and coffee enthusiast.

Defending your app from copies and clones

App developers sometimes ask me what they should do when their features, designs, or entire apps are copied by competitors.

Legally, there’s not a lot you can do about it:

If someone literally copied your assets or got too close to your trademarked name, you need to file takedowns or legal complaints, but that’s rarely done by anyone big enough to matter. If a competitor just adds a feature or design similar to one of yours, you usually can’t do anything.

You can publicly call out a copy, but you won’t come out of it looking good:

These disputes are best kept private, or not fought at all.

Nobody else will care as much as you do. Nobody cares who was first, and nobody cares who copied who. The public won’t defend you.

The instant someone else has the same feature or design as you, the public and press see it as a collective checkbox feature, or a “standard” or “obvious” design, that apps in this category just have. It’s no longer yours.

You can try to “educate” the public, but you’ll lose.

This feels unfair when it happens to you, but it’s just how it goes, and the entire ecosystem benefits. Every app — even yours — includes countless “standard” and “obvious” features and designs that, at one time, weren’t. Everything is a remix.

A great design or feature can give you a competitive advantage for a little while, but it’s always temporary. Compete on marketing, quality, and what you can do next, not the assumption that nobody can copy what you made.

Setting the roadmap for competitors is a satisfying accomplishment, but only a personal one. You know you’ve done it. That has to be enough.


  1. For instance, nobody else can make an app that uses Overcast’s exact icon, or anything clearly derivative of it, but I can’t stop anyone from making a different-looking, originally-drawn orange icon with a radio tower in it. ↩︎

  2. For instance, nobody else can make an audio player named Overcast or anything similar to it, but I can’t stop anyone from making a weather app with that name. And other podcast players can’t make features named Smart Speed or Voice Boost, but I can’t stop them from making similar features with different-enough names. ↩︎

WatchKit is a sweet solution that will only ever give us baby apps

In the original 2007 iPhone introduction, Steve Jobs famously derided other smartphones at the time for running “baby” software and the “baby” internet. He was right.

Developers weren’t given access to make native apps until the iPhone’s second year. Before the native development kit was ready, Apple tried to pass off web apps as a “sweet solution” for third-party apps, but nobody was fooled.

Apple wasn’t using web apps for their own built-in iPhone apps — they were using native code and frameworks to make real apps.1 Developers like me did our best with web apps, but they sucked. We simply couldn’t make great apps without access to the real frameworks.

Apps were terrible, and didn’t take off, until we had access to the same native tools that Apple used.

*   *   *

Developing Apple Watch apps is extremely frustrating and limited for one big reason: unlike on iOS, Apple doesn’t give app developers access to the same watchOS frameworks that they use on Apple Watch.

Instead, we’re only allowed to use WatchKit, a baby UI framework that would’ve seemed rudimentary to developers even in the 1990s. But unlike the iPhone’s web apps, WatchKit doesn’t appear to be a stopgap — it seems to be Apple’s long-term solution to third-party app development on the Apple Watch.

The separation of Apple’s internally-used frameworks from WatchKit has two huge problems:

Apple will never have a very good idea of where WatchKit needs to improve if they’re not using it. But this sweet solution is the only choice anyone else has to make Apple Watch apps.

WatchKit only lets us create “baby” apps. That’s all it will ever let us create.

WatchKit needs to be discontinued and replaced.

No focus on quality or expansion of WatchKit will fix this. There are only two ways to meaningfully improve Watch apps, spur third-party innovation, and unlock the true potential of the Apple Watch.

One solution is for Apple to reimplement all of its own Watch apps with WatchKit instead of their internal frameworks, which will force them to fix WatchKit’s many bugs and dramatically expand it.

The much better solution, and the one I hope they take, is for Apple to expose its real watchOS UI and media frameworks to third-party developers, as it has done on iOS.

*   *   *

I also made this argument in podcast form in Under The Radar 114.


  1. Defensive web developers who object to my “real” classification, remember this was 2007 hardware with 2007 cellular speeds and 2007 browser capabilities. You don’t realize how good you have it today. (But most apps should still be native.) ↩︎

  2. Here’s one from today for WKAudioFilePlayer, an abysmal, demoralizing API that I lost weeks of my life battling that feels like it had literally zero testing at Apple. I’d bet money that nobody at Apple has ever tried to build an app with it. ↩︎