Slashdot Mirror
Ask Slashdot: Swift Or Objective-C As New iOS Developer's 1st Language?
macs4all (973270) writes "I am an experienced C and Assembler Embedded Developer who is contemplating for the first time beginning an iOS App Project. Although I am well-versed in C, I have thus-far avoided C++, C# and Java, and have only briefly dabbled in Obj-C. Now that there are two possibilities for doing iOS Development, which would you suggest that I learn, at least at first? And is Swift even far-enough along to use as the basis for an entire app's development?
My goal is the fastest and easiest way to market for this project; not to start a career as a mobile developer. Another thing that might influence the decision: If/when I decide to port my iOS App to Android (and/or Windows Phone), would either of the above be an easier port; or are, for example, Dalvick and the Android APIs different enough from Swift/Obj-C and CocoaTouch that any 'port' is essentially a re-write?"
The one really good thing that has come out of the Apple fashion parade is objective C. Jobs' legacy isn't all the shiny fashion crap, it is this powerful and really rather beautiful language. This is from someone usually branded a Microsoft shill. If you want to write iOS/OSX take advantage of the native tools.
"Our opponent is an alien starship packed with atomic bombs," I said. "we have a protractor"
Learning the language itself is not that difficult. Learning the SDK and how things work in Cocoa-land is the important part.
For example, if you need to display a list of of items in a list, an UITableView will work the same regardless of your language choice. You will still need to understand the idiosyncrasies of working with UITableViewDelegate and UITableViewDataSource.
I would stick to Objective-C for the moment as there are more learning resources online.
Why not write it in C and ommit Swift/Objective-C?
Perhaps easier to port even, but honestly, if you want to use the Frameworks, try Swift.
There is a reason we have a flodded AppStore market with iOS Apps ... Apples tools are 30 years old, granted. But the rest of the industry simply did not catch up since 35 years.
Using a text editor to write code for a device like an iOS device, that simply displays the weather or a stock price is so ... 1960s?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I would tend to agree with this. If you intend to develop cross-platform, do yourself a favor and design your applications from the ground up with cross-platform in mind. Anything else and you're going to spend a lot of time rewriting code. That's just the reality of the situation.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
There are way more tutorials and examples for Objective-C than Swift.
I'm already getting barraged by headhunters asking for five years of Swift minimum for contracts now...
If you've spent this long avoiding modern languages why start now? If you're not interested in object oriented design you're just going to spend your whole time cussing at the frameworks. Just hire a contractor.
I was very tempted by Xamarin but put off by the $$$. Is it as good as claimed?
"Our opponent is an alien starship packed with atomic bombs," I said. "we have a protractor"
If you're just starting out you're going to be learning a lot, reading blogs, reading stackoverflow, and there is far more Obj-C out there than Swift now. So you since you want fast, not best, Obj-C is the correct choice for you. Not necessarily for everybody, but for you.
Taken at face value, requiring more experience in a technology than the time it has existed publicly would mean they're trying to poach from inside Apple. Perhaps they're trying to satisfy the legal requirements to ensure that nobody in your country is suitable before they can import immigrant workers.
since you are already a C programmer and are talking about maybe moving to android at a future time. i would write as much as possible in C and just bind to the UI with java/objc/swift.
take advantage of what you know. build wrappers around the java/objc code you will need to you can easily transport that to whatever platform you are on as long as it binds with C.
"Dalvick and the Android APIs different enough from Swift/Obj-C and CocoaTouch that any 'port' is essentially a re-write"
Without knowing what kind of apps you're going to write, it's difficult to know if this is feasible, but if you write as much as possible in portable C code, with a layer of Obj-C (iOS) or Java (Android) on top of it, you might be able to maintain a lot of your functionality in a single code base.
I'm also about to learn iOS programming. If I write an app in Swift, what is the oldest version of iOS that it will run on?
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Don't listen to these ass clowns saying "Go with Obj-C". If they had any clue they would know that introducing Swift was the first step towards obsoleting Obj-C.
Assuming you're not learning this language to obsolete yourself, then you definitely want to stick with Swift.
I do all native for my development. But, if you design your business and storage layers correctly, it is all but a few "find and replaces" to convert ObjC to Java. Then all you have to worry about is your UI. Apps that took months to sort out business logic have been ported (business layer) to the other platform in a day.
This is fading away. The better solution is something like PhoneGap. This lets you build mobile cross platforms apps in HTML/JavaScript.
This is fading away. The better solution is something like PhoneGap. This lets you build mobile cross platforms apps in HTML/JavaScript.
Since Phonegap got bought by Adobe you are better off with the open source port of PhoneGap Apache Cordova.
Swift is still a very immature language, with lots of bugs in the compiler, rough support in the debugger and IDE, and the syntax isn't even set in stone yet (don't expect the syntax to settle down before Swift 2.0, probably some time in late 2015 if not 2016). There are a number of things that you still can't do in Swift (e.g. providing a callback function for APIs that expect a C function pointer), and you'll just spend a lot more time hitting your head against walls than writing working code. On top of this there are many more resources available for learning Objective-C than there are for Swift, and the pitfalls and corner cases are better understood for Objective-C than they are for Swift. As a bonus most of your instincts honed on C will carry over to Objective-C (while they are likely to lead you astray in Swift).
Swift is a really exciting language, and fun to play around with, but it's not ready for production work (yet). It will get there, but in the mean time you should stick with the established tools, which means Objective-C for iOS and Mac OS X app development.
just a ghost in the machine.
A lot of comments here saying how Obj-C is "ugly", and so forth. I wonder how many commenters are actually using it to any great extent, on a day-to-day basis, rather than have just looked at it out of curiosity for five minutes?
If you want to write an app now, Obj-C is the only sensible choice. Swift looks promising, but it's not ready. It's changing almost weekly and at the moment it's actually introducing bugs into the frameworks where none exist in Obj-C. If you want to live on the bleeding edge, go for Swift, but if you want to write an app, get it working and ship it out of the door, Obj-C is the only game in town today.
Once you get into Obj-C, it's a much more elegant language than it's usually given credit for anyway. Sure, it's old, but the runtime and compiler work put in in recent years makes up for many of its older roots. Manual memory management is not required, there is a dot syntax for properties and so on, so square brackets are not the only way to call getter/setter methods. As a pure superset of C99, it's easy for a C programmer to learn. It's also a small language. The real power lies in the frameworks, and that will take you far longer to learn than the language. Don't be put off by the superficial "ugliness" of Obj-C code, it isn't relevant. It's expressive and straightforward, and as a former C++ programmer, I also found it dramatically more productive when I first adopted it over a decade ago. It is possible to become fond of it, believe it or not. Whether the same eventually becomes true of Swift, only time will tell. Ignore the nay-sayers who have probably never actually used Obj-C in anger in their lives.
I want all devices to end up running HTML5 apps or some kind of compatible format. I'm working on a mobile game using CocoonJS. Phonegap is also pretty good, especially now that modern HTML5 canvas are rendering using webgl.
Although I am well-versed in C, I have thus-far avoided C++, C# and Java, and have only briefly dabbled in Obj-C. Now that there are two possibilities for doing iOS Development, which would you suggest that I learn, at least at first? And is Swift even far-enough along to use as the basis for an entire app's development? My goal is the fastest and easiest way to market for this project; not to start a career as a mobile developer.
This portends badly. You don't know enough about any of the languages currently in use on any platform, and your goal is "the fastest and easiest way to market?" The obvious solution is to give the job to someone else who knows what they're doing.
So, since that's not what's happening here (and any sane - and most insane - business would go that route), this is a case of "I've got a cool idea for a mobile app but I don't know anything about the platforms or how to code in the languages behind them, and I don't want to give any details about what its' performance and resource requirements are because someone might steal the idea." This is further borne out here:
If/when I decide to port my iOS App to Android (and/or Windows Phone), would either of the above be an easier port; or are, for example, Dalvick and the Android APIs different enough from Swift/Obj-C and CocoaTouch that any 'port' is essentially a re-write?
Why not just download the dev kits for Android and iOS and ask yourself if you can even understand the development documentation, the APIs, etc? The problem right now is yo don't even know enough to ask the right questions: you don't want to commit to something (objc vs swift) this early in your learning curve and then find out you made the wrong choice because you didn't take a month to pick up some basics.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Adobe flex. Cross platform, works on everything.
Your choice then... to be good on the platforms you write for, or evenly craptastic for everyone. Cross platform equals lowest common denominator. If you want to put out apps that people will call good... do the extra mile and code for that platform.
Have you written ANY code for iOS or OS X? How old are LLVM based compilers? How old are the US Tools available in Xcode 6?
I do not understand how your post was marked as insightful. If you want to write an iOS app you must use swift or Objective-C?
.
So, as the parent suggests, start from the beginning targeting multi-platform in your design stages. A small amount of extra effort in the beginning will save you a large amount of work down the road. And your apps will be less buggy.
It is very good that you are coming from a C and assembly background. Its always important to understand what any compilers or interpreted language do behind the scenes. My experience was Pascal => assembly => Basic => ObjectPascal => C => C++ => Java => Objective C => Python => Ruby => Perl; a lot of them overlapping.
The first thing I would suggest is to get up to speed on object-oriented programming concepts.
I would say that you should be familiar C++, Objective-C, Objective-C++ (can come in very hand when using c++ and Objective-C in the same project).
Swift seems to be the future for iOS and OS X and looks to be a very interesting language with some really great Xcode tools behind it. Think Playgrounds.
Its always good to know JVM based languages Java, Scala, etc... Obviously if you are going to do any Android you will have to know Java.
My prediction: Swift will be the most important language for iOS, OS X five years from now. It is usable today. Keep in mind that Swift is a language that is quickly evolving based on developer input, so there is going to be some overhead in keeping up with the changes.
Xcode is free, but it is worth the 99.00 dev program just to watch the last few years WWDC videos. Its pretty wild what you can do with Xcode these days.
Good luck with your iOS adventure. It can be a lot of fun!
My current company did most of their work in Objective-C. It's a bear. One of the worst parts is all the retain and release calls. They're used for memory management, and god help you if you forget because there's no obvious way to see the problem. Our current company is ditching Objective-C entirely and moving to QT and C++. My boss, who wrote all the Objective-C stuff, says that Objective-C has become a mess over the past 5-10 years as Apple is promoting Objective-C for both iOS (iPhone, iPad) and OSX (desktop) applications, which has caused all kinds of problems and bloat. I've had all kinds of problems with Objective-C, so I don't doubt his characterization of it.
Write the core of your application in C/C++, or asm if you like :-), however use objective-c for platform specific calls on iOS. Objective-C is the native language of the Cocoa API. Don't fight the platform. Use whatever is the native language for the platform, objective-c for iOS, java for Android, etc.
Keep the core C code separate from the platform specific code. Write the core code as if it will be a library, define an interface to its functionality. Have the platform specific code, like your UI code, use this interface. Depending on the language you do the platform specific stuff in you may in fact need to put this core code in a library.
Objective C is more convenient than Swift since it integrates much more easily with C code. Mix objective-c files and C/C++ files in your project and they all just compile down to native code into a single binary. You don't need a library, although a library is a nice way to organize things.
Now that you have the core code in this nice portable "library" you can move it to Android or whatever platform you might be interested in.
For UI code I tend to just do a native implementation on each platform, use platform specific technologies, etc. Basically give the user the look and functionality they expect. To fail to do so may result in poorer reviews.
Swift is interesting, but personally its a little too new for my tastes. I don't want to be an early adopter of a development language. Objective-c is the native API for Cocoa, I'll stick with that until the bugs/quirks of Swift are worked out and examples of how to do things are plentiful like they are in objective-c.
I was very tempted by Xamarin but put off by the $$$. Is it as good as claimed?
My company got a few licenses for a project recently since our client wanted it done in C#.
From version 3 it has the ability to write cross-platform GUI code. The other option being to write Android/iOS GUI code seperately through C# mappings of their native apis. I wasn't responsible for trying the x-plat GUI part out but I do know that ultimately we were unimpressed and elected not to use it, instead developing for Android and later porting the GUI code to iOS. From memory it was just too limited.
It may be acceptable for routine business apps but then why not just develop them as a web-service and avoid the Apple-tax and pain of dealing with Apple's provisioning cluster fuck. (Seriously why do so many company's want to use iPads for internal apps? Distributing apps on them is a major pita)
The other pain point for us was third party libraries. In theory you can import jars and it will automatically map them to C#. In practice that doesn't work. We had to support mobile scanners with a laughably bad and somewhat broken API and broken default apps. I ended up writing an Android service to deal with all that crap. When it is time to add iOS support we'll have to write an iOS specific layer.. (iOS bluetooth access is too limited to directly access the scannner so that will probably involve treating it as a keyboard and capturing keystrokes...)
IMO. the real value is for Windows shops that want to utilize their existing investment in tooling/developer training, reuse existing core-logic code and/or write their core logic once in C#. For places like that it could be worth the several thousand dollars per developer.
Assembler is the tool. Assembly is the language. You could admit you are the pretender, with hopes and dreams of one day knowing what it is you ... pretend to know - Pretender.
No Poser I.
Not to brag, but I have been an Embedded Dev. For over three decades. I have written tens and tens of thousands of lines of Assembly Language for everything from 8 bit 6502 to 32 bit ARM9 Cortex, and everything in between. Various MCUs and CPUs from Microchip, Mot., Zilog, Intel, ST, Atmel, to name but a few. I have personally rewritten 6502 assemblers to cross-assemble for 6809 and 8051. I am experienced in many, many different IDEs, debuggers, ICEs, etc. My specialty is real-time measurement and control systems, with or without RTOSes.
But sometimes, just like the many Nuclear Physicists that still occasionally slip-up and say "Nuke-U-Ler", I occasionally flip the terms "Assembler" and "Assembly".
So, Mr. terminology-Nazi: You are hereby cordially invited to Bite Me.
No no no no no.
Cross platform GUI application development has never, and will never work correctly. People buy different platforms because they behave differently, and because they like the behaviour of one platform over the other. Using a 3rd party hack job of a "cross platform" library only gets you into a position where you're making everyone unhappy by making it behave shiftily (compared to their platform) on all devices equally.
I would stick to Objective-C for the moment as there are more learning resources online.
I agree with this. As a new user, for the moment, Objective-C is likely the way to go due to their being more documentation out there. Swift documentation though is rapidly increasing.
As a developer in both Swift and Objective-C, the primary advantage of Swift is it is slightly faster to do many things as it doesn't require strict classing of variables, so you find yourself not having to spend as many lines of code swapping strings to integers as that kind of thing and end up with slightly more readable code.
However, these advantages likely aren't as important for a new user as having a wealth of documentation to learn from.
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
apple's proprietrary[sic]?languages
So, you, the Great Programmer, thinks that Objective-C is "proprietrary"?
This proves just how little you know...
FYI, Dalvik (no "c") and its successor, ART (Android RunTime) are a version of Java, so no matter what you do, you'll have to rewrite for Java. There is the option of writing "native" code, but you'll need to compile for ARM, MIPS, and Intel if you want the widest compatibility for your apps.
Hey, my article submission said "Dalvik". Slashdot editors put in the unwanted "c".
Swift isn't finished. From what I've read, they expect to make syntax-incompatible changes.
That was before Swift 1.0 introduced with the final XCode 6 and iOS8. They aren't breaking syntax anymore...
And even when they were, it was usually pretty minor things to fix.
I'd imagine it will eventually (over a couple of decades)
HA HA HA HA HA HA HA
You don't know Apple, or iOS developers. Dominant over ObjC within two years (and by the end of next year that prediction will probably seem ridiculously conservative).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
There's a very strong case to be made for Swift first going forward, and not many seem to be making it or understand the iOS dev world at all.
I speak as someone who has been developing iOS applications since somewhat before the release of the iOS SDK way back when.
I don't think anyone outside those paying the closest attention to iOS development realize how rapidly Swift is being adopted, especially by those who have been doing Objective-C the longest.
That's the core aspect of this I don't think people understand. iOS developers by and large are a very pragmatic bunch. Even those who love Objective-C (and there are many) are perfectly happy to move to something new that makes development even faster so they can accomplish the end goal of building apps for people.
That's really what iOS developers really care about, delivering apps. Anything that helps they are on-board with, and you can plainly see Apple is backing Swift big-time so the developers are hitching to that very powerful wagon.
If I were advising ANY developer new to iOS, I would absolutely say go Swift first. Someone said there's more Objective-C educational material? Technically true, but also consider how much of that is outdated. With Swift anything you find (and there is a LOT right now) is guaranteed fresh.
If you worry the iOS development market is overcrowded, don't - experienced developers for all backgrounds are badly needed all over.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
You say you're an experienced embedded-systems developer. Those are rare. Stay with that and get better at it. There are already a huge number of people grinding out appcrap, more than the app market can support. Soon there will be a glut of former phone app programmers, if there isn't already.
Try to get in on the back end of the "Internet of things". That crowd is overrun with appcrap people and has no clue about embedded.
The problem with introducing a new language, no matter how good it is, is that a beginner will find limited online resources.
Stackoverflow.com has been a godsend for me getting into iOS App development.
So too has cocoacontrols.com for finding something I want, which I know someone else will have already written and made free.
Swift on the other hand hasn't been out long enough for there to be enough answers on the knowledge base websites to cover all issues that will arise in the learning curve.
Nor will there be an avalanche of re-writes of the free, object-c, code utilities that are available.
AFNetworking springs to mind, a fabulous effort that has saved so many so much time, bugs and frustration.
You can use a bridge between it and Swift but that's just added complexity and time.
To (mis)quote Tony Blair "there is a third way" http://www.robovm.org/
If you want to put out apps that people will call good... do the extra mile and code for that platform.
I can with the authority of someone who tries, jumps between and uses a LOT of apps say that the one thing has nothing to do with the other.
Crap apps are always crap regardless of language and portability.
Good apps are always good regardless of language and portability.
Specific function apps coded for specific hardware can be good or crap, but force you down a particular language.
There was a blog post this week (can't remember where I found the link now) that details common problems and how you'd approach them in both Obj-C and Swift. I haven't finished reading it yet but it's pretty clear that the author is sticking with Obj-C for the time being. Worth a read. http://owensd.io/2014/09/24/sw...
But as I've said many times since then, I'll switch when something better comes along. That time has come. Swift is a major improvement over Obj-C, and it was developed to meet Apple's internal needs, by engineers who know Obj-C inside out.
It's kind of a kick being a beginner again. Swift takes some getting used to, but I expect it to give me as much of a productivity improvement over Obj-C as Obj-C gave me over C++.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
You're an experiecned C developer? Well, sorry, but that's a no-brainer then. Go for Objective-C. Anything else would be really really stupid. You'll have to change some C habits to actually 'get' Obj-C, but you'll live. Obj-C works on every plattform, so you wouldn't be tied to iOS/OS X either. Only upsides to that route for you.
I OTOH also am an experienced developer, but pampered by 15 years of modern scripting language usage. I would want to learn C++ or Objective-C (I've been trying to pick up C++ for the last 2 years but haven't put enough effort into it yet), especially because im a FOSS Linux Geek, but I hate having to deal with anachronistic shit - so for me actually using an easy-to-use lock-in language would actually make sense - especially if I know what I want to build on iOS exclusively, since I would only do something very product and project specific on iOS. And only if I'm paid for it.
We suffer more in our imagination than in reality. - Seneca
I read a few of these posts by zealots for "this" language or "that" language. There is a right tool for every job, and in many cases, more than one tool that will do the job. The questions to ask yourself it which languages meet the your criteria: ... etc. .NET for C# to be useful. The same goes for Java - you have to learn the massive class libraries in order to leverage those environments. Even interpreted languages like Ruby, Python, Perl et al have modules or libraries that you will need rather than "roll your own". With 'C', the joke was that you have to "sire your own user community" - but the "modern" languages (read "newer than 'C') come with classes/functions/tools to do almost anything imaginable today - all you need to do is learn which class/method/function does what. ;-) and I still code today (amongst other things), in many languages, because I like something about each of the languages. It isn't an "either or" thing - for some projects .NET might be a better fit as long as you only want to code for Windows. For another project, Ruby, SCALA, Java, whatever. (NOTE: For all the purists jumping up and down right now, the C# language doesn't run only on Windows platforms, but it is so tightly linked with the .NET environment and dependant on the CLR that it's not terribly useful in a non-Windows environment. Yeah, I hear the LINUX zealots shouting "mono" at me, but really...) :-)
* Do you want another language as a marketable skill?
* Do you want to write and sell iOS apps?
* Do you want cross-platform functionality?
* What functionality is that? Is it single code-base native GUI on multiple platforms? Do you want to write games, communications, accounting programs, robotics, web apps?
*
For every language you entertain there'll be a bunch of zealots espousing it's virtues and an equal group of naysayers panning it. A programming language is a syntax, but also in today's world it is dependent on a massive class library (functions in 'C'-speak). There is a mental "mindset" around each language also that once you "get" it, the language will make more sense and be more powerful and natural for you.
Coming from 'C' (either Kernihan & Ritchie or ANSI) your biggest transition is going to be to the Object-oriented paradigm. I say learn more than one language so that you have a basis for comparison. And make one of those languages a "scripted" or "interpreted" language - something that you don't have to compile to test as you learn. Ruby and Python come to mind but there are plenty of others. Once you get your head around objects, then look at the compiled languages. Moving to C++ or Objective-C will be pretty familiar because of your 'C' background - but not trivial. The same way Basic programmers can write a 'Basic' program in the 'C' syntax (which is a horrible program) you can write a 'C' program in C++ or Objective-C or C# or Java, with an equally horrible result. Once you get your head around the whole idea of Object-oriented programming, you have to learn the massive, and I mean MASSIVE class libraries of
I've started programming computers 40 years ago
Learn more than one, and at least one interpreted, scripted object-oriented language. I add "scripted" because your could argue that that any language that has a runtime or JVM could be "interpreted". You asked our advice - well, that's mine
FWIW I was a straight 'C' programmer for many, many years and made the difficult transition to objects and all the other paradigms. It was well worth it.
amen. The problem is highlighted there.
If you are writing a LoB app, make it a web application and free yourself from the deployment and upgrade problems desktop apps have. Businesses love webapps for this reason.
If you're writing a game or similar, you'll want performance and fancy graphics and though you can do it with Mono and unity, they do tend to bog down if you have too much stuff going on, and all use 100% CPU permanently (at least the ones I've used do)
For those looking for a cross platform solution, there's also RAD Studio XE from Embarcadero (current owners of Delphi and C++ Builder). RAD Studio includes both Delphi and C++ Builder, so you can either go Object Pascal or C++. The cross platform framework you'll be learning would be their Firemonkey API. With this package, you can develop for Android, iOS, and Windows from one code base (however I'm guessing, as with the case with all cross platform solutions, your mileage may vary).
I haven't tried it myself, but I've been looking seriously into it. I would be interested to see if anybody has actually tried this tool for mobile development and would care to share their experiences.
Remember how long it took to lay Carbon to rest.
Carbon was an entirely different set of frameworks.
Swift on the other hand uses all of the existing frameworks - only the have tweaked the Swift definition of the endpoints such that it's more Swift friendly (like knowing when arguments or return values will or will not be null for sure).
So there is zero Carbon-Like transition time involved.
I'm not drinking the Apple Kool-Aid, I am telling you what is happening in real-world iOS development today. If you learn anything but Swift you are going to be WAY behind state of the art inside a year.
I'd say it's 50/50 whether or not Swift will get enough traction to continue on.
Jumping horny ghost toad of Fernando, you are not really that stupid, are you? Please tell me you are just trolling? You really don't understand what happens when Apple puts weight behind a development technology? Wow.
In one year I will re-link to your post in EVERY Slashdot post you make.
At this point I wouldn't even buy whatever CEREAL you normally buy, with judgement like that.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Swift on the other hand hasn't been out long enough for there to be enough answers on the knowledge base websites to cover all issues that will arise in the learning curve.
Between Apple's excellent free books and StackOverflow (which is brimming with Swift questions and answers) that is not at all true. Any issue you run into coding Swift is well covered by online resources already.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I think the reason that people are going a bit nit-picky (heck, I still call it assembler because, lets face it, it's always a specific target, and a specific assembler with its own syntax) is because of the implied assumptions in your original question. As someone who is comfortable with assembler, c, c++, java, the p languages, etc., I could see how silly the reverse question would be: "I have decades of c++ experience, and now I want to write a program in asm or c. Which is the better choice?" Someone who has both c and c++ experience would say "Are you ready to work without destructors? Without all those standard class libraries?" Thinking exclusively in terms of procedures, and not classes?
Someone who would pose the even worse question: "I have decades of java experience, and now I want to write a program in asm or c. Which is the better choice?" would get treated worse."Are you ready to deal with the macro processor and all those clever #defines that tend to obfuscate the code if you're not a c/c++ programmer?"
And of course, neither really prepares them for using assembler/assembly, unless they've already been writing embedded assembler in their existing code.
Learning the language is easy, compared to using it well. "A good idea, poorly executed, is worse than a bad idea, well executed." Marketing (which is part of execution) makes plenty of bad ideas look good, and gives time to come out with an improved version that is less bad.
So part of the problem is that your question is just an unfortunate twist to one we've heard too many times: "I have a great idea and now all I need to do is code it? How do I do that?" It's like the people in decades past who said "I have a great idea. If you code it, I'll give you 10%." I came very close to losing one friend over my refusal. He felt I was depriving him and his family of a chance to get rich quick.
As for my original advice, I would add this: You don't need to learn an IDE to do Android development. A shell, a few makefiles and scripts, and a cheap Android device (just buy a $100 android tablet) and the sdk and a usb cable. The android device can easily be put into developer mode with just a few taps on-screen. This would probably be more familiar for, and similar to, your current workflow. And once you learn the ins and outs of eclipse ...
Either way, don't be discouraged, and try not to take any criticism personally - a mis-step here or there is no big deal in the long run.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
You obviously never used a cross platform environment or used an App/Application that was written with one. ... but for Swing, Qt, zApp?
Your claim was perhaps true for Java/AWT
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
If you'd bother to look at current Swift benchmarks, not the initial betas, you'd see it racing passed C code due to its inherent parallelism.
See: http://www.jessesquires.com/ap...
In a series of typical sort tests, Swift bests objC in these tests by 6-18 times, both using Clang & LLVM. Yikes!
I'm currently writing a project using Xamarin ( http://xamarin.com/ ). Did the Objective-C thing at a previous job for about 6 months. C# is way way better than Objective-C, and you get the added bonus of being able to reuse your business logic (and even some of your UI depending on how you write it) across platforms. There is some overhead in learning the apis through C# instead of Obj-C, but its more than made up for by a better language and cross-platform reuse of code. Not as many examples of how to use apis in C#, but, for the most part, its pretty trivial to translate things from Obj-C. The worst bit is that existing third-party libraries are substantially harder to use. You do have to pay for a license for apps over a certain size, but its only $25/mo for an indy developer.
Apple are known to ditch current technologies if they think they have a better option for the future.
They dropped their own proprietary ports in favour of USB.
They dropped floppy drives around the time USB flash drives appeared.
They dropped SCSI in favour of FireWire.
They dropped PowerPC in favour of x86.
They're currently dropping FireWire in favour of Thunderbolt on most of their computers.
They may still be supporting Objective-C in parallel to Swift today, but what makes you think Swift won't be the only option in a few years?
Get free satoshi (Bitcoin) and Dogecoins
Apportable lets you compile Objective-C to native ARM and x86, making porting trivial. I heard many success stories but did not actually use it myself. But having one code base is too good an opportunity to miss. I would like to hear downsides as well. Any developers using apportable to do Android ports, reading this, please share your experiences.
I am well-versed in C, I have thus-far avoided C++, C# and Java
If you've successfully avoided anything except for C, it doesn't sound like you're too ambitious to pickup much new. I can't say I blame you. I'd skip both ObjC and Swift.
I don't see you actually learning 3 new languages and 3 new frameworks if you've stuck with C and avoided nearly everything in the past 30 years. Look into Xamarin (C#) or Cordova (JS), depending if you need more native-level performance or can get by on a webapp.
http://www.accountkiller.com/en/delete-slashdot-account Stop visiting Slashdot.
Why not use Python and run on iOS/Android/Windows/MacOSX/Windows with one codebase? http://kivy.org/
'If/when I decide to port my iOS App to Android (and/or Windows Phone)?'
To answer your question, you should check out the IDE called Codename One, it allows you to develop for a bunch of mobile platforms all at the same time:
http://www.codenameone.com/
Michael
http://s1.sfgame.us/index.php?rec=58163
I know there are many different ways to get to where you're going. But if you're going to be learning a new language, you should consider making it C# and use Xamarin, the cross-platform solution that will let you develop for Android, iOS, and Windows Phone using shared code and great native code. It's better than the HTML5 approach as it gives you access to native functionality that HTML can't access. I am originally a C# developer, so it was a no-brainer for me, but I still recommend that you at least take a look at it.
What about Servo?