Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't know how true this is, but I upvoted because I'd be interested in hearing what other people who have worked with both systems think of the issue. I'm a little surprised that they say fragmentation is so bad that they need 2-3x the resources for Android. I wonder if that's only the case because they seemed to be using a lot of more advanced features on their Android app?


I've been switching back and forth between Android and iPhone development for 4 years now, and I'd say development time is roughly equal between the platforms. A developer that understands Android well should instinctively know how handle different device sizes and fragmentation. The platform is equipped to handle these things well, and the only complaints I ever hear are from iOS developers that simple aren't used to and aren't willing to understand the platform.


One other challenge related to different device sizes is that designers cannot create a pixel-perfect design in Photoshop and send it off to the developer. They have to be aware of how the interface components will resize and shift around as the aspect ratio, resolution, and screen size changes.


Designing for responsive layouts should be second nature for designers dealing with Android. The same issues appear on web in much more dramatic fashion.


It should be, but many of those designers are coming from iOS backgrounds.


You would assume that web desginers and graphic designers in general have been around much longer than iOS though. This is not a "new" problem which haven't already been solved.

Being too iOS-centric in this space will severely limit your capabilities as a developer and designer.


In my consultancy I have dealt with the usual case many times: Android second. IF you build the same app for both platforms, the difference in level of effort can be almost entirely attributed to the relative familiarity of the developers with each platform.

That misses the point. You can usually do more in Android, and, while I'm a firm believer in shipping an MVP (or even an interim port based on a Web wrapped), if you don't implement a few key features on Android, like Fragment based UI scaling for different device geometries, the Share operation, and standard Intent-based high-level IPC if applicable, you have a pretty lame Android app.

Different expectations regarding some conventionally standard features, plus Java, plus Eclipse, plus grokking the Android component life-cycle, plus design for a continuum of screen geometries, means Android is usually more demanding of development resources.


> the Share operation

I'm extremely new to Android development. Does this have a special contextual meaning? What is the Share operation?


Here is a good tutorial: http://developer.android.com/training/sharing/shareaction.ht...

It can mean very different things to different apps. In all cases it means "I can do something with that data."


Thanks!


I've been building mobile apps for about 2-3 years. The company I consult for builds iOS first... not because of any design/coding difficulty though. Not to beat this very dead horse anymore but iOS users pay more frequently... so we go iOS first to determine if it's even worth it to build for Android.


> I'm a little surprised that they say fragmentation is so bad that they need 2-3x the resources for Android.

It's highly dependent on what you're doing. For instance, if you're using OpenGL ES, you'll likely have a lot of testing overhead. Ditto if you're doing anything interesting with the camera API (OEMs like breaking this). If you avoid OpenGL ES, the camera, any of the new UI stuff, and the network, then testing becomes less scary.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: