Eric Schmidt predicts developers will prioritize Android over iOS in 6 months

[badb0y]

Not really, I have a great choice of devices on Android. Screen size, what material its constructed from, screen res, etc.

I also have a massive amount of paid and free apps to choose from.

Yes I know, I own the One X.

 

[WelshBloke]

Yes I know, I own the One X.

So why should anyone be annoyed by the perceived iOS advantage compared to the tangible Android ones?

 

[badb0y]

So why should anyone be annoyed by the perceived iOS advantage compared to the tangible Android ones?

I don't think either one has a conplete advantage over the other I just find it funny when others do and then try so hard to convince others.

 

[Nothinman]

I don't think either one has a conplete advantage over the other I just find it funny when others do and then try so hard to convince others.

Both have significant advantages which are also disadvantages. How you view them depends on your perspective. I will never own an iOS device because of the draconian restrictions placed upon their usage by Apple. Even with jailreaking you still don't have as much control over the device as you do with Android. And you're stuck with the one form factor that Apple deems appropriate for you. If you're happy with the one true size, software, functionality, etc that Apple provides then you'll see that as an obvious advantage.

With Android you have choice in hardware, software, manufacturer, etc. The manufacturers have the freedom to create cheap, little phones that are barely better than a feature phone or to create a high end phone with specs that could double as a PC. With that comes some responsibility to make sure you're buying the right one for what you want from it. If you want to root your phone and install custom ROMs then you need to make sure you avoid manufacturers that make it a real pain, if not impossible, to do that like Motorola.

 

[DaveSimmons]

Choice does mean fragmentation.

If I want to write an iOS app I have a couple of screen resolutions and a few different pieces of hardware. The only other choice is what iOS level, but almost everyone that can, does upgrade.

If I want to develop for android I need to worry about making a touch interface work well at dozens of resolutions and pixel densities. Yes, you can come up with scaling schemes that will mostly work, but you have to worry about fonts scaling too large or too small, scaled areas being too small to be easy to tap or blowing up too far and looking ugly.

Edit: in Windows most programs can ignore much of that because you're using a mouse pointer and buttons to control the UI rather than a fingertip. With Metro development for tablets it will become more of a problem.

If you're doing anything in 3D or CPU-intensive, you have to worry about a wide variation in the device hardware's speed and 3D power.

Unless you want to pass on a huge market, you do also have to deal with both the Google and Amazon markets.

Choice is good, but it's sticking your head in the sand to pretend that this doesn't make life harder for Android developers, or potentially hurt app sales.

 

[Nothinman]

Choice does mean fragmentation.

If I want to write an iOS app I have a couple of screen resolutions and a few different pieces of hardware. The only other choice is what iOS level, but almost everyone that can, does upgrade.

If I want to develop for android I need to worry about making a touch interface work well at dozens of resolutions and pixel densities. Yes, you can come up with scaling schemes that will mostly work, but you have to worry about fonts scaling too large or too small, scaled areas being too small to be easy to tap or blowing up too far and looking ugly.

Edit: in Windows most programs can ignore much of that because you're using a mouse pointer and buttons to control the UI rather than a fingertip. With Metro development for tablets it will become more of a problem.

If you're doing anything in 3D or CPU-intensive, you have to worry about a wide variation in the device hardware's speed and 3D power.

Unless you want to pass on a huge market, you do also have to deal with both the Google and Amazon markets.

Choice is good, but it's sticking your head in the sand to pretend that this doesn't make life harder for Android developers, or potentially hurt app sales.

The fact that you have more than 1 screen resolution and multiple pieces of hardware to content with in the Apple world also technically means that it's fragmented too. It's less fragmented because there's less options, but it's still fragmented. You still have at least 3 different top level devices with different screen sizes and capabilities and varying versions of iOS with some fairly major functionality missing from older releases. And if the rumors about the next iPhone being 4" turn out to be true, Apple just added a little more fragmentation to their ecosystem.

And then there's the fact that you have to buy a Mac and learn Objective C to make iOS apps. Objective C is pretty much useless outside of iOS apps now. Android apps can be built with any hardware on Linux, OS X or Windows and
while Android doesn't use a traditional JVM it's still mostly Java which is a language that most developers have some experience with already and learning it won't be limited to just Android.

