Love the iPhone or hate the iPhone, at least you know what you’re getting out of the box is a device that will work with all the apps in the App Store. That’s been the case so far with Google’s Android platform as well — but only because there has been only one device, the G1. With more devices starting to roll out, and a new firmware (1.5, “cupcake”) to support them, things are continuing to get a bit murky.
Last week, we wrote about how the 1.5 Android software update would break some apps that previously worked with Android. Google gave some tips as to how to fix them, but it’s still a bit troubling. Today, comes another post on the Android Developer blog with two dreaded words: Backward compatibility.
As an open platform, Google isn’t requiring backward compatibility for all Android apps. But as more devices and applications come out, that could be an issue. As Google writes, “do you want to allow your application to run on all devices, or just those running newer software?” Plenty of iPhone apps answer that very question with the latter. And while you might think that may be limiting, it ensures a certain level of simplicity in the App Store — and perhaps more importantly, in developing for the iPhone.
The iPhone platform already has a massive lead in terms of applications built for it over Android. Anything, such a backwards compatibility code, that adds complexity to developing for Android is certainly not going to help. And it ties back to the fundamental difference between the iPhone and Android. iPhone, as a closed system with devices only made by Apple, can easily control the development ecosystem and important things like user experience. Android, with its more open system, will have a much harder time doing both. But because Android will be on so many more phones (and various other machines) it would seem that it will grow into the larger platform at some point.
Yes, it’s essentially the same thing that happened with Microsoft versus Apple in the PC wars of the 80s and 90s. But, as we’ve learned from that, “bigger” doesn’t necessarily mean “better.”
first
Given the fact that Googles list of FAIL is pretty short.. i’m betting on Google.
.
.
Butch Decossas
But what have they done well other than have a cool search name?
Troll.
gmail?
google maps?
analytics?
adsense?
google earth??
picasa
maps/ street view
blogger
blueprint
chrome
google’s list of success is pretty short too.
Arrest Developement Galore right there.
You know, I really thought google would do better with this. Modularity is very important and has been for some time now. And you would think that they would have built their framework to withstand upgrade/updating.
That being said, maybe they were working on the first version of Android longer than we can assume (could be documented, who knows?) and their code might be able to make up for the setbacks it creates. Basically, maybe they developed it at a time where the features on it were unheard of, came to market late, and now this new upgrade might fix things and add the modularity.
Let’s hope for the users’ sake that BackCompat will be for this generation only and that they are creating a way for developers to be ensured that their work will not be broken with updates and upgrades to android.
See, that’s why I think they should do as much as they possibly can server-side, regardless of implications on user-to-user rights to any given licenses and hard copies of data.
Brian
There is no system or design so resilient that unforeseen requirement changes can be incorporated without breaking an existing assumption. Stuff always has to be broken to accommodate the new. Think deprecated libraries(or calls within them), DLL hell, COM/ActiveX, binding to specific versions of runtime to ensure programmed assumptions remain valid were all attempts to nail this problem.
Bottom line there is no easy or even no solution.
I thought android was proprietary – I do fully understand where you are coming from though I am not yet good with programming, and actually I would very much like to connect with some.
Nevertheless, since Android began development (since I’m sure it was being worked on for long before I ever heard of it) there have been a lot of advancements made in how you can future-proof your applications. GTA IV, though unrelated here, will be one of those examples that are most noticeably “future proofed” – they said it is and we don’t see it yet, but we also don’t see the subsequent games on that technology yet, nor do we have the opportunity to look into the file structures and see them evolve either – we only have Liberty City to look at. The way that that game’s press influenced my mode of thought leads me to believe this is the new trend – especially with serious architecture changes looming in the near future for lots of different devices, not just PCs.
I know nothing is truly future proofed, but as I begin to recall now without taking the time to go look into Android history, it did use a lot of existing technology and third party stuff, right? Making my assumption Android was proprietary wrong?
I based my comment on the way that google is really keen on innovation – definitely one of my favorite companies, and the best one doing what they do in most of things they do, in my opinion of course *breathe* lol
You know how you can only make a wheel so round, then you’ve got to move on to something else? I like to take the optimistic approach that we are pretty close to having the right production systems in place where sequential releases will be the norm for any given brand, singularly, and backward compatibility will be a thing of the past – at least for things like cell phone OSs, and one from google, where this company knows all too well the hints that the modularity of the web can and has loaned to the real programming world that creates the code that actually runs it all.
Given that the Cloud concepts are so popular and frameworks now allow speedy development with only a cost at initialization of the program (if I understand correctly – I’m new to code, not to tech, so I can be presumptuous at times about this! I think it can inspire the coders out there if I’m wrong, because it’s a view of someone who thinks “this might be where they are going with cloud, .net and similar, branded OS’s on devices)
I’m a total nub with this right now, though. I’ve watched lots of programming videos and lectures and read through a few parts of the well known books out there, written a hello world and did the C# web browser building webinar.
If, and only if since I am spectating, I am anywhere near the right guess at the goals of the leading technology providers out there, then I’d predict here and now that though this breaks backward compatibility for some apps, it will probably greatly reduce that happening in the future. Of course, that would obviously make sense to shoot for, but I think if anyone can pull it off, it would be google, it would be MS, it would be Apple, it would be Rockstar North. Again, though, I am watching from the sidelines, and if it isn’t too much, you really seem to know what you are talking about and I’d like to hear your view and come out with an even better understanding if it isn’t too much. Thanks Mahesh!
I think you misunderstood what “GTA4 is future proof” actual meant. Rockstar claimed it was future proof because it has graphics settings that can’t be handled very well by today’s hardware. So when you upgrade your computer in the future, you will be able to run on higher settings.
1. This really only “future proofs” it until the next generation of hardware comes out
2. I think that was more of a PR friendly way to say they didn’t optimize it for the PC very well.
It can be looked at that way, but you also haven’t seen it yet – I am spectating though. Same game will be future proof for the next XBox though, and the new XBox will compete with the PS3.
You might like to look into the future of game development and you’ll see why I got that impression from it that title. Particularly the abandonment of graphics APIs and shifting most of the efforts toward in-house solutions that use CPU cycles more and leaving DX for playing your then-to-be-legacy games. Sweeney from Epic talks about it a lot in his interviews lately, but it IS all one big puzzle that will never be accurate until it actually happens – in which case I reiterate that I am speculating. I am fairly certain that IV was built to last through 5, 6, 7 (and not the sequels to IV – the sequels to the actual series ie: not VC, SA, but the next thee Liberty Cities)
Cheers!
You seem to be basing your opinion on this TechCrunch article. Let me tell you, that is a mistake. They are as uninformed as anyone.
Go take a look at the actual platform. The Android SDK’s handling of versioning is actually pretty damn good.
MG
As I was reading the post thought about what challenges Microsoft would have had and you nailed that idea in your closing statement. Balanced perspective in this post.
Backward compatibility is dirty word until you actually need an older application to just work. Not every user wants the shiniest newest app that is going to disregard the infrastructure and familiarity invested already.
Android will do just fine as long as its open nature remains. It does not have to match every value proposition of the iPhone platform. A simple open system will always outmatch a complex closed system, however contrary the initial signs might be.
True on backwards compatibility to some extent, but it’s surprising that Android is having to delve into these more complicated waters so soon after the initial launch.
This is the first significant update of the Android platform, adding support for new kinds of hardware (without keyboards) and major new APIs. It is perfectly reasonable to tell developers things like how to use the new APIs while still running on older versions of the platform (as the referenced backwards compatibility post discusses) if they want to do that. This is totally normal software development.
These issues come up with any platform update… show me a platform that never causes problems for some older applications, and I’ll show you one that either has very few applications or never has significant updates.
Fwiw, a lot of the backwards compatibility issues in this update come from developers using non-public APIs that they were repeatedly warned not to do. The major changes most developers may want to do are for software input methods, but this is optional since the platform will allow most existing applications to work on new devices that don’t have a physical keyboard (as the platform should do), though often in a non-optimal way. There was also some tightening of security that limits what a few apps can do (but should make things better for most users), and a few apps actually have true problems caused by changes in the platform that are no fault of the apps themselves.
I disagree with that closing statement you laud:
“Yes, it’s essentially the same thing that happened with Microsoft versus Apple in the PC wars of the 80s and 90s. But, as we’ve learned from that, “bigger” doesn’t necessarily mean “better.””
We have a positive Apple halo right now, but keep in mind how miserable the Apple experience was for much for the 90s. It wasn’t until OSX that Apple definitively overtook the user experience mantle that Microsoft owned (after Apple’s initial ownership of said mantle).
State what you will about the cause of Apple decline during that era, but I think most would agree that their closed system had something to do with it.
I love my iPhone, but I think Apple has been proven to fall victim to hubris and mistakes of control. I’d hate to see it happen again, but they show symptoms.
It’s way too early in the game for Google to start screwing with their users like this.
Well some android apps, like the decongester, are only going to make sense (or be sanitary) with specialized hardware.
http://www.yout...h?v=KEYWtouy8eE
Beyond backward compatibility, open platforms also make it more difficult to write optimized code — important for 3D applications and games. What’s fast on one device might be slow on another. Programmers end up getting bogged down with pre-processor instructions, and productivity declines.
There are two other analogues to the iPhone vs. Android debate: video game consoles vs. PCs for gaming, and the Java Platform vs. native code for desktop app development. We all know who the winners were. Closed platforms are a blessing for developers; I can’t explain the relief and security of knowing that if my program works on my iPhone, it’ll work on all of them.
MG, your images are epic. windows vs. os x developers are the perfect analogy. There is no shortage of amazing applications on OS X.
If this is really like the pc wars, we’ll have mobile phones virtualizing each other by the end of the next 2 year cycle … great
In other news the iphone might still not be able to establish a simple serial connection with another bluetooth device by the end of said 2 year cycle
MG,
As I blogged in a post comparing the openness versus proprietary approaches of Google vs. Apple:
While device makers can do pretty much “anything” with an open platform, in order to deliver a superior user experience, Google will either have to take on the burden of supporting “anything” or set limits on what will work on any particular instantiation of the platform.
Of course, setting limits makes Android less open, reducing leverage across the entire ecosystem. It’s a problem for all open source platforms, and as an old embedded systems guy, I can tell you that all the issues are only magnified with mobile devices.
Why? Because performance, reliability and user experience really matter with mobile devices, making integration key, which is a conundrum for the open source approach.
The reality is that openness is just an attribute -– it’s not an outcome, and customers buy outcomes. They want the entire solution and they want it to work predictability. Only a tiny minority actually cares about how or why it works.
It’s little wonder, then, that the two device families that have won the hearts, minds and pocketbooks of consumers, developers and service providers alike (i.e., BlackBerry and iPhone) are the most deeply integrated from a hardware, software and service layer perspective.
Here’s a link to the full post:
Android vs. iPhone: Why Openness May Not Be Best (http://bit.ly/jih2x)
Check it out if interested.
Cheers,
Mark
@Mark Sigai
“While device makers can do pretty much “anything” with an open platform, in order to deliver a superior user experience, Google will either have to take on the burden of supporting “anything” or set limits on what will work on any particular instantiation of the platform.”
That’s what we would call minimum requirements. Usually found on a box of software so that you know your PC or MAC can run it. Not sure how this is any different.
If it doesn’t have a camera… you won’t be able to use that portion of the API.
Simple checks on the developer’s part into the capabilities of the device already exists.
I don’t understand why this is such a big deal… you just need a good Developer who’s not lazy and writes good code to check the capabilities of the device (based on the API methods exposed from Google Android) and then move forward.
@Joe, to be clear, I am not saying that it is a big deal, anymore than I agree that the so-called openness of Android is a big deal (save for accelerating the demise of the Symbians of the world).
That said, I think that the distinction between PCs/Macs and mobile devices is that users expect (post iPhone) a highest common divisor experience versus an LCD one (as was case with PC revolution, where LCD and minimum requirements go hand in hand), and that that necessarily drives tighter integration across hardware, software and service layers (plus dev tools).
In other words, for Android to remain open is somewhat at odds with choosing to deeply support specific game-changing device form factors and service providers.
As they say, you can abstract anything out except for performance.
Once you focus on differentiating on performance, you are sacrificing openness.
In the long run, maybe it doesn’t matter (everything over time trends toward commoditization in tech, or has so far), but in the short run, Apple keeps evolving and raising the bar, which relegates Android to the low price leader.
Plenty of innings to be played in this particular ballgame, to be sure.
Cheers,
Mark
I can agree that there will be some sacrifice made for performance to expand to multiple device types.
Not sure how noticeable it will be though. It’s kind of like how Cisco works. If you get a consultation they will suggest (demand) you use all of their hardware for an implementation otherwise they can’t guarantee performance.
This in general, is true, for just about everything. So yeah, closing it up might provide you better performance, but at a higher cost to the end user/company (in Cisco’s case).
Open source continues to thrive, and it will be interesting to see it play out.
Thanks, Joe. Appreciate the perspective, as I am not a zealot on either side of the equation.
Open source neither heals all wounds nor is being proprietary something that can be maintained into perpetuity nor necessarily equates to better products.
I do think your Cisco analog is a good one, inasmuch as they have found balance between proprietary and open (in part by being so customer focused), and I am hoping that we can improve upon the LCD centered personal computing experience.
In the matter of Google v. Apple, they are what I call the Chess Masters, as they are simultaneously without peers, and executing radically different strategies/business, all the while pursuing overlapping segments.
Check out my post:
The Chess Masters: Apple versus Google
http://bit.ly/IHPmW
For more fodder on that topic.
Cheers,
Mark
It is prudent for Google to fix the compatibility and any outstanding API issues especially that there is still currently one released phone that serve as standard reference implementation and testbed. It is now or never since it will be a gargantuan task and problematic to fix those issues later. It seems that Google is using G1 phone to study, build experience and understand the mobile industry before going full force into it. Android’s success lies on how well application run consistently on the first batch of new Android phones, so as to mitigate the impression of the fragmentation issues that plague mobile platforms today.
mgsiegler get your head off your … apple. if backwards compatibility, or compatibility in general was such a huge problem then MS windows would be the greatest failure ever. it’s not. it’s 19 times more popular than macs
there are differences to the iphone and ipod touch os’s so its not quite as straight forward as you make it sound.
I think this is going to be an issue with all app stores.
I agree that there will be added complexity, but from my perspective (as a developer). I’m willing to spend the extra time to perhaps develop different versions to support the different capabilities of one device vs. the next.
In the end, the availability of the android platform will surpass that of Apple’s. Why? Because they will run on more devices.
Honestly, backwards compatibility is something that has and probably always will exist in some fashion. It’s one of the facts of life with Hardware and Software involvment.
MG – too early to tell, and I doubt this will cause much of a comotion among users or developers. It’s quite common.
Look at Facebook or Myspace or any other API Platform. They all deprecate functionality to bring in new functionality.
MG
if iPhone comes out with a new phone that has a magentometer inside of it, I’m sure there will be new API’s.
So how is that backwards compatible?
Open source platform for a phone:
Pros:
It’s pure and wonderful and full of rainbows and unicorns.
Cons:
It’s a crapshoot whether your apps will actually work.
Call me crazy, but it’s almost as if Apple keeps a closed platform and hardware to improve the user experience and not because Steve Jobs is the devil and hates developers….
magnetometer*
Dear MG Siegler,
You did a good clarification about the very important Backward Compatibility, about the G1 and G2 in Android. But at the contrary in the ‘80 and early ‘90, the Mobile Operators are the key players in the expansion of both: iPhone OS and Android. Apple is dealing with one Mobile Operator by Country, as Android did. In these case, iPhone has the advantage, but Android has several “flavors” by operator and iPhone has only 2 flavors. May be the battle is tight, ergo it not seems like a PC vs Mac.
The last WSJ rumor said that Apple is working in some taylor made solution for Verizone now. Sounds like a conquer “operator by operator”…and of course with the old ones really happy. iPhone is [near] the Cellular Market, as the iPod is a Music’s Players.
But Android has other goals: Conquer by default other electronic places: Netpc and the small electronic devices.
At least Google is more receptive to developers than Apple, and doesn’t impose arbitrary restrictions. Al this recession talk is overblown http://iamned.com/blog/ stock market will keep surging
This is not a story, this is how software has always worked and will for the foreseeable future. APIs change, new functionality is added and sometimes poor design decisions are fixed.
Siegler I really don’t think you have any idea what you are talking about, sorry to be blunt. Open or closed system, single hardware or multiple hardware is irrelevant to the fact that APIs can and will change, resulting in compatibility problems.
This is a smart move by Google to fix and improve the existing API. From the developers perspective versioning shouldn’t be a big drama, just a little extra testing across versions.
this is the same as making your site xhtml/css compatible and then fine tuning extras to get 4 different browsers to access your site properly.
whats the big deal about this, i dont get.
Totally agree with @craigbbaker… this is blown way out of proportion. Additionally, it’s not confusing… it’s called version targeting.
Android does not even have JIT compiler, it is a pure (optimized of course) Java interpreter. Thats’ sucks.
twitter must die.
I meant: twitter must be destroyed.
I am going to explain you that I really thought google would do better with this. Modularity is very important and has been for some time now. And you would think that they would have built their framework to withstand upgrade/updating.