
What iOS Can Learn from Unix - ananddass
http://blog.inkmobility.com/post/60759200492/what-ios-can-learn-from-unix
======
tuxracer
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...](http://assets.sbnation.com/assets/1219228/complete-action-
android-41-jelly-bean-ss-16-verge-300.jpg)

~~~
rcoh
Ah, thanks for the heads up. I've updated the footnote.

------
nraynaud
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.

------
RyanZAG
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?

~~~
rcoh
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.

~~~
RyanZAG
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.

~~~
rcoh
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.

~~~
RyanZAG
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/](http://webintents.org/)

------
gdubs
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.

~~~
alayne
At this point there is JACK, AudioBus, and soon inter-app audio in iOS7.

~~~
swift
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-update-
is-already-here/)

------
mscottmcbee
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".

~~~
pjmlp
And Windows Phone adopted it in the form of contracts as well.

------
fournm
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.

~~~
rcoh
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?

~~~
Navarr
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.

~~~
alayne
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.

------
gwu78
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.

~~~
alanctgardner2
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.

~~~
gwu78
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.

~~~
alanctgardner2
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/](http://en.miui.com/)

~~~
gwu78
Thanks for this. If I can use U-boot with Nexus 4, I will certainly
investigate.

------
k_bx
> 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?

~~~
zeckalpha
Do you need the concept of files in order for that to happen?

~~~
k_bx
Well, I think yes (mimetypes at least).

~~~
zeckalpha
Sure, but the user doesn't need to know about the filesystem.

~~~
k_bx
Yes. He doesn't. He just taps on file he downloaded. Or opens reader app
(which scans all pdf's for him).

------
jpinkerton88
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.

~~~
kunai
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.

~~~
jpinkerton88
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.)

------
masswerk
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.

~~~
manojlds
Android does this already. Windows 8 (RT) and Windows Phone do too. The
article is only about iOS.

~~~
earlz
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

------
residualmind
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.

~~~
MrScruff
I think you're conflating being a software developer and being a power user.

------
ianstallings
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...](https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/AdvancedAppTricks/AdvancedAppTricks.html)

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.

~~~
rcoh
This is a good start -- [http://x-callback-url.com/](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.

------
bitwize
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.

~~~
rcoh
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.

------
mimiflynn
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\))

------
ekr
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.

------
ratherhost
What the author wants is Android.

iOS doesn't work that way, and for good reasons.

------
getachew
What inkmobility can learn from Unix: open source and live forever.

