Comparisons to Android's Intents only tell part of the story.

Of all the new features introduced in iOS 8 last week, app extensions are the ones that will have the biggest, most visible impact on the new operating system. The feature is most commonly described as a way for third-party applications to talk to each other, though that's an oversimplification—that's not the only thing app extensions can do, and technically third-party apps in iOS still can't talk directly to one another.

We've read the developer documentation and watched the WWDC sessions. Now it's time to break down how these features work, what they do, and how Apple is continuing to balance third-party access to the operating system with security.

What do app extensions do?

Allowing third-party apps to communicate with other apps is just one of the problems extensions are meant to solve—third-party keyboards, connecting apps to cloud services other than iCloud, and the new Notification Center widgets are all their own kind of extensions.

Not all parts of iOS can be changed (or "extended") by third parties. If you wanted to replace one of the default apps with your own or add some kind of toggle to the Control Center, you can't do that. Apple defines a handful of pre-set "extension points" to show developers where they can add stuff. The iOS 8 extension points are as follows:

Today extensions, also called widgets, are used to deliver glanceable information in the Today view in the Notification Center. Think of them as an answer to Windows Phone's Live Tiles or Android's home screen widgets.

Share extensions allow for the posting of photos, links, or other files from one app to an online service. This will enable things like posting pictures to Pinterest or uploading files from an app into Dropbox or OneDrive. Older versions of iOS support posting to Facebook and Twitter, and Share extensions open up the doors to others.

Action extensions "manipulate or view content within the context of another app." In English, that means editing a photo embedded in a text document or, as Apple showed onstage in the WWDC keynote, using something like Bing Translate to translate the text in a Safari window.

Photo Editing extensions can be used to take a picture you're viewing in Photos and call upon features from another app to edit it (Apple showed off a VSCO Cam extension in the keynote). Photos keeps both the edited image and the unedited original, though this isn’t true for video files.

Storage Provider extensions will let productivity apps open documents from a variety of cloud services. One could, for example, use Dropbox to store documents that you can then open and edit in Office for iPad or Pages.

Keyboard extensions let you swap out Apple's first-party software keyboard for one of your choosing.

We'll focus primarily on iOS extensions today, but many of these (including Notification Center widgets and Share extensions, among others) work in OS X Yosemite just as they do in iOS. For apps in the Mac App Store tied to Apple's sandboxing restrictions they'll be useful, though of course many Mac apps continue to bypass the App Store and Apple's restrictions altogether.

