What iOS Can Learn from Unix(blog.inkmobility.com)
blog.inkmobility.com
What iOS Can Learn from Unix
http://blog.inkmobility.com/post/60759200492/what-ios-can-learn-from-unix
58 comments
So really this is, "What iOS can learn from a 2008 Android device"? The author is wrong in his footnote. Android intents are both action and file type based or even wildcard URL based. http://assets.sbnation.com/assets/1219228/complete-action-an...
Ah, thanks for the heads up. I've updated the footnote.
I think they avoid a lot of features because they are immediately used for spam. Like the tray icons for windows, the start menu entry, the desktop icons, the chrome plugins, the menu icons in Mac OS X, the notifications etc.
The marketers are a plague, they destroy everything.
The marketers are a plague, they destroy everything.
From the footnotes:
> Android has intents which are a big step in the right direction. With a few tweaks to user experience they could solve this problem on the platform.
What tweaks would 'solve this problem'? As far as I can tell, Android intents work flawlessly for transferring content between apps. I can click an attachment on an email, open it in an editor, make changes, and then share that file back on a social network or another email. Each step taking only two taps. The speed of downloading attachments could do with some work in most cases, but that's just a hardware issue and will probably be far faster in another generation or two of hardware.
I have a feeling the author has never really used an Android device much? Or am I missing some key piece missing from intents?
> Android has intents which are a big step in the right direction. With a few tweaks to user experience they could solve this problem on the platform.
What tweaks would 'solve this problem'? As far as I can tell, Android intents work flawlessly for transferring content between apps. I can click an attachment on an email, open it in an editor, make changes, and then share that file back on a social network or another email. Each step taking only two taps. The speed of downloading attachments could do with some work in most cases, but that's just a hardware issue and will probably be far faster in another generation or two of hardware.
I have a feeling the author has never really used an Android device much? Or am I missing some key piece missing from intents?
An Android phone is my primary device. A few key issues for me:
1. No app discovery -- I want to find out about apps that can work with my content.
2. Action curation -- I want to see the actions that other people think are most useful when dealing with my content.
3. No "Return" actions -- eg. The context knowledge necessary to reply to the same message, or overwrite an existing file.
4. Cross device and cross OS: If this is done right, there's no reason for the action to be bound to just one device or even one person.
1. No app discovery -- I want to find out about apps that can work with my content.
2. Action curation -- I want to see the actions that other people think are most useful when dealing with my content.
3. No "Return" actions -- eg. The context knowledge necessary to reply to the same message, or overwrite an existing file.
4. Cross device and cross OS: If this is done right, there's no reason for the action to be bound to just one device or even one person.
1. When you initiate any action that would use an intent in Android, you get that selection popup window that let's you choose any app that can handle that intent. So I think there is already app discovery? Unless you mean something like Play Store integration into Android itself, in which you can view applications on Google Play that can handle that intent. That is pretty interesting and should be do-able even without Google's intervention with just a database of Google Play apps... I looked around but didn't find anything. Might be a cool project to try.
2. Each app defines what intents it can handle, so I don't think curation is necessary. The app select popup window is already curating that for you?
3. This context knowledge is provided inside every intent. Not all apps choose to use it, though. In some cases I'd guess the sandbox would get in the way as well. I'm not sure how much practical value this would have anyway? Can you explain it a bit more?
4. There is nothing stopping Apple from adopting Android intents, but obviously they won't. This is a 'pie in the sky' suggestion that won't happen for the same reason there is more than one flavour of Linux. It's like asking why you can't pipe results from your unix system to a Windows system - it just won't happen for political reasons.
2. Each app defines what intents it can handle, so I don't think curation is necessary. The app select popup window is already curating that for you?
3. This context knowledge is provided inside every intent. Not all apps choose to use it, though. In some cases I'd guess the sandbox would get in the way as well. I'm not sure how much practical value this would have anyway? Can you explain it a bit more?
4. There is nothing stopping Apple from adopting Android intents, but obviously they won't. This is a 'pie in the sky' suggestion that won't happen for the same reason there is more than one flavour of Linux. It's like asking why you can't pipe results from your unix system to a Windows system - it just won't happen for political reasons.
A few issues I have with android intents (Overall I love them):
- They are sometimes vague, and apps often advertise support for many intents they can't actually handle sanely. Trying to setup an email intent which actually only shows email clients is an example of this. The UX of showing a list of many apps which are not really good choices is pretty bad. I think the blame for this is largely on the apps themselves for not being more specific in their intent filters, but it still reflects badly on the platform.
- It loses the default choices on a regular basis. Updating an app which supports that intent and/or installing a new one seems to invalidate the default choice, which is really annoying. Especially in cases where you have e.g. installed a 3rd party browser, and now every time you click a link you have to choose which one to use.
- Once you have selected a default, you can't choose to use another one without digging through settings and clearing them for the app which has the default action set. Something like the right click and open with which we have on desktop operating systems would be great.
- They are sometimes vague, and apps often advertise support for many intents they can't actually handle sanely. Trying to setup an email intent which actually only shows email clients is an example of this. The UX of showing a list of many apps which are not really good choices is pretty bad. I think the blame for this is largely on the apps themselves for not being more specific in their intent filters, but it still reflects badly on the platform.
- It loses the default choices on a regular basis. Updating an app which supports that intent and/or installing a new one seems to invalidate the default choice, which is really annoying. Especially in cases where you have e.g. installed a 3rd party browser, and now every time you click a link you have to choose which one to use.
- Once you have selected a default, you can't choose to use another one without digging through settings and clearing them for the app which has the default action set. Something like the right click and open with which we have on desktop operating systems would be great.
1. I'm thinking of it being connected with Google Play.
2. Once you've increased the scope beyond the apps on the device, work needs to be done to show the most relevant and useful actions.
3. Enabling flows like:
- Take file from one app, edit in another app, save back over the original file
- Take an email attachment, edit / modify in another app, then reply back on the same thread
4. But there is no reason a third party can't come in and make it happen.
2. Once you've increased the scope beyond the apps on the device, work needs to be done to show the most relevant and useful actions.
3. Enabling flows like:
- Take file from one app, edit in another app, save back over the original file
- Take an email attachment, edit / modify in another app, then reply back on the same thread
4. But there is no reason a third party can't come in and make it happen.
Good points. The problem with creating this is that it would need system level access for each OS, I think. Adding these kind of intents into Windows or OSX would be easy enough, and adding them into browsers should be possible too (Firefox, at least, would be open to it). I can't see how you'd ever get this added into iOS. Google is unlikely to extend intents in this way for Android as it would break backwards compatibility also.
I think the technical challenge may be too great for current gen OSes and browsers? Perhaps we will see a system like this arise on the 'next battlefield', whatever that might be.
Here's hoping someone works it out. The system itself is not that difficult to understand or to implement, it's the logistics of it that would be difficult and (by definition) need a lot more collaboration between corps than currently.
Web Intents [1] are a push in this direction, but adoption is extremely slow and does not look like it is going to take place.
[1] http://webintents.org/
I think the technical challenge may be too great for current gen OSes and browsers? Perhaps we will see a system like this arise on the 'next battlefield', whatever that might be.
Here's hoping someone works it out. The system itself is not that difficult to understand or to implement, it's the logistics of it that would be difficult and (by definition) need a lot more collaboration between corps than currently.
Web Intents [1] are a push in this direction, but adoption is extremely slow and does not look like it is going to take place.
[1] http://webintents.org/
I've posted this before, but it's relevant to mention AudioBus which is a way to pipe separate music apps together on one iOS device. I've incorporated it into one of my apps and it works really well.
According to Michael, it's creator, it uses Mach Ports to communicate between apps. Apple embraced it and included it with GarageBand.
According to Michael, it's creator, it uses Mach Ports to communicate between apps. Apple embraced it and included it with GarageBand.
At this point there is JACK, AudioBus, and soon inter-app audio in iOS7.
Apparently AudioBus has already been updated to be interoperable with inter-app audio:
http://createdigitalmusic.com/2013/09/audiobus-for-ios-7-upd...
http://createdigitalmusic.com/2013/09/audiobus-for-ios-7-upd...
Android has this in the form of intents. Not quite as useful, but still works well. Maybe look at more than just iOS when talking about "the mobile space".
And Windows Phone adopted it in the form of contracts as well.
From a user perspective, intents are more useful and cover almost everything they're talking about. Most people really don't want to think about the how, they just want to share something to Facebook somehow. Having a standard way to just hook the Facebook app for it is what they really need.
It is a shame that we can't get more app functionality sharing in place, but really I don't know if we necessarily want to bring that much dependency management into the mobile space at large either.
It is a shame that we can't get more app functionality sharing in place, but really I don't know if we necessarily want to bring that much dependency management into the mobile space at large either.
I am not an Android developer. Is it possible for an application to create a new Intent, and then have another application use it, or can they only be blessed by Google?
Yes, it's possible. In fact, it's the whole idea. There is also content providers, which allows an app to give another app access to it's data. In fact, intents are how an app launches a new screen when you press a button etc - by sending an intent to the system telling it to launch a new activity.
Some of the UX around intents isn't great, but the core concept and implementation is very clever and doesn't get the attention and respect it deserves. Much like many aspects of Android.
Some of the UX around intents isn't great, but the core concept and implementation is very clever and doesn't get the attention and respect it deserves. Much like many aspects of Android.
Intents are useful, but could be better. A standard way to hook into the Facebook app is fine for Facebook but what about when the space is more fragmented? Should app authors have to integrate with every document viewer or Mail App?
I think the document manager [1] covers this use-case rather well. Any app can register with the OS as being able to open a certain type of file. Then it's just a couple lines to show the user an "Open in..." prompt for a file. This is what Dropbox, Mail, and GDrive do and I think we're going to see a lot more of it in the future.
[1]: https://developer.apple.com/library/ios/documentation/FileMa...
[1]: https://developer.apple.com/library/ios/documentation/FileMa...
You don't have to tie into any particular document viewer at all, in fact the default behavior is exceedingly simple. Call an ACTION_VIEW intent, provide the file argument, and the OS finds the right viewer that is already installed. The app I write doesn't have to know about the difference between .dxf and .xlsx at all, as long as the user has the right viewers. I can't honestly imagine an easier API than that.
In my app, I went one step further and when the user doesn't have an app installed for the given file type, I recommend one, but that isn't a requirement. I keep track of what percentage of view file requests are fulfilled by an already installed app, and it is generally over 95%.
I think you guys should better understand Intents before you trash them (and actually try to replicate them on iOS). Why was the use of Intents so minimal in the Filepicker.io Android library? I replaced that library with a intents and have a much more robust application.
In my app, I went one step further and when the user doesn't have an app installed for the given file type, I recommend one, but that isn't a requirement. I keep track of what percentage of view file requests are fulfilled by an already installed app, and it is generally over 95%.
I think you guys should better understand Intents before you trash them (and actually try to replicate them on iOS). Why was the use of Intents so minimal in the Filepicker.io Android library? I replaced that library with a intents and have a much more robust application.
Standard way to hook into the Facebook app is a "Share Intent" which can be picked up by any other social network application; such as Google+, my text messaging app, Google Hangouts, and so many others. Even allowing "copy to clipboard" and "Pin" and whatever else. Almost every Android app creates a Share Intent listener to pull in data.
If there's a document viewer, it'll listen in for the file types it supports when you try to open a file (I think its a VIEW intent). It's all very impressive and very, very useful.
If there's a document viewer, it'll listen in for the file types it supports when you try to open a file (I think its a VIEW intent). It's all very impressive and very, very useful.
Unless they've changed it, you'll have to use the FaceBook SDK to do anything more than post a URL. FB's intent support is bad.
Ah, yeah. I was talking about iOS in particular. Android intents are pretty sweet -- a couple the missing bits to make them great in my mind are
-- App discovery: tell me about apps that can use my content if I don't have any?
-- Action curation: What do users think are the best app for this action?
How about we produce an enclosure that looks about as good as an iPhone or iPad (as some are already doing; hello Samsung). Inside we put cheap electronics, but with no barriers to what software can be run (hello Apple) and no barriers to inspecting each and every line of software code that will be running on our device that we own (hello, Apple). Finally, we install our own open source OS (say, UNIX). That UNIX might be so simple that we could, if desired, compile it ourselves from scratch. Maybe even the compiler itself. No better route to security, if there is such a thing.
If iOS is so great and there is demand, Apple can sell us a license to run it on our device. My guess is that few would pay for this. More likely, the market would demand a windowing GUI, not an entire OS (e.g., one borrowed from CMU, FreeBSD and NetBSD; hello again Apple). Could developers respond and deliver one?
UNIX can do lots of things well. And well enough. That's probably why iOS relies on UNIX and not some other OS. But iOS won't let you do all the things that UNIX will let you do.
Conclusion: iOS is inferior to other, more open, more traditional UNIX alternatives. Apple does make a nice windowing GUI. And some very nice enclosures. Each worth a price, no doubt. But UNIX, the code that does the important stuff, has always been free.
If iOS is so great and there is demand, Apple can sell us a license to run it on our device. My guess is that few would pay for this. More likely, the market would demand a windowing GUI, not an entire OS (e.g., one borrowed from CMU, FreeBSD and NetBSD; hello again Apple). Could developers respond and deliver one?
UNIX can do lots of things well. And well enough. That's probably why iOS relies on UNIX and not some other OS. But iOS won't let you do all the things that UNIX will let you do.
Conclusion: iOS is inferior to other, more open, more traditional UNIX alternatives. Apple does make a nice windowing GUI. And some very nice enclosures. Each worth a price, no doubt. But UNIX, the code that does the important stuff, has always been free.
There is no barrier to what software will run on your nexus device. For example, I could put android, or Ubuntu on my Nexus 4. Doesn't that meet all your requirements? The hardware is even sold near cost, by a well-known manufacturer.
It might meet some. Does it boot from external media? Can I use my own bootloader? Android or Ubuntu are both Linux. What about something like BSD or Plan9?
To be truthful, my "requirements" include first and foremost, a great looking enclosure. There is a reason for that. I want be able to buy the enclosure separately. This is important.
In my vision, there would multiple sources for boards that might fit inside. Not every user might want or need the same computing power or peripherals.
Imagine, to take an example, if there were multiple RaspberryPi-sized boards. Then you could mix and match different available enclosures[1] with different boards.
1. We are seeing the market respond with many, varied enclosures for the Pi.
There are lots of development boards for sale to consumers, and there are dedicated people porting UNIX OS's to run on them.
What I don't see, generally, are reasonably-priced and attractive enclosures for these boards. The RaspberryPi may be changing this state of affairs, as the Pi enclosure market continues to grow.
Separating out the parts of the device, from the enclosure to the PCB to the OS to the third party software is, you might say, like the UNIX userland philosophy of isolating functions to their own individual utilities. This separation allows more flexibility and more power, in the example of the UNIX userland by allowing the user to filter and redirect output and connect utilities together with pipes.
What are the things Apple does well? Enclosures and graphics, in my opinion. (And controlling their users :) UNIX is not on the list. There are better UNIX alternatives than iOS. My opinion.
Or, as in the article, you can wait and hope that iOS can be improved to be more like those UNIX alternatives.
To be truthful, my "requirements" include first and foremost, a great looking enclosure. There is a reason for that. I want be able to buy the enclosure separately. This is important.
In my vision, there would multiple sources for boards that might fit inside. Not every user might want or need the same computing power or peripherals.
Imagine, to take an example, if there were multiple RaspberryPi-sized boards. Then you could mix and match different available enclosures[1] with different boards.
1. We are seeing the market respond with many, varied enclosures for the Pi.
There are lots of development boards for sale to consumers, and there are dedicated people porting UNIX OS's to run on them.
What I don't see, generally, are reasonably-priced and attractive enclosures for these boards. The RaspberryPi may be changing this state of affairs, as the Pi enclosure market continues to grow.
Separating out the parts of the device, from the enclosure to the PCB to the OS to the third party software is, you might say, like the UNIX userland philosophy of isolating functions to their own individual utilities. This separation allows more flexibility and more power, in the example of the UNIX userland by allowing the user to filter and redirect output and connect utilities together with pipes.
What are the things Apple does well? Enclosures and graphics, in my opinion. (And controlling their users :) UNIX is not on the list. There are better UNIX alternatives than iOS. My opinion.
Or, as in the article, you can wait and hope that iOS can be improved to be more like those UNIX alternatives.
While there doesn't exist any project to run BSD or Plan 9 on a Nexus right now, there is literally nothing stopping that from happening (except tremendous apathy from pretty much the whole world).
I don't understand being so hung up on the enclosure. Nothing's stopping you from fabricating new enclosures for Nexus 4s. You could even mass produce them, and repackage new Nexus 4s as a value-added service for people. You could, theoretically, buy up busted iPhones from ebay and repack them as Android devices - although it'd be much easier to buy one of the million fake iPhones from China, which are already basically reference Android devices.
On the UI side, Samsung was on the way to shipping their devices with an iOS clone around the time of the S2. If you want an Android experience which is very similar to iOS, you could even look at MIUI [1], which rips off a bunch of Apple's design philosophy.
In short, everything you asked for is already very possible, it's just that nobody is handing it to you on a platter. You could try to get rich enough to buy 51% of Apple, and redirect their whole corporate focus. Or you could pick an interesting project and start hacking ;)
1. http://en.miui.com/
I don't understand being so hung up on the enclosure. Nothing's stopping you from fabricating new enclosures for Nexus 4s. You could even mass produce them, and repackage new Nexus 4s as a value-added service for people. You could, theoretically, buy up busted iPhones from ebay and repack them as Android devices - although it'd be much easier to buy one of the million fake iPhones from China, which are already basically reference Android devices.
On the UI side, Samsung was on the way to shipping their devices with an iOS clone around the time of the S2. If you want an Android experience which is very similar to iOS, you could even look at MIUI [1], which rips off a bunch of Apple's design philosophy.
In short, everything you asked for is already very possible, it's just that nobody is handing it to you on a platter. You could try to get rich enough to buy 51% of Apple, and redirect their whole corporate focus. Or you could pick an interesting project and start hacking ;)
1. http://en.miui.com/
Thanks for this. If I can use U-boot with Nexus 4, I will certainly investigate.
Yeah - the only restriction on a Nexus is that if/when you unlock it, you must wipe the data on the phone - which is for completely legitimate security reasons.
> What iOS Can Learn from Unix
Having concept of "files" to be able to open pdf you just downloaded from email/browser inside pdf reader?
Having concept of "files" to be able to open pdf you just downloaded from email/browser inside pdf reader?
You can totally do that today.
I would like to see this done well. However, with Apple trying to protect and cater to the "every-day user", I wonder if we will ever see something like this, because of the security implications that come with it.
It's a fallacy that the every-day user doesn't want or need a filesystem.
They do need a filesystem and interoperable components. What they do NOT need is a hierarchical based filesystem that limits you to a directory trees. It's an organizational nightmare, and unless you've ever used git before it's a literal hell for the average user.
Instead, a flat filesystem with smart names, tagging, and metadata is the way forward. Subdirectories will be relegated to those who want them.
As for security, that excuse is nonexistent when Apple has the final authority to application interoperability and analysis. If an implementation is flawed, they can reject it at will and tell the developers to improve it.
They do need a filesystem and interoperable components. What they do NOT need is a hierarchical based filesystem that limits you to a directory trees. It's an organizational nightmare, and unless you've ever used git before it's a literal hell for the average user.
Instead, a flat filesystem with smart names, tagging, and metadata is the way forward. Subdirectories will be relegated to those who want them.
As for security, that excuse is nonexistent when Apple has the final authority to application interoperability and analysis. If an implementation is flawed, they can reject it at will and tell the developers to improve it.
I agree. I was just trying to imagine what Apple's will do since they have been trying for years to eliminate the file system for the every-day user, even on OSX (iTunes, iPhoto, Notes, etc.)
We think that the key is to provide a limited and controlled interface between the apps (which is what we're trying to do). We'll see how it goes :-)
I think that there's more to it than what's mentioned in the article: Todays mobile OSes (and iOS prominently) have been designed as consumer OSes. Now it is becoming apparent that mobile devices are eventually becoming a platform for work (well, "work" might be a bit exaggerated here) and targeted task-fullfilment too.
Time to rethink the mobile OS as a whole.
Time to rethink the mobile OS as a whole.
Maybe that's exactly the point - they're consumer OSes. And while Android already does this, with intents, I doubt most consumers are very happy with this feature (if they even know it exists).
You want to do something with an image, for example, and you're greeted with a huge list of apps that all claim to handle images. Not only is it hard to find the app you want, most of the ones in the list have nothing to do with the task you're trying to accomplish. Hardly user friendly behavior.
FWIW, I personally don't really mind the huge list and can find my way around it, but I'm a heavy Unix user that does most of his work in the terminal already. Most consumers are not.
You want to do something with an image, for example, and you're greeted with a huge list of apps that all claim to handle images. Not only is it hard to find the app you want, most of the ones in the list have nothing to do with the task you're trying to accomplish. Hardly user friendly behavior.
FWIW, I personally don't really mind the huge list and can find my way around it, but I'm a heavy Unix user that does most of his work in the terminal already. Most consumers are not.
You are right. I can't see this for consumer devices. Also it would do major damage to app-stores, so there is no broader interest in it. And no one would release and maintain an OS dedicated to power users only (there are to few) – it just doesn't scale.
Apple had once an approach to this in the old Classic OS, by a switch that would enable or disable some access and features in the OS (esp. Finder). While this wasn't a great success on the desktop (like any other easy-suites), it might be worth to rethink for the mobile platform.
Apple had once an approach to this in the old Classic OS, by a switch that would enable or disable some access and features in the OS (esp. Finder). While this wasn't a great success on the desktop (like any other easy-suites), it might be worth to rethink for the mobile platform.
Android does this already. Windows 8 (RT) and Windows Phone do too. The article is only about iOS.
Windows RT does NOT do this.. They have a few very limited APIs for IPC, such as Search.. other than that, it's very tied down. Even so much so that it's impossible to make a universal file browser. You have to declare ahead of time which file extensions your application should be capable of opening
Think of Mac OS Automator for mobile devices (let's name it "Task Composer"), letting you assemble whole workflows based on pipes. But this would potentially harm any AppStore interests, so this will never happen, not on any of the current platforms.
(Edit: This would also afford to expose system calls to the end user, being the end of consumer haven.)
(Edit: This would also afford to expose system calls to the end user, being the end of consumer haven.)
Yes. The Ubuntu Phone / OS is a interesting byproduct of this idea.
This is why I'm still not able to wrap my head around some developers' fascination or love for iOS. Or actually apple at all, since the Apple ][ tbh. Especially when it is becoming more clear that they target the "consumer" range. Unless it's only for profit. But love? Off topic, sorry. Android intents.
I think you're conflating being a software developer and being a power user.
Although it's not a true "pipe", the best way to handle data transfer between apps on iOS is to use custom URL schemes. I've done this to pass data and launch another application.
See "communicating with other apps": https://developer.apple.com/library/ios/documentation/iPhone...
In one app framework we built we had a fairly complicated parser and it could handle a pretty wide variety of URL paths and the supplied data. But there in turn lies the problem - each app must have a mechanism to handle the parsing and routing for these URLs.
See "communicating with other apps": https://developer.apple.com/library/ios/documentation/iPhone...
In one app framework we built we had a fairly complicated parser and it could handle a pretty wide variety of URL paths and the supplied data. But there in turn lies the problem - each app must have a mechanism to handle the parsing and routing for these URLs.
This is a good start -- http://x-callback-url.com/ is a standard and listing for apps that support it. The biggest problem is that there is a limited amount of data that you can transfer in a URL (about 80KB I believe) so even large PDFs will start to cause problems.
Small isolated components lead to communication overhead and can cripple performance.
They offer certain advantages, too, but this is no different from any other software-engineering tradeoff.
There's a reason why the winning kernel is a monolithic kernel, and the winning init system is one large God-daemon that replaces many smaller legacy daemons.
They offer certain advantages, too, but this is no different from any other software-engineering tradeoff.
There's a reason why the winning kernel is a monolithic kernel, and the winning init system is one large God-daemon that replaces many smaller legacy daemons.
There's a difference between the performance you want in your kernel and the performance you need sharing to Facebook. It seems like creating monolithic mobile apps is premature optimization.
When I read the headline I thought "isn't iOS based on Darwin?" and then I read the article. Good points, but I feel the headline is a bit off.
http://en.wikipedia.org/wiki/Darwin_(operating_system)
http://en.wikipedia.org/wiki/Darwin_(operating_system)
All the downfalls mentioned in the article (and many others) are direct consequences of non-free software. Apparently the author is oblivious to this fact, and the nature of free software.
What the author wants is Android.
iOS doesn't work that way, and for good reasons.
iOS doesn't work that way, and for good reasons.
What inkmobility can learn from Unix: open source and live forever.