Android doesn’t drive early adoption, so it would make sense to leave it out while you let iOS “take the cake” so to speak, for a while at least. Android, being the dominant platform with a huge mass of people in the early-to-late majority part of the bell curve, makes sense for when you want to scale.
From personal experience and from hearing 1st person stories of startups who went Android second, it takes at least 2x to even 3x the amount of time to build an Android app.
This is why when a very talented Android engineer like Sarah Haider (Twitter's Android lead) goes from Twitter to Secret, it is a big deal. There are many strong, capable iOS technical leads out there and probably a fraction thereof in Droidlandia (using Pareto's famous rule, probably 4 - 5 good iOS technical leads for every 1 good Android technical lead).
To make an app on Android look good, the responsibility lies much more on the developer than the designer. The designer on iOS can easily use IB. Not so much Android Studio or Eclipse.
At the highest levels (slightly below Jake Wharton), talented Android developers who care about the user experience and can deliver compelling, beautiful apps can name their own price.
Eclipse is also HORRIBLE. Horrible, horrible horrible. Objective-C isn't exactly easy to understand, but Xcode is. I could functionally make things work in Xcode in 2 days having no experience with C or Objective C, I've probably spent 6 weeks in Eclipse in my life and I still couldn't really tell you how to do things. I have to re-learn it every time I want to do something, especially with the UI.
I've heard that, and that's fine - I appreciate the suggestion and will probably use it, but if that's actually the best then people will take Android dev more seriously when the best is the standard IDE. Right now Eclipse is the default and it blows.
Eclipse is the default for most Java development, but I know fairly few serious Java developers who use it. Some do, I'm not saying they don't exist, but IntelliJ--of which Android Studio is a fork--is generally the go-to tool amongst the experienced, skilled Java folks I know. Double for Scala. (I used nothing but IDEA for Android work at my last job, for about eighteen months - Eclipse is certainly not required and doesn't really make it easier.)
Second this. Not to say I'm an experienced Java developer, but after trying both, I'm sticking with IntelliJ, which was introduced to me by a Google SSE who definitely favored it over Eclipse.
I was wondering how IDEA compared to Eclipse for android dev, in large part because I'm interested in porting my app to Kotlin, if it's not too huge a jump. It's good to hear that it works well, despite not being the "official" default.
Android Studio is completely replicated within IDEA itself, so there's that too. We used a Maven build that worked really well within IDEA--it correctly wired up the Android facet and everything.
I don't know anything about Kotlin on Android, though.
Although I cannot compare to Eclipse. I'm a .NET Dev with an interest in Android. In fact I'm falling out with MS and sticking to that for a day job, but want to do Java / Android in my spare time. I've just completed the Courera programming Android course and I did the whole thing in IDEA community edition. I had no problems what so ever getting answers to any questions. I was relatively comfortable and productive within about 20 hours. I had no previous Java experience (although I'm a clean C# coder for over 6 years)
I was impressed with the tools you get out the box. I've paid hundred (close to thousands) for similar tools in .NET.
Actually "Eclipse is the default" is probably going to be false very soon. Every mid to senior level Android developer I know has migrated to Android Studio for months already. The advantages of Gradle and Studio are very apparent almost immediately.
I do not like Eclipse - it is clunky and often requires restarts to pick up changes or clear itself of confusion - and have never used Android Studio, but AFAICT the latter is still not the recommended editor according to the Android documentation - https://developer.android.com/sdk/index.html says "If you're a new Android developer, we recommend you download the ADT Bundle to quickly start developing apps." The ADT bundle is Eclipse-based. On the Studio page it warns "Caution: ... you may encounter bugs" (though as I say, with Eclipse I'm also sure you'll encounter your fair share of bugs!)
> On the Studio page it warns "Caution: ... you may encounter bugs"
Android Studio only added Gradle, which provides Groovy for its scripting, recently. Groovy has a history of shipping standalone versions as soon as possible and letting users find the bugs, and only afterwards does Grails bundle the version. I'd say Gradle-bundled sits somewhere between standalone and Grails-bundled on the testing scale for Groovy versions.
It surely does. But why should I switch my build system? I'm a happy maven user. After all, only after AS came into picture I hear about the gradle non-sense. Gradle doesn't even use the proxy settings configured in AS (at least on Linux).
I suppose to each their own, but if anything except for the provisioning/plist stuff in Xcode is complicated to you, you must be used to something else because in and of itself xCode is phenomenal.
xCode (sic) is far from phenomenal. I have been writing iOS apps since 2008 and Mac apps longer than that and Xcode has made significant progress, but is still mediocre.
It's very telling that Jetbrains managed to pull AppCode out of nowhere and blitz Xcode. I had never before used an IntelliJ-based IDE, but within a week or two my productive increased severalfold. It really puts Apple's efforts to shame.
I'm a big IntelliJ fan and I can't roll with AppCode. I admire the work, but XCode feels a lot better for native code development. (I do work in C++ and only use Objective-C for tooling via Obj-C++, though.)
Congratulations on the most ridiculous comment on HN today. How many apps on the app store was that now, 1,000,000+ according to the admittedly non-authoritative Wikipedia. And all of them created with hex editors, you would have us believe. Not the completely unusable Xcode.
(b) people might suffer through substandard products because they're the only reasonable way of developing software for a platform (you see that sentiment a lot of times from people who claim to be forced to do development on Windows)
Just saying that a single person claiming that XCode is an unusable, horrible piece of shit probably says as much as 1 million apps being written for that platform. At least not about usability of the development environment.
I find Xcode pretty awful and instead use AppCode with Xcode open at the same time.
Xcode 5 finally makes it easy to run single unit tests. Before this, you had to create a schema to run a single test, which was several clicks and possibly some typing. Now it's click and run, which is lovely.
Eclipse (or Android Studio) is good for when you are getting your feet wet with Android. If you don't like using it there are alternatives.
I usually use Emacs or vi. The only thing I miss when not using Eclipse with the ADT plugin is after typing say "LinearLayout ll;" with Eclipse I can type Control-Shift-O and the LinearLayout class is automatically imported in the code. I miss this, but I kind of have this in Emacs with JDE - a Control-C-V-Z has similar behavior. I could probably do some more tool work on Emacs and make it even more automatic.
I do everything with emacs, vi, ant, astyle, adb, and the Android commands "android" and "monitor". Some people do Android in IntelliJ, some in Netbeans. Some use Sublime Text.
If you think Eclipse with ADT is bad for Android development now, you should have seen Eclipse/ADT at the end of 2009. Just getting the ADT plugin to work with Eclipse was a nightmare. Having seen the improvement since then, I guess it all seems less bad to me. Although I don't use Eclipse when I do Android programming, generally.
I'm doing CoreOS based development at the moment and it only comes with vi. I've come across many other minimal linux environments where vi is the only option.
It's worth learning, even if you only learn the basics.
> To make an app on Android look good, the responsibility lies much more on the developer than the designer.
I would add that the designer has to understand Fragment, understand that density, orientation, screen size and text size are different dimensions of screen geometry, and how to avoid a combinatorial explosion of layouts, or, conversely, layouts that only work at default font sizes on medium denisty screens.
Absolutely. In a lot of ways, Android UI design is like designing for the web, in that you're designing rules for layout more than you're designing specific layouts.
Although I'd argue that that's really what designers should be doing anyway, thinking procedurally and in terms of systems rather than fixed, one-off designs.
"From personal experience and from hearing 1st person stories of startups who went Android second, it takes at least 2x to even 3x the amount of time to build an Android app." This differs from my experience. I've work on several large app projects (> 200 000 downloads), and the Android versions have been ready before or at the same time as their iOS counterparts.
Also, the good apps are not made using IB. Fine for prototyping, sure, but not suitable for real world use. Feel free to prove me wrong, and name IB success stories.
Saying good apps are not made using IB, and that its not suitable for real use, sounds like FUD to me too :)
Sure you need to leave IB sometimes (or a lot of the time - depending on the app), but if you are coding every little view by hand... well you have more time on your hands (and budget?) than I do :P
I develop apps for both major mobile platforms, and when I speak with designers and artists about Android and iOS, they overwhelmingly prefer iOS. Since they use iOS devices themselves, it is their go to platform. It is almost always the one they want to work with.
Oddly, when I ask them why, the answers are mostly qualitative. It has nothing to do with "reaching the most people" or "getting exposure". It's a simple matter of taste. Designers tend to choose iOS products because they identify with them. They see Apple as an institution that they would enjoy being a part of in some way. Almost all the designers I know that are worth their salt use and love their macs for working in Photoshop and Illustrator, so it naturally follows that they prefer the iOS platform, regardless of numbers and market share.
Admittedly, my sample size is only around 50 or so, but this has been my experience.
Glad you said that. Apple prepositioned itself as a design oriented company something that designers associate with. Something being easy is highly subjective.
That's not really surprising, since a large portion of mobile developers probably became mobile developers specifically because of what Apple was doing in iOS.
No android phone nor interface is close to the level of what Apple is putting out - both from an experience and product standpoint. This is also the same exact same reason why I purchase all apple products.
I really don't understand the argument of "You're paying more for a lesser product when you buy Apple". Ok - so the hardware isn't as good/powerful, fine, but that's not why I'm buying an Apple product. I'm buying it because of the UX, because of the way the phone feels in my hand, because of the way the keys feel on the keyboard when I press them down, because of how great the applications look and feel when I use them.
If android came out with something that looked and felt great I would certainly consider using it. In fact, I purchased a Samsung Galaxy S3 several years ago when it first came out. The phone was absolute garbage - plastic bevels still had molding pieces around the edges, the unnecessary bloatware (which would have been fine if it was remotely useful) was very poorly designed, and overall the phone felt very light and cheap.
> Ok - so the hardware isn't as good/powerful, fine, but that's not why I'm buying an Apple product.
The funny thing is, that's kind of a myth, particularly in phone land. The A7 (the 5S's SoC) had pretty much class-leading performance when it came out, except in highly parallel tasks, and to a large extent it _still does_.
I was able to successfully train a designer to use the Android SDK's tools when appropriate, and check in graphical assets. In preparatory meetings I insisted the designer be in the room with the coders and product managers as I explained how Android is different. I taught them all how to use conditional layouts and how to test apps for good practices by changing font sizes to see if they really are geometry-independent. Once they saw how easy it is to make other developers' work look less than competent, I could see the switch in their minds flip: They were not doing to be tripped up by users who change font size.
This client was the typical kind of client who could easily have fallen into a "portitis" pattern of not designing for the capabilities of Android's layout system. If all parts of the system - product managers, coders, and designers, not have bought into thinking about their part of the project differently from an iOS implementation, the designers would have had no inputs from those other parts of the team re how they were modifying their approach for an Android version of their product.
Android has a richer system for adapting code modules to different layouts, and therefore a more sophisticated UX for tablets. It's a pity than many Android apps are low-bidder porting jobs that plaster right over that.
I'd be interested in reading more about this - I'd love to show it to some designers I work with.
At the moment, I'm struggling to get the designers to acknowledge that Android and iOS need to be designed seperately. iOS designs can look pixel-perfect due to having only 2 resolutions to care about (ok, iPhone 5+ have taller screens, but same width)
This is how I introduce Android to teams that are making their first serious non-game app:
1. How to scale the app across all screen geometries:
a. Let Android choose the layout from among the alternatives you create for different geometries
b. This means different numbers of Fragment objects can be displayed
c. This means different functionality can be available
d. This means you have to organize functionality in a hierarchy (for the smallest screens) that can be unfolded and flattened (for the biggest screens)
2. Then I get into Activity and how the code that used to be in activities should be organized into Fragment subclasses, and about top-level layouts.
3. Then I get into Relative Layout and how to make your layouts "stretchy" enough that you don't have to specify a different layout for every combination of size, density, orientation, and text size.
4. Now that the coders and designers understand how they fit together in making a UX that "folds up" and "unfolds" I teach the designers how to check in to the client's repos, and how to edit layouts in Eclipse, so they can be responsible for their own work getting into the project and build and run the app to see how their layouts work.
This is still a vast simplification, leaving out things like Android remote methods and high-level (Intent) IPC and how hat affects UX, and numerous other areas where Android is substantively different from iOS's app environment.
I wonder how much of it had to do with how graphically inconsistent Android was until 4.x
I had Stock Android 1.x and 2.x devices (before switching to iOS), and there was no consistent UI anywhere to be found, even different parts of the base system did things differently, not to mention non-scrollable UI elements that'd render off partially the screen (parts of the menus for example) - and thats just the interface - while android is better now, you still have the supposed fragmentation issues, and the fact that if you have a single device that has some issues with your app, you can end up with comments and ratings that reflect that minority rather than the majority of users for whom it works fine.
"Mika says it spent 20% of its total development time last year on the process of porting two of its games to Android and then tweaking those titles for individual devices. It could never even get Battleheart to work on Galaxy S phones, because they can't download .apk's larger than 30MB with stock software. For all the months of "thanklessly modifying shaders and texture formats to work on different GPUs, or pushing out patches to support new devices without crashing, or walking someone through how to fix an installation that wouldn't go through," Mika claims it never made a profit off either of its Android games."
Geez, I wouldn't go into Android game development after reading this. And we haven't even breached the piracy issues.
You apparently missed that the article itself is from March 2012, talking about a game (Battleheart) released in June 2011.
The Galaxy S was released in June 2010 (so it's not even 4 years old, let alone 5…), it was barely a year old at game release and was not only one of the popular smartphones of the times, as the Nexus S it was also the reference device until November 2011.
It is both a real thing and laziness. With decent technical design and Google's Android support library you can pretty much code as if 98% of people run KitKat and not worry about it, the support library will fallback gracefully down to all the OS versions you do care about.
Most of the time when I hear designers complaining about Android fragmentation they are really just using "fragmentation" as a scapegoat to bemoan they fact that they can't just create a very small set (1-3) of universal "pixel perfect" mockups and ship those off as a PSD to a developer as the end-all, be-all "visual spec". They have to worry about things like how different parts of the app should scale as more real estate is made available, really understand DPI (I've met more than a few designers who shockingly don't really grasp DPI scaling), etc. Some designers are awesome at this and welcome the challenges (and benefits!) that "responsive layout" brings with it, but a lot of them (most of them, in my personal experience) just want to punt on all that shit.
It's "easier" in the same sense that it's easier to hack up a quick website in PHP than it is to write kernel driver.. (though the magnitude of the difference is not as great as that example picked for illustration).
It IS much easier. Given that you only have to worry about 2 devices, with 2 resolutions (2x scaling is handled pretty well), it's perfectly possible to make a pixelperfect layout off a PSD (of course, things get a bit complex with font sizes, etc, but autolayout helps out).
> With decent technical design and Google's Android support library you can pretty much code as if 98% of people run KitKat and not worry about it
People say this. It's not really actually true.
A nice little example encountered recently. Say you have a HTTP server which uses gzip or deflate when the client asks it to. Pretty standard, right? And say you want to return a HTTP 204, or other contentless success. Seems reasonable? And if you do this on Android 4.4 using the standard HTTP client, it will work. If you do it on Android 4.1 (the most commonly-deployed version of Android), it will throw a null pointer exception deep in the library code.
This is just one of many issues. Compatibility support libraries are all very well, but they don't really help with the standard libraries being buggy, and those bugs will _never be fixed_ for the vast majority of users.
Does that really matter though? Apps which require 4.0+ still frequently have terrible design which is just an iOS clone, complete with fuzzy assets and a frustratingly iOS-centric UI.
At the same time, developers like ShiftyJelly (www.shiftyjelly.com) show that fantastic crossplatform apps can be developed which have a great Android UI and are still very similar to their iOS counterparts.
I genuinely think it is just laziness, but while users continue to put up with it (especially since Android users appear to be happy to stick with a shitty UI on a free app compared to dropping a couple of dollars on a great one), it is unlikely to change.
They design for the devices they have. They also design for the largest part of the viewing traffic of the web (ios). Apple is still a design deity.
Apple had the first big app platform and clients still demand iOS first. In game and app development, it still gets the most focus.
Finally, and a bit of a trick almost, is the review times are longer for Apple when talking about apps, this causes a focus on iOS earlier many times. Projects tend towards getting iOS ready early and in the queue and approved and the Android platforms second because Google Play is instant almost (Amazon is as slow as Apple on reviews). Like complaining customers that get the most focus, the more difficult to approve platform gets the most focus but only because of its market share and past (new entrants need to be easier).
However with Google's beta system on Play more and more projects are starting there now that a good chunk of clients have Android devices. Apple really needed to buy testflight because they didn't have anything as nice. Android is becoming a better test market and something you can iterate on faster early to prepare it for iOS, lots of game developers are thinking this way now, primarily because iOS is so hit driven at launch you have to get right and Google is better long tail is seems.
Granted I'm a developer who's just starting out with Android, but for the life of me I can't figure out any reasonable way to position things with percentages and maximum widths. I tried weight_sum and weight and gravity=center and that gets me percentages but then maxWidth is ignored.
Most of the advice online seems to be "you must construct additional LinearLayouts".
I've been writing Android code for close to 3 years now and I can tell you the problem isn't you. Android layouts are like CSS in that eventually they warp your brain to the point where you can mostly understand them and be productive with them, but they are still kind of ridiculous and make doing things that should be relatively easy much harder than they ought to be.
Sadly the whole way the layout system works seeps into the programmatic APIs in all sorts of bad ways too -- like, I just want to set the width of this view... there's no setWidth, wtf? Oh... LayoutParams? What in the hell is all this. Not to mention things like every layout type having its own LayoutParams class and all the fun that comes along with changing say a RelativeLayout to a LinearLayout and then having to both change all your different dpi xml files to match (especially on tablet/phone hybrid apps), and also make a ton of code changes to correct your Java casting, etc. bleh.
I've been there. I even started one small isolated project with the experimental idea to completely forego the XML layouts and just build the entire thing in Java.
Embarrassingly, it actually worked out okay. The thing is, with XML layouts, eventually the functionality requirements force you to pull in nearly all the views in Java and set styles and behavior programmatically. It's not exactly pleasant to do everything in Java (especially things like RelativeLayout.LayoutParams), but you're going to have to do it anyway, so the only thing the XML layouts really save you is setting up the view hierarchy. Perhaps if I worked with a designer who created the XML layouts and styles, this wouldn't be the case, but the Android tools for designers seem laughably bad.
And this is where a seasoned developer is required to implement good design on Android: you'll want to write a custom ViewGroup to layout child views the way that you want, without nesting layouts and causing overdraw or slow rendering.
Has anyone seen good results with the new Qt mobile tools? I realize that it won't look quite native - but Qt's got a pretty good track record, and if I could write apps using C++ instead of Java, and get some cross-platform capability, I'd certainly be interested.
I have probably been writing and porting more C++ code on Android lately than Java code. I haven't done much with QT. Some of the apps used the SDL library. Some of the apps have been OpenGL 1.x code ported to OpenGL ES.
I guess it all depends on what platforms you have in mind.
I've been burned by cross-platform tools. I tried Sencha Touch, and it was a horrible 2-year mistake.
Something that compiles might do better, but at the end of the day you really want to be calling into the cocoa touch framework directly. If Qt lets you do this, great. If it doesn't, look elsewhere.
I am. On my Nexus 5. Compared to a iPhone 5s, this runs circles around it. I'm not trying to start a flamewar or anything, but why are iOS devices so slow and clunky, and why is the UI so... fruity? Its just weird.
I've also got an iPad and seriously considered getting a iPhone instead of my Nexus 4 but iOS's poor keyboard i.e. key caps are always uppercase regardless of shift state, it's hunt and peck rather than swype, and the lack of intents were a deal breaker for me.
Yes but sure the key idea behind soft keyboards is they can change to reflect what I'm going to type, as for example the iOS keyboard does when I hit the number / punctuation shift key
You're in a tiny minority, right now. 2.5% of Android users use 4.4, compared to 19% using 2.3.x, 15% using 4.0.x, and _35%_ using 4.1.x. It's nice that you like it, but it's probably not worth most developers' time using 4.4-specific features for a year or so.
>A browser permanently playing catch-up will always be an additional, potentially redundant, layer in the technology stack. If a single OS ends up running >90% of the world’s connected devices, why bother writing software for the browser?
I can't agree here. I think the OS world will be fragmented for a very long time (forever) and that the browser world will always have a core set of functionality to write apps once that run everywhere. I don't think Android, iOS, or the desktop browser are going anywhere fast, and so the only platform you can write for that reaches all three is the browser.
I suppose the author is predicting the end of desktops/laptops being relevant but even given that (which I don't think will ever happen) there will still be iOS and Android. That's still double the work to release one app on both. People will always try to find the common denominator and the browser is it (even if in another incarnation, e.g., Cordova/PhoneGap).
And assuming Android beats iOS, I can't imagine it beats the WWW too. I'd like to see a statistical breakdown of "native" apps with embedded browsers vs actual native apps. And if Cordova simply won't ever offer an elegant enough user experience, then I think Firefox OS will become the winner. The WWW is just so much bigger than Objective C or Dalvik, no one's going to port all that. So, even assuming that one OS rules >90% of devices, what percent of existing webapps/websites is that? And what percent of existing mobile apps' tech stacks is that, accounting for apps that are seemingly native but actually built on web tech?
Also it spares you from having to write Java, or worse - Objective C. I went for HTML5 just because I could use a (relatively) sane language and not be forced in walled gardens in the process - like having to buy a $3000 Mac to use a language that looks like it's straight from the 80's (and now they're trying to get me to buy a Mac just so I can view the console output of my Javascript app - I'm starting to think Apple HATES the people that develop software for their devices).
The chart is from a well known and respected former Nokia analyst who, incidentally, has a degree in computer science. I guess the question should be; "Why do people on the internet consistently mouth off without checking their facts, which are always a mere search away?"
> The other replies were mostly variations on the theme that Android users don’t pay for apps, they don’t have data plans, you can’t monetise them easily, and designers are all iPhone users and don’t really understand Android users … Socially, excluding Android users seems almost prejudicial. Unlike Android is difficult, this isn’t about about mere convenience; it’s a value judgment on who is worth designing for. Put uncharitably, the root issue is “Android users are poor”.
This position sells the opposing argument short. It's not so much "designers believe a priori that Android users won't pay for good design," it's "Android users have a long and well-established track record of not paying for good design." People are still experimenting, and I think that this is actually a case you can rely on market mechanisms to handle. If Android users start demonstrating a willingness to pay for good design commensurate with the difficulty of producing good design for Android devices, there'll be a market opportunity there. Someone will get rewarded for providing people with what they're willing to pay for.
This leads into how Bowles sells the other argument short: he conflates design and graphic design when he address the "Android is hard to design for" argument. Design is, to borrow a famous phrasing, how it works. Sure, it was tough to do good graphic design for Gingerbread and it's much easier now. Great. However, the fragmentation and glacially-slow upgrades have a real cost here - to design the same functionality, may require spanning multiple API versions. The comparison to the diversity of Web browsers and viewers doesn't work because that diversity, relies on web standards. The equivalent of web standards that would allow an Android app to do responsive design in the manner of a web app, devices don't have or respect.
Fundamentally, it seems like Bowles doesn't get that the answer to his question is "because doing good design work on Android is more expensive and people pay less for it." Sure, you could ask designers to make speculative investments in Android, but I suspect that'll go about as well as asking people to make speculative investments of their professional time and skill usually goes. Professionals who respect their own time and worth, go where they can do good work and get paid well for it. Currently, that means they don't go to Android.
You posted three links to the android documentation that don't address sedev's point at all.
Your first point doesn't address the "falling back gracefully" part. The second part of that example, the ActionBar, which was introduced in ICS, IIRC, only has a community shim. Granted if you want to use a new API that may not have as much community support as the ActionBar, you either code one yourself (strengthening the sedev's point that you have to design the same functionality across multiple versions).
Your second point is even more off base. With the web's responsive design, I have to make one HTML file, and one CSS file, and if my design is sane, it works across all screen sizes. Your second link requires you to hand code different layouts for every device size which is hardly a solution - infact you are back squarely where you started. And I'm unsure if you actually read those tutorials but they don't even seem to have been updated since eclair. IIRC, you only had to deal with 3 sizes then - ldpi, mdpi, and hdpi. I haven't done Android dev in a while, but I'm sure the number of layouts have tripled.
If you really want to counter sedev's point, you should point to an app with the relevant code that actually does what sedev is talking about and not some links to the documentation. Everyone is already aware of the documentation, and if it actually worked as you said it did, we would not be having this conversation.
You just make your app out of fragments and then use different layouts based on screen size to arrange your fragments. It's pretty straight forward and really not the problem. For general reactive design like on websites, you can just set up your layout in XML to grow correctly to fit the screen, which is something it does by default.
The real problem is that Android very heavily links layout with function. In HTML-land, a designer who knows a bit of html and css can happily redesign the layout of the page. In iOS-land, a designer can use UIBuilder to redesign the layout of the page as well (they usually break it too by dragging stuff inside other stuff, but it's visual and generally fixable). In Android, redesigning the layout of an app is generally very complex and nearly always requires major code changes because of how fragments are forced to interact through the activity god object.
As RyanZAG explained, your multiple layout files should only re-organize fragments.
Yes Android dev is hard, with multiple versions, sizes, formats and bugs. But there is documentation, tools and example to adress them. Deal with it.
If you are willing to try again, as so many things have changed since Eclair, you can have a look at this exemple where you will see how you can use new API and a fallback when they are not available: http://code.google.com/p/android-protips-location/source/bro...
I do not know how graceful falling back is in web development, but there are some non-graceful holes in what can be accomplished with Android compatibility libraries
The biggest design-impacting issues I've encountered are the absence of expandable or interactive notifications pre 4.1 and limitations in styling/visualizing list selection states pre 3.0
I haven't checked on Android as a platform in quite a long time but it is amazing to see that things still are exactly where they were when I last checked.
Android == Google == Free Software
That still seems to be the basic idea many users have.
It was always weird to see a platform with such high market share compared to iOS can not even get close to what iOS rakes in as revenue and mobile traffic.
If one looks at the numbers it's staggering that a platform with so many active devices cannot even get close to the mobile traffic that iOS generates. And no, I do not think that Android users just use apps and that's why you don't see regular mobile traffic from them. iOS also has apps and personally, I use mostly apps and don't surf that much using the browser.
Still, even back when I last checked people where projecting this to be a temporary thing and things would soon change to reflect Androids market share in the mobile revenue and mobile internet traffic statistics. Apparently, that does not seem to be the case. The Google == Free mentality seems to be too ingrained in people's minds. And I guess the recent privacy issues don't help there. "If they all gonna get my personal infos, then I surely won't pay for the app" seems to be the rational.
And why shouldn't it? It was long since established that if something is free, you are not the customer, you are the product. And if every other app seems to try and collect your info, of course you want the app to be free.
uggh, conversations about this stuff get so messy....
Android users mobile traffic? iOS users may show more mobile traffic because the locked down nature of so many iOS app/features forces you to go out to the browser/web for daily tasks. Android allows so much to be done with only a few apps and basic information which accounts for 85% of your daily us to be at your fingertips without having to open a browser.
So yeah, Android users may just use apps, but the reasoning/tracking for mobile traffic and pattern exhibited from iOS comes for different reasons...
Perfect, I think that's the answer in one sentence: "doing good design work on Android is more expensive and people pay less for it". It's harder work for less reward.
"However, the growth patterns of Android are what give it such power. Android utterly dominates in emerging markets."
The last point there is an important one. In the US (and various other markets), iOS and Android are not that far apart in user count. In fact I believe in the US now, iOS is taking share back (albeit a minor share lol): http://www.comscore.com/Insights/Press_Releases/2014/3/comSc...
But anyway, I've enjoyed reading the comments here, and I think the point about designers themselves being more mac-oriented (historically) is a pretty valid reason!
You are right, I have but a little anecdotal evidence.
In my experience there does exists a group of designers who view Apple to be the gospel of UI design, which can sometimes lead to them ignoring other schools of thought.
So if I've got this right... It's those nasty lazy designerses fault, and has nothing to do with Androids colossal shortcomings either as a platform to develop for, or to earn a living from?
Probably because when Android evangelists (not necessarily Google) market Android as the "anti-Apple" OS, you remind a lot of current Apple users about the days when Windows ruled the earth and all of the anti-usability that came with it.
Money is in iOS, so companies prioritize it first. After Android becomes the main platform for monetization, it will probably be taken a lot more seriously.
Right now it goes like this in every company.
1) Lets make an iOS app
2) okay we have an iOS app, can someone clone an Android one real quick? It doesn't have to be perfect, just get it done ASAP.
> I recognise that I have a fairly rare stance, given the ideology that surrounds platform issues.
It's not a rare stance. Android is the hot thing now and has been gaining tons of momentum.
Most designers I see have iPhones. I think they just like designing for a platform that they like. It's natural. People who like Linux develop for Linux, etc. Why would you do otherwise?
> My uncharitable interpretation for this class of responses is simple laziness
What does this mean? If I was uncharitable, I'd say it sounds like he wants designers and developers to work nights and weekends. If there's a business case for supporting Android, then you need more headcount. If not, calling the team lazy is unnecessary.
> I do hope, given tech’s rhetoric about changing the world and disrupting outdated hierarchies, that we don’t really think only those with revenue potential are worth our attention.
Most designers work for for-profit companies where revenue potential is an extremely important consideration, irrespective of whether they personally sympathize with the poor.
There's a valid point buried in here somewhere. It's possible that companies are underinvesting in Android because they've underestimate the opportunity, but blaming this on designers preferring iOS is just weird. A decision as important as the choice of platform is rarely left up to the personal preference of the designer.
Rather than asking "Why don't designers take Android seriously?" I'd ask "Why don't companies take Android seriously?" Once a company decides to take Android seriously, it isn't all that difficult to create compelling apps, with or without a designer that is dedicated to the Android platform. While I don't advocate simply copying the iOS experience on Android, a developer with some knowledge of how the platform works doesn't necessarily need a designer's help to modify the iOS experience to fit Android paradigms.
143 comments
[ 2.9 ms ] story [ 257 ms ] threadSurely you're going to provide data or some citation to back that huge assertion.
This is why when a very talented Android engineer like Sarah Haider (Twitter's Android lead) goes from Twitter to Secret, it is a big deal. There are many strong, capable iOS technical leads out there and probably a fraction thereof in Droidlandia (using Pareto's famous rule, probably 4 - 5 good iOS technical leads for every 1 good Android technical lead).
To make an app on Android look good, the responsibility lies much more on the developer than the designer. The designer on iOS can easily use IB. Not so much Android Studio or Eclipse.
At the highest levels (slightly below Jake Wharton), talented Android developers who care about the user experience and can deliver compelling, beautiful apps can name their own price.
I don't know anything about Kotlin on Android, though.
I was impressed with the tools you get out the box. I've paid hundred (close to thousands) for similar tools in .NET.
Android Studio only added Gradle, which provides Groovy for its scripting, recently. Groovy has a history of shipping standalone versions as soon as possible and letting users find the bugs, and only afterwards does Grails bundle the version. I'd say Gradle-bundled sits somewhere between standalone and Grails-bundled on the testing scale for Groovy versions.
It's very telling that Jetbrains managed to pull AppCode out of nowhere and blitz Xcode. I had never before used an IntelliJ-based IDE, but within a week or two my productive increased severalfold. It really puts Apple's efforts to shame.
But for pure Obj-C apps I'll take AppCode every day. There are so many little usability and productivity wins over Xcode.
(b) people might suffer through substandard products because they're the only reasonable way of developing software for a platform (you see that sentiment a lot of times from people who claim to be forced to do development on Windows)
Just saying that a single person claiming that XCode is an unusable, horrible piece of shit probably says as much as 1 million apps being written for that platform. At least not about usability of the development environment.
Xcode 5 finally makes it easy to run single unit tests. Before this, you had to create a schema to run a single test, which was several clicks and possibly some typing. Now it's click and run, which is lovely.
I usually use Emacs or vi. The only thing I miss when not using Eclipse with the ADT plugin is after typing say "LinearLayout ll;" with Eclipse I can type Control-Shift-O and the LinearLayout class is automatically imported in the code. I miss this, but I kind of have this in Emacs with JDE - a Control-C-V-Z has similar behavior. I could probably do some more tool work on Emacs and make it even more automatic.
I do everything with emacs, vi, ant, astyle, adb, and the Android commands "android" and "monitor". Some people do Android in IntelliJ, some in Netbeans. Some use Sublime Text.
If you think Eclipse with ADT is bad for Android development now, you should have seen Eclipse/ADT at the end of 2009. Just getting the ADT plugin to work with Eclipse was a nightmare. Having seen the improvement since then, I guess it all seems less bad to me. Although I don't use Eclipse when I do Android programming, generally.
It's worth learning, even if you only learn the basics.
I code in MacVim. For anything, not just Android and I didn't like either Eclipse or XCode, XCode even lesser as mentioned above.
I would add that the designer has to understand Fragment, understand that density, orientation, screen size and text size are different dimensions of screen geometry, and how to avoid a combinatorial explosion of layouts, or, conversely, layouts that only work at default font sizes on medium denisty screens.
The coder has to get it right, too.
Although I'd argue that that's really what designers should be doing anyway, thinking procedurally and in terms of systems rather than fixed, one-off designs.
Also, the good apps are not made using IB. Fine for prototyping, sure, but not suitable for real world use. Feel free to prove me wrong, and name IB success stories.
Smells like good old FUD spreading to me.
Sure you need to leave IB sometimes (or a lot of the time - depending on the app), but if you are coding every little view by hand... well you have more time on your hands (and budget?) than I do :P
Oddly, when I ask them why, the answers are mostly qualitative. It has nothing to do with "reaching the most people" or "getting exposure". It's a simple matter of taste. Designers tend to choose iOS products because they identify with them. They see Apple as an institution that they would enjoy being a part of in some way. Almost all the designers I know that are worth their salt use and love their macs for working in Photoshop and Illustrator, so it naturally follows that they prefer the iOS platform, regardless of numbers and market share.
Admittedly, my sample size is only around 50 or so, but this has been my experience.
I can definitely sympathize.
No android phone nor interface is close to the level of what Apple is putting out - both from an experience and product standpoint. This is also the same exact same reason why I purchase all apple products.
I really don't understand the argument of "You're paying more for a lesser product when you buy Apple". Ok - so the hardware isn't as good/powerful, fine, but that's not why I'm buying an Apple product. I'm buying it because of the UX, because of the way the phone feels in my hand, because of the way the keys feel on the keyboard when I press them down, because of how great the applications look and feel when I use them.
If android came out with something that looked and felt great I would certainly consider using it. In fact, I purchased a Samsung Galaxy S3 several years ago when it first came out. The phone was absolute garbage - plastic bevels still had molding pieces around the edges, the unnecessary bloatware (which would have been fine if it was remotely useful) was very poorly designed, and overall the phone felt very light and cheap.
The funny thing is, that's kind of a myth, particularly in phone land. The A7 (the 5S's SoC) had pretty much class-leading performance when it came out, except in highly parallel tasks, and to a large extent it _still does_.
This client was the typical kind of client who could easily have fallen into a "portitis" pattern of not designing for the capabilities of Android's layout system. If all parts of the system - product managers, coders, and designers, not have bought into thinking about their part of the project differently from an iOS implementation, the designers would have had no inputs from those other parts of the team re how they were modifying their approach for an Android version of their product.
Android has a richer system for adapting code modules to different layouts, and therefore a more sophisticated UX for tablets. It's a pity than many Android apps are low-bidder porting jobs that plaster right over that.
At the moment, I'm struggling to get the designers to acknowledge that Android and iOS need to be designed seperately. iOS designs can look pixel-perfect due to having only 2 resolutions to care about (ok, iPhone 5+ have taller screens, but same width)
Android is a whole different story.
(whole slide deck is worth looking at)
1. How to scale the app across all screen geometries:
2. Then I get into Activity and how the code that used to be in activities should be organized into Fragment subclasses, and about top-level layouts.3. Then I get into Relative Layout and how to make your layouts "stretchy" enough that you don't have to specify a different layout for every combination of size, density, orientation, and text size.
4. Now that the coders and designers understand how they fit together in making a UX that "folds up" and "unfolds" I teach the designers how to check in to the client's repos, and how to edit layouts in Eclipse, so they can be responsible for their own work getting into the project and build and run the app to see how their layouts work.
This is still a vast simplification, leaving out things like Android remote methods and high-level (Intent) IPC and how hat affects UX, and numerous other areas where Android is substantively different from iOS's app environment.
I had Stock Android 1.x and 2.x devices (before switching to iOS), and there was no consistent UI anywhere to be found, even different parts of the base system did things differently, not to mention non-scrollable UI elements that'd render off partially the screen (parts of the menus for example) - and thats just the interface - while android is better now, you still have the supposed fragmentation issues, and the fact that if you have a single device that has some issues with your app, you can end up with comments and ratings that reflect that minority rather than the majority of users for whom it works fine.
"Mika says it spent 20% of its total development time last year on the process of porting two of its games to Android and then tweaking those titles for individual devices. It could never even get Battleheart to work on Galaxy S phones, because they can't download .apk's larger than 30MB with stock software. For all the months of "thanklessly modifying shaders and texture formats to work on different GPUs, or pushing out patches to support new devices without crashing, or walking someone through how to fix an installation that wouldn't go through," Mika claims it never made a profit off either of its Android games."
Geez, I wouldn't go into Android game development after reading this. And we haven't even breached the piracy issues.
[1] http://www.androidpolice.com/2012/03/12/mika-mobiles-decisio...
"It's too hard" or "it doesn't make enough money" are more than reasonable. A software limitation in a 5 year old device is not.
The Galaxy S was released in June 2010 (so it's not even 4 years old, let alone 5…), it was barely a year old at game release and was not only one of the popular smartphones of the times, as the Nexus S it was also the reference device until November 2011.
Most of the time when I hear designers complaining about Android fragmentation they are really just using "fragmentation" as a scapegoat to bemoan they fact that they can't just create a very small set (1-3) of universal "pixel perfect" mockups and ship those off as a PSD to a developer as the end-all, be-all "visual spec". They have to worry about things like how different parts of the app should scale as more real estate is made available, really understand DPI (I've met more than a few designers who shockingly don't really grasp DPI scaling), etc. Some designers are awesome at this and welcome the challenges (and benefits!) that "responsive layout" brings with it, but a lot of them (most of them, in my personal experience) just want to punt on all that shit.
People say this. It's not really actually true.
A nice little example encountered recently. Say you have a HTTP server which uses gzip or deflate when the client asks it to. Pretty standard, right? And say you want to return a HTTP 204, or other contentless success. Seems reasonable? And if you do this on Android 4.4 using the standard HTTP client, it will work. If you do it on Android 4.1 (the most commonly-deployed version of Android), it will throw a null pointer exception deep in the library code.
This is just one of many issues. Compatibility support libraries are all very well, but they don't really help with the standard libraries being buggy, and those bugs will _never be fixed_ for the vast majority of users.
It gets even worse when you take OEM crap into account. Want to use the camera? You'd better know about obscure Samsung quirks: http://stackoverflow.com/questions/13448731/does-samsung-gal...
At the same time, developers like ShiftyJelly (www.shiftyjelly.com) show that fantastic crossplatform apps can be developed which have a great Android UI and are still very similar to their iOS counterparts.
I genuinely think it is just laziness, but while users continue to put up with it (especially since Android users appear to be happy to stick with a shitty UI on a free app compared to dropping a couple of dollars on a great one), it is unlikely to change.
Apple had the first big app platform and clients still demand iOS first. In game and app development, it still gets the most focus.
Finally, and a bit of a trick almost, is the review times are longer for Apple when talking about apps, this causes a focus on iOS earlier many times. Projects tend towards getting iOS ready early and in the queue and approved and the Android platforms second because Google Play is instant almost (Amazon is as slow as Apple on reviews). Like complaining customers that get the most focus, the more difficult to approve platform gets the most focus but only because of its market share and past (new entrants need to be easier).
However with Google's beta system on Play more and more projects are starting there now that a good chunk of clients have Android devices. Apple really needed to buy testflight because they didn't have anything as nice. Android is becoming a better test market and something you can iterate on faster early to prepare it for iOS, lots of game developers are thinking this way now, primarily because iOS is so hit driven at launch you have to get right and Google is better long tail is seems.
Most of the advice online seems to be "you must construct additional LinearLayouts".
Sadly the whole way the layout system works seeps into the programmatic APIs in all sorts of bad ways too -- like, I just want to set the width of this view... there's no setWidth, wtf? Oh... LayoutParams? What in the hell is all this. Not to mention things like every layout type having its own LayoutParams class and all the fun that comes along with changing say a RelativeLayout to a LinearLayout and then having to both change all your different dpi xml files to match (especially on tablet/phone hybrid apps), and also make a ton of code changes to correct your Java casting, etc. bleh.
I really wish Google would let people use HTML and CSS instead of that bizarre relational XML stuff.
http://phonegap.com/
Embarrassingly, it actually worked out okay. The thing is, with XML layouts, eventually the functionality requirements force you to pull in nearly all the views in Java and set styles and behavior programmatically. It's not exactly pleasant to do everything in Java (especially things like RelativeLayout.LayoutParams), but you're going to have to do it anyway, so the only thing the XML layouts really save you is setting up the view hierarchy. Perhaps if I worked with a designer who created the XML layouts and styles, this wouldn't be the case, but the Android tools for designers seem laughably bad.
But picked it up again later using Xamarin Studio. Much nicer experience and easier to make a nice design.
I managed to make a small app and have it run on my iPhone and Windows Phone, and my flatmates Android.
Lots of fun, just lacking ideas to make a real world app now :(
I guess it all depends on what platforms you have in mind.
Something that compiles might do better, but at the end of the day you really want to be calling into the cocoa touch framework directly. If Qt lets you do this, great. If it doesn't, look elsewhere.
I've also got an iPad and seriously considered getting a iPhone instead of my Nexus 4 but iOS's poor keyboard i.e. key caps are always uppercase regardless of shift state, it's hunt and peck rather than swype, and the lack of intents were a deal breaker for me.
I can't agree here. I think the OS world will be fragmented for a very long time (forever) and that the browser world will always have a core set of functionality to write apps once that run everywhere. I don't think Android, iOS, or the desktop browser are going anywhere fast, and so the only platform you can write for that reaches all three is the browser.
I suppose the author is predicting the end of desktops/laptops being relevant but even given that (which I don't think will ever happen) there will still be iOS and Android. That's still double the work to release one app on both. People will always try to find the common denominator and the browser is it (even if in another incarnation, e.g., Cordova/PhoneGap).
And assuming Android beats iOS, I can't imagine it beats the WWW too. I'd like to see a statistical breakdown of "native" apps with embedded browsers vs actual native apps. And if Cordova simply won't ever offer an elegant enough user experience, then I think Firefox OS will become the winner. The WWW is just so much bigger than Objective C or Dalvik, no one's going to port all that. So, even assuming that one OS rules >90% of devices, what percent of existing webapps/websites is that? And what percent of existing mobile apps' tech stacks is that, accounting for apps that are seemingly native but actually built on web tech?
Oh, wait, they do!
This position sells the opposing argument short. It's not so much "designers believe a priori that Android users won't pay for good design," it's "Android users have a long and well-established track record of not paying for good design." People are still experimenting, and I think that this is actually a case you can rely on market mechanisms to handle. If Android users start demonstrating a willingness to pay for good design commensurate with the difficulty of producing good design for Android devices, there'll be a market opportunity there. Someone will get rewarded for providing people with what they're willing to pay for.
This leads into how Bowles sells the other argument short: he conflates design and graphic design when he address the "Android is hard to design for" argument. Design is, to borrow a famous phrasing, how it works. Sure, it was tough to do good graphic design for Gingerbread and it's much easier now. Great. However, the fragmentation and glacially-slow upgrades have a real cost here - to design the same functionality, may require spanning multiple API versions. The comparison to the diversity of Web browsers and viewers doesn't work because that diversity, relies on web standards. The equivalent of web standards that would allow an Android app to do responsive design in the manner of a web app, devices don't have or respect.
Fundamentally, it seems like Bowles doesn't get that the answer to his question is "because doing good design work on Android is more expensive and people pay less for it." Sure, you could ask designers to make speculative investments in Android, but I suspect that'll go about as well as asking people to make speculative investments of their professional time and skill usually goes. Professionals who respect their own time and worth, go where they can do good work and get paid well for it. Currently, that means they don't go to Android.
Oh, really?
Let's take a look shall we:
1. Using new APIs if available and falling back gracefully if not: http://developer.android.com/training/basics/supporting-devi...
2. Adapting your layout and UI to each device based on screen size, density and other features: http://developer.android.com/training/multiscreen/index.html
3. Libraries to help use newer features while being backward-compatible: http://developer.android.com/tools/support-library/index.htm...
And so on. Looks to me like there's plenty of infrastructure to help building responsive apps if you want to.
Your first point doesn't address the "falling back gracefully" part. The second part of that example, the ActionBar, which was introduced in ICS, IIRC, only has a community shim. Granted if you want to use a new API that may not have as much community support as the ActionBar, you either code one yourself (strengthening the sedev's point that you have to design the same functionality across multiple versions).
Your second point is even more off base. With the web's responsive design, I have to make one HTML file, and one CSS file, and if my design is sane, it works across all screen sizes. Your second link requires you to hand code different layouts for every device size which is hardly a solution - infact you are back squarely where you started. And I'm unsure if you actually read those tutorials but they don't even seem to have been updated since eclair. IIRC, you only had to deal with 3 sizes then - ldpi, mdpi, and hdpi. I haven't done Android dev in a while, but I'm sure the number of layouts have tripled.
If you really want to counter sedev's point, you should point to an app with the relevant code that actually does what sedev is talking about and not some links to the documentation. Everyone is already aware of the documentation, and if it actually worked as you said it did, we would not be having this conversation.
The real problem is that Android very heavily links layout with function. In HTML-land, a designer who knows a bit of html and css can happily redesign the layout of the page. In iOS-land, a designer can use UIBuilder to redesign the layout of the page as well (they usually break it too by dragging stuff inside other stuff, but it's visual and generally fixable). In Android, redesigning the layout of an app is generally very complex and nearly always requires major code changes because of how fragments are forced to interact through the activity god object.
ActionBar is not a community shim anymore, a compatibility library down to gingerbread is provided and supported by Google: http://developer.android.com/reference/android/support/v7/ap...
As RyanZAG explained, your multiple layout files should only re-organize fragments.
Yes Android dev is hard, with multiple versions, sizes, formats and bugs. But there is documentation, tools and example to adress them. Deal with it.
If you are willing to try again, as so many things have changed since Eclair, you can have a look at this exemple where you will see how you can use new API and a fallback when they are not available: http://code.google.com/p/android-protips-location/source/bro...
The biggest design-impacting issues I've encountered are the absence of expandable or interactive notifications pre 4.1 and limitations in styling/visualizing list selection states pre 3.0
Android == Google == Free Software
That still seems to be the basic idea many users have. It was always weird to see a platform with such high market share compared to iOS can not even get close to what iOS rakes in as revenue and mobile traffic.
If one looks at the numbers it's staggering that a platform with so many active devices cannot even get close to the mobile traffic that iOS generates. And no, I do not think that Android users just use apps and that's why you don't see regular mobile traffic from them. iOS also has apps and personally, I use mostly apps and don't surf that much using the browser.
Still, even back when I last checked people where projecting this to be a temporary thing and things would soon change to reflect Androids market share in the mobile revenue and mobile internet traffic statistics. Apparently, that does not seem to be the case. The Google == Free mentality seems to be too ingrained in people's minds. And I guess the recent privacy issues don't help there. "If they all gonna get my personal infos, then I surely won't pay for the app" seems to be the rational.
And why shouldn't it? It was long since established that if something is free, you are not the customer, you are the product. And if every other app seems to try and collect your info, of course you want the app to be free.
Come on!
My daughter used 8 gig of data last month. It meant she watched a lot of Netflix at her college who's Wifi is weak.
Video = More Data not necessarily a good measurement.
The last point there is an important one. In the US (and various other markets), iOS and Android are not that far apart in user count. In fact I believe in the US now, iOS is taking share back (albeit a minor share lol): http://www.comscore.com/Insights/Press_Releases/2014/3/comSc...
But anyway, I've enjoyed reading the comments here, and I think the point about designers themselves being more mac-oriented (historically) is a pretty valid reason!
Or, "How to get me to stop reading after the first paragraph".
"Android users obviously picked their device for other reasons than design, so it doesn't have to look as good."
Let's not use pejoratives. While we are at it, let's not project our own assumptions as points of fact.
But if all you are trying to do is make it look like iOS, you are on the wrong track.
Monetization issues are a separate problem as far as I can see. While money can shift priorities, but shouldn't affect design.
Right now it goes like this in every company.
1) Lets make an iOS app
2) okay we have an iOS app, can someone clone an Android one real quick? It doesn't have to be perfect, just get it done ASAP.
> I recognise that I have a fairly rare stance, given the ideology that surrounds platform issues.
It's not a rare stance. Android is the hot thing now and has been gaining tons of momentum.
What does this mean? If I was uncharitable, I'd say it sounds like he wants designers and developers to work nights and weekends. If there's a business case for supporting Android, then you need more headcount. If not, calling the team lazy is unnecessary.
> I do hope, given tech’s rhetoric about changing the world and disrupting outdated hierarchies, that we don’t really think only those with revenue potential are worth our attention.
Most designers work for for-profit companies where revenue potential is an extremely important consideration, irrespective of whether they personally sympathize with the poor.
There's a valid point buried in here somewhere. It's possible that companies are underinvesting in Android because they've underestimate the opportunity, but blaming this on designers preferring iOS is just weird. A decision as important as the choice of platform is rarely left up to the personal preference of the designer.
I've seen two identical apps (games specifically) on Android and iOS, the iOS versions made considerably more revenue than the Android version.
So I guess the commonly asked question is "Will we make the same amount of money with a cheaper design?"
Obviously this is a bit anecdotal, but I think it's a contributing factor.