This pre-set list of extension points differs from Android's Intents system. Android apps use "Intent Filters" to tell the operating system the kinds of things the apps can handle. The Twitter or Facebook apps can tell Android that they're capable of posting photos or links; Google Drive and Dropbox can be used to upload most kinds of files; Chrome and Firefox can open Web pages; new launchers can completely change the way your Home screen looks and works. Third-parties can even specify their own custom Intent Filters to the operating system. By contrast, iOS is still more limited (though not without reason, as we'll discuss later).

Keep this in mind, because it's going to come up a bunch: Extensions greatly increase the list of things third-parties can do, and for many common use cases they'll be functionally indistinguishable from Intents. The changes stop far short of Android's "anything goes" mentality, though, largely in the name of preserving iOS' security model.

How do you get extensions, and how do they work?

Enlarge/ Extensions are delivered as binaries that live within a "containing app."

Apple

Like all third-party apps on a non-jailbroken iPhone, all iOS extensions are downloaded from the App Store. The biggest limitation here is that Apple won't allow developers to offer apps that are just extensions. Each extension has to live within a "containing app," and Apple mandates that the containing app must offer some functionality to the user. Unlike in Android, developers cannot offer apps that are just widgets or just keyboards (this applies only to iOS; OS X developers can offer apps that are simply wrappers for extensions).

This restriction sounds more onerous than it actually is. Look at Fleksy, a third-party keyboard app already offered through the App Store. Its containing app is little more than a keyboard tutorial, a field of text to practice in, and a settings panel. A basic Share button lets you send the text you type as an e-mail or Tweet. This app doesn't do a whole lot, but it's about as complicated as a containing app for a keyboard or widget would have to be.

Enlarge/ Containing apps don't necessarily have to be complicated, but they do have to do something. The Fleksy keyboard's containing app is an extremely basic note-taking app primarily used for practicing.

Andrew Cunningham

Other things are recommended by Apple but not mandated. The company suggests that extensions be designed to complement Apple's built-in software. Third-party widgets should look and act like Apple's own widgets. Photo editing extensions that work with the Photos app shouldn't look radically different from that Photos app. There will definitely be developers who won't follow these guidelines, but most iOS app developers are already practiced at making apps that meld with Apple's UI.

While these guidelines are more restrictive than what Android developers will be used to, Apple imposes no limitations on the number or types of extensions your containing app offers. You can add an extension to your app by adding a new "target" to it in Xcode, and Apple provides default templates for all the different kinds of extensions.

Each type of extension is activated in different ways. Widgets are enabled and disabled from the Notification Center, and keyboards are changed in the Keyboards section of the Settings (where you'd go to select a different language or enable the emoji keyboard in iOS 7). Photo Editing and Storage Provider extensions only come up in specific situations—when using the Photos app and using any app that has a document picker, respectively. Share and Action extensions can be invoked from within any app, but developers should add Activation Rules to the extension to specify what kind of data it will work with. If your extension is only meant to share photos, Activation Rules can be configured to make sure that extension doesn't appear when the user is trying to share a URL or a document.

Enlarge/ Activation rules tell the OS what kind of files your extensions can work with. You won't want to be offered a photo editing extension if you want to upload a document.

Apple

While they all need to be packaged up inside containing apps, extensions are generally run separately from the containing app itself. Each extension is its own little binary with an .appex file extension that can open, do its job, and close without ever running the containing app. For extensions that need to be able to perform some of the same tasks as their containing app—an Instagram extension that adds a filter to an image, for example—developers are encouraged to use an "embedded framework" to share the code responsible for those tasks. Create the framework, drop the code into it, and then embed that framework into both the containing app and the extension. The only caveat is that apps set up this way will require iOS 8.0 or later, and they won't run on earlier versions of the operating system.

One reason why extensions are launched separately from their containing apps is because of strict Apple-imposed memory limitations. Widgets are especially constrained, since the user can have many of them running at the same time. We'll have to see how a Notification Center packed with widgets will perform on a memory-constrained device like the iPhone 4S or the iPad 2.

Enlarge/ Apple has designed extensions to have a "short lifecycle." They open, they do their job, and they close.

Apple

Also, in part because of memory limitations, extensions don't run for very long and are aggressively cleared out of memory by the system. Extensions are designed to do their task and then get out of the way. For extensions that perform lengthy background tasks like uploading, Apple recommends that extensions pass that upload task to the system and then close down.

This covers the basics of how extensions are packaged, how they're accessed, and how they'll behave while they're running. Even with their restrictions, they stand to add a lot to the operating system—they're probably the biggest functional change we've gotten since iOS 4 or iOS 5. What's more impressive is the way these extensions work without sacrificing Apple's sandboxing model, which should help keep you and your data about as safe and as private as it can be these days.

301 Reader Comments

I haven't doubted that iOS descended from NextStep for a moment. However, if iOS inherited the concept directly from NS, then how come it took 6 years for iOS to come up with Extensions?

Quote:

They didn't come up with Extensions.

They came up with a secure way to offer the Services already present in NextStep and MacOS and called the result Extensions.

IPC mechanisms have existed on desktop platforms for a while. But I haven't seen anything as clean, flexible, robust and standard as Intents on Android. Intents on Android is by far the most superior IPC protocol I've seen on any desktop or mobile platform. Extensibility is really just a fraction of Intent's capabilities.

iOS and OS X applications are written in sandboxed silos. Android applications are written as mini services that communicate with each other and the OS via Intents. Extensibility will make iOS applications share some of the architecture of Android applications, but it remains to be seen how developers on iOS adjust to this new way of writing applications.

I haven't doubted that iOS descended from NextStep for a moment. However, if iOS inherited the concept directly from NS, then how come it took 6 years for iOS to come up with Extensions?

They didn't come up with Extensions.

They came up with a secure way to offer the Services already present in NextStep and MacOS and called the result Extensions.

Really? Who came up with extensions in iOS then?

Seems like although the end result of Services and Extensions is somewhat similar, but the architecture is new. From the ground up.

Hence the part where they redeveloped the feature so it could be used securely by third party developers?

Services are alive and well in iOS. The system wide spell checking is provided by a service on NextStep, OSX and iOS. Looking up definitions for words is provided by a service on NextStep, OSX and iOS.

However, Apple wasn't about to provide the Services API to third party developers until it was implemented securely. Hence, Extensions.

It's too bad that a pretty straightforward article has spawned such a pointless discussion, instead of an interesting one focused on the cool new things that will be possible with iOS 8 extensions. Also too bad that the one poster with a couple of good questions was totally ignored, and instead there were almost 5 pages worth of crap.

Is all users of NextStep, Windows, Mac, and OS X have to do is "install an app"? Remember, those platforms at the time all had difficult processes for installing apps.

I can't speak directly for NextStep, having only read bits and pieces about it. And I was a child during the days of Mac OS. But I'm a competent Apple power user and .NET developer for Windows. Although they all had comparable features, they weren't A) on a mobile device and B) commonly used. Which makes them irrelevant in a discussion of who Apple decided to copy when they made the decision to implement Extensions in iOS.

Double clicking an installer and clicking next is "hard"?

Also, support for OLE has been a requirement to be allowed to use the Windows logo on your software box since Windows freaking 95. "Not commonly used" my ass.

You're that special combination of not knowing what the hell you're talking about and a constant stream of bullshit.

There's more to installing than simply double clicking. Let's take Windows 9x as an example. You had to find the program's CD at your local store. Insert the disc. If AutoPlay didn't come up, you had to open up My Computer and navigate to the disc drive and launch autoplay or setup.exe. You have to choose the installation path, and sometimes whether you want a Typical or Full install. If the program required .NET, you had to obtain that and get it installed. Oh, but make sure you reboot after installing .NET. All this may seem obvious to you as a power user or developer. But to the average person, that's a lot of steps, some of which can be complicated.

iOS and Android are much more intuitive than this. One place to get your app from, simple searching to find the app, tap install, put in password, and you're done. On Android, you can review the permissions first.

Yes, OLE was an early requirement for the Windows sticker. How long did that last? I've installed hundreds of programs that didn't implement OLE but still had the sticker.

I haven't doubted that iOS descended from NextStep for a moment. However, if iOS inherited the concept directly from NS, then how come it took 6 years for iOS to come up with Extensions?

Quote:

They didn't come up with Extensions.

They came up with a secure way to offer the Services already present in NextStep and MacOS and called the result Extensions.

IPC mechanisms have existed on desktop platforms for a while. But I haven't seen anything as clean, flexible, robust and standard as Intents on Android.

You haven't heard of Visual Basic for Applications or Applescript? Everything that intents does, plus the ability to record a workflow and replay it at will.

You are vastly under-representing the capabilities of Intents. And since you seem to think VBA and AppleScript are comparable, they're not. They're not simple. Which is an important feature. Great power user tools, but that doesn't have much to do with what we're talking about.

It's too bad that a pretty straightforward article has spawned such a pointless discussion, instead of an interesting one focused on the cool new things that will be possible with iOS 8 extensions. Also too bad that the one poster with a couple of good questions was totally ignored, and instead there were almost 5 pages worth of crap.

I haven't doubted that iOS descended from NextStep for a moment. However, if iOS inherited the concept directly from NS, then how come it took 6 years for iOS to come up with Extensions?

Quote:

They didn't come up with Extensions.

They came up with a secure way to offer the Services already present in NextStep and MacOS and called the result Extensions.

IPC mechanisms have existed on desktop platforms for a while. But I haven't seen anything as clean, flexible, robust and standard as Intents on Android.

You haven't heard of Visual Basic for Applications or Applescript? Everything that intents does, plus the ability to record a workflow and replay it at will.

You are vastly under-representing the capabilities of Intents. And since you seem to think VBA and AppleScript are comparable, they're not. They're not simple. Which is an important feature. Great power user tools, but that doesn't have much to do with what we're talking about.

Click record. Carry out a series of steps in multiple applications. Hit stop when done.

Yea. Soooo difficult.

Why can't you be honest?

Not only could you do everything that intents allows, it was all recordable and scriptable.

They came up with a secure way to offer the Services already present in NextStep and MacOS and called the result Extensions.

IPC mechanisms have existed on desktop platforms for a while. But I haven't seen anything as clean, flexible, robust and standard as Intents on Android.

You haven't heard of Visual Basic for Applications or Applescript? Everything that intents does, plus the ability to record a workflow and replay it at will.

You are vastly under-representing the capabilities of Intents. And since you seem to think VBA and AppleScript are comparable, they're not. They're not simple. Which is an important feature. Great power user tools, but that doesn't have much to do with what we're talking about.

Click record. Carry out a series of steps in multiple applications. Hit stop when done.

Yea. Soooo difficult.

Why can't you be honest?

Not only could you do everything that intents allows, it was all recordable and scriptable.

It just wasn't secure.

AppleScript and VBA aren't nearly that easy in practice. Sure, recording is an awesome feature, but the scripts always have to be hand edited aftewards to be of any use.

But that has nothing to do with Intents. Intents is about Developer A making Application X exposing some functionality, while developer B makes Application B with some functionality. Developer A has no idea who Developer B is or what Application B does or how it works. And Developer B has no idea about Developer A or Application A. Yet, their apps can communicate in an intelligent way of the end user's behalf without the need to write script (or record one). AppleScript doesn't do this. AppleScript is a scripting language for power users.

Please stop making personal jabs about me being dishonest. Even if I were factually incorrect that doesn't mean I'm being dishonest. Being civil and courteous goes a long ways towards having an intelligent discussion. Ad hominem attacks undermine it.

Um, this isn't taking a page out of Android's book at all. This whole scheme is a direct copy of Windows Phone/Windows 8's extension mechanism that's been around for 2 years!

Sorry to disappoint, but Android has had the Intents mechanism for longer than 2 years. Sure it probably copied someone else, but it's the first major successful example of this sort of interoperability between apps.

If you ignore Services on NextStep since the late 80's, which carried over to Services in every version of Mac OS X?

You would also have to ignore Microsoft's Component Object Model and Apple's Applescript on classic Mac OS starting in the 90's.

Hell, UNIX had pipelining between apps back in the 70's.

But sure, Android totally invented interoperability between apps.

There is a subtle difference between Services and intents. Services are designed to be invoked by the end user from the Services menu; the only way to access them programmatically is via Applescript. On the other hand, intents are deeply integrated into the Android API and are fundamental to how the system operates. Communication between the various components of an application, as well as between components of different applications, are all handled by intents. To me, the intents system is more accurately characterized as a sort of hybrid between unix pipes and services. Like pipes, they are designed to be used by the programmer to glue together multiple tools to accomplish a complex task (such as attaching a file to an email). On the other hand, they are similar to Services in that the end point of the pipe can be determined at run time, rather than at compile time.

Um, this isn't taking a page out of Android's book at all. This whole scheme is a direct copy of Windows Phone/Windows 8's extension mechanism that's been around for 2 years!

Sorry to disappoint, but Android has had the Intents mechanism for longer than 2 years. Sure it probably copied someone else, but it's the first major successful example of this sort of interoperability between apps.

If you ignore Services on NextStep since the late 80's, which carried over to Services in every version of Mac OS X?

You would also have to ignore Microsoft's Component Object Model and Apple's Applescript on classic Mac OS starting in the 90's.

Hell, UNIX had pipelining between apps back in the 70's.

But sure, Android totally invented interoperability between apps.

There is a subtle difference between Services and intents. Services are designed to be invoked by the end user from the Services menu; the only way to access them programmatically is via Applescript. On the other hand, intents are deeply integrated into the Android API and are fundamental to how the system operates. To me, the intents system is more accurately characterized as a sort of hybrid between unix pipes and services. Like pipes, they are designed to be used by the programmer to glue together multiple tools to accomplish a complex task (such as attaching a file to an email). On the other hand, they are similar to Services in that the end point of the pipe can be determined at run time, rather than at compile time.

And you don't have to be a programmer or command line warrior to use Intents.

You have made a long series of false claims such as "installing programs on Windows is hard"

You're either stupid, or lying.

>AppleScript and VBA aren't nearly that easy in practice. Sure, recording is an awesome feature, but the scripts always have to be hand edited aftewards to be of any use.

Not true in the least. If you want to record a linear system of steps, you don't have to edit a damn thing.

>Intents is about Developer A making Application X exposing some functionality, while developer B makes Application B with some functionality. Developer A has no idea who Developer B is or what Application B does or how it works.

Um, this isn't taking a page out of Android's book at all. This whole scheme is a direct copy of Windows Phone/Windows 8's extension mechanism that's been around for 2 years!

Sorry to disappoint, but Android has had the Intents mechanism for longer than 2 years. Sure it probably copied someone else, but it's the first major successful example of this sort of interoperability between apps.

If you ignore Services on NextStep since the late 80's, which carried over to Services in every version of Mac OS X?

You would also have to ignore Microsoft's Component Object Model and Apple's Applescript on classic Mac OS starting in the 90's.

Hell, UNIX had pipelining between apps back in the 70's.

But sure, Android totally invented interoperability between apps.

There is a subtle difference between Services and intents. Services are designed to be invoked by the end user from the Services menu; the only way to access them programmatically is via Applescript. On the other hand, intents are deeply integrated into the Android API and are fundamental to how the system operates. To me, the intents system is more accurately characterized as a sort of hybrid between unix pipes and services. Like pipes, they are designed to be used by the programmer to glue together multiple tools to accomplish a complex task (such as attaching a file to an email). On the other hand, they are similar to Services in that the end point of the pipe can be determined at run time, rather than at compile time.

And you don't have to be a programmer or command line warrior to use Intents.

You don't have to be a programmer or command line warrior to record linear scripts or use services.

However, if you want to break bad and go all power user, you have the option of more advanced capabilities that Android lacks.

You have made a long series of false claims such as "installing programs on Windows is hard"

You're either stupid, or lying.

I'm sorry you disagree, but that doesn't mean I'm stupid or lying. I know many people that are not stupid (perhaps technically challenged) that did have trouble installing things. I ran into the occasional problem myself. Installing things wasn't easy back in the day. On Android and iOS devices, after 5 minutes I can explain it to one of those technically challenged people.

Quote:

>AppleScript and VBA aren't nearly that easy in practice. Sure, recording is an awesome feature, but the scripts always have to be hand edited aftewards to be of any use.

Not true in the least. If you want to record a linear system of steps, you don't have to edit a damn thing.

Occasionally a workflow that doesn't need editing presents itself. But often when you need to repeat yourself, you need to do it slightly differently each time. And if you don't know anything about scripting or programming, then AppleScript or especially VBA can be very daunting.

Quote:

>Intents is about Developer A making Application X exposing some functionality, while developer B makes Application B with some functionality. Developer A has no idea who Developer B is or what Application B does or how it works.

Which is exactly what Services have done on NextStep since the 80's.

That's great. But we're not talking about NextStep, because it's not an OS for a mobile device. Will you please acknowledge that I've been talking about mobile devices from the beginning? I'm not going to make fun of you if you admit that you were attacking a position that I didn't support. I'll just drop it.

Um, this isn't taking a page out of Android's book at all. This whole scheme is a direct copy of Windows Phone/Windows 8's extension mechanism that's been around for 2 years!

Sorry to disappoint, but Android has had the Intents mechanism for longer than 2 years. Sure it probably copied someone else, but it's the first major successful example of this sort of interoperability between apps.

If you ignore Services on NextStep since the late 80's, which carried over to Services in every version of Mac OS X?

You would also have to ignore Microsoft's Component Object Model and Apple's Applescript on classic Mac OS starting in the 90's.

Hell, UNIX had pipelining between apps back in the 70's.

But sure, Android totally invented interoperability between apps.

There is a subtle difference between Services and intents. Services are designed to be invoked by the end user from the Services menu; the only way to access them programmatically is via Applescript. On the other hand, intents are deeply integrated into the Android API and are fundamental to how the system operates. To me, the intents system is more accurately characterized as a sort of hybrid between unix pipes and services. Like pipes, they are designed to be used by the programmer to glue together multiple tools to accomplish a complex task (such as attaching a file to an email). On the other hand, they are similar to Services in that the end point of the pipe can be determined at run time, rather than at compile time.

And you don't have to be a programmer or command line warrior to use Intents.

You don't have to be a programmer or command line warrior to record linear scripts or use services.

However, if you want to break bad and go all power user, you have the option of more advanced capabilities that Android lacks.

That screen is intimating to the average person. Do you agree, or disagree?

Um, this isn't taking a page out of Android's book at all. This whole scheme is a direct copy of Windows Phone/Windows 8's extension mechanism that's been around for 2 years!

Sorry to disappoint, but Android has had the Intents mechanism for longer than 2 years. Sure it probably copied someone else, but it's the first major successful example of this sort of interoperability between apps.

Again, you're just making up straw men and attacking them. Stop. It's annoying and you're just wrong.

So the founder of Apple is kicked out of the company, founds NeXT whith a product that features the best inter app communcation anyone had ever seen.

then his company is purchased by Apple, he becomes the CEO, and throws away almost everything Apple's engineering team had ever worked on, putting the NeXT engineers in charge and most of them still work for Apple today.

Then when they bring that feature back to their product years later, you think they copied someone else?

Question #1: Could these Extensions finally do away with the "double copy" issue?

For instance, I download a file in a web browser — say Mercury — then I go into Mercury's Downloads, select the file and "Open File" in another app — say Comic Zeal. This laboriously copies the file to Comic Zeal's Library and then, I have to go back to Mercury's Downloads and laboriously delete the file because I don't want to waste space on the already cramped iPad. Doing away with this particular user experience would be swell.

Question #2: Can we finally aim files at local network shares instead of The Cloud through Extensions?

For instance, I created my masterpiece in an app — say Sketchbook — and want to store a copy on my NAS. Will I be able to do that from inside Sketchbook if the devs add the option, or if not, will I at least be able to send my masterpiece to a LAN capable app — say Good Reader — that can then directly access and write to my NAS?

This was the post with two good questions that should have been answered, instead of the ridiculous and pointless back and forth flame battle.

Um, this isn't taking a page out of Android's book at all. This whole scheme is a direct copy of Windows Phone/Windows 8's extension mechanism that's been around for 2 years!

Sorry to disappoint, but Android has had the Intents mechanism for longer than 2 years. Sure it probably copied someone else, but it's the first major successful example of this sort of interoperability between apps.

Copied NeXT maybe, which steve jobs helped create in the 1980s?

For example, you could embed an image in the body of an email, and edit the image using a third party image editor without ever leaving the email compose window - using inter-app communication.

Sure. It doesn't really matter though, as Android was the first widespread use of this type of user facing inter application communication on a mobile device, which is the comment I made that started this whole conversation in the beginning. Who Android copied isn't important unless it 1) served as the inspiration for Extensions 2) was technology for a mobile device 3) was user facing 4) was wide spread

