At WWDC, Apple unveiled a new App Extension architecture for both iOS 8 and OS X Yosemite. Here's how the new extensions enable a new type of widgets in Notification Center for both platforms, along with enabling third party Custom Keyboards for iOS.

Apple introduced a wide variety of new avenues for third party development under iOS 8 and OS X Yosemite that are all tied together by the common thread of App Extensions. The previous article examined Photo Editing Extensions for Apple's new Cloud Kit-savvy Photos app.

This article examines how the same underlying technology is being put to work to create "Today Extensions," which are widgets that will appear in Notification Center, as well as Custom Keyboards for use on mobile devices.

Is Apple just really slow at stealing Android features?

Home screen widgets and third party keyboards (which replace the default system keyboard) have been associated with Android for the last five years as something iOS has lacked.

Given that Apple created the concept of Desk Accessories as mini apps for the Mac desktop back in 1981, and that OS X Tiger promoted more recent Dashboard Widgets back in 2005 (before Google even acquired Android), it might make you wonder why Apple is only now introducing standalone widgets for iOS.

Custom Keyboards pose a similar quandary: iPhone presented a virtual onscreen keyboard when it debuted in 2007 as one of its primary differentiating features. Additionally, among the first iOS App Store titles in 2008 was ShapeWriter, a non-traditional keyboard app that input text via gestures using technology developed at IBM and LinkÃ¶ping University, similar to Swype (both of which have since been acquired by Nuance, which has already announced support for Swype as a Custom Keyboard Extension for iOS 8).

While the original ShapeWriter could record text, the user had to copy and paste what they'd entered into the app they wanted to use, making the technology far less useful than custom keyboards integrated right into apps (like the custom numeric keyboard presented in Apple's Numbers, below) or the system itself (enabling input into any installed app).

Android didn't even debut until nearly a year after ShapeWriter, in part because Google's original concept for Android was a Java Mobile button phone, just like everyone else had been selling.

In 2009, Google threw open the door to widgets and third party keyboards in Android 1.5 Cupcake, nearly a year before the platform began catching on in the market. That resulted in virtually all Android users being familiar with the concept of both ideas, despite Android having shown up two years late to the iPhone party in terms of virtual keyboards.

Why Apple didn't focus on widgets and third party keyboards

Given that Apple had such an early lead, why has the company resisted opening up a third party market for system-integrated custom keyboards and Home screen widgets over the past five years? In a nutshell: performance, privacy and security.

