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
Feb 26, 2021
OMG! Three 32-bit processor cores each running at 300 MHz, each with its own floating-point unit (FPU), and each with more memory than you than throw a stick at!...
Feb 26, 2021
In the SPECTRE 20.1 base release, we released Spectre® XDP-HB as part of the new Spectre X-RF simulation technology. Spectre XDP-HB uses a highly distributed multi-machine multi-core simulation... [[ Click on the title to access the full blog on the Cadence Community si...
Feb 24, 2021
mmWave applications are all the rage. Why? Simply put, the 5G tidal wave is coming. Also, ADAS systems use 24 GHz for SRR applications and 77 GHz for LRR applications. Obviously, the world needs mmWave tech! Traditional mmWave technology spans the 30 – 300 GHz frequency...

featured video

Designing your own Processor with ASIP Designer

Sponsored by Synopsys

Designing your own processor is time-consuming and resource intensive, and it used to be limited to a few experts. But Synopsys’ ASIP Designer tool allows you to design your own specialized processor within your deadline and budget. Watch this video to learn more.

Click here for more information

featured paper

How to Fast-Charge Your Supercapacitor

Sponsored by Maxim Integrated

Supercapacitors (or ultracapacitors) are suited for short charge and discharge cycles. They require high currents for fast charge as well as a high voltage with a high number in series as shown in two usage cases: an automatic pallet shuttle and a fail-safe backup system. In these and many other cases, the fast charge is provided by a flexible, high-efficiency, high-voltage, and high-current charger based on a synchronous, step-down, supercapacitor charger controller.

Click here to download the whitepaper

Featured Chalk Talk

Smart Embedded Vision with PolarFire FPGAs

Sponsored by Mouser Electronics and Microchip

In embedded vision applications, doing AI inference at the edge is often required in order to meet performance and latency demands. But, AI inference requires massive computing power, which can exceed our overall power budget. In this episode of Chalk Talk, Amelia Dalton talks to Avery Williams of Microchip about using FPGAs to get the machine vision performance you need, without blowing your power, form factor, and thermal requirements.

More information about Microsemi / Microchip PolarFire FPGA Video & Imaging Kit