This is my main question as well, because I am a firm believer in password managers, and the current "type my master password into Dashlane and then copy and paste once I switch back to XYZ app" really blows. Using TouchID to unlock the password manager from within another app and seamlessly fill the appropriate field with as little back and forth as possible is my dream...

They think so and are going to make every effort to implement the feature.

Quote:

By now you may have heard about App Extensions, one of the many, many new features Apple announced is coming to iOS 8 in the fall. In short, App Extensions allow third-party apps to plug into other apps, including Apple’s own. Combine that with Apple’s announcement that Touch ID is also opening up to third-party developers, and you can see why we were doing Snoopy dances in our keynote seats.

This all is incredibly exciting, and we are looking into the delectable possibilities these features might be able to unlock for 1Password. Might.

Right now, we have nothing to announce since we learned of all this awesomeness at the same time as you. We still need to explore the actual capabilities of these features and whether we can even use them.

Question #1: Could these Extensions finally do away with the "double copy" issue?

For instance, I download a file in a web browser — say Mercury — then I go into Mercury's Downloads, select the file and "Open File" in another app — say Comic Zeal. This laboriously copies the file to Comic Zeal's Library and then, I have to go back to Mercury's Downloads and laboriously delete the file because I don't want to waste space on the already cramped iPad. Doing away with this particular user experience would be swell.

