feature article
Subscribe Now

No Reindeer In Appland

Q: What did the Swedish lawyer say to his Finnish colleague? A: So Suomi.

Lame Scandinavian puns aside, let’s all give Yuletide thanks to the humble “app,” the now-popular term for third-party programs. Embedded systems didn’t use to have apps. Indeed, that was their defining characteristic: any box that shipped with all the software it would ever have, and they didn’t accept third-party programs. Elevator controllers were clearly embedded systems; a Macintosh clearly wasn’t.

But now formerly embedded systems like cell phones have apps galore, and even tech-phobic grandmothers know what apps are. The world of third-party software has descended into the embedded realm—but in a very different way than we’re used to seeing. Whether for good or ill, we’re not developing, testing, or selling embedded apps the way we did for PCs, Macs, and Linux boxes. No, siree. This is a whole new ballgame. We’ll start with Apple, but you can fill in BlackBerry, Android or most other brands as you see fit.

Apple maintains tight-fisted control over all the apps that run on the iPhone/iPad/iPod gadgets. Any programmer can write an iPad app, but only Apple can sell it. That means you can’t just pass around demo CDs or offer free downloads for the simple reason that all apps have to pass through iTunes. It’s the only way to get code onto (or off of) an iGadget. So unless Apple blesses your code via iTunes, it ain’t getting on their hardware.

Video game makers take a similar, but opposite, approach. You may have noticed that you can’t write your own PlayStation 3 game and sell it online. No, sir, you have to sign a developer’s agreement with Sony and be officially sanctioned to develop PS3 games. The same goes for Nintendo and Microsoft game consoles. That’s why there are no open-source video games.

In all three cases, Nintendo/Sony/Microsoft reveal to you the details of their hardware systems and programming tricks. In return, you agree to uphold certain company standards (no X-rated games, please) and to abide by their quality testing (no bug-infested games, please). But the most important requirement is that Nintendo/Sony/Microsoft have the final word on whether you can sell your game at all. Without their sign-off, your app is dead in the water. Assuming you get the stamp of approval, you can sell the game through any channel you like: retail stores, downloads, of whatever suits you.

So Apple and the console makers take opposite approaches to get the same results. Apple says anyone can create apps but only Apple can sell them. Nintendo, Sony, and Microsoft say anyone can sell apps but only approved developers can create them. Apple controls distribution while the console makers control development.

In all cases, the hardware vendor is the gatekeeper. They decide what code runs on their platform and, by extension, who gets to develop it. If Nintendo doesn’t want you writing Wii games because they don’t like the color of your eyes or your middle initial, then presumably they can deny you that privilege.

The other thing that Apple, RIM, and the console makers have in common is that they all take a cut of the software revenue. Not incidentally, their gatekeeper role allows them to collect a toll on every app passing through their fingers. In the case of $0.99 iPhone apps, that amounts to just a few cents per download. But for blockbuster video games that retail for $60, Microsoft, Sony, and Nintendo take a hefty chunk right off the top.

This videogame royalty is what pays for the hardware. You didn’t really think your PS3 cost $299 to build, did you? Quite the contrary: Nintendo, Sony, and Microsoft all sell their respective game consoles at a loss. They might as well be taping $100 bills to the outside of the box. All three companies make up the difference on the games, at about $10 to $25 a pop. After you’ve bought enough games, the product starts to be profitable. (If a nefarious and ballistically wealthy Bond villain wanted to bankrupt the video game makers, he’d buy millions of consoles but no games.)

As a game developer, that means you have to share your revenue with the console maker, after first getting approved by said console maker. Essentially the same rules apply for iWidget apps: you share the wealth with Apple, but only after Apple agrees to distribute your masterpiece. 

What Does It All Mean?

So what does this brave new business model portend for the poor, wretched software developer? For starters, you’ve got to be approved by your hardware developer; that’s obvious. In a sense, your software becomes less your individual effort and more of an extension of the hardware vendor’s brand.

Second, it means you’re going to share some of your revenue, which you might not have done with the “open” PC/Mac/Linux way of things. In addition to your fixed distribution costs, you’ve now got a royalty burden as well. 

On the plus side, this may lead to better quality software. Additional testing rarely introduces new bugs; it tends to squash existing ones. Having an extra set of eyes at Nintendo’s QA department may put the final polish on a product before it hits the streets. That’s good news for everyone.

As the Norwegian snowmobile repairman said to his customer, “you blew a seal.” Some programmers will blow a gasket awaiting vendor approval for their software. The wait time may be months or it may be mere days, but it introduces a nonzero delay either way. The approval process also introduces a kind of Big Brother oversight that many programmers aren’t accustomed to. “I’ll release my code when and how I feel like it,” doesn’t cut it in the new app economy.

For hardware vendors, it’s a dream come true. “I get paid for my hardware and for all the software that runs on it? Sign me up!” Who wouldn’t accept that deal? Plus, it allows them to “control the brand” by selectively approving only those apps that promote their desired image, values, and reputation. As Apple’s official developer guidelines state in black and white, “we don’t need any more Fart apps.” And no, I don’t know why it’s capitalized.

The same document goes on to say, “If it sounds like we’re control freaks, well, maybe it’s because we’re so committed to our users and making sure they have a quality experience with our products.” Well, that’s one explanation. Controlling the “experience” is important to many companies, and controlling software development and distribution is an extraordinarily effective way to do that. Or, it could just be a money-grubbing way to get between the customer and the programmer. It’s a free market; if you don’t like it you can try to sell your apps somewhere else.

The “open” and non-entangled software business still exists. You can still write apps for PCs, Linux boxes, Macintoshes, and a thousand other hardware platforms without official dispensation from the hardware vendor. You can deal directly with your customers/users and handle your own distribution channel. I don’t think that traditional model is ever going away… but I do think it’s disappearing over the horizon. There’s so much incentive for hardware vendors to handle apps distribution that most new platforms will follow suit. After all, isn’t that the embedded way? Time was, the hardware developer created also created all the software. There were no outside apps. By tightly controlling development and/or distribution, we’re really just returning to the embedded way of doing things. 

Leave a Reply

featured blogs
Dec 19, 2024
Explore Concurrent Multiprotocol and examine the distinctions between CMP single channel, CMP with concurrent listening, and CMP with BLE Dynamic Multiprotocol....
Dec 20, 2024
Do you think the proton is formed from three quarks? Think again. It may be made from five, two of which are heavier than the proton itself!...

Libby's Lab

Libby's Lab - Scopes Out Littelfuse's SRP1 Solid State Relays

Sponsored by Mouser Electronics and Littelfuse

In this episode of Libby's Lab, Libby and Demo investigate quiet, reliable SRP1 solid state relays from Littelfuse availavble on Mouser.com. These multi-purpose relays give engineers a reliable, high-endurance alternative to mechanical relays that provide silent operation and superior uptime.

Click here for more information about Littelfuse SRP1 High-Endurance Solid-State Relays

featured chalk talk

Reliability: Basics & Grades
Reliability is cornerstone to all electronic designs today, but how reliability is implemented and determined can vary widely by different market segments. In this episode of Chalk Talk, Amelia Dalton and Sam Accardo from the YAGEO Group explore the definition of reliability for electronic components, investigate the different grades of reliability offered by the YAGEO Group and the various steps that the YAGEO Group is taking to ensure the greatest reliability of their components.
Aug 15, 2024
53,494 views