Apple's focus on performance, privacy and security in iOS have trumped Android's widgets and custom keyboard features in the market for premium phones, keeping Apple sustainably profitable as other hardware makers using Android have gone out of business or regularly lost money (including Google's own Motorola, which lost hundreds of millions of dollars in quarter after quarter).Even if Tim Cook has a time machine, he has no need to travel back to 2009 to urge iOS engineers to focus on widgets and third party keyboards

Consider that Android's best performer, Samsung, has seen its stock appreciate over the last five years by 119.3 percent while Google's stock is up 175.24 percent over the same period.

Over the same five years, Apple stock is up over 362 percent, despite the media's delusional panic throughout 2013. Even if Tim Cook has a time machine, he has no need to travel back to 2009 to urge iOS engineers to focus on widgets and third party keyboards.

That's not to say that there's no value in widgets or custom keyboards. Android's promotion of both has highlighted a variety of interesting abilities. And of course, Apple's iOS has also incorporated system-supplied widgets (like Stocks and Weather) and app-specific custom keyboards (again, as in Apple's own Numbers). What Apple hasn't done is fling iOS wide open to unrestricted hobbyist experimentation without considering the consequences.

Google's decision to do just that with Android has manifested the problems associated with rushing poorly conceived, half baked solutions to market. Widgets on Android are commonly associated with battery drain and can help contribute to the noticeable performance lag that still affects the system.

Additionally, Google's implementation of both widgets and third party keyboards expose significant security vulnerabilities and privacy issues that many end users wouldn't reasonably assume possible. It's virtually impossible for Google to police whether a third party keyboard spies on users. And it is well known that many actually do, recording users' key presses and uploading the data via the network because there's no functional security boundaries in place to stop such malicious activity from occurring.

Security on Android is largely based upon naive trust. Even apparently legitimate custom keyboard developers have been found to send users' keystrokes back to their servers for processing in clear text making everything they type open to anyone listening.

As an experienced platform vendor that has dealt with malicious security attacks decades before Google was even incorporated, Apple exercises a lot more concern about leaving its platform open to exploit. It also doesn't delegate its basic security design to end users, most of whom have no expertise in navigating the complex issues involved.

In the design of Android, Google has repeatedly bet that nothing bad will ever happen, and has regularly lost that bet at the expense of its users. But the reputation of Android has also become tarnished, particularly affecting valuable clients in government and in the corporate enterprise, where Android remains a minority overall and offers Apple's iPad virtually no competition in tablets at all.

Widgets moving from OS X Dashboard to Notification Center

In both iOS 8 and OS X Yosemite, Apple will present widgets within Notification Center, owing to the relationship between push notifications and widgets' primary role in displaying regularly updated information. For this reason, Apple commonly refers to the new widgets as "Today Extensions."

On OS X, Today Extensions will effectively replace the Dashboard widgets introduced nearly a decade ago in OS X Tiger (below). Dashboard widgets were conceived as desk accessories that could be quickly invoked and dismissed, and were implemented in HTML, CSS and JavaScript to allow for a similar level of security sandboxing as standard web pages. Web standards have been designed not to implicitly trust foreign hosts.

However, rather than being, effectively, mini web pages like Dashboard widgets, Today Extensions are native code that—like other App Extensions—use a new security model based on Apple's XPC and modern iOS-style Cocoa sandboxing. They are launched by the system and dynamically managed; if they use too much memory on iOS, the system can terminate them to maintain optimum performance.

Building the infrastructure to support such as secure, native implementation has taken years of engineering behind the scenes. XPC, which Apple describes as an "interprocess communication technology that complements App Sandbox by enabling privilege separation," was first introduced in OS X Lion in 2011. Privilege separation is key to allowing App Extensions to perform limited tasks without opening up dangerous new vulnerabilities.

In addition to native performance and a mature security infrastructure, App Extensions also need a viable market supporting them. Dashboard widgets have long languished on OS X after their initial novelty wore off, in part because of the delay involved with launching the web rendering process that animates them when users invoke Dashboard, and in part because free Dashboard widgets lacked a functional business model similar to App Store apps.

Today Extensions (as with all forms of App Extensions) are packaged with new or existing apps, making it possible for developers to market the new widgets as a valuable feature of their paid (or ad supported) apps.

Today Extensions on iOS 8 & OS X Yosemite

Today Extensions will work slightly differently on iOS and OS X; on mobile devices, the widgets appear as touchable presentations that lack text input or editing features (meaning that a stocks widget, for example, would need a companion app to edit the list of stocks it presents). On OS X, widgets can be edited in place and can support text input.

These differences are largely due to the fact that on iOS, Notification Center is a temporary pull down designed to present information at a glance. Add a keyboard and editing controls, and the value of presenting widgets would be crowded out by all of the editing UI. Mobile devices also have less processing power and memory available to devote to widgets than a Mac would.Apple's vision for Today Extensions is clearly aimed at presenting quick access to scores, stocks and similar information in the context of other notifications

On iOS, any sort of widget that demands more UI and resources than Notification Center can reasonably accommodate would make more sense to implement as a standalone app—just as Apple implemented its own Stocks and Weather "widget apps" seven years ago on the original iPhone.

In contrast to Android, Apple's vision for Today Extensions is clearly aimed at presenting quick access to scores, stocks and similar information in the context of other notifications, rather than simply padding the Home screen with a busy box of fluff to make up for a lack of significant, native apps.

Apple's Notification Center & Android widgets

Like widgets themselves, Notification Center is another feature Android users like to complain that Apple "stole" from an open source project built upon, ironically, the foundation of "copy left" ideology where there is no such thing as stealing.

However—just as with the overall concept of both widgets and a multitouch mobile device designed to launch discrete apps from a home screen of icons—Apple publicly outlined its efforts to develop a central notification system for iOS before Android was even released.

In early 2008 at the release of the App Store and "iPhone OS 2.0," Apple's then head of iOS development Scott Forstall announced the company would be setting up a centralized Push Notification Service as a mechanism for allowing apps to respond to updates from outside services without needing to remain active in the background, constantly polling for new data and eating up battery power, CPU and memory.

Apple's overview of its push notification service.

At the time, Samsung was still promoting Windows Mobile 6, which (like Android today) required users to manually manage background processes and the memory and CPU resources their apps were consuming, an implementation Apple pointed to as an example of a poor design it wanted to dramatically improve upon.

The Task Manager application in Windows Mobile 6.

However, Apple noted later that year that it had greatly underestimated the overwhelming demand for both apps and push notifications, sending the company back to the drawing board and delaying the rollout of its Push Notifications Service until iOS 3.0 in early 2009, following a stress-testing beta program involving the Associated Press and other app developers.

In late 2009, Google, a major iOS developer, filed a patent for "notification of mobile device events," describing a feature it would later add to Android. Android enthusiasts now claim Apple simply copied its Notification Center from Android rather than having laid all the groundwork for touchscreen smartphones, a functional app store and a secure, battery-efficient notifications system.

In 2010, Apple brought its push notifications to the Mac as an API, initially to support FaceTime notifications and then more broadly as a public API in 2011's OS X Lion.

Today's basic design of Notification Center (above) appeared on the Mac as a user-facing feature in 2012's OS X Mountain Lion, after first making an appearance on Apple's mobile devices in iOS 5 the previous year.

Google patents the type of patent that Google doesn't respect today

Rather than Apple's newest implementation of widgets being "slavishly copied" from Android, the reality is that Google was fully aware of Apple's public work on notifications and—similar to Samsung—sought to patent a basic notification listing concept (below) it witnessed others developing first, including prior art developed at Palm for webOS by former Apple engineers.

Among those engineers is Rich Dellinger, who worked at Apple from 1999 to 2006 before leaving for Palm, where he developed the "non-intrusive banner notification system used in webOS" (below) that debuted at the beginning of 2009.

Dellinger returned to Apple after Palm was acquired by HP in 2010. Apple also hired Peter Hajas, who had developed MobileNotifier, an app for jailbroken iOS 4 devices that presented a pull down list of notifications. Apple subsequently released its official Notification Center in iOS 5 (above).

In parallel, Google hired Palm's webOS designer Matias Duarte, who is credited with developing the UI for Android 3.0 Honeycomb, as well as the company's latest web-inspired 'Material Design' appearance for both Android L and future versions of Chrome OS. That work draws clear inspiration from Apple's richly animated UI for iPhone released seven years ago, albeit with a unique color palette.

Custom Keyboards as a system plugin

More important than the identity of the first implementation rushed to market is the superior implementation currently available. That's particularly evident among the second type of App Extension that Android users are claiming Apple "stole" from Google: third party, system wide Custom Keyboards.

After belatedly recognizing the value of onscreen keyboards, Google opened up third party access to a core Android system resource back in 2009 to allow anyone to offer custom software for text input. This has been particularly valuable to Android users because Google's default system keyboard was widely considered to not be very good. Google's first attempt at a virtual keyboard was delivered alongside third party options.

As one user noted in a question posed to Android Central years afterward, "my biggest gripe about Android as an iOS user, was that I thought all of the keyboards but the Jelly Bean one were garbage. I found text prediction to be sorely lagging behind iOS, and having to pause to select your word I thought was a bad idea. I'm a fairly rapid typer, and on the iPhone made relatively no mistakes, and never had to backspace at all."

Apple's default keyboards—including support for Chinese finger stroke input—in addition to iOS input features including spell correction and auto correction, have long held a major advantage over the basic keyboard included with Android. So much so that Samsung was found to have infringed Apple's 8,074,172 patent on keyboard auto correction in an effort to make its devices more competitive with iPhones.

At the same time, there are third party custom keyboards that many Android users find compelling, and those input systems were previously impossible to port to iOS because of Apple's abundance of caution to protect users' privacy and security.

Apple's strict rules for new Custom Keyboards

With iOS 8's new Custom Keyboard Extensions, developers can implement alternative systems, with a few restrictions. First of all, Custom Keyboards can't be used to type in secure text field objects, such as the users' passcode or other password fields. When a user attempts to enter secure text using a Custom Keyboard (like the new Swype, below), iOS 8 temporarily reverts to the system keyboard, then returns the user back to their preferred keyboard afterward.

Custom Keyboards are also prevented from entering "phone pad" input, such as the phone number field in Contacts. Apple also notes that Custom Keyboards "cannot select text or control cursor position" and "cannot offer inline autocorrection controls near the insertion point" due to the way they are implemented."Your first consideration when creating a custom keyboard must be how you will establish and maintain user trust. This trust hinges on your understanding of privacy best practices and knowing how to implement them." - Apple

Apple also outlines that "by default, a keyboard has no network access and cannot share a container with its containing app."

The company's documentation devotes an entire section to "Designing for User Trust," noting to developers, "your first consideration when creating a custom keyboard must be how you will establish and maintain user trust. This trust hinges on your understanding of privacy best practices and knowing how to implement them."

The company spells out three principles of design to earn users trust. Under "Safety of keystroke data," it states "users want their keystrokes to go to the document or text field they're typing into, and not to be archived on a server or used for purposes that are not obvious to them."

Under "Appropriate and minimized use of other user data" it adds,"If your keyboard employs other user data, such as from Location Services or the Address Book database, the burden is on you to explain and demonstrate the benefit to your users."

Finally, under "Accuracy" it notes, "accuracy in converting input events to text is not a privacy issue per se but it impacts trust: With every word typed, users see the accuracy of your code. To design for trust, first consider whether to enable network access. Although network access makes many things possible for a custom keyboard, it also increases your responsibilities."

To turn on network access, a Custom Keyboard must request permission from the user. There are a variety of reasons why a user might opt to allow this, including features such as saving a custom autocorrect dictionary; providing enhanced touch-event processing, input prediction, and speech recognition for dictation; providing quick access to "names, places, and phone numbers relevant to the user" from the user's Contacts or from network supplied data; or autocorrection of nearby place names from Location Services.

Apple outlines specific requirements for developers to implement in their Custom Keyboards when network access is granted by the user, including the instruction, "do not store received keystroke or voice data beyond the time needed to provide text back to the user or to provide features that you explain to the user."

Users who aren't interested in Custom Keyboards will still get the benefit of iOS 8's intelligent QuickType keyboard, which offers predictive text customized to both the app users are typing in and the person they are addressing, in addition to isolating common answers from the context of the conversation (below).

Apple's considered design for App Extensions

As with Photo Editing Extensions, Custom Keyboards and Today Extensions provide third party developers with new ways to extend and add value to users via Apple's platform, which strictly regulates how App Extensions can work.

Apple has also designed App Extensions to benefit developers by highlighting the value of their work. As the company notes, "when users enter your extension, your custom UI can help to show them that they're shifting into a new context. Because users can distinguish your extension from the current app, they can appreciate the unique functionality that you provide."

At the same time, Apple has also given consideration to how users manage their own environment. "Users' awareness of extensions as separate entities also means that they can identify and remove extensions that misbehave or don't perform well," Apple states. The company has also outlined how users will be able to easily specify which Extensions they want to activate or remove.

The inclusion of both Today Extensions and Custom Keyboard functionality into the design of App Extensions indicates that Apple is working to erase any perceived advantages held by alternative operating systems. However, the design of iOS and OS X aren't simply reacting to follow market trends. Apple is also establishing its own unique functionality with App Extensions in ways that are not shared with the rest of the industry, as the following segment will outline.

Are these specific requirements for developers by Apple the same on Android? After typing that out I guess it's a rethorical question as I doubt they would put in so much time and effort in getting these things right. Having read about so much memory leaks, battery drains, the lot, I guess the SDK and its rules aren't quite the same on Android as they are for iOS. Oh well, for a mere $99 Google can copy these requirements from Apple I guess.

After past experience with browser plugins causing security problems, should we or should we not extend plugins to other bundled apps? Something as personal as the Photos app, or something as critical as the keyboard?

There is no way I would trust something as critical as my keyboard to a third party, even one on the App Store. Do you know how much it costs to sell apps on there? Only $100/year. And if you're giving them away free you don't have to provide official government tax documentation.

If you think Apple will be able to safely lock-down these plugins, I ask you to please read Apple's security advisories page. This lists six ways, since Mavericks came out alone, that apps can potentially escape the app sandbox. Even if the security model (as described in this article) is perfect, you still have to consider the implementation.

And where do plugin frameworks ultimately lead anyway? I mean, do Apple think third party devs will have hundreds of new ideas for things to do with a keyboard or photo that Apple can't think of themselves? No, it never works out that way. There will be *one or two* good plugins (such as Flash and Java in the browser) that come to dominate in each plugin-space. And is it really worth developing and maintaining an entire plugin architecture to harvest one or two good ideas? And what if those plugins become so popular that you can't realisticially update the app in ways that might break them, isn't that potentially problematic?

What if there was a way to get the benefit of those 1 or 2 awesome ideas without all the bother of a plugin framework? Well, there is. All iOS apps have to go through the App Store. This gives Apple a single place to watch for innovation. If a 3rd party app has a great new photo processing idea or cool custom keyboard (there's nothing to stop you implementing your own in a UIView) Apple can simply buy the company and port the feature to Photos or iOS with (most likely) less developer time than it takes to develop and maintain a plugin framework. These days a lot of tech companies are founded with the simple goal of being bought out, as opposed to making massive sales of their own.

Apple's answer to Android's plugins should not be a plugin framework of their own, it should be The App Store + their Big Purse.

List of Sandbox vulnerabilities in Mavericks:
----------------
10.9.0 http://support.apple.com/kb/HT6011
App Sandbox
Impact: The App Sandbox may be bypassed
Description: The LaunchServices interface for launching an application allowed sandboxed apps to specify the list of arguments passed to the new process. A compromised sandboxed application could abuse this to bypass the sandbox. This issue was addressed by disallowing sandboxed applications from specifying arguments.
CVE-2013-5179 : Friedrich Graeter of The Soulmen GbR

10.9.1: http://support.apple.com/kb/HT6084
App Sandbox
Available for: OS X Mountain Lion v10.8.5
Impact: The App Sandbox may be bypassed
Description: The LaunchServices interface for launching an application allowed sandboxed apps to specify the list of arguments passed to the new process. A compromised sandboxed application could abuse this to bypass the sandbox. This issue was addressed by preventing sandboxed applications from specifying arguments. This issue does not affect systems running OS X Mavericks 10.9 or later.
CVE-2013-5179 : Friedrich Graeter of The Soulmen GbR

ATS
Available for: OS X Mavericks 10.9 and 10.9.1
Impact: The App Sandbox may be bypassed
Description: A memory corruption issue existed in the handling of Mach messages passed to ATS. This issue was addressed through improved bounds checking.
CVE-2014-1262 : Meder Kydyraliev of the Google Security Team

ATS
Available for: OS X Mavericks 10.9 and 10.9.1
Impact: The App Sandbox may be bypassed
Description: An arbitrary free issue existed in the handling of Mach messages passed to ATS. This issue was addressed through additional validation of Mach messages.
CVE-2014-1255 : Meder Kydyraliev of the Google Security Team

After past experience with browser plugins causing security problems, should we or should we not extend plugins to other bundled apps? Something as personal as the Photos app, or something as critical as the keyboard?

Good question! However, Apple's implementation of App Extensions is very different than the Plugin APIs of Netscape, Safari, Aperture, and other apps that expose a way for insecure plugins to extend their functionality. Will detail more in a future segment.

Also, the vulnerabilities you cite are fixed issues. That's like saying that a car is probably unsafe to drive because it suffered a flat tire that was subsequently replaced. Having third parties find your vulnerabilities and then fixing them is a sign that the system is safer, nor more flawed.

After past experience with browser plugins causing security problems, should we or should we not extend plugins to other bundled apps? Something as personal as the Photos app, or something as critical as the keyboard?

...

TL;DR "Plugins suck"

Don't you realize how irrational that is? Nothing in this universe is 100% secure, including extensions. But if you want to experience life, you have to take risks. After all, what good is an app if you don't make good use of it?

Extensions allow people to make good use of their apps. Sure, there's a risk, but Apple has accounted for that very well. Not perfectly so (nothing is!), but they've done quite well. What more can you ask?

You remind me of people who keep their furniture covered in plastic, afraid of damaging and normal wear. Well, guess what? You will have a pristine sofa that you've never actually used!

Ah, I see it's time for the weekly Android-bashing from Danny boy. How predictable.

Additionally, Google's implementation of both widgets and third party keyboards expose significant security vulnerabilities and privacy issues that many end users wouldn't reasonably assume possible. It's virtually impossible for Google to police whether a third party keyboard spies on users. And it is well known that many actually do, recording users' key presses and uploading the data via the network because there's no functional security boundaries in place to stop such malicious activity from occurring.

Security on Android is largely based upon naive trust. Even apparently legitimate custom keyboard developers have been found to send users' keystrokes back to their servers for processing in clear text making everything they type open to anyone listening.

I'm getting dizzy from the spin.

A few years ago, Dianne Hackborn, a senior Android engineer at Google, wrote a detailed post on Google+ explaining how Android works - . The piece is mainly about graphics, but it goes into some detail about keyboards. In short, keyboards run in their own sandbox with a seperate window on the screen.

The only evidence you cite is a three-year-old story about an app sending data in the clear. Lots of apps, on Android and iOS, sent data in the clear then. Many still do. Even Apple used cleartext for the App Store until last year. This is hardly evidence that third-party keyboards are a spyware cesspool.

By the way, when is AppleInsider going to support SSL for logins? The site currently sends data in the clear.

At the time, Samsung was still promoting Windows Mobile 6, which (like Android today) required users to manually manage background processes and the memory and CPU resources their apps were consuming....

What are you talking about DED? Android does not require users to manually manage background processes, memory or CPU resources. Years ago, there were some users who thought task killers could extend their battery life, but that's been shown to be false for quite some time. And as far as I know, Android doesn't even provide a UI for users to manage memory or CPU resources. More FUD.

With iOS 8's new Custom Keyboard Extensions, developers can implement alternative systems, with a few restrictions. First of all, Custom Keyboards can't be used to type in secure text field objects, such as the users' passcode or other password fields. When a user attempts to enter secure text using a Custom Keyboard (like the new Swype, below), iOS 8 temporarily reverts to the system keyboard, then returns the user back to their preferred keyboard afterward.

Custom Keyboards are also prevented from entering "phone pad" input, such as the phone number field in Contacts. Apple also notes that Custom Keyboards "cannot select text or control cursor position" and "cannot offer inline autocorrection controls near the insertion point" due to the way they are implemented."

I don't know about you, but this constant switching from a custom keyboard back to stock one sure sounds like a lousy user experience to me. I have to think that if Google had implemented Android keyboards this way, that folks on here would waste no time bemoaning the terrible UX and that such behavior indicates Google didn't take the time to properly secure third-party keyboards....

Apple also outlines that "by default, a keyboard has no network access and cannot share a container with its containing app."

I don't know about you, but this constant switching from a custom keyboard back to stock one sure sounds like a lousy user experience to me. I have to think that if Google had implemented Android keyboards this way, that folks on here would waste no time bemoaning the terrible UX and that such behavior indicates Google didn't take the time to properly secure third-party keyboards....

1) Why is there constant switching? How often are you having to access a secure password field?

2) If Android actually put security first with the keyboard it mocked. It's a lack of security that gets talked about most, and that's OS agnostic.

A few years ago, Dianne Hackborn, a senior Android engineer at Google, wrote a detailed post on Google+ explaining how Android works - . The piece is mainly about graphics, but it goes into some detail about keyboards. In short, keyboards run in their own sandbox with a seperate window on the screen.

Having a "sandbox" doesn't mean there is any security involved. As noted in the quote you cited, Android keyboards have sent keystrokes over the network in the clear. That's bad.

Also, a 3rd party keyboard innately has access to anything users type, regardless of being "in a sandbox," so if it has network access, it minimally can do stupid things with it (like send it in over the Internet as clear text) or do malicious things with it (like parse for passwords and private data)

Many users, myself included, want our soft keyboards to learn our writing styles, and to sync that data across devices. It's a feature. It's not spyware. On SwiftKey, one of the most popular third-party keyboards, cloud-sync is opt-in.

That is clearly presented in the article.

The only evidence you cite is a three-year-old story about an app sending data in the clear. Lots of apps, on Android and iOS, sent data in the clear then. Many still do. Even Apple used cleartext for the App Store until last year. This is hardly evidence that third-party keyboards are a spyware cesspool.

Apple "used cleartext for the App Store" meaning what? That it sent user credentials unencrypted? That it intercepted everything that users typed and sent it to its servers unencrypted? What you are typing makes no sense.

By the way, when is AppleInsider going to support SSL for logins? The site currently sends data in the clear.

At the time, Samsung was still promoting Windows Mobile 6, which (like Android today) required users to manually manage background processes and the memory and CPU resources their apps were consuming....

What are you talking about DED? Android does not require users to manually manage background processes, memory or CPU resources. Years ago, there were some users who thought task killers could extend their battery life, but that's been shown to be false for quite some time. And as far as I know, Android doesn't even provide a UI for users to manage memory or CPU resources. More FUD.

Over the past five years of Android custom keyboards and widgets, the top app on the platform has been task killers, and memory and battery use are the top problems Android users have. You can claim that's not an issue, just like Android fans claim keyboards are not a security threat, but that's ignorant.

I don't know about you, but this constant switching from a custom keyboard back to stock one sure sounds like a lousy user experience to me. I have to think that if Google had implemented Android keyboards this way, that folks on here would waste no time bemoaning the terrible UX and that such behavior indicates Google didn't take the time to properly secure third-party keyboards....

Saying that switching to a secure keyboard for entering secure data is a "lousy user experience" undermines your credibility.

Also, as the article points out, there really isn't any way for Google to "properly secure third-party keyboards," because Google doesn't curate its own apps, let alone the side loaded and alternative app stores that are both the hallmark of Android openness and what the majority of global Android users actually use.

Apple also outlines that "by default, a keyboard has no network access and cannot share a container with its containing app."

You mean just like Android apps?

What percentage of Android keyboards work without network access? What's the business model? SwiftKey is free and needs full internet access. The business model is data mining.

Also, the vulnerabilities you cite are fixed issues. That's like saying that a car is probably unsafe to drive because it suffered a flat tire that was subsequently replaced. Having third parties find your vulnerabilities and then fixing them is a sign that the system is safer, nor more flawed.

A list of fixed vulnerabilities is indeed a sign that a system is getting safer. But it's also telling that 3 years after the OS X sandbox came out (Lion was RTM in July 2011), they are still fixing issues (10.9.4 is only a few days old). The Plugins framework constitutes a whole new attack surface that will have to go through it's own period of breaking in. And it's an attack surface that includes things such as photos, and the keyboard itself.

Where I'm coming from is my belief is that the fundamental cause of security issues (talking about any OS here) is complexity. The system gets so complex that even the designers themselves can not forsee all the ways someone might potentially attack it. So if there's any way to achieve functionality goals without introducing new layers of complexity, that is the way to go. I offered one suggestion of simply buying out new innovative apps and integrating their functionality in to Apple apps, but I'm sure there are other solutions. Technical challenges from other companies do not always require a technical response, sometimes a business response will do.