Yes. Now you can have one location for your file, such as DropBox, OneDrive, Google Drive, or iCloud Storage. You'd start of in Comic Zeal's library and say "Open from another location" or something to that effect, and then go to your storage location of choice (someone might implement NFS shares or FTP besides just cloud services) and then do what you want with the file there. You'd need to store the downloaded file in a storage area (Mecury may have its own storage area).

Quote:

Quote:

Question #2: Can we finally aim files at local network shares instead of The Cloud through Extensions?

For instance, I created my masterpiece in an app — say Sketchbook — and want to store a copy on my NAS. Will I be able to do that from inside Sketchbook if the devs add the option, or if not, will I at least be able to send my masterpiece to a LAN capable app — say Good Reader — that can then directly access and write to my NAS?

Sure, why not? Good Reader will just need to provide an extension and it should be possible.

Quote:

Quote:

This was the post with two good questions that should have been answered, instead of the ridiculous and pointless back and forth flame battle.

The back and forth flame battle has little to do with the question getting answered or not.

Um, this isn't taking a page out of Android's book at all. This whole scheme is a direct copy of Windows Phone/Windows 8's extension mechanism that's been around for 2 years!

Sorry to disappoint, but Android has had the Intents mechanism for longer than 2 years. Sure it probably copied someone else, but it's the first major successful example of this sort of interoperability between apps.

