5 ms·

It's actually a bit harder to create an Android app of comparable quality, isn't it? Apple gives you a boatload of really thoughtful, usable UI classes. What I

It's actually a bit harder to create an Android app of comparable quality, isn't it? Apple gives you a boatload of really thoughtful, usable UI classes. What I've read is that Android's SDK UI code isn't nearly as substantial or mature. Can you confirm if this is the case? edit: Then there's Core Data for object modeling and persistence, which is a huge time saver. Is there an Android analog of this with comparable power?

gte910h 16y ago
Mobile developer here: Most definitely android is costlier to produce feature for feature than iOS.
- jlmendezbonini 16y ago
  Can you elaborate? You develop for which platforms (iOS, Android, Symbian, etc)? What type of software (games, utilities, etc)? Thanks
  - gte910h 16y ago
    iOS, android, typically media centric applications, never games.
  - jrockway 16y ago
    Android is costlier because designers don't like Google's widgets, so every Android app (that involves a "designer") makes their own instead. This results in shitty apps that are costly to develop. Fortunately, most of the apps that people actually use don't do this, so it's not really a big deal for users.
    - gte910h 16y ago
      Android is costlier to produce because: The API's have more gotchas and simple bugs than the Apple ones. The 1.6 API in particular has some hairy bugs. The debug cycle takes considerably longer (almost 3x as long as the iPhone debug cycle for a non-media app). The debugger doesn't work as well. The lack of a GUI UI layout tool (there are some, they don't work well yet). The project setup is considerably more time intensive (barring signing issues, which experienced iPhone shops don't have issues with really). Now it's not all against android: The lax approval criteria and ease of market publications are awesome. I'm just saying it costs MORE to do android, I'm not saying don't do it. And yes, you're right, custom widgets are harder in android than in iOS. If it makes you feel better, I find the amount people change iOS custom widgets silly too.
Skroob 16y ago
I can't speak to Android SDK's maturity, but I can say that the foundation of the iOS SDK has been around a long time. All our Foundation classes are still prefixed with NS. Almost all of the most basic stuff, and even a lot of higher level stuff as well, has come over from MacOS X and NextStep before that.
- danilocampos 16y ago
  Yeah, OS X is an enormous, and often underestimated asset of Apple's. Put them on great footing from the very iPhone SDK. On the NS prefix: Lots of fun to switch between iOS and OS X dev. Wrote my first OS X app a couple months ago and it was weird to stop using the UI prefix for all the view classes. My big wish for the next major iOS SDK is to get bindings. Those are awesome on the desktop.
  - Skroob 16y ago
    Yeah I took on a short Mac project a number of months back and got really messed up with the switch. The ubiquity of Core Animation on the iOS was what spoiled me I think. Don't hold your breath for bindings on iOS though. I'd rather have garbage collection anyway.
    - sudont 16y ago
      I'm sure garbage collection's on the way with the increases in processor and memory in iOS devices. Lack of GC seems to be an artificial constraint designed to force dev's to take charge of a situation with very limited memory. Unless there was some major overhaul to the Foundation classes. Am I way off?
      - nimms 16y ago
        I'd think it also has to do with battery life. Especially with long running apps.
  - jsolson 16y ago
    > My big wish for the next major iOS SDK is to get bindings. I wouldn't expect this. Honestly I'd expect things to go the other way: 10.7 maybe deprecating bindings on the Desktop for things like table and outline views. Particularly since they added NSTableViewDataSource/Delegate and NSOutlineViewDataSource/Delgate in 10.6.
yish 16y ago
The other challenge is developing for all the variants on Android (OS version, different manufacture idiosyncrasies, hardware speeds, screen resolutions, orientation, virtual vs hardware keyboard) all increase the development time and especially the QA time on Android.
guelo 16y ago
I can't really say whether Android is harder, but I think Apple's tight design guidelines make the design easier if you're using the default built-in controls.

gte910h 16y ago

Mobile developer here: Most definitely android is costlier to produce feature for feature than iOS.

jlmendezbonini 16y ago
Can you elaborate? You develop for which platforms (iOS, Android, Symbian, etc)? What type of software (games, utilities, etc)? Thanks
- gte910h 16y ago
  iOS, android, typically media centric applications, never games.
- jrockway 16y ago
  Android is costlier because designers don't like Google's widgets, so every Android app (that involves a "designer") makes their own instead. This results in shitty apps that are costly to develop. Fortunately, most of the apps that people actually use don't do this, so it's not really a big deal for users.
  - gte910h 16y ago
    Android is costlier to produce because: The API's have more gotchas and simple bugs than the Apple ones. The 1.6 API in particular has some hairy bugs. The debug cycle takes considerably longer (almost 3x as long as the iPhone debug cycle for a non-media app). The debugger doesn't work as well. The lack of a GUI UI layout tool (there are some, they don't work well yet). The project setup is considerably more time intensive (barring signing issues, which experienced iPhone shops don't have issues with really). Now it's not all against android: The lax approval criteria and ease of market publications are awesome. I'm just saying it costs MORE to do android, I'm not saying don't do it. And yes, you're right, custom widgets are harder in android than in iOS. If it makes you feel better, I find the amount people change iOS custom widgets silly too.

Skroob 16y ago

I can't speak to Android SDK's maturity, but I can say that the foundation of the iOS SDK has been around a long time. All our Foundation classes are still prefixed with NS. Almost all of the most basic stuff, and even a lot of higher level stuff as well, has come over from MacOS X and NextStep before that.

danilocampos 16y ago
Yeah, OS X is an enormous, and often underestimated asset of Apple's. Put them on great footing from the very iPhone SDK. On the NS prefix: Lots of fun to switch between iOS and OS X dev. Wrote my first OS X app a couple months ago and it was weird to stop using the UI prefix for all the view classes. My big wish for the next major iOS SDK is to get bindings. Those are awesome on the desktop.
- Skroob 16y ago
  Yeah I took on a short Mac project a number of months back and got really messed up with the switch. The ubiquity of Core Animation on the iOS was what spoiled me I think. Don't hold your breath for bindings on iOS though. I'd rather have garbage collection anyway.
  - sudont 16y ago
    I'm sure garbage collection's on the way with the increases in processor and memory in iOS devices. Lack of GC seems to be an artificial constraint designed to force dev's to take charge of a situation with very limited memory. Unless there was some major overhaul to the Foundation classes. Am I way off?
    - nimms 16y ago
      I'd think it also has to do with battery life. Especially with long running apps.
- jsolson 16y ago
  > My big wish for the next major iOS SDK is to get bindings. I wouldn't expect this. Honestly I'd expect things to go the other way: 10.7 maybe deprecating bindings on the Desktop for things like table and outline views. Particularly since they added NSTableViewDataSource/Delegate and NSOutlineViewDataSource/Delgate in 10.6.

yish 16y ago

The other challenge is developing for all the variants on Android (OS version, different manufacture idiosyncrasies, hardware speeds, screen resolutions, orientation, virtual vs hardware keyboard) all increase the development time and especially the QA time on Android.

guelo 16y ago

I can't really say whether Android is harder, but I think Apple's tight design guidelines make the design easier if you're using the default built-in controls.