Neither situation is perfect, but I'll take choice and freedome over the alternatives any day.

 

[Eug]

Choice and freedom is nice, but so is the almighty dollar. It's nice to have both, but it seems that's not quite the case for mobile apps in 2012.

 

[DaveSimmons]

Sure if you want to be nit-picky dealing with 3-4 resolutions and 2-3 levels of hardware means iOS is also "fragmented", but that's nothing compared to the fragmentation in the Android world.

That means you work harder, and reach a smaller market for that work unless you are happy with writing something for the majority 2.x platform or creating multiple versions for 2.x / 3.x / 4.x

I'm not saying iOS is better somehow, just currently easier and more profitable so claims of Android app sales and development outpacing iOS' soon are wild dreams.

 

[Nothinman]

Sure if you want to be nit-picky dealing with 3-4 resolutions and 2-3 levels of hardware means iOS is also "fragmented", but that's nothing compared to the fragmentation in the Android world.

That means you work harder, and reach a smaller market for that work unless you are happy with writing something for the majority 2.x platform or creating multiple versions for 2.x / 3.x / 4.x

I'm not saying iOS is better somehow, just currently easier and more profitable so claims of Android app sales and development outpacing iOS' soon are wild dreams.

You don't need to create multiple versions for Android 2.x, 3.x and 4.x because they all run the same apps just fine, just like the different iOS releases. Whenever I went from my old Droid Incredible running Gingerbread to my Galaxy Nexus with ICS everything worked without any effort from me. I just signed into my Google account and all of my old apps reinstalled OTA.

 

[Zaap]

Doesn't Schmidt make a lot of goofy pronouncements?

 

[shortylickens]

Doesn't Schmidt make a lot of goofy pronouncements?

Goofy pronouncements generate a LOT more traffic than safe predictions.

 

[DaveSimmons]

You don't need to create multiple versions for Android 2.x, 3.x and 4.x because they all run the same apps just fine, just like the different iOS releases. Whenever I went from my old Droid Incredible running Gingerbread to my Galaxy Nexus with ICS everything worked without any effort from me. I just signed into my Google account and all of my old apps reinstalled OTA.

Yes, old 2.x apps keep working, but you can't use 3.x - 4.x features in new apps unless you want to create multiple versions or give up the huge 2.x installed base.

With iOS, you can expect that almost all devices except the oldest hardware will be running the latest iOS, so it's safe to use its features.

In other words, you can target up-to-date iOS and gain the majority of the market, while with Android you have to stick with 2.x or lose that majority. ICS might as well not exist unless you plan to write 2 versions of your app.

 

[Nothinman]

Yes, old 2.x apps keep working, but you can't use 3.x - 4.x features in new apps unless you want to create multiple versions or give up the huge 2.x installed base.

With iOS, you can expect that almost all devices except the oldest hardware will be running the latest iOS, so it's safe to use its features.

In other words, you can target up-to-date iOS and gain the majority of the market, while with Android you have to stick with 2.x or lose that majority. ICS might as well not exist unless you plan to write 2 versions of your app.

No, you don't need multiple releases, you just need to check at runtime and enable/disable the new features as appropriate.

http://developer.android.com/training/basics/supporting-devices/platforms.html

 

[2timer]

The NY Times has a pretty good article on iOS and Android developers:
http://mobile.nytimes.com/2012/06/11/technology/apple-keeps-loyalty-of-mobile-app-developers.xml

Reading this you'd think iPhone devs are pretty happy. But there's also been sporadic reports they want to form a union.

 

[Steelbom]

Android is heavily fragmented.

On the hardware side you've got a couple of hundred Android smartphones and slates, with different resolutions, aspect ratios, CPUs, GPUs, and varying amounts of RAM, so it's more effort for a developer to create an app for Android -- particularly if said app is a game.

And on the software side you've got half a dozen different versions of Android running on those smartphones with a substantial user base, which further complicates everything.

Contrast that to iOS which has five different models of iPhone all which use 480x320 points of screen real estate, four different models of iPod touch which also use 480x320 points of screen real estate, and three different models of iPad which use 1024x768 points of screen real estate. That's only two different resolutions you need to target. (The "retina" devices only need higher resolution assets.)