Again, you're just making up straw men and attacking them. Stop. It's annoying and you're just wrong.

So the founder of Apple is kicked out of the company, founds NeXT whith a product that features the best inter app communcation anyone had ever seen.

then his company is purchased by Apple, he becomes the CEO, and throws away almost everything Apple's engineering team had ever worked on, putting the NeXT engineers in charge and most of them still work for Apple today.

Then when they bring that feature back to their product years later, you think they copied someone else?

Lying or stupid... Lying or stupid...

I'm leaning towards lying, since the truth has been pointed out many, many times.

That screen is intimating to the average person. Do you agree, or disagree?

Nobody except a power user needs to see that screen, unlike this one:

Android asks complete noobs to deal with that. No wonder 99% of all malware infests Android.

That doesn't look intimidating to me. It's simply a list of permissions saying what the app can do. You either hit Accept - Install or Decline - Don't Install.

And yes, if someone wanted to implement anything beyond the most trivial of AppleScripts, they would need to look at that AppleScript configuration screen. Which is intimidating, because it has inputs, and outputs, and a workflow. A lot of parts. Since I'm a programmer, I could make it do what I wanted with a little experimentation. But technically challenged people? They likely will be confused.

That screen is intimating to the average person. Do you agree, or disagree?

Nobody except a power user needs to see that screen, unlike this one:

