4 ms·

There is one thing that can be observed here, imho. That iOS was made to be sleek right from the start, from there they sacrificed pragmatic system design, whic

by nubela 15y ago

There is one thing that can be observed here, imho. That iOS was made to be sleek right from the start, from there they sacrificed pragmatic system design, which efficiently crimped a lot of flexibility; flexibility such as 3rd party input, etc, of which has gotta be now implemented from system up. As an Android user, given my (now) better understanding of the Android architecture design, I am happy and safely say that Android was made for the future, and is only gonna get better from here on.

chwahoo 15y ago
However, if iOS is able to evolve additional flexibility as it is needed without too much pain, then perhaps they made the right design choices at the start?
- campnic 15y ago
  I agree, its far to early to make any decisions about which platform "made the right decisions". We're in the first inning still for mobile.
- fpgeek 15y ago
  I think both Google and Apple made the right design choices at the start. They just made different ones is because they had different business goals. Google wanted Android to be ubiquitous and free to quickly evolve into whatever it needed to be to be in order to capture territory in the mobile device world. That means supporting a wide range of devices, technologies and, most importantly, partners (both hardware, software, carriers, etc.). So Android was designed for flexibility and has extension points everywhere (input frameworks, sharing, alternative browsers, launchers and so on). Google gave up performance along many dimensions in order to maximize Android's adaptability. Apple is very different. They have a vision and want to build that vision as precisely as they can because that is what has driven their success. That means Apple doesn't want hardware partners. And even at the software level, thsat means they are very careful about who and what they allow into their user experience. You can see this in how they built new features for iOS 5: Apple added a split keyboard for the iPad rather than adding support for alternative keyboards. They bought Siri rather than exposing relevant extension points. Apple baked Twitter into iOS 5 as a one-off, rather than riffing off of Android's sharing (as they did with notifications). And so on. These are all business decisions, not technical ones (as Cydia often proves). Instead, iOS's technical architecture flows from Apple's goals in the same way Android's flows from Google's.
  - MrScruff 15y ago
    You're inferring engineering decisions based on product outcomes. You have no idea how the various extensions you describe were implemented, and with what regard to future extension. For example many people claimed early on that iOS 'didn't support multitasking', which was correct at a feature level, but not at an engineering level.
foobarbazetc 15y ago
Your views make no sense. iOS applications also run in separate processes and are just as secure as Android apps. There's nothing "made for the future" in the poor up front design choices the Android team made early on. In fact, we can clearly see that the iOS team made all the right decisions because drawing/compositing in iOS on a 3GS is faster and smoother than on a shiny new Android Inspiration XL HD 4G. Also, Dianne shows a fundamental misunderstanding of how drawing/compositing works on iOS. So this entire series of posts is just moot. The other guy (Windows Phone guy) had no idea how Android or iOS worked, either. The most annoying thing about all this is that none of these views are based on actual facts -- and we all know what happens when someone is wrong on the Internet. At the end of the day, who cares which one is better or how it's implemented? I don't care about the "Android has windows" explanation because it's irrelevant to me as an end user. It's all about perception. This entire Android vs iOS thing is getting long in the tooth. Edit: also, it's going to take a long, long time to be able to pull off something as awesome as Core Animation. Or Core Text. Or Core Graphics. These things have been stewing in OS X for more than a decade.
- kkowalczyk 15y ago
  In what way exactly Skia (which is the vector graphics library that powers Android and Chrome) is any less "awesome" than Core Graphics? The same goes for Core Text or Core Animation - they are not doing anything especially hard or mind blowing. Android displays text just as well and has an animation APIs that are arguably easier to use that Objective C APIs.
  - stephen_g 15y ago
    It may just be the (in my opinion at least) bad typefaces Android ships with, but you're the first person I've heard say that Android's text rendering is as good as iOS's... Perhaps it's also that most of the Android devices I've used have had worse displays than my iPhone's as well, but I've not found Androids text to look that good...
    - Xuzz 15y ago
      Be sure to take a look again with a phone running Android 4.0 when those are more available: the new "Roboto" typeface is pretty good on more hi-res secreens, especially compared to the "Droid Sans" they were using before.