One important thing that misses is Android provides the tools necessary to make resolution independent apps while iOS does not. Heck Apple is stuck using a odd aspect ratio on the iPhone because any changes to it would destroy backwards compatibility while Android manufactures are free to make advancements to their products without being restricted by hardware choices made back in 2007.

That's not true, you can make resolution independent apps on iOS.

 

[runawayprisoner]

The NY Times has a pretty good article on iOS and Android developers:
http://mobile.nytimes.com/2012/06/11/technology/apple-keeps-loyalty-of-mobile-app-developers.xml

Reading this you'd think iPhone devs are pretty happy. But there's also been sporadic reports they want to form a union.

iPhone devs are happier working with iPhones than with Android in general.

Like I mentioned, it is MUCH easier developing for iPhone than for Android, even if Android only has one handset for developers to worry about. Google has made no effort in making the Android SDK easier for developers to mess around with.

And a union is a stupid idea IMO. If someone wants to quit iOS app development, they can just do it. The rest of us will see that as an opportunity for our new apps to rise and shine in the App Store. It just means more revenue for us while the other guys sit idly by for an "ideal" of some sort. It doesn't really work that way, y' know. Everybody has gotta make a living somehow, and to some people, iOS app developing is no small chunk of their earning.

 

[Puddle Jumper]

Objective-C is a horrible language indeed, but it's not that hard to learn unless you never had any coding experience to begin with.

Xcode is slow and unintuitive? That's the first I have heard of that. Unless the machine it runs on is slow to begin with (due to design, some older Macs overheat and throttle their processors down to almost 40% their original clocks), I don't think I can ever say that it's slow.

Whether it's unintuitive is also debatable. It works well for its intended purposes, and Apple has introduced some welcome improvements in recent updates. I know I like it far better than other IDEs... like Eclipse.

But it's not Xcode that's the star. It's the iOS API stack. The API stack of iOS tremendously reduces the effort needed to write iOS softwares. I'd LOVE to talk to those guys who have developed on both platforms that you mentioned, because I have NEVER met a single person in the Bay area that likes working with Android.

Ironically, that also includes some Google employees. If even Google employees find developing for Android harder than writing codes for iOS, what does that tell ya?

I've got quite a bit of coding experience and Objective-C is one of the worst languages I have worked with, the only one that really comes to mind as being worse is Lisp.

I was running Xcode on one of the last gen Core 2 Duo MBP 13s and the performance on a decent sized project was simply terrible, I've seen Visual Studio handle larger projects on slower hardware without any issues. Personally I thought it was simply much worse than Visual Studio or even Eclipse in general.

 

[runawayprisoner]

I've got quite a bit of coding experience and Objective-C is one of the worst languages I have worked with, the only one that really comes to mind as being worse is Lisp.

I was running Xcode on one of the last gen Core 2 Duo MBP 13s and the performance on a decent sized project was simply terrible, I've seen Visual Studio handle larger projects on slower hardware without any issues. Personally I thought it was simply much worse than Visual Studio or even Eclipse in general.

I don't know how you define a decent-sized project, but I feel inclined to note that most iOS apps don't require more than 4 source code files, and the rest are just interface assets that don't really get referenced as aggressively as codes (they're not referenced at all if interface builder is not used), so they shouldn't hamper performance at all.

Any decent iOS developer to my standard should be able to get most stuffs up and working in as few files and codes as possible, because the API allows that. If they end up having to make it long, then they should be able to organize their codes so that the whole project doesn't get bogged down. As an aside, I have yet to see Xcode slow down even on a Core 2 Duo 2008 iMac with a meager 2GB RAM... and I have tested something as intensive as Unreal Engine 3 on that. I can't imagine how "decent-sized" your project must be for it to be slow on a similar (superior in tech specs) MBP.

But all of that aside, the real shine was the fact that with Xcode 4, all I have to do to test my app directly on a phone device is plug the phone in, enable it for development (click one button), and run the code (click one button). 3 steps, and my app is up and running on the actual device with output and diagnostic tools available on my computer. Doesn't get any simpler than that.

