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
Nov 25, 2020
It constantly amazes me how there are always multiple ways of doing things. The problem is that sometimes it'€™s hard to decide which option is best....
Nov 25, 2020
[From the last episode: We looked at what it takes to generate data that can be used to train machine-learning .] We take a break from learning how IoT technology works for one of our occasional posts on how IoT technology is used. In this case, we look at trucking fleet mana...
Nov 25, 2020
It might seem simple, but database units and accuracy directly relate to the artwork generated, and it is possible to misunderstand the artwork format as it relates to the board setup. Thirty years... [[ Click on the title to access the full blog on the Cadence Community sit...
Nov 23, 2020
Readers of the Samtec blog know we are always talking about next-gen speed. Current channels rates are running at 56 Gbps PAM4. However, system designers are starting to look at 112 Gbps PAM4 data rates. Intuition would say that bleeding edge data rates like 112 Gbps PAM4 onl...

featured video

Accelerate Automotive Certification with Synopsys Functional Safety Test Solution

Sponsored by Synopsys

With the Synopsys Functional Safety Test Solution architecture, designers of automotive SoCs can integrate an automated, end-to-end BIST solution to accelerate ISO compliance and time-to-market.

Click here for more information about Embedded Test & Repair

featured paper

Keys to quick success using high-speed data converters

Sponsored by Texas Instruments

Whether you’re designing an aerospace system, test and measurement equipment or automotive lidar AFE, hardware designers using high-speed data converters face tough challenges with high-frequency inputs, outputs, clock rates and digital interface. Issues might include connecting with your field-programmable gate array, being confident that your first design pass will work or determining how to best model the system before building it. In this article, we take a look at each of these challenges.

Click here to download the whitepaper

Featured Chalk Talk

Mom, I Have a Digital Twin? Now You Tell Me?

Sponsored by Cadence Design Systems

Today, one engineer’s “system” is another engineer’s “component.” The complexity of system-level design has skyrocketed with the new wave of intelligent systems. In this world, optimizing electronic system designs requires digital twins, shifting left, virtual platforms, and emulation to sort everything out. In this episode of Chalk Talk, Amelia Dalton chats with Frank Schirrmeister of Cadence Design Systems about system-level optimization.

Click here for more information