Android asks complete noobs to deal with that. No wonder 99% of all malware infests Android.

That doesn't look intimidating to me. It's simply a list of permissions saying what the app can do. You either hit Accept - Install or Decline - Don't Install.

And yes, if someone wanted to implement anything beyond the most trivial of AppleScripts, they would need to look at that AppleScript configuration screen. Which is intimidating, because it has inputs, and outputs, and a workflow. A lot of parts. Since I'm a programmer, I could make it do what I wanted with a little experimentation. But technically challenged people? They likely will be confused.

LOL... Android permissions are simple but installing a program on Windows is hard?

Um, this isn't taking a page out of Android's book at all. This whole scheme is a direct copy of Windows Phone/Windows 8's extension mechanism that's been around for 2 years!

Sorry to disappoint, but Android has had the Intents mechanism for longer than 2 years. Sure it probably copied someone else, but it's the first major successful example of this sort of interoperability between apps.

Again, you're just making up straw men and attacking them. Stop. It's annoying and you're just wrong.

So the founder of Apple is kicked out of the company, founds NeXT whith a product that features the best inter app communcation anyone had ever seen.

then his company is purchased by Apple, he becomes the CEO, and throws away almost everything Apple's engineering team had ever worked on, putting the NeXT engineers in charge and most of them still work for Apple today.

Then when they bring that feature back to their product years later, you think they copied someone else?

Yes. It took six years to get that implemented in iOS. Intents is often seen as a large factor in Android's success. Android had it since API Level 1.

So Google pushed Apple into copying Android. And I appreciate that Apple did it. It's a good thing for you, me, Android users, and iOS users. I'm not saying Apple did anything wrong at all, and I'm not saying Android was the first ever implementation of inter app communication on all platforms. But I'm saying that we would not have Extensions at this moment if Intents weren't in Android.

That screen is intimating to the average person. Do you agree, or disagree?

Nobody except a power user needs to see that screen, unlike this one:

Android asks complete noobs to deal with that. No wonder 99% of all malware infests Android.

That doesn't look intimidating to me. It's simply a list of permissions saying what the app can do. You either hit Accept - Install or Decline - Don't Install.

And yes, if someone wanted to implement anything beyond the most trivial of AppleScripts, they would need to look at that AppleScript configuration screen. Which is intimidating, because it has inputs, and outputs, and a workflow. A lot of parts. Since I'm a programmer, I could make it do what I wanted with a little experimentation. But technically challenged people? They likely will be confused.

LOL... Android permissions are simple but installing a program on Windows is hard?

That screen is intimating to the average person. Do you agree, or disagree?

Nobody except a power user needs to see that screen, unlike this one:

Android asks complete noobs to deal with that. No wonder 99% of all malware infests Android.

That doesn't look intimidating to me. It's simply a list of permissions saying what the app can do. You either hit Accept - Install or Decline - Don't Install.