I have experience working with Java/C++/Obj-C/ActionScript (for Flash and Blackberry Playbook) and while I agree that Obj-C is the worst out of all of those to digest, it's not bad once you get used to the syntax and realize that it's just trying to add on to C.

The easiest of the bunch? ActionScript. It doesn't force you to deal with pointers, and you don't have to initialize a bunch of things to get graphics up and working.

 

[Deeko]

I've got quite a bit of coding experience and Objective-C is one of the worst languages I have worked with, the only one that really comes to mind as being worse is Lisp.

I was running Xcode on one of the last gen Core 2 Duo MBP 13s and the performance on a decent sized project was simply terrible, I've seen Visual Studio handle larger projects on slower hardware without any issues. Personally I thought it was simply much worse than Visual Studio or even Eclipse in general.

Agreed. Obj-C is mind bogglingly obtuse. Its like they said "hmm, lets take a programming language that follows most of the normal conventions, but with totally different syntax. Trust us!! This way is better."

Its so bad that I'm still debating porting my apps to iOS using PhoneGap and HTML5 as opposed to Obj-C....and I consider HTML5 to be pretty terrible too.

 

[runawayprisoner]

Agreed. Obj-C is mind bogglingly obtuse. Its like they said "hmm, lets take a programming language that follows most of the normal conventions, but with totally different syntax. Trust us!! This way is better."

Its so bad that I'm still debating porting my apps to iOS using PhoneGap and HTML5 as opposed to Obj-C....and I consider HTML5 to be pretty terrible too.

If you know ActionScript (I'd assume that to be the case since you seem to have some Playbook dev experience), then you can also use either Flash or Flash Builder to port your app to iOS. The performance is far from being okay with what you can do with Obj-C, but it's decent for small-scale projects, and much better than PhoneGap or whatever else.

I'd still advise that you try to digest Obj-C (and it's not that complicated, by the way) anyhow, because it gives you access to much better APIs and tools.

 

[Deeko]

If you know ActionScript (I'd assume that to be the case since you seem to have some Playbook dev experience), then you can also use either Flash or Flash Builder to port your app to iOS. The performance is far from being okay with what you can do with Obj-C, but it's decent for small-scale projects, and much better than PhoneGap or whatever else.

I'd still advise that you try to digest Obj-C (and it's not that complicated, by the way) anyhow, because it gives you access to much better APIs and tools.

Yea, I'm familiar with ActionScript but I don't like it much either It follows normal syntax conventions, but it does some...irritating....things that had me banging my head against the wall when writing PlayBook apps. Plus I have no desire to purchase Flash Builder.

Its not that Obj-C is complicated. Like I said, it does, for the most part, act the way a normal language acts. Its just mind boggling that they chose to change the syntax that every other language uses for no real reason. I write C# code all day, I don't really want to completely shift gears like that for app work. Hence why I write a lot of Windows Phone apps....if Mono weren't so expensive, that would be a perfect solution for me.

 

[Puddle Jumper]

I don't know how you define a decent-sized project, but I feel inclined to note that most iOS apps don't require more than 4 source code files, and the rest are just interface assets that don't really get referenced as aggressively as codes, so they shouldn't hamper performance at all.

Any decent iOS developer to my standard should be able to get even 3D stuffs up and working in as few files and codes as possible, because the API allows that. If they end up having to make it long, then they should be able to organize their codes so that the whole project doesn't get bogged down. As an aside, I have yet to see Xcode slow down even on a Core 2 Duo 2008 iMac with a meager 2GB RAM... and I have tested something as intensive as Unreal Engine 3 on that.

But the real shine was the fact that with Xcode 4, all I have to do to test my app directly on a phone device is plug the phone in, enable it for development (click one button), and run the code (click one button). 3 steps, and my app is up and running on the actual device with diagnostic tools available on my computer. Doesn't get any simpler than that.

I have experience working with Java/C++/Obj-C/ActionScript (for Flash and Blackberry Playbook) and while I agree that Obj-C is the worst out of all of those to digest, it's not bad once you get used to the syntax and realize that it's just trying to add on to C.

I'm sure performance is much better for simple apps where you can make extensive use of the built in API's but when you start working with larger, more complicated projects performance basically nosedives. The project I was working on was an enterprise application where we needed a lot of functionality not offered by the iOS API's so we were forced either use several third party libraries or spend a considerable amount of time and manpower building the functionality from scratch.

 