Xuzz 15y ago
As someone who spends a significant amount of time reverse engineering how iOS works, that is incorrect. Currently, the iOS keyboard is managed by the app itself (and I agree: this was likely chosen originally for performance). However, iOS does not expose any APIs that would break by moving this out of process, and in fact, many parts of the UI while inside an app are rendered and displayed out of process, by a separate application (in this case, the window manager, "SpringBoard"): the "Notification Center" is one, but also the "multitasking tray" and the little overlays you get when you change the volume. The reason that the keyboard is required to be implemented "from the system up" is that Apple idea of an "App Store" is fundamentally opposed to the idea, not because of any technological restriction. Apple only sells "apps" with "icons" (by choice), but this gives them one fundamental advantage: all apps are identical, and completely self-contained. I don't agree with that — I use a jailbroken iPhone, for one. But I definitely do see the value for users who don't know what the idea of "an alternate keyboard" would even mean. (On a jailbroken iPhone, I could likely move the keyboard out of process with a week of work; Apple could surely do it even faster. They just don't have any need to: there is no possible situation where, to them, the "flexibility" of alternate input methods is superior to the mental simplicity of just selling an "app" with an "icon".)
deleted 15y ago
[deleted]
conradev 15y ago
I completely disagree. As someone else who reverse engineers how iOS works, one of its core principles is in fact flexibility. Almost every key feature in iOS - search, backup, Siri, sharing, etc. is implemented using bundles, which are modules of code. This system provides a convenient interface for Apple and jailbreakers alike to add functionality to the OS. Your assumptions are based on the fact that no official APIs are provided to modify the OS in a sweeping way. Apple could very easily implement such a thing if they wanted - they would simply have to shift some code around. The reason Apple does not do this is because Apple favors simplicity over flexibility, or rather, maintains a balance between the two.

by nubela 15y ago

chwahoo 15y ago

However, if iOS is able to evolve additional flexibility as it is needed without too much pain, then perhaps they made the right design choices at the start?

campnic 15y ago
I agree, its far to early to make any decisions about which platform "made the right decisions". We're in the first inning still for mobile.
fpgeek 15y ago
I think both Google and Apple made the right design choices at the start. They just made different ones is because they had different business goals. Google wanted Android to be ubiquitous and free to quickly evolve into whatever it needed to be to be in order to capture territory in the mobile device world. That means supporting a wide range of devices, technologies and, most importantly, partners (both hardware, software, carriers, etc.). So Android was designed for flexibility and has extension points everywhere (input frameworks, sharing, alternative browsers, launchers and so on). Google gave up performance along many dimensions in order to maximize Android's adaptability. Apple is very different. They have a vision and want to build that vision as precisely as they can because that is what has driven their success. That means Apple doesn't want hardware partners. And even at the software level, thsat means they are very careful about who and what they allow into their user experience. You can see this in how they built new features for iOS 5: Apple added a split keyboard for the iPad rather than adding support for alternative keyboards. They bought Siri rather than exposing relevant extension points. Apple baked Twitter into iOS 5 as a one-off, rather than riffing off of Android's sharing (as they did with notifications). And so on. These are all business decisions, not technical ones (as Cydia often proves). Instead, iOS's technical architecture flows from Apple's goals in the same way Android's flows from Google's.
- MrScruff 15y ago
  You're inferring engineering decisions based on product outcomes. You have no idea how the various extensions you describe were implemented, and with what regard to future extension. For example many people claimed early on that iOS 'didn't support multitasking', which was correct at a feature level, but not at an engineering level.

foobarbazetc 15y ago

Your views make no sense. iOS applications also run in separate processes and are just as secure as Android apps. There's nothing "made for the future" in the poor up front design choices the Android team made early on. In fact, we can clearly see that the iOS team made all the right decisions because drawing/compositing in iOS on a 3GS is faster and smoother than on a shiny new Android Inspiration XL HD 4G. Also, Dianne shows a fundamental misunderstanding of how drawing/compositing works on iOS. So this entire series of posts is just moot. The other guy (Windows Phone guy) had no idea how Android or iOS worked, either. The most annoying thing about all this is that none of these views are based on actual facts -- and we all know what happens when someone is wrong on the Internet. At the end of the day, who cares which one is better or how it's implemented? I don't care about the "Android has windows" explanation because it's irrelevant to me as an end user. It's all about perception. This entire Android vs iOS thing is getting long in the tooth. Edit: also, it's going to take a long, long time to be able to pull off something as awesome as Core Animation. Or Core Text. Or Core Graphics. These things have been stewing in OS X for more than a decade.

kkowalczyk 15y ago
In what way exactly Skia (which is the vector graphics library that powers Android and Chrome) is any less "awesome" than Core Graphics? The same goes for Core Text or Core Animation - they are not doing anything especially hard or mind blowing. Android displays text just as well and has an animation APIs that are arguably easier to use that Objective C APIs.
- stephen_g 15y ago
  It may just be the (in my opinion at least) bad typefaces Android ships with, but you're the first person I've heard say that Android's text rendering is as good as iOS's... Perhaps it's also that most of the Android devices I've used have had worse displays than my iPhone's as well, but I've not found Androids text to look that good...
  - Xuzz 15y ago
    Be sure to take a look again with a phone running Android 4.0 when those are more available: the new "Roboto" typeface is pretty good on more hi-res secreens, especially compared to the "Droid Sans" they were using before.

Xuzz 15y ago

As someone who spends a significant amount of time reverse engineering how iOS works, that is incorrect. Currently, the iOS keyboard is managed by the app itself (and I agree: this was likely chosen originally for performance). However, iOS does not expose any APIs that would break by moving this out of process, and in fact, many parts of the UI while inside an app are rendered and displayed out of process, by a separate application (in this case, the window manager, "SpringBoard"): the "Notification Center" is one, but also the "multitasking tray" and the little overlays you get when you change the volume. The reason that the keyboard is required to be implemented "from the system up" is that Apple idea of an "App Store" is fundamentally opposed to the idea, not because of any technological restriction. Apple only sells "apps" with "icons" (by choice), but this gives them one fundamental advantage: all apps are identical, and completely self-contained. I don't agree with that — I use a jailbroken iPhone, for one. But I definitely do see the value for users who don't know what the idea of "an alternate keyboard" would even mean. (On a jailbroken iPhone, I could likely move the keyboard out of process with a week of work; Apple could surely do it even faster. They just don't have any need to: there is no possible situation where, to them, the "flexibility" of alternate input methods is superior to the mental simplicity of just selling an "app" with an "icon".)

deleted 15y ago

[deleted]

conradev 15y ago

I completely disagree. As someone else who reverse engineers how iOS works, one of its core principles is in fact flexibility. Almost every key feature in iOS - search, backup, Siri, sharing, etc. is implemented using bundles, which are modules of code. This system provides a convenient interface for Apple and jailbreakers alike to add functionality to the OS. Your assumptions are based on the fact that no official APIs are provided to modify the OS in a sweeping way. Apple could very easily implement such a thing if they wanted - they would simply have to shift some code around. The reason Apple does not do this is because Apple favors simplicity over flexibility, or rather, maintains a balance between the two.