Why it’s hard to find Android developers(blog.sephiroth.it)
blog.sephiroth.it
Why it’s hard to find Android developers
http://blog.sephiroth.it/2014/09/16/why-its-hard-to-find-android-developers/
16 comments
'Plug in an Android device, and you might need to search around to find a manufacturer-specific toolset, and/or navigate secret menus to enable debugging (like "click this menu item that doesn't look like a button seven times"'
Sorry I need to call BS on that. Developing on your android device is approximately a thousand times easier than the entire Apple developer/certificate/code-signing dance. Running the app under debugger is also a single button click experience. To top it all, all of this is free and runs on multiple desktop platforms (Linux, windows or OSX). The relative shortage of Android developers in SF and NYC is much better explained by the original article than any sort of difference in ease of starting out in either platform.
Sorry I need to call BS on that. Developing on your android device is approximately a thousand times easier than the entire Apple developer/certificate/code-signing dance. Running the app under debugger is also a single button click experience. To top it all, all of this is free and runs on multiple desktop platforms (Linux, windows or OSX). The relative shortage of Android developers in SF and NYC is much better explained by the original article than any sort of difference in ease of starting out in either platform.
That's extremely exaggerated. What phone did you need to find a "manufacturer-specific toolset"? I'm not even sure what you are referring to. In fact starting on Android is significantly easier than iOS. Enable debugging, plug phone in and you can start debugging your apps on the phone.
Don't even get me started on sharing apps to testers. iOS is just a nightmare without using something like TestFlight.
You can't even get started on iOS without having a Mac, a $99/year subscription and worrying about creating app ids, profiles and other strange things through the developer portal.
You can't even get started on iOS without having a Mac, a $99/year subscription and worrying about creating app ids, profiles and other strange things through the developer portal.
Some phone manufacturers (like Samsung) ship with an incompatible, JSON library. You have to enforce the dependency against the official library if you want your app to not fail mysteriously.
Nothing is as bad as Apple's brain-dead method of tracking files in its projects. They create UUIDs for each entry, instead of doing something more file-specific. This results in merge conflicts when more than one person works on a project. Poor design.
Nothing is as bad as Apple's brain-dead method of tracking files in its projects. They create UUIDs for each entry, instead of doing something more file-specific. This results in merge conflicts when more than one person works on a project. Poor design.
I haven't run into that issue but I am not surprised. Anything goes with Samsung phones.
With Gradle and Maven support I've found it really easy to manage dependencies to third party libraries. Personally I use Jackson when dealing with anything JSON related.
On Windows, plugging in a new phone/tablet can be bothersome since you can need to install a new driver.
On OsX/Linux, it is pretty much transparent. take the phone, activate dev mode if it is not already the case, plug it and you are done.
I don't think that developing for Android is so complicated - but maybe you had some bad luck with a device.
But RELEASING your app is much easier on Android (the Play store) than on Apple's store.
We had developed some apps for some customers and it was always a chore to release them into the Apple app store.
Somebody paid us money to make an app for them and then we can't release it on IOS because you think it has no sense for people and that it was written with the wrong toolset.
It would be no problem if there was an easy way on IOS devices to use another, more open store.
But RELEASING your app is much easier on Android (the Play store) than on Apple's store.
We had developed some apps for some customers and it was always a chore to release them into the Apple app store.
Somebody paid us money to make an app for them and then we can't release it on IOS because you think it has no sense for people and that it was written with the wrong toolset.
It would be no problem if there was an easy way on IOS devices to use another, more open store.
Huhwhat? Download eclipse, search for "android" in the marketplace, click "ok" repeatedly, write your code, plug in your phone, push the deploy button, and it Just Works. At least that's always been my experience.
I have to second that. I'm a rather experienced java-developer, I've done two Android apps and the Android-SDK is one of the worst SDKs I've ever seen. Substandard doesn't even begin to describe it. No matter where you look it seems to throw in a Gotcha! with every step you're doing.
* The IDE-Integration is meh: I do like Eclipse, but even the SDK-Manager for Android bugs around. The Layouting-Screen is so slow that everybody edits the XML directly anyway. This should get a bit better with Android Studio.
* The API seems to have been converted from a (bad) C-API. Loads and loads of useless inheritance. Whenever you instantiate an object in Android it brings along at least 15 methods that make no sense to call. It often doesn't even use generics. Happy casting. Why use enums when you can have Bitfields!
* Hardware acceleration is just a gamble. The doc here [0] says that you can enable it or disable it, except that sometimes that get's overridden and that you can enable and disable it partially as well, except that with some parts that doesn't work, especially in conditions that might apply sometimes. In practise I've seen that enabling acceleration made some parts of my applications smoother, and some slower. This behaviour changes with every minor version update on the tablets, of course. Way to go Android!
[0] https://developer.android.com/guide/topics/graphics/hardware...
* If you ask the Android API (on GalaxyTab 3) if an SD-Card ("external storage") is inserted, it will always return true, because the internal memory uses sd-card drivers and is always there. That is one of these thousands of gotchas that cost you 30 minutes of debugging.
* Android's standard Activity has methods for storing and restoring state, which is reasonable except that those are not persistent and should be only used when the Activity get's destroyed and recreated during turning of the display, for example. If you want persistent state, so that your App can be killed, you have to invent it yourself. At this point, I did the turning-thing with my own mechanism as well, because it was less cumbersome and less code-duplication.
* MultiTouch is just messing around with raw values. There are 10 pinch-zoom libraries out there, and none of them is perfect.
I could rant on endlessly, so I will some it up:
* The android SDK is 50% crap, by which I mean that if you are doing something slighty complex than you will find yourself outgrowing the extremely limited usecases that it's Views allow you and reimplement new ones yourself. I even had to modify the TextView because it performs so badly.
* The android section of StackOverflow is the lowest-quality section I've seen there. Many questions are answered by workaround and hacks ("copy/paste this"), by, what seem to be programming-beginners. This is sad, because I assume that many people learn Java via Android, and the style it teaches or rather requires is plain awful.
Most in-depth questions are not answered at all, because no-one has a clue, I asked a couple of things regarding performance and the rendering-pipeline on the mailing-list, but never get answers other than "your app is slow? make it simpler and read our beginner's howto."
Most of the answers I got, I got by reading the sourcecode [1].
* Performance is terrible. Most of the performance it get's is gained by faster CPUs. Just think about this: In most animations android will need time in every frame to recalculate the height of each letter of whatever text is on the screen. Because most aren't cached. And you can't tell Android which things will change.
At some point I was even thinking about reimplementing a layout manager myself, because of stuff like this.
[1] http://grepcode.com/file/repo1.maven.org/maven2/org.robolect...
It is my opinion that the main reason many Android apps lack quality compared to iOS is not Apple's review-process but the crippling SDK.
PS: If I google "Android SDK sucks" i get a lot of results. If I google "iOS SDK sucks" I mostly get the same results about Android.
* The IDE-Integration is meh: I do like Eclipse, but even the SDK-Manager for Android bugs around. The Layouting-Screen is so slow that everybody edits the XML directly anyway. This should get a bit better with Android Studio.
* The API seems to have been converted from a (bad) C-API. Loads and loads of useless inheritance. Whenever you instantiate an object in Android it brings along at least 15 methods that make no sense to call. It often doesn't even use generics. Happy casting. Why use enums when you can have Bitfields!
* Hardware acceleration is just a gamble. The doc here [0] says that you can enable it or disable it, except that sometimes that get's overridden and that you can enable and disable it partially as well, except that with some parts that doesn't work, especially in conditions that might apply sometimes. In practise I've seen that enabling acceleration made some parts of my applications smoother, and some slower. This behaviour changes with every minor version update on the tablets, of course. Way to go Android!
[0] https://developer.android.com/guide/topics/graphics/hardware...
* If you ask the Android API (on GalaxyTab 3) if an SD-Card ("external storage") is inserted, it will always return true, because the internal memory uses sd-card drivers and is always there. That is one of these thousands of gotchas that cost you 30 minutes of debugging.
* Android's standard Activity has methods for storing and restoring state, which is reasonable except that those are not persistent and should be only used when the Activity get's destroyed and recreated during turning of the display, for example. If you want persistent state, so that your App can be killed, you have to invent it yourself. At this point, I did the turning-thing with my own mechanism as well, because it was less cumbersome and less code-duplication.
* MultiTouch is just messing around with raw values. There are 10 pinch-zoom libraries out there, and none of them is perfect.
I could rant on endlessly, so I will some it up:
* The android SDK is 50% crap, by which I mean that if you are doing something slighty complex than you will find yourself outgrowing the extremely limited usecases that it's Views allow you and reimplement new ones yourself. I even had to modify the TextView because it performs so badly.
* The android section of StackOverflow is the lowest-quality section I've seen there. Many questions are answered by workaround and hacks ("copy/paste this"), by, what seem to be programming-beginners. This is sad, because I assume that many people learn Java via Android, and the style it teaches or rather requires is plain awful.
Most in-depth questions are not answered at all, because no-one has a clue, I asked a couple of things regarding performance and the rendering-pipeline on the mailing-list, but never get answers other than "your app is slow? make it simpler and read our beginner's howto."
Most of the answers I got, I got by reading the sourcecode [1].
* Performance is terrible. Most of the performance it get's is gained by faster CPUs. Just think about this: In most animations android will need time in every frame to recalculate the height of each letter of whatever text is on the screen. Because most aren't cached. And you can't tell Android which things will change.
At some point I was even thinking about reimplementing a layout manager myself, because of stuff like this.
[1] http://grepcode.com/file/repo1.maven.org/maven2/org.robolect...
It is my opinion that the main reason many Android apps lack quality compared to iOS is not Apple's review-process but the crippling SDK.
PS: If I google "Android SDK sucks" i get a lot of results. If I google "iOS SDK sucks" I mostly get the same results about Android.
I've never had a problem with the Activity state, but then I always shove data in an SQLite database anyway, which isn't hard. Is it really that troublesome to implement?
No, but it get's on my nerves that Android always says "Hey I have something in my API for that", and I after a (short or longer) while I realize it doesn't work as expected.
I most often just use Json (because with Google Gson, you can just serialize it into an object without boilerplate).
I most often just use Json (because with Google Gson, you can just serialize it into an object without boilerplate).
Activity state is persisted to disk (by the ActivityManager). That's why your process can be killed to free memory then woken up again when the user task switches back to it.
Never had much of a problem with it; just use reflection to see if certain API calls are available (kind of like seeing if a function is available within a DLL/so natively, not a problem)
I found it easy to start, and the documentation is quite extensive and easy to follow. This differs from my iOS experience, as xcode worked in a different way every new release, and the documentation on how to write things changed every time too, from what I could tell?
I found it easy to start, and the documentation is quite extensive and easy to follow. This differs from my iOS experience, as xcode worked in a different way every new release, and the documentation on how to write things changed every time too, from what I could tell?
Back end developer. I tried producing the most basic of Android apps, to see how to get set up (displayed a message when a button was pressed). I didn't find it especially difficult. It was easier then setting up a lot of the server side stuff that I am used to. One file I had to edit form what I remember. Does it get a lot more difficult if I do something more complex?
It's all nice, but one major caveat: "from any OSX environment".
Many developers prever Linux or Windows and don't see a point in buying Mac just to develop for iOS.
Why would companies switch to delivering Android apps first if their paying customers are mostly on iOS? This is a business decision and not a religious/"I like X platform and you should follow" decision.
I wonder if this statement is true. The reports I read about Android vs iOS revenue are US market only, or about e-commerce payments.
I'm an app developer and we make a lot of money developing apps that never end up in the app stores. They are in-company apps, both Android and iOS apps.
There is a very big app market that you will never see.
I'm an app developer and we make a lot of money developing apps that never end up in the app stores. They are in-company apps, both Android and iOS apps.
There is a very big app market that you will never see.
It is mostly 'has been repeated to death so it must be true' statement.
The reality, as always, is way more complicated. Outside of the US market, Android and iOS have very comparable high end marketshare.
Depending on your niche and your business model, the good choice for your app can vary from one opposite to another.
I thought OP was very clear about the serious business reasons they see for US startups to make an earlier and more serious commitment to Android:
1. You will need Android support eventually (to go global, because users demand it, etc.).
2. If you try to add Android support later, you'll screw it up in ways that will be difficult to fix (e.g. porting iOS apps too slavishly, not taking advantage of Android-specific platform benefits, building a corporate culture that treats Android as second-class, etc.), especially since most of the best Android talent will want nothing to do with you.
1. You will need Android support eventually (to go global, because users demand it, etc.).
2. If you try to add Android support later, you'll screw it up in ways that will be difficult to fix (e.g. porting iOS apps too slavishly, not taking advantage of Android-specific platform benefits, building a corporate culture that treats Android as second-class, etc.), especially since most of the best Android talent will want nothing to do with you.
Outside of games paying customers are increasingly irrelevant in the app store. It's becoming more and more difficult to make an app a profit generator in itself. These days mobile is more about reach for existing businesses. In this world user base counts.
It's also much, much easier to quickly iterate on Android without two-week delays between updates and a capricious review system.
It's also much, much easier to quickly iterate on Android without two-week delays between updates and a capricious review system.
I've seen this disproven many times. It may have been true early on but I don't think it still holds up.
Because outside US, the majority is on Android.
I second that. There seems to be a shortage of strong Android devs in the bay area... at least as compared to iOS developers. I know... we've been looking. It's not for an app though.. lower level hacking (involving NDK code) is required. Unfortunately a lack of stable Android API's has resulted in this situation. Not a lack of desire to push out an Android product before iOS. I, the CEO, am a long-time Android user and developed the first raw prototype of the technology on my own rooted Nexus 4.
BTW, where can I learn the Android programming language?
How about right on their site, to start?
http://developer.android.com/training/index.html
Edit to add that applications are usually developed in the Java programming language using the Android Software Development Kit, but other development tools are available.
http://developer.android.com/training/index.html
Edit to add that applications are usually developed in the Java programming language using the Android Software Development Kit, but other development tools are available.
Java, here's a starting point:
http://blog.teamtreehouse.com/java-basics-for-android-develo...
http://blog.teamtreehouse.com/java-basics-for-android-develo...
Udacity has a good video course taught by the Android team at Google. Ignore the stuff about $200/month tutor support. All the materials are free.
Edit: here's a link https://www.udacity.com/course/ud853
Edit: here's a link https://www.udacity.com/course/ud853
My experience has been that finding mobile developers in general is extremely difficult, primarily because there are so many opportunities for mobile developers to make a ton of money freelancing that they don't necessarily feel the desire to commit to working for a company. Recruiting is hard in general, but looking for a skill set that's so in demand makes it much harder.
Based on my experience another reason is simply that mobile development is not nearly as fun as anything else.
By far most of the time is being spent finding out why something doesn't work on a Model X which is sold only in South Korea and is kinda like a model sold here except with totally different chipset and different driver version. In the end you report a bug to the driver manufacturer and receive an answer "This has been fixed in our internal release" and it will never be supplied to the current phones in the market.
Sure there is a similar effect in other areas, but it's not nearly as bad as it is in mobile.
By far most of the time is being spent finding out why something doesn't work on a Model X which is sold only in South Korea and is kinda like a model sold here except with totally different chipset and different driver version. In the end you report a bug to the driver manufacturer and receive an answer "This has been fixed in our internal release" and it will never be supplied to the current phones in the market.
Sure there is a similar effect in other areas, but it's not nearly as bad as it is in mobile.
We tried to recruit an android developer in London, UK.
Absolutely no problem finding candidates but finding one that had done more than 'Android Programming for dummies' type stuff is painful. The majority of people have written a TODO list app and nothing else, not even any other programming of any sort and expect £60-70k. It does make me worry that comp sci education will end up being pushed down this route as it fulfills the UK government's sudden focus on 'programming'.
Also, having done a bit of Android programming, around the TODO type app level, it's a horrible tool chain. Even people we already have don't want to be paid to take training to do it.
Consequentially we contracted our Android front end out to an Indian company in the end who did a decent job for the money. No complaints.
Next iteration is Xamarin.
Absolutely no problem finding candidates but finding one that had done more than 'Android Programming for dummies' type stuff is painful. The majority of people have written a TODO list app and nothing else, not even any other programming of any sort and expect £60-70k. It does make me worry that comp sci education will end up being pushed down this route as it fulfills the UK government's sudden focus on 'programming'.
Also, having done a bit of Android programming, around the TODO type app level, it's a horrible tool chain. Even people we already have don't want to be paid to take training to do it.
Consequentially we contracted our Android front end out to an Indian company in the end who did a decent job for the money. No complaints.
Next iteration is Xamarin.
I put out a job advert on JobServe Monday for an Android dev in London.
In 24 hours I got 12 CV's (we're skipping recruiters), reduced down to 3 we actually want to see.
I reckon we'll have a shortlist of 10 applicants, cut down to 3-4 interviews on Friday.
I'm an Android contractor myself, and it's true, there's a lot of chaff around.
What's your recruitment process?
In 24 hours I got 12 CV's (we're skipping recruiters), reduced down to 3 we actually want to see.
I reckon we'll have a shortlist of 10 applicants, cut down to 3-4 interviews on Friday.
I'm an Android contractor myself, and it's true, there's a lot of chaff around.
What's your recruitment process?
Our recruitment process is basically the same as yours.
It is hard to find a "good" developer - on any system or programming language.
If I could use Go on Android (with no major headaches) and a simple way to describe the interfaces, I would be very tempted to switch to being an Android programmer.
But I just can't bear to return to Java, I'm not sure I ever had job satisfaction working with Java.
But I just can't bear to return to Java, I'm not sure I ever had job satisfaction working with Java.
As opposed to Objective-C, or C++?
Languages for writing client side apps have always sucked. They sucked in the 90's when targeting Windows (ok Delphi wasn't too bad), they sucked in the 2000's when targeting MacOS X and they suck now when targeting mobile. Of all the languages that mainstream operating systems have used, Java is by far the least worst. Especially because you can use any JVM-compatible language and are not really restricted to Java. For example Kotlin is looking like it's going to be pretty nice, pretty soon.
Go would be nowhere near a useful upgrade on the status quo.
Languages for writing client side apps have always sucked. They sucked in the 90's when targeting Windows (ok Delphi wasn't too bad), they sucked in the 2000's when targeting MacOS X and they suck now when targeting mobile. Of all the languages that mainstream operating systems have used, Java is by far the least worst. Especially because you can use any JVM-compatible language and are not really restricted to Java. For example Kotlin is looking like it's going to be pretty nice, pretty soon.
Go would be nowhere near a useful upgrade on the status quo.
Sucks writing JavaScript browser based apps as well in my opinion.
I wonder, would Go be more suited for Android or Rust? Obviously Google would much prefer to use Go since they're developing it and could optimize it however they want for Android.
On the other hand, Rust seems higher performance and might be more suited for apps, but Google doesn't have much control over it. However they don't have control over Java either, and they could create a "fork" of Rust if needed, just like they did with Java/Dalvik.
On the other hand, Rust seems higher performance and might be more suited for apps, but Google doesn't have much control over it. However they don't have control over Java either, and they could create a "fork" of Rust if needed, just like they did with Java/Dalvik.
I've become a Go convert and love coding in it, but for mobile devices with limited resources that are often used for gaming, Rust seems like it'd get more mileage because of its slightly more hands on approach to memory.
I program in Android/Java for my day job but use Go for my own stuff, and love Go and I'm pretty meh on Java. So I would love to see this (and to some degree work in this area is already happening in that you can technically run Go code on Android today and it will soon be suitable for things like OpenGL-based games).
When it comes to traditional apps, though I'm not sure how the existing Java APIs could be mapped to Go in a way that made any sense at all (I mean... technically you could do it via bridges to and from cgo<->ndk, but having it make sense in Go and be reasonably future maintainable seems like it would be a huge undertaking, even for Google). Seems more likely that something like Go+go-qml+Qt would be more practical, though I have yet to play around with the Android port of Qt enough to see if it is reasonably "native" feeling.
When it comes to traditional apps, though I'm not sure how the existing Java APIs could be mapped to Go in a way that made any sense at all (I mean... technically you could do it via bridges to and from cgo<->ndk, but having it make sense in Go and be reasonably future maintainable seems like it would be a huge undertaking, even for Google). Seems more likely that something like Go+go-qml+Qt would be more practical, though I have yet to play around with the Android port of Qt enough to see if it is reasonably "native" feeling.
Scala runs on Android and is the most satisfying language I've ever worked in. (Admittedly you still have to call some pretty terrible APIs, but those are the platform APIs - that part would be the same in Go or anything else).
I have this almost dream-like hope that Google will encapsulate all of the Android APIs in a proxy layer in Go with much nicer APIs.
That we'll be able to have a cleaner interface to the platform, and have access to a better toolchain and programming environment.
I doubt it will happen, but one can hope.
That we'll be able to have a cleaner interface to the platform, and have access to a better toolchain and programming environment.
I doubt it will happen, but one can hope.
I think the Android team will hardly consider supporting another Java 1.0-like language progress.
The problem with Java was never the language, but the 'enterprise' platforms, which suffocated it. Within Android, Java works much more as it was designed and is dare I say it, fun to use.
According to the Android team at Google IO, the official language is Java.
Now management might change this point of view, but that was the official statement.
Just search for the Android devs fireside at Google IO 2014.
Now management might change this point of view, but that was the official statement.
Just search for the Android devs fireside at Google IO 2014.
I had no idea finding Android Developers was considered difficult. I started developing Apps with Android and always found it to be very straightforward. Java is much easier to understand than objective-c.
I've also never understood why Android is hated on as far as profits go. Sure nobody wants to buy anything, but (in my experience) ad eCPMs are comparable.
I've also never understood why Android is hated on as far as profits go. Sure nobody wants to buy anything, but (in my experience) ad eCPMs are comparable.
I agree with cliveowen (you da bomb in Children of Men, yo!) in that the language isn't everything. But for different reasons.
The Android documentation is spectacularly good, IMO, though admittedly it is more reference focused than tutorial focused (which works for me, YMMV). Eclipse sucks but Android Studio is pretty nice, and in either case you don't need to use an IDE if you don't want to. I use Sublime Text 2 and command-line builds most of the time, using Android Studio only when I want to do on-device visual debugging.
The Java thing is a bit more true, the language can feel somewhat painful at times, especially since it is frozen in time at Java 6 for the most part, with a few little bits of Java 7 thrown in at random with little to no clear guidance from Google on where it is headed post-Oracle lawsuit.
Also there are places where the OS APIs are a bit too Java-esque in terms of being overly abstracted without a compelling reason why. Also the whole activity/fragment lifecycle and the way services work is a bit weird at first for people used to writing traditional apps, but any competent developer will learn to live with it pretty quickly. It still tends to be a sticking issue anyway because of the fact that a lot of designers (who are mostly iOS-centric, as the original article alludes to) don't really "get it" and thus design in ways that don't fit the OS app lifecycle (and don't get me started on their "pixel perfect" designs).
All that aside I had no idea Android Developers were seen as hard to find. Maybe I need a raise!
The Android documentation is spectacularly good, IMO, though admittedly it is more reference focused than tutorial focused (which works for me, YMMV). Eclipse sucks but Android Studio is pretty nice, and in either case you don't need to use an IDE if you don't want to. I use Sublime Text 2 and command-line builds most of the time, using Android Studio only when I want to do on-device visual debugging.
The Java thing is a bit more true, the language can feel somewhat painful at times, especially since it is frozen in time at Java 6 for the most part, with a few little bits of Java 7 thrown in at random with little to no clear guidance from Google on where it is headed post-Oracle lawsuit.
Also there are places where the OS APIs are a bit too Java-esque in terms of being overly abstracted without a compelling reason why. Also the whole activity/fragment lifecycle and the way services work is a bit weird at first for people used to writing traditional apps, but any competent developer will learn to live with it pretty quickly. It still tends to be a sticking issue anyway because of the fact that a lot of designers (who are mostly iOS-centric, as the original article alludes to) don't really "get it" and thus design in ways that don't fit the OS app lifecycle (and don't get me started on their "pixel perfect" designs).
All that aside I had no idea Android Developers were seen as hard to find. Maybe I need a raise!
The language isn't everything, in fact, it's the least important part of the package. Android has horrible online documentation, iOS has stacks of nicely formatted PDFs and a great online reference. Android tools (Eclipse/Android Studio) are simply horrible, while XCode and related tools are really great. Add to this the performance hit you have from having your code run on a vm and the bloat that comes from using Java itself, and you have yet another reason as to why Android developers are few and far between.
I'll take Android Studio over Xcode any day of the week. I've been working with the Xcode 6 GM for the last few days and it crashes hard on me at least once an hour. I think Android Studio, despite being in beta status, has crashed on me once in the entire time I've been using it. And Xcode's refactoring and code management tools are a joke compared to Android Studio's.
And I'll take Android's layout schemes over managing the house of cards that is auto layout in Interface Builder. If you're lucky you can get auto layout to do what you want with a ton of pointing and clicking but good luck maintaining that mess when you come back to it a few weeks from now. WYSIWYG tools have no place in a professional developer's toolkit, IMO. Leave that stuff to the designers.
Merging xibs and Xcode project files is another hell lying in wait for anybody doing Mac or iOS development on a team.
I'll grant you that the iOS documentation is generally better and certainly the APIs for dealing with multimedia on a lower level are far better on iOS. But for the typical listview-hitting-a-json-api kind of app life is generally easier in Android, in my experience.
And I'll take Android's layout schemes over managing the house of cards that is auto layout in Interface Builder. If you're lucky you can get auto layout to do what you want with a ton of pointing and clicking but good luck maintaining that mess when you come back to it a few weeks from now. WYSIWYG tools have no place in a professional developer's toolkit, IMO. Leave that stuff to the designers.
Merging xibs and Xcode project files is another hell lying in wait for anybody doing Mac or iOS development on a team.
I'll grant you that the iOS documentation is generally better and certainly the APIs for dealing with multimedia on a lower level are far better on iOS. But for the typical listview-hitting-a-json-api kind of app life is generally easier in Android, in my experience.
I tend to believe this will change in the next couple of years.
With Android Wear the whole ecosystem will attract new talent. And the new Material Design seems to be well accepted from designers.
So the apps quality should be better and company will be willing to have a great product in both platforms.
With Android Wear the whole ecosystem will attract new talent. And the new Material Design seems to be well accepted from designers.
So the apps quality should be better and company will be willing to have a great product in both platforms.
As an Android developer I have observed that the Android market is widespread in certain countries and is marginally less popular in some. But anyhow, when people ask me to port apps to look like iOS, it aches.
As the higher-end Android market matures, with the release of L, there will be an increased market for paid apps. So it will become more attractive to develop Android first, having a paid version, and an ad-supported one.
Because the Android SDK sucks.
This blog completely misses the mark.
First, android has had a culture of "free, ad-sponsored" applications, whereas iOS apps have always been about paying for the stuff (not surprising if you understand a bit of apple and google businesses).
As a consequence (or because of the fact) iOS users are more likely to spend money than android users. This means that if you're doing a mobile shopping app, you expect iOS users to be much more likely to buy your products. So it's not just about market share, it's about market share times purchasing power.
That's for the market, now on the other end, about developers, saying "android" has a large market share, is not relevant. You want to speak about android market share per OS/api version. I did start developing on android, but the minute you click on the "create new project" you need to ask yourself how many android users you want to ignore (in double digit percentages). If you want to have the maximum market share you need to develop with 3 years old apis, and you'll probably frustrate users that have brand new devices. In my experience, that's where project owner decide to postpone the decision to start the android version of their product.
Then, if you make it up to this point, you need to decide what screen size you want to support and how many different version of your UI you will need to design. Note that you still haven't started a single line of code yet !
Finally, you start coding and realize the toolchain sucks pretty much. Xcode is obviously much better than anything on the market and i won't even start talking about the simulator (which is important as soon as you need to test on different screen sizes).
All in all, most of the time android feels like developing for a second grade market, having second grade devices, with second grade tools, on 3 years old apis. No wonder developers don't rush for it..
First, android has had a culture of "free, ad-sponsored" applications, whereas iOS apps have always been about paying for the stuff (not surprising if you understand a bit of apple and google businesses).
As a consequence (or because of the fact) iOS users are more likely to spend money than android users. This means that if you're doing a mobile shopping app, you expect iOS users to be much more likely to buy your products. So it's not just about market share, it's about market share times purchasing power.
That's for the market, now on the other end, about developers, saying "android" has a large market share, is not relevant. You want to speak about android market share per OS/api version. I did start developing on android, but the minute you click on the "create new project" you need to ask yourself how many android users you want to ignore (in double digit percentages). If you want to have the maximum market share you need to develop with 3 years old apis, and you'll probably frustrate users that have brand new devices. In my experience, that's where project owner decide to postpone the decision to start the android version of their product.
Then, if you make it up to this point, you need to decide what screen size you want to support and how many different version of your UI you will need to design. Note that you still haven't started a single line of code yet !
Finally, you start coding and realize the toolchain sucks pretty much. Xcode is obviously much better than anything on the market and i won't even start talking about the simulator (which is important as soon as you need to test on different screen sizes).
All in all, most of the time android feels like developing for a second grade market, having second grade devices, with second grade tools, on 3 years old apis. No wonder developers don't rush for it..
I don't think startups or small companies should be looking specifically for "Android developers", or "X developers" for any language or platform value of X. Instead, they should be looking for generalist developers who can learn whatever platform they need to work on.
They should, but look at most job ads. Then again, I had an initial interview with a guy the other day. I re-read the job description, and I wasn't strong in many of the technologies listed, though I have a very generalist CV, so it seemed to appeal to him. The thing is, I am often put off allying for jobs like that.
If there's a shortage of Android developers, find a good developer with no Android experience and assign him an Android project. It'll take him less time to learn than it will take you to find your dream candidate purple squirrel.
Plug in an iPhone, and (after jumping through the byzantine code-signing system) you'll be able to deploy development code to it (from an OSX environment). If your app runs on one iPhone, it probably runs well on another, barring some screen geometry concerns.
Plug in an Android device, and you might need to search around to find a manufacturer-specific toolset, and/or navigate secret menus to enable debugging (like "click this menu item that doesn't look like a button seven times"). You might also have to worry about ancient devices that can't be updated to a modern Android version, and have egregious platform bugs. Comparatively, it's a mess.