[oznerol]

I don't know how you define a decent-sized project, but I feel inclined to note that most iOS apps don't require more than 4 source code files, and the rest are just interface assets that don't really get referenced as aggressively as codes (they're not referenced at all if interface builder is not used), so they shouldn't hamper performance at all.

Any decent iOS developer to my standard should be able to get most stuffs up and working in as few files and codes as possible, because the API allows that. If they end up having to make it long, then they should be able to organize their codes so that the whole project doesn't get bogged down. As an aside, I have yet to see Xcode slow down even on a Core 2 Duo 2008 iMac with a meager 2GB RAM... and I have tested something as intensive as Unreal Engine 3 on that. I can't imagine how "decent-sized" your project must be for it to be slow on a similar (superior in tech specs) MBP.

But all of that aside, the real shine was the fact that with Xcode 4, all I have to do to test my app directly on a phone device is plug the phone in, enable it for development (click one button), and run the code (click one button). 3 steps, and my app is up and running on the actual device with output and diagnostic tools available on my computer. Doesn't get any simpler than that.

4 source files? Are you making fart apps and soundboards?

IB and the iOS simulator (especially iPad) are what kill performance. When they integrated IB into XCode, it got a bit worse. I have a 2010 MBP that only had 2GB of RAM. It was a bit sluggish, but I'm more patient than most, so I managed.

Eventually I got fed up with having to wait for things like indexing to complete or a a storyboard to load, so I upped it to 8GB and now it doesn't flinch. I was actually surprised how much it helped. The 4.3.2 release also improved performance for me for some reason, though it might just be in my head.

I don't even understand what you're saying about organizing your code so it doesn't get bogged down...

 

[Puddle Jumper]

I don't even understand what you're saying about organizing your code so it doesn't get bogged down...

Yeah, even assuming it helped performance the last thing I want is someone throwing away all semblance of design and packing 5,000 lines of code into a single source file just to make Xcode run better.

I've spoken with several other people who also said that having 6gb or more of ram significantly improved performance for them.

 

[runawayprisoner]

Yea, I'm familiar with ActionScript but I don't like it much either It follows normal syntax conventions, but it does some...irritating....things that had me banging my head against the wall when writing PlayBook apps. Plus I have no desire to purchase Flash Builder.

Its not that Obj-C is complicated. Like I said, it does, for the most part, act the way a normal language acts. Its just mind boggling that they chose to change the syntax that every other language uses for no real reason. I write C# code all day, I don't really want to completely shift gears like that for app work. Hence why I write a lot of Windows Phone apps....if Mono weren't so expensive, that would be a perfect solution for me.

I didn't think ActionScript could be that irritating to use, but it might just be me.

I'm sure performance is much better for simple apps where you can make extensive use of the built in API's but when you start working with larger, more complicated projects performance basically nosedives. The project I was working on was an enterprise application where we needed a lot of functionality not offered by the iOS API's so we were forced either use several third party libraries or spend a considerable amount of time and manpower building the functionality from scratch.

That's probably why. But I don't think you can say that the majority of apps out there for iOS need third-party libraries or in-house libraries made from scratch.

As an aside, I'd also advise against Interface Builder.

4 source files? Are you making fart apps and soundboards?

IB and the iOS simulator (especially iPad) are what kill performance. When they integrated IB into XCode, it got a bit worse. I have a 2010 MBP that only had 2GB of RAM. It was a bit sluggish, but I'm more patient than most, so I managed.

Eventually I got fed up with having to wait for things like indexing to complete or a a storyboard to load, so I upped it to 8GB and now it doesn't flinch. I was actually surprised how much it helped. The 4.3.2 release also improved performance for me for some reason, though it might just be in my head.

I don't even understand what you're saying about organizing your code so it doesn't get bogged down...

No, sir. It's not fart apps, but as I said, aside from the delegate, I'd think you should only need ONE more class to make most apps, and most often, it's a view controller.

And I don't rely on Interface Builder. I avoid it completely unless the job specifically requires it. That probably explains why I haven't had problems with performance.