Should I Learn To Program iOS Or Android Devices?
HW_Hack writes "In my early career in the '90s I had a hardware tech degree, but also a strong interest in software. I completed software courses in assembly, Pascal, HTML, and C as I prepped for a CS degree. I then got my chance to do hardware design for a major US firm and went that direction for a good 18-year career. I now work in a good sized school district doing IT support work at a large high school. I plan to revive my programming skills this winter so I can write apps for the flood of mobile devices. I am very much platform / OS agnostic and I support on any one day OS X, XP, Win 7, Linux servers, and now iOS as we pilot iPads in our school. My question focuses on three topics: Which programming environment (iOS or Android) is easier to jump into from a technical perspective / number of languages needed to master? Which one has a better SDK ecosystem of documentation, programmer support, and developer community(s)? Where is the market and the money going? I do not expect to get rich doing this, but with my insights into K12 needs I hope I can write effective apps for that market."
you should.
"You'll get nothing, and you'll like it!"
iPhone is too proprietary it is a dead end.
If you don't already have a Mac, iOS requires Apple hardware for development. You also need to learn objective-C which doesn't get much play outside of a Mac environment. None of that is bad, just a hurdle.
Personally, while iOS is currently ahead of Android (user base, # of devs, apps, etc) I think before long it's going to start playing catch up to Android. Android has got a lot of momentum.
Working with both systems will give you a deeper understanding of each, as well as allowing you to sell to a larger customer base, should that be something that appeals to you.
Chu vi parolas Vikipedion?
You should never, EVER think platform, then app. Think audience, application, and THEN learn what you need.
Your school district is using iPads? Then learn iOS. You have an android phone at home, or have java experience? Learn Android. You want to just make something work? Get the Android, iOS, and WebOS SDKs, and test like @#% so your mobile phone works everywhere. (Heck, get Blackberry and windows mobile if you can.)
You definitely should. One of the biggest benefits of building apps for mobile phones is that you don't need to market your app - the app stores are excellent distribution channels and your app isn't stuck out there waiting to be discovered by the masses for the next 20 years. Major indie mac developers have made the switch to the iPhone and now more actively focus on iOS devices than they do on the Mac. This is a general trend. Smartphones' potential is still being discovered. Try to profit from the gold rush while you can.
Why not aim to learn both iOS and Android? You'll please more people and incur the wrath of less. If you pick just one, you have to deal with the tens of percents that can't run your apps, which is difficult.
Yes, it will take more time and effort to learn to environments, but not much more. Most of your time will be spent designing and testing the apps, not implementing code.
Yes. You should hedge your bets and learn both. The smartphone wars are far from over, and most smartphone content producers are releasing for, at the very least, both iOS and Android. Some also simultaneously release for Blackberry and Windows Mobile as well.
Each platform has its relative strengths and weaknesses. Writing code on Android pretty much means learning Java; similarly, writing code on iOS pretty much means learning Objective C. Neither language is likely to become obsolete very soon. The startup costs for writing code on Android are a bit lower; you don't need to buy anything to write Android apps. If you expect to write iOS apps, you need a Mac and you need XCode. On Android, you need Eclipse and the Android Eclipse SDK.
But, like I said, I wouldn't learn just one.
My blog
Except one 99c app like angry birds netted the developers more than the gross of the entire android marketplace..
Choose sides, and you will surely lose at the end of the day. Apple's iDominance will die out. Android will fork to the point of there being a new distro daily. The best way to remain relevant is to develop the core ideas behind your application THEN learn how to implement them using the tools at hand. Consumers care about what works. Lets face it, what works today might not work tomorrow.
Apple is making exactly the same mistakes they made in the early desktop market: they're refusing to license their software to more nimble hardware manufacturers.
Here's a clue: which of the early makers of desktop computers survived the Wintel monoculture of the late 80s and 90s and is still an influential, if minority, platform today? Hint - it begins with "A". What happened to CP/M and GEM, MSX and Unix which were licensed to multiple manufacturers?
Anyway, Apple have already tried that. Twice, actually: Apple with "classic" Mac OS and Steve Jobs with NeXTStep before he returned to Apple. That went well, didn't it?
What has worked spectacularly since the release of the iMac in 1998 is tying the software to premium-priced "designer label" hardware (but not quite as premium-priced as the old NeXT cubes). But you're right - Apple should drop their winning formula and go with the one that has already been proven to fail.
The fly in the ointment is that "more nimble hardware manufacturers" don't care whether they ship machines with Windows or MacOS as long as they make their money (usually by selling upgrades, peripherals, extended warranties and finance rather than the computers themselves). They'll be more than happy to attract custom from existing Apple converts, cannibalizing Apple's sales, Windows users to switch. So you've got guaranteed cannibalization of Apple's existing sales but no guarantee whatsoever that the clone-makers and their resellers will aggressively promote MacOS to Windows users. Look at Dell and Asus's feeble efforts to sell Linux-based machines...
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
I hear people on /. saying this all the time and I simply don't think it's true. I've been coding post-university for > 14 years so I consider myself a "senior developer". I used to know c way back in the day, and have done some Java coding and a bit of C#, but Objective C still to me isn't "a few late nights" simple.
.NET or iOS development, are the libraries and everything that goes beyond the bare syntax. Understanding what method to use where takes a LOT more than just a few late nights. Additionally, every language brings with it its own pitfalls, security issues, etc., that a newbie developer is just not going to pick up right away.
Sure, a few late nights will let you pick up the syntax, but the real value of a platform, whether it's JEE,
Sure, after a couple weeks of hard studying you can start to program in a new language. I'm not debating that. Additionally, some languages and environments are going to be easier than others. But the vast majority of developers are not going to be even nearly up to speed on a new language without having a severe impact on the timeline of a project.
www.clarke.ca
There's something stinky about flash on mobiles. They tried to make it the next big mobile platform before (aka Flashlite) and it flopped.
Three big flash developers Nitrome, Semi Secret Software and Astro Ape Studios, are rewriting their games for iPhone natively rather than using CS5, because flash is too slow.
http://www.gamasutra.com/view/news/30368/InDepth_iOS_Flash_Devs_Cautiously_Optimistic_Of_Apples_New_Tools_Policy.php
"My personal opinion is that Objective C is pretty tedious and annoying. The syntax is ugly and non-intuitive. Again, this is my personal opinion. But having done years of C, C++, C#, I find it bizarre that Objective C syntax is non-obvious. Not that it is particularly complex, but if you know C++, Java and C# seem pretty obvious, whereas Objective C is just very different in syntax."
How is it not obvious? Your complaint seems to be that it is different, while admittedly not complex. Different != not obvious.
Objective C is an old language, and when it came out, it was a possible competitor to the still pretty shiny and new C++. It's an old enough language, that when Java was written, Java took a lot of cues from Obj-C. Apple didn't go out of their way to make a different language because back when Obj-C was created there wasn't a standard syntax for OOP programming.
Obj-C is dead simple, and honestly, not confusing if you take the time to learn it. However, it seems many people these days are afraid of languages that look different and immediately write it off, when it's pretty gosh darn elegant. Every time I ask people why they dislike Obj-C, they can't get any further than the brackets. It just amazes me how many people write off iOS because they think Obj-C is hard (which, alone, is mind numbing, considering the biggest draw of OS X on the desktop for software engineers is how easy Obj-C is compared to C++).
If the ability to learn is dead in software engineering, we're all in a lot of trouble.