And yes, if someone wanted to implement anything beyond the most trivial of AppleScripts, they would need to look at that AppleScript configuration screen. Which is intimidating, because it has inputs, and outputs, and a workflow. A lot of parts. Since I'm a programmer, I could make it do what I wanted with a little experimentation. But technically challenged people? They likely will be confused.

LOL... Android permissions are simple but installing a program on Windows is hard?

I'll just quickly reply that, by your own logic, iOS is a couple of decades plus 7 years late on this concept. No it doesn't matter iOS came from OSX and that OSX had this function because pre-iOS 8 versions don't.

Not to mention now one can also claim Android/iOS is a couple of decades late on the concept of touch input and virtually everything OS related. Because apparently even when a new OS is created with a function built-in from the get-go, it can still be considered as "decades-late" if some prior-OS had it already.

The ridiculousness of this exclamation just made it clear that my time would be much better spent doing something like finish reading the Apple's book on Swift than here, so thanks I guess

Question #1: Could these Extensions finally do away with the "double copy" issue?

For instance, I download a file in a web browser — say Mercury — then I go into Mercury's Downloads, select the file and "Open File" in another app — say Comic Zeal. This laboriously copies the file to Comic Zeal's Library and then, I have to go back to Mercury's Downloads and laboriously delete the file because I don't want to waste space on the already cramped iPad. Doing away with this particular user experience would be swell.

Yes. Now you can have one location for your file, such as DropBox, OneDrive, Google Drive, or iCloud Storage. You'd start of in Comic Zeal's library and say "Open from another location" or something to that effect, and then go to your storage location of choice (someone might implement NFS shares or FTP besides just cloud services) and then do what you want with the file there. You'd need to store the downloaded file in a storage area (Mecury may have its own storage area).

Quote:

Quote:

Question #2: Can we finally aim files at local network shares instead of The Cloud through Extensions?

For instance, I created my masterpiece in an app — say Sketchbook — and want to store a copy on my NAS. Will I be able to do that from inside Sketchbook if the devs add the option, or if not, will I at least be able to send my masterpiece to a LAN capable app — say Good Reader — that can then directly access and write to my NAS?

Sure, why not? Good Reader will just need to provide an extension and it should be possible.

Quote:

Quote:

This was the post with two good questions that should have been answered, instead of the ridiculous and pointless back and forth flame battle.

The back and forth flame battle has little to do with the question getting answered or not.

Thanks for the responses. However, you're totally incorrect on your last point. Most of the higher-quality posters who really want to share info avoid threads like this specifically because of the wasteland you and others turned it into via your mobile OS holy war diatribes and personal attacks. Likewise, finding the few decent posts amidst almost 95% BS is difficult. I encourage you and others to think on it, and maybe ask yourselves why you really give so much of a shit about convincing other people on the internet you have not met nor ever will meet of something as silly as something involving who did what feature in a smart phone OS first.

How does this prevent a rogue keylogger? i.e. an "extension" keyboard that when remotely activated for a specific phone number begins to log key-presses to ... err ... a datacenter in Utah or China?

Good question.

One way that pointed out is that you explicitly have to enable the keyboard to have network access. Beyond that, really only Apple's security checks can prevent that. Here's an article about that.

It's worth pointing out that Android's security model is similar (apart from you accept the permission up front rather than piecemeal). So the moral of the story is only install apps from developers you trust!

If the only thing you can think to do when you see an article about a phone OS you don't use is to go into it and start complaining about how your preferred OS does it better/first, maybe you should find something else to occupy your time.

Just as a general suggestion. Also works for preferred desktop OSes, preferred videogame consoles and lots and lots of other subjects.

Question #1: Could these Extensions finally do away with the "double copy" issue?

For instance, I download a file in a web browser — say Mercury — then I go into Mercury's Downloads, select the file and "Open File" in another app — say Comic Zeal. This laboriously copies the file to Comic Zeal's Library and then, I have to go back to Mercury's Downloads and laboriously delete the file because I don't want to waste space on the already cramped iPad. Doing away with this particular user experience would be swell.

Yes. Now you can have one location for your file, such as DropBox, OneDrive, Google Drive, or iCloud Storage. You'd start of in Comic Zeal's library and say "Open from another location" or something to that effect, and then go to your storage location of choice (someone might implement NFS shares or FTP besides just cloud services) and then do what you want with the file there. You'd need to store the downloaded file in a storage area (Mecury may have its own storage area).

Quote:

Quote:

Question #2: Can we finally aim files at local network shares instead of The Cloud through Extensions?

For instance, I created my masterpiece in an app — say Sketchbook — and want to store a copy on my NAS. Will I be able to do that from inside Sketchbook if the devs add the option, or if not, will I at least be able to send my masterpiece to a LAN capable app — say Good Reader — that can then directly access and write to my NAS?

Sure, why not? Good Reader will just need to provide an extension and it should be possible.

Quote:

Quote:

This was the post with two good questions that should have been answered, instead of the ridiculous and pointless back and forth flame battle.

The back and forth flame battle has little to do with the question getting answered or not.

Thanks for the responses. However, you're totally incorrect on your last point. Most of the higher-quality posters who really want to share info avoid threads like this specifically because of the wasteland you and others turned it into via your mobile OS holy war diatribes and personal attacks. Likewise, finding the few decent posts amidst almost 95% BS is difficult. I encourage you and others to think on it, and maybe ask yourselves why you really give so much of a shit about convincing other people on the internet you have not met nor ever will meet of something as silly as something involving who did what feature in a smart phone OS first.

You're right, I shouldn't engage in flame wars. But when I do so, it's often out of a sense that I am saying something that is correct and someone else is wrong. And sometimes it's hard to know you're in a flame war until you're in one. And sometimes the flame part is a little one sided. If you bothered to read what I wrote, I have nothing against Apple or Google. I actually own devices by both, and I can see that they each have their merits.

For me personally, it's important that correct information be out there. I know I know, I can't fix everything. That's way too naive. But when it's something I have a bit of knowledge about I like to chime in. I'm a Business Systems Analyst, a large part of my job is training people to use software and to create intuitive software for them. So I see a lot of people with misconceptions and I like to kill that at the source, lest someone not as knowledgeable come along and believe something that's incorrect simply because they don't know better and it was unchallenged.

If the only thing you can think to do when you see an article about a phone OS you don't use is to go into it and start complaining about how your preferred OS does it better/first, maybe you should find something else to occupy your time.

Just as a general suggestion. Also works for preferred desktop OSes, preferred videogame consoles and lots and lots of other subjects.

I'll just quickly reply that, by your own logic, iOS is a couple of decades plus 7 years late on this concept.

Services have existed on iOS since the start. As I've already pointed out, system wide spell checking and dictionary lookup are examples of things implemented as Services in NextStep, OSX, and iOS.

However, Apple didn't allow third party developers access to Services until they came up with locked down secure version of the API.

This should seem very familiar from multitasking. iOS allowed first party programs to multitask right from the start. First party apps could, for instance, check mail in the background and play music in the background.

Third party apps were locked out until Apple came up with a restricted, battery life friendly multitasking API they allowed third party developers to use.

If the only thing you can think to do when you see an article about a phone OS you don't use is to go into it and start complaining about how your preferred OS does it better/first, maybe you should find something else to occupy your time.

Just as a general suggestion. Also works for preferred desktop OSes, preferred videogame consoles and lots and lots of other subjects.

Who was complaining?

Well the person who's spent the last four pages insisting that Android's implementation of this concept was the first and best version of it leaps to mind.

And of course whether or not that is true is ultimately entirely irrelevant, both in the context of this article and in the context of the Android/iOS "debate".

This article was describing how a new feature of iOS works, and how it was both similar and different to how Android handles it. The fact that Android did it first is of exactly zero importance for anything other than point scoring in an ultimately meaningless competition.

If the only thing you can think to do when you see an article about a phone OS you don't use is to go into it and start complaining about how your preferred OS does it better/first, maybe you should find something else to occupy your time.

Just as a general suggestion. Also works for preferred desktop OSes, preferred videogame consoles and lots and lots of other subjects.

Who was complaining?

Well the person who's spent the last four pages insisting that Android's implementation of this concept was the first and best version of it leaps to mind.

That's not complaining. Anyways, I said it was the first mobile device to be widely accepted that had an Intents/Extensions type model. Which is good. I'm glad Apple now has Extensions, and I look forward to using it in iOS 8. Copying from each other is good-it builds progress! When you keep standing on the shoulders of giants, both products get better and better. That benefits everyone.

Quote:

And of course whether or not that is true is ultimately entirely irrelevant, both in the context of this article and in the context of the Android/iOS "debate".

I never intended anything I said to be interpreted as an Android vs iOS debate. They're both solid mature, platforms that have learned from each other. Windows Phone is catching up in market share, and in my mind has the most growth potential. I'm a fan of things that work!

Quote:

This article was describing how a new feature of iOS works, and how it was both similar and different to how Android handles it. The fact that Android did it first is of exactly zero importance for anything other than point scoring in an ultimately meaningless competition.

I don't think it's of zero importance. It's nice to appreciate the evolution of your device. Sometimes the stories are entertaining!

I have no idea how factually accurate this is, but The Social Network showed that Mark Zuckerberg came up with the idea of displaying relationship status on a person's Facebook profile after a fellow student asked if he knew if a certain girl was single or not. That's the kind of little fact that's not necessarily handy to know, but it makes you appreciate how these products come to be the way they are. In the same vein, I think it's important to realize that Apple implemented Extensions on iOS in response to the success of the Intents system on Android. Android has been gaining market share, and one of the big differentiating features for Android was Intents. Give iOS a comparable solution, and it levels the playing field out. It might even it out so much as to cause some people to consider iOS devices that otherwise wouldn't have (the thought has crossed my mind to ditch my personal S4 and just use my company iPhone 5).

I don't care who "wins"-I just care that all platforms keep getting better. As the users, we benefit.

Andrew Cunningham / Andrew has a B.A. in Classics from Kenyon College and has over five years of experience in IT. His work has appeared on Charge Shot!!! and AnandTech, and he records a weekly book podcast called Overdue.