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"
The Xamarin tools allow creating portable mobile apps using C#. The C# is compiled to assembly rather than relying on Mono or .Net.
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.
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...
Since Objective-C is 100% compatible* with C, it might be to your advantage to use Objective-C to write the UI and use native API while continue to use the language you are already familiar with.
(*) I don't know if Apple 's version of Objective-C is still 100% compatible...
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.
With Xamarin, you can write apps for iOS and Android in C#. Shared projects allow you to use the exact same code on both platforms. Depending on the nature and architecture of the app, you can get >60% code reuse between platforms. Xamarin is not free, but the benefits far outweigh the cost.
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.
Adobe flex. Cross platform, works on everything.
If you are writing for iOS, and its green fields, then Swift is a strong contender - you'll get a faster, higher quality output. Keep in mind you can mix and match Swift and C derivatives in the same project, so you can build cross platform stuff that doesn't touch platform frameworks & use it.
If when , you want to port, re-write in the native tool for that platform. You get to re-use a lot of design & conceptual effort, but if you want an App to appeal to the users of a platform, then damn well build something that is part of that platform, not a bodgy port trying to be another OS, or buy in to the hubris of "oh we know more than the platform vendors about user experience, come and use our cross platform abstraction layer meta platform thats really 2-3 years behind whats available on any platform, as your development target" crap.
"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.
Apple replaced it with ARC which relies on the compiler to manage memory.
You must avoid Objective-C at all costs. It's a bizarre Frankenstein language that will destroy your sanity. I have no idea if Swift is any good, but it can't possibly be worse than Objective-C.
I would rather people not bother with either ObjC or Swift unless they absolutely must. I hope Apple will finally take Mobile Safari more seriously so they stop falling behind so laughably. At this rate even Internet Explorer will leapfrog them soon, and with all the new WebAPIs coming out to manage hardware, speed up JS and make it memory-efficient, and transpile your language of choice into JS, there will be less and less of a reason to care about Apple's more proprietary languages and OS features. Unless of course they try to hold everyone back to stay relevant.
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.
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?
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!
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.
mod this redundant.
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.
Same thing with Java haters,.. and C++ haters. I wonder how many years they've spent programming in it.
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.
neither language will lend itself well to writing portable software. Write only what UI parts you have to in apple's proprietrary languages, and implement the remainder in something portable like C++. This will lead to better structured code anyway. I don't see any reason for any competent devloper to write non-portable softwarenin the modern world. Lack of portability is the hallmark of developer incompetence.
try creating a game engine from scratch with artifical intelligence, etc, actually try and require to use your mathematical abilities, rather than learning arcane rules, "gotchas" or technicalities of some 'new trend' language
once you do that, come back to mobile development after programming that requires instense mathematical abilitity, is like going from running with 20lb weights attached to each boot to walking with running shoes on.
seriously, what are you trying to do, create some crappy app that no one will probably use, or actually increase your programming ability?
Also to the guy who said that, those who say that 'x' language is crap are wrong, is wrong. the truth is every language is crap, the sooner you realize this the better off.
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.
Thanks for reminding me of the dup key.
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/
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...
IOS will be dead and gone inside of 2-3 years. Android is winning far and wide and MS is hard at work coercing CIO's and CTO's to switch to winphones using all kinds of tricks in all of the books. So programming IOS will be a waste of your time.
The best crossplatform platform is javascript, where you will find a framework such as IONIC, that already has +50.000 apps out there very worth your while.
We're in transition, so unfortunately you'll need both, at least for the next couple of years. But Obj-C is a very small language compared to C++ or other languages, so it's not hard to master.
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.
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.
Do you have the slightest hint as to what a colossal douche you are?
That is EXACTLY right. I am in fact a giant colossal douche.
What is the definition of Douche?
"a jet or current of liquid (as a cleansing solution) directed against or into a bodily part or cavity"
That is exactly what I do - a jet of truth fluid directed squarely against a bodily part or cavity (like an Anti-Apple asshole such as yourself).
The world badly needs more douches to wash away the mental stains left by people like yourself all over the internet.
To claim I am a force for cleansing is ironically the most accurate statement you will ever make in your pathetic life.
Why? My $0.02 take it as you will.
Since you already know C/etc. picking up Objective C should be relatively quick, most just understanding it's OO functionality and associated OS libs, and swift, well, maybe it will be used and maybe Apple will drop it like a cold dead turkey in a year or two, so why invest the time unless you enjoy learning a completely new programming language and libs for fun, which would be the way that I'd approach swift ATM.
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
There's a reason why every new app announcement says the iOS version is out now, and an Android version is coming later. It's not that easy.
The worst thing that could ever happen to an Android developer is to get some GUI designer who draws user interfaces in Photoshop and hands them off to an iOS designer to implement in a pixel-by-pixel exact way, because that's not how Android works, and trying to explain relative layouts to a Photoshop person is not easy.
You are not going to port code, either. Android and iOS work ... well, inside out from each other. An iOS design is going to be a bad Android design, and vice versa. They're event driven, but backwards. iOS delegates everything to your main class, and Android uses Java's listener model.
Some of your back-end design might port conceptually, but even that's iffy. Maybe if you use a lot of web services.
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.
bullshit, that makes no fucking sense
My experience with Java haters: usually they've spent a lot of years with it.
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.
C# (on Mono) with Xamarin as the IDE: you'll obtain sonewhere around 80-95% code reuse, and the development time will be a lot shorter.
Actually, Java is really really fast today and in theory can be faster than C++, because it is adaptive optimized. For instance, if you run a for loop with a class of objects, and the next time, there is a different subclass in the for loop - JVM can optimize for each subclass. Dynamically. C++ can not do that, it has been optimized once and for all, it is static and can not adapt to the different data that is processed at different runs.
For instance, NASDAQ's large stock exchange system on Wall Street with huge throughput and extremely low latency, is written in Java 100%. All fast stock exchanges today, with sub 100 microsecond latency, are written in Java or C++. So, you just need to avoid trigger the Garbage Collector in Java, and your stock exchange system will fly. Its quite simple to do actually, and NASDAQ does that all the time. You can never have a stock system pausing while GC for a second, the High frequency Trading customers would go to another exchange instead.
If you look at the difference between C and Objective-C, you will be amazed about how little changed. Brad Cox was clearly a genius. I mean its about 10 new things to know.
Below Stolen from Wikipedia:
All objects can trace back to the NSObject in Apple's version of Objective-C.
id return type is a pointer to any object.
Sending a message:
[obj method:argument]; -> send a message to an object
Defining an Interface: // instance variables
@interface classname : superclassname {
}
+ classMethod1;
+ (return_type)classMethod2;
+ (return_type)classMethod3:(param1_type)param1_varName;
- (return_type)instanceMethod1With1Parameter:(param1_type)param1_varName;
- (return_type)instanceMethod2With2Parameters:(param1_type)param1_varName param2_callName:(param2_type)param2_varName;
@end
Defining an Implementation: // implementation // implementation
@implementation classname
+ (return_type)classMethod
{
}
- (return_type)instanceMethod
{
}
@end
Method Syntax:
- (int)method:(int)i
{
return [self square_root:i];
}
Object Instantiation (creation)
MyObject *o = [[MyObject alloc] init];
Protocols (Interfaces in other languages)
@protocol NSLocking
- (void)lock;
- (void)unlock;
@end
denotes that there is the abstract idea of locking. By stating in the class definition that the protocol is implemented,
#import[edit]
In the C language, the #include pre-compile directive always causes a file's contents to be inserted into the source at that point. Objective-C has the equivalent #import directive except each file is included only once per compilation unit, obviating the need for include guards.
Object Creation and Allocations, and Initiation:
The alloc message allocates enough memory to hold all the instance variables for an object, sets all the instance variables to zero values, and turns the memory into an instance of the class; at no point during the initialization is the memory an instance of the superclass.
The init message performs the set-up of the instance upon creation. The init method is often written as follows:
- (id)init { // perform initialization of object here
self = [super init];
if (self) {
}
return self;
}
In the above example, notice the id return type. This type stands for "pointer to any object" in Objective-C (See the Dynamic typing section).
The initializer pattern is used to assure that the object is properly initialized by its superclass before the init method performs its initialization. It performs the following actions:
self = [super init]
Sends the superclass instance an init message and assigns the result to self (pointer to the current object).
if (self)
Checks if the returned object pointer is valid before performing any initialization.
return self
Returns the value of self to the caller.
A non-valid object pointer has the value nil; conditional statements like "if" treat nil like a null pointer, so the initialization code will not be executed if [super init] returned nil. If there is an error in initialization the init method should perform any necessary cleanup, including sending a "release" message to self, and return nil to indicate that initialization failed. Any checking for such errors must only be performed after having called the superclass initialization to ensure that destroying the object will be done correctly.
If a class has more than one initialization method, only one of them (the "designated initializer") needs to follow this pattern; others should call the designated initializer instead of the superclass initializer.
You now know the basics of Objective-C.
Give 'em five years, they'll start to make sense
Not a big one, and unlike GC a deterministic one, but a run-time hit none the less.
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?