Marco.org

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:

• Copyright protects your icon, images, other creative resources, and source code. You automatically have copyright protection, but it’s easy to evade with minor variations.¹ App stores don’t enforce it easily unless resources have been copied exactly.
• Trademarks protect names, logos, and slogans. They cover minor variations as well, and app stores enforce trademarks more easily, but they’re costly to register and only apply in narrow areas.²

• Only assholes get patents. They can be a huge PR mistake, and they’re a fool’s errand: even if you get one ($20,000+ later), you can’t afford to use it against any adversary big enough to matter.

  Don’t be an asshole or a fool. Don’t get software patents.

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:

• If they’re more successful than you, it’s envy and sour grapes.
• If they’re less successful than you, it’s jealousy and punching down (and giving them attention!).
• The public may have a very different opinion on whether you’re really being copied from, whether you were really the first to do it, or whether you deserve to “own” it.

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.

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.¹ 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 doesn’t feel WatchKit’s limitations. Since they’re not using it, it’s too easy for Apple’s developers and evangelists to forget or never know what’s possible, what isn’t, what’s easy, and what’s hard. The bugs and limitations I report to them are usually met with shock and surprise — they have no idea.
• WatchKit is buggy as hell. Since Apple doesn’t use it and there are relatively few third-party Watch apps of value, WatchKit is far more buggy, and seems far less tested, than any other Apple API I’ve ever worked with.²

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.