Ask Slashdot: Swift Or Objective-C As New iOS Developer's 1st Language? 316
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?"
Obj-C (Score:4, Insightful)
Re: (Score:2)
Re:Obj-C (Score:4, Interesting)
Agreed. And for the op, Obj-C is the best language to use right now. Being well versed in C means he can learn Obj-C in a day. Obj-C is a very small superset of C.
The hard part is learning Cocoa, but that is true of any framework whether that is Swing, Android, MFC, GNOME, Qt.
Swift is so new, you will have to learn Obj-C anyway to learn Cocoa.
The best bet is for the op to write model/cross-platform code in C, and then use Obj-C for the native UI layer. Then repeat for Android/Java (via JNI) and Windows Phone/C++CX.
Re: (Score:3)
I wrote a toy Lisp interpreter in Objective-C, on Linux without any of the NS* libraries. It was great for that, because it gave polymorphism while at the same time letting you mess with object internals. My root class had a method that would overwrite the object's isa pointer, changing it into an object of another class, for use by the garbage collector; try that in most languages.
The basic layer is C, which is a small and relatively clean language, with a small and relatively clean Smalltalkish object m
Re:Obj-C (Score:4, Informative)
Objective-C didn't "come out of" Apple or NeXT or Jobs. It was created by Brad Cox and Tom Love at ITT and Stepstone in 1983 and is derived from Smalltalk-80. Jobs just bought the company in 1995.
Re: (Score:2)
So... based on your later posts you have never even USED Objective-C but you lucked out on /. First Post. Yay for useless comments!
And trashing Apple in the process, nice.
Objective-C is a semi-painful language but in my experience SO much more efficient than Android's choice of Java. There is a lot of misinformation about Swift but the reality is its development was headed by the lead dev of Clang who was also responsible for a lot of the innovations in Objecive-C. His goal *was* in fact to replace Obje
Re: (Score:2)
Re: (Score:3)
Are you serious? Objective C is crap. It may have been hot stuff 25 years ago, but it's older than Java, and that shows. Swift is the future for Mac OSX/iOS development. Don't waste your time learning what was state of the art in 1988 (ie Objective C).
Objective C no worse than C, C++, Java, C# .... in fact I prefer Objective C to C++ in many ways and I definitely prefer all of these languages to Java.
Re: (Score:3)
and I definitely prefer all of these languages to Java.
Probably safe to ignore everything else he said too...
Re:Obj-C (Score:5, Insightful)
public static void main(String[] args) {
System.out.println("Hello, World");
}
}
Re: (Score:3)
No no, your boss is going to have a word with you about that:
Re:Obj-C (Score:5, Insightful)
Anyone who says 'X' language is crap, can safely be ignored.
Unlike our previous poster, though My opinion is that Java, is actually one of the least useful languages out there. It doesn't provide a higher level syntax than objC or C++, like the "better languages" Ruby, Python, etc. Nor does it provide the performance or memory footprint of systems languages like C, C++ or objC. It is bound by a runtime, that is meant to make it run-anywhere. Yet ironically the universal crown is going to javascript+HTML5, not java. Java in many ways is the new pascal, it is largely an educational language with a strong base in corporate intra-net applications.
You can use c, objC & C++ for decades to come. However Swift is very exciting (and I'm a embedded guy). It is the first serious language to come along that can challenge the C family of systems languages that I can remember. It has all of the native performance of C, the memory footprint advantages of reference counting, all of the syntactical goodness of ruby or python, the inherent parallelism of groovy and haskell, yet can morph into a JIT language in development with a very enticing hot-coding environment. With Chris Lattner & Apple backing it, it will be successful. I can't wait till it filters down to the open source space so I can use it in embedded systems.
Re: (Score:3)
I tell people this when they bring up iphone vs android. From a developer point of view, I prefer the iOS/objective-C/Apple way.
This is with the huge caveat of general happiness on my part. Android's making everyone run linux. I've always wanted to see Windows knocked off the top spot (for economic and CS/IT reasons) - and it's finally happening
Re:Obj-C (Score:5, Insightful)
Unlike our previous poster, though My opinion is that Java, is actually one of the least useful languages out there. It doesn't provide a higher level syntax than objC or C++, like the "better languages" Ruby, Python, etc.
Java doesn't provide a higher level syntax than C++/Obj-C but it does provide a much more easily parsed syntax. The result is lightning fast compilation, sane compilation errors and excellent tooling support. Auto-completion, powerfull refactoring, background compilation and powerful lint tools make for a very productive programming environment. Even C# doesn't have full proper background compilation yet. Intellisense is close but there are whole classes of compile time errors that it doesn't pick up.
Similarly stability has done a lot for the language. Java is one of the few languages were I'm confident that I could build a project I wrote ten years ago with no issues. C++ on the other hand... ugh! Just last week I shifted a project from VS2012 to VS2013 and had spend an afternoon fixing random code breakage because MS broke their Chrono libraries and their retarded compiler gave errors in the template definition in their header file rather than the actual lines breaking compilation. Not to mention the ball of fun that was trying to get the latest versions of our dependencies to compile... Fun stuff like the 64bit build for some reason produced 32bit obj files... In Java land I add a line to Maven or for Android drop a library in the libs file and add it to the dependencies... Presto, nothing more to think about.
It's also a very readable proramming language imo. Packages=directories and one public class per file make navigating Java code very easy. Types are obvious and code is simple to follow. I've worked in C++,Java,C#,Javascript,Python and also on my own time in C and Haskell. Out of those I'd say Java and C# easily have the best readability. (For the record Haskell has the worst by far imo.)
It is bound by a runtime, that is meant to make it run-anywhere. Yet ironically the universal crown is going to javascript+HTML5, not java.
I'm not sure if that is ironic. The Java runtime brings other benefits than cross platform compatibility. If I dereference a null pointer or use an index outside of array bounds, the Java runtime will give me a nice error telling me exactly what the error was, which line of code in which class caused it and what the sequence of calls that lead to the error was. Try doing the same thing in C++/Obj-C. If you're lucky the code will be running on a developer machine and you can hook in the debugger and if the code isn't too heavily optimized maybe even get the line of code it occured on. If you're unlucky the code is on a production server/client system somewhere and your stuck trawling through a log to find the error. (For the record record Haskell easily takes the title of hardest to debug language thanks to lazy evaluation.)
Plus it's not like C++/ObjC have no runtime. For example, if you don't have the right VC++ redistributable installed, you'll get nowhere trying to run C++ application compiled in VC++. Their runtime just doesn't include a JIT compilation stage (for better or worse)
Anyway here's the tl;dr: Java doesn't have exciting language features but it does have excellent tooling, excellent readability and is one of the easiest languages out their to debug. That too me is way more valuable than exciting language features. I prefer C# but I'm happy to work in Java instead.
Re: (Score:2)
So basically you're complaining because you wrote bad code that only worked due to Visual Studio not following standards and that on top of that you don't know how to read template error messages?
Re: (Score:2)
Anyone who says 'X' language is crap, can safely be ignored.
Interesting, I usually think "Anyone who says 'X' language is not crap, can be safely ignored. They're all crap. :) Programming is still far from what it could be.
Re: (Score:2)
Re:Obj-C (Score:4, Informative)
Sure Java exploded but it became the Honda Civic of languages while C is still around but Delphi is not.
The news of Delphi's death has been greatly exaggerated. [embarcadero.com]
Re: (Score:2)
Re: (Score:2)
n/t [wordpress.com]
Re: (Score:2)
Re:Obj-C (Score:4, Informative)
Nobody said Java was useless. I just can't think of why I'd use it over another language unless I had to. I'd either pick C/C++/objC for speed, or I'd pick Ruby/Python for efficiency, or I'd pick Groovy or Haskell if I was leaning functional... depending on my needs. I can't think of why I'd go in the middle. Seems like the worst of all worlds.
Rust and Swift are very on par languages attempts, with the exception that Swift also has a very nice compile time JIT and hot-coding environment. However, and this is crucial: Swift is beating Rust to the punch - and that is an important factor in languages. Swift had 200,000 devs download the language spec in the 1st 24 hours. That is probably 10x more than have ever downloaded the Rust spec.
Rust is still listed as experimental, as Swift is being rolled out to developers. The Rust team is still arguing over implementation, in an unfortunate design-by-committe kind of way. Rust has no killer-application driving it. Swift does. Swift is Driven by Chris Lattner, who has probably done more for the compiler world in the last 10 years than the next 25 guys put together (LLVM, Clang, OpenCL, etc). And Swift is backed by a huge amount of Apple dollars. Even the Original developer behind Rust has tipped his hat to the project. So Yeah, I expect Swift to rocket to the Top 5 languages in the next 2 years while Rust stays a academic plaything for many years to come.
Re:Obj-C (Score:4, Insightful)
Swift right now is a slow toy with incoherent semantics (lambdas and no GC, really?). It has _NO_ real advantages over Rust as they both use the same LLVM ecosystem for the backend. And I don't get where you got the idea that Swift uses any kind of JIT, it's a strictly compiled language like Rust. Compile speed of Rust is excellent (it's self-hosting, so there's a fair amount of code to compile) and by now Rust's design is mostly finished.
But of course, as we know, Apple has invented programming languages.
Re: (Score:3)
Here is what you are missing:
LLVM is enabling new languages that blur the lines between JIT and compiled. LLVM can do either. Right now Xcode JIT compiles code as you type in C/C++/objC. It is also used in openCL as a runtime JIT to compile C code to the target runtime platform (CPU or GPU). Now with Swift they have leveraged that ability further to JIT in a hot-coding environment... which is really the main advantage of interpreted and JITed languages: coding efficiency.
If you don't understand why GC is a
Re: (Score:2)
Fundamentally the interpreted/runtime nature of C# and python put them at a serious performance disadvantage, and well as generally limit what you can do with them. They can't be systems languages, they aren't even fully general purpose languages. The C# only allows for it to be suited for certain applications, as an application language. Python isn't high performance enough to be more than a scripting or prototyping language.
While Swift will be evangelized by only Apple initially, I hope it gets general tr
Re: (Score:2)
Re: (Score:3)
LLVM was originally developed by Chris Lattner , Apples VC of Dev Tools. He joined Apple right after he developed the first version. And He and Apple have kept on driving and developing the project. You'll notice that the top 10 devs on the project are full time Apple employees. It would be hard to say LLVM is anything but a Apple project, under Apple's primary control
Re: (Score:3)
It is now under the primary control of Apple, certainly, but it didn't "come out of the Apple compiler group" as you erroneously stated. It came out of the University of Illinois's compiler group. In addition, Lattner was not the only person developing it there.
It is true that LLVM has been Apple-driven since 2005, but it didn't come out of Apple— they picked it up after it was already out there.
Re: (Score:2)
It was my understanding that if you want "complete" control, you still need to use ObjC, and that Swift was for dashboards, things previously known as WebApps, and other lightweight situations where you aren't actually doing anything novel, just packaging an interface to a datastore or moving sprites around.
That said, Swift is just as good on inheritance as ObjC, and does garbage collection correctly (benefits of a CLR).
ObjC has been tuned to OS X/iOS, and if you write in ObjC, you should be able to make a
Re:Obj-C (Score:4, Informative)
I was recently pondering whether my game engine (written in C++) should have it's native OSX back-end / interop written in Swift or Objective-C. From what I can see, for what I need to do, Objective-C remains the clear choice, at least for now. There's a lot of good documentation on Objective-C / Cocoa, as well as lots of examples for how to interop between Objective-C and C++. I haven't even been able to determine if this is possible with Swift after searching around a bit on the net. Interop with Objective-C, yes, but that's pointless for me. I don't see Apple obsoleting or depreciating Objective-C in the near future. There's a heck of a lot of legacy code in that language, and like you mentioned, it seems like Swift wouldn't even be a proper replacement at this point for everything Objective-C can currently do.
As with pretty much any other language-choice debate, you really first need to know what someone plans to do with it before you can make a worthwhile recommendation. All languages have strengths and weaknesses, so it's foolish to point to one without even knowing what you'll be doing. The OP first wants to know about "quick and easy" for which I'd probably recommend Swift, but then wants "portability", for which I'd recommend C (for him, since he knows that - personally I use C++) with carefully walled off interfaces to the GUI frontend, but *only* if the complexity merits such treatment rather than a simple port in native code for each version. Without any more info, I can't make a better recommendation than that really.
Re: (Score:2)
Apple has explicitly said in their "Using Swift with Cocoa and Objective-C" document that Swift isn't compatible with Objective-C++. You have to create a C API for the C++ code and call it through that. Hopefully that will be remedied soon, but in the meantime using Objective-C++ instead of Swift is a no-brainer for new development that needs extensive compatibility with a C/C++ installed base or set of libraries.
It looks like a fun language, and perhaps appropriate for small projects, but it's definitely
Re:Obj-C (Score:5, Informative)
It was my understanding that if you want "complete" control, you still need to use ObjC, and that Swift was for dashboards, things previously known as WebApps, and other lightweight situations where you aren't actually doing anything novel, just packaging an interface to a datastore or moving sprites around.
That said, Swift is just as good on inheritance as ObjC, and does garbage collection correctly (benefits of a CLR).
ObjC has been tuned to OS X/iOS, and if you write in ObjC, you should be able to make a single back end that's easily portable to OS X as well as iOS; Swift would be more for iOS only.
I really do like the real-time iteration available in Swift though.
That said, my opinion must be crap, because I'm older than Java too :D I still like Pascal and Common LISP, but wouldn't write a modern application in them (flashback to writing Avara mods in the 90's using ClarisWorks). Most stuff I write these days is in C or Python.
Oooof. So much wrong in a single post. Let's review....
Swift definitely does not do garbage collection. Obj-C actually had a garbage collector for a while (Swift never has) but it was optional, and support for it has ended.
What Obj-C has now is something called ARC (Automatic Reference Counting). At compile time (not run time) the compiler does a static analysis of the code and determines where it needs to add memory management code, and then quietly does so for you. This means there is no run time hit, and behind the scenes everything is still manual memory management. Sometimes you still need to hint to the compiler what to do (usually when trading pointers with C), but 99.99% of the time it just works.
Swift is built on the same runtime as Obj-C, so it inherits ARC. With Obj-C, you can turn ARC off and continue writing manual code, and I'm not sure if Swift allows the same, but it's the exact same behavior. Swift uses the same manual memory management functions as Obj-C in the background, while in the foreground the developer still writes without memory management. I'm not sure what this "benefits of a CLR" is you're talking about, as that's a term usually associated specifically with the Common Language Runtime of the Microsoft language family, but it's neither here nor there. Swift does not run in a VM (it's natively compiled just like C or Obj-C), and it does not have a garbage collector. (But the compiler will add your memory management code for you.)
As far as Swift being multi platform, Swift most definitely for sure runs on OS X, so the language choice has absolutely no bearing on what platforms you want to port between. I have a partially Swift project going on the Mac right now. Swift is definitely not iOS only. Beyond that, it looks like Apple will be working to open source much of it and move it to other platforms.
I'm not sure what this business is about Swift being for lightweight solutions. It runs on the same runtime as Obj-C, it's starting to be as fast as Obj-C, and it interoperates with any Obj-C code (as Obj-C will interoperate with any Swift code). Apple has never messaged that it's for lightweight apps, and developers aren't treating it that way. I still prefer Obj-C, but I'm not sure what that bit is about at all.
Re: (Score:2)
CLR in this context means a very large standardized library, which is not subject to fragmentation nor availability. It runs or it doesn't, and it behaves as documented (by google or stack overflow, not necessarily MSDN).
You can care about performance and study the IL, or ignore it and use Linq for elegant and readable one liners.
I won't address the remainder, as that is where you professed ignorance. Aside from lightweight, where you made a good point in support despite not understanding.
Re: (Score:2)
CLR in this context means a very large standardized library, which is not subject to fragmentation nor availability. It runs or it doesn't, and it behaves as documented (by google or stack overflow, not necessarily MSDN).
That's not what the term CLR actually means (http://en.wikipedia.org/wiki/Common_Language_Runtime) nor does that necessarily apply to Swift. Swift does indeed have a slightly larger core function base than Obj-C, but still not enough to build an entire app. For example, there is no I/O (either file or console, except for printing to console), networking, or GUI support that is part of the core implementation. You won't be building much with the Swift core library by itself.
Here's a list of every single func
Re: (Score:3)
Automatic reference c
Re: (Score:2)
It is inferior in just about every way (runtime overhead, latency, memory utilization) to a good garbage collector.
It's certainly not inferior in terms of memory utilization because it's precise in that it deallocates as soon as the last object pointing to it disappears, whereas in normal GC, you have to wait for the allocator to run.
Re: (Score:3)
He is clearly not a Swift learner!
Re:Obj-C (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Interface Builder generates a bunch of boilerplate obj-c code for you. But anytime you need to add your own references etc or do anything other than simple stuff, you have modify that code. It's not as easy to use as C#, VB or Delphi because it exposes all the plumbing of the GUI.
Re: (Score:2)
Interface Builder generates a bunch of boilerplate obj-c code for you.
You know not what you speak of.
Interface Builder doesn't generate any Obj-C code. Interface builder creates XML .XIB files which are compiled into object stores with a .NIB extension. Those objects are Obj-C runtime objects. But there is no boilerplate code that creates them. The application simply asks for a nib file and all the objects within it are created.
As such Obj-C exposes LESS of the "plumbing of the GUI" than the languages you mention whose visual designers DO generate boilerplate code.
Re: (Score:2)
I'd bet the majority of budding iOS developers start their first project using Interface Builder. It works pretty well if you don't stray too far from the Apple "look". But once you want to do something novel, you start spending more and more time working around IB than with it.
And god forbid you want to collaborate with other developers via version control. Having to manually 3-way merge a couple thousand lines of XML causes IB to quickly lose its shine...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Doesn't really matter! (Score:5, Insightful)
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.
Re: (Score:3)
Re: (Score:3)
You have obviously never used Perl.
Re: Doesn't really matter! (Score:5, Interesting)
Learning Resources (Score:2)
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 reada
If you 'speak' C (Score:3, Insightful)
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?
Re:If you 'speak' C (Score:4, Informative)
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?
Well -- 1970's maybe. 1960's were more about drum storage and all that. Even in the early '70s, the 029 keypunches didn't let us correct typos -- you had to hold the "dup" key down to duplicate the bit you got right, and then carry on keying from where the mistake started. The 129's were much better, as they only punched the card after you finished the whole line.
Although come to think of it, I did write a nice simple weather app in 360/Assembler for a class in 1974.
Re: (Score:2)
BALR *,13 to you, sir.
Oh... and:
0C7 ABEND
ABORT
CORE DUMP FOLLOWS
Re: (Score:3)
Objective C is a superset of C; therefore, every C program should also be a valid Objective C program. You might need an Objective C shim to access libraries for IO and whatnot, but you could write the core of your app in plain old procedural C if you wanted.
Re: (Score:2)
I don't see why not. AFAIK, Apple removed the restrictions on developers' choice of programming languages just five months after they added them—probably in response to developers with pitchforks....
C/C++ for core, Obj-C for UI (Score:3)
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,
Re: (Score:2)
It's technically possible [stackoverflow.com] to write an iOS application in nothing but C, but it's deeply unpleasant compared with using the right tool for the job. Just learn Objective-C. There's very little more to the language than plain C, but it makes things so much easier. Then, when you're familiar with the platform, pick up Swift. It's by far the better language, but it's a bigger change than C to Objective-C and it's still pretty immature.
Objective-C, if you don't know much about how iOS (Score:2, Insightful)
There are way more tutorials and examples for Objective-C than Swift.
Five years of Swift minimum... (Score:5, Funny)
I'm already getting barraged by headhunters asking for five years of Swift minimum for contracts now...
Poaching or immigration ploy? (Score:3, Interesting)
Re: (Score:2)
I'm already getting barraged by headhunters asking for five years of Swift minimum for contracts now...
Put it on your resume, "five years Swift". If anyone asks you to explain, mumble something philosophical about gazelles on the plains in Spain.
Why start now? (Score:2)
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.
More help is available on Objective-C (Score:5, Interesting)
either works if you take advantage of (Score:3, Insightful)
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.
Does Swift work on older iOS versions? (Score:2)
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?
Re: (Score:3)
can only deploy to ios7 or newer with swift
Re: (Score:2)
can only deploy to ios7 or newer with swift
You're not dealing with the Android market which has a crap ton of people still clinging to Android 2.3 or earlier. New version adoption rate on IOS is the highest for any platform. And every phone that apple sells now runs on 7.0 or better.
Re: (Score:2)
The question is irrelevant.
As a deceloper of a 'small company' you can not put Apps into the AppStore that run below iOS 7 (and I woukd not wonder if that is in a few days iOS 8)
Only companies like MS or Google can still 'update' iOS 6 or older Apps. All others are forced to publish for a newer version of the OS.
Re: (Score:2)
Are you sure about that? My understanding is that new/updated apps must be "optimized" for iOS 7, but they can still run on older versions.
Re: (Score:2)
No, you're right, there's no rule against supporting older versions. Xcode 6, which is the version released just the other day to support iOS 8 development, supports building applications targeting iOS 6 and up.
Apple have never explicitly required developers to support a minimum version of iOS, they just drop support for targeting older versions in Xcode a few years after release. Xcode 5, which was the most recent version until the other day, still supported iOS 4.3, which is over three years old and ha
They are wrong... (Score:2)
Assuming you're not learning this language to obsolete yourself, then you definitely want to stick with Swift.
Re:They are wrong... (Score:5, Informative)
Here's why you should learn Objective-C first:
Swift is designed to make it easy to build apps that include a mix of Swift, C, and Objective-C. Therefore, there's no reason to believe that it won't be possible to write fully capable apps for iOS and OS X in Objective-C for the foreseeable future. And even if, God forbid, Apple decides to be a bunch of a**holes and starts shipping a bunch of Swift-only classes in a reckless and desperate attempt to pressure developers to switch to Swift, you'll still only be a tiny bit of glue code away.
That's not to say that Swift isn't interesting. The ability to test code on the fly is certainly cool, and if Swift proves to be a long-term-viable language, I'd imagine it will eventually (over a couple of decades) become the dominant language for OS X and iOS development. However, there's plenty of time to learn Swift. If you want to start writing real-world code today, you're better off learning Objective-C, because there are orders of magnitude more examples, you'll be more likely to find employment (there's way more Objective-C code out there to maintain), and more people can help when you run into problems.
Ask again in five years, and the answer might be different, but for now, IMO, Objective-C is the clear choice unless you don't already know any C-based language, and probably even then.
Very outdated info (Score:2)
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)
Re: (Score:2)
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).
Oh really? Drink some more koolaid. Remember how long it took to lay Carbon to rest. And the Cocoa APIs are still incomplete in many areas. Then take a look back at all the new programming languages and frameworks Apple has introduced over the years and then shot in the head. Dylan? OpenDoc?
I'd say it's 50/50 whether or not Swift will get enough traction to continue on.
Re: (Score:2)
Very different situation. I work with a lot of companies that develop iOS applications, and it's extremely rare for them to be more than a couple of years behind the cutting edge.
Modern Apple does it very infrequently, and usually, when they do, it's because they've got something newer to replace it. In this case,
Objective-C, hands down (Score:5, Informative)
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.
Right now, Obj-C (Score:5, Informative)
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.
HTML5? (Score:2)
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.
Why are you in charge of the decision? (Score:5, Insightful)
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 [android.com] and iOS [apple.com] 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.
Re: (Score:2)
First, nowhere did you state that this was a personal project. If you had been up-front and written "I have a cool idea for a personal project..."
Given the context (your first line):
I am an experienced C and Assembler Embedded Developer who is contemplating for the first time beginning an iOS App Project.
... it's not clear whether you are putting this forward as something your employer wants, and you're thinking of throwing your hat in the ring, or a personal project.
Your questions make it VERY clear that you haven't even done the basic research, and your assumption that decades of experience doing asm and c (w/o any real
Re: (Score:2)
And btw, I notice that, with 99 comments in, nobody else has bothered to actually provide you with the links to the official Apple iOS developers or Android developers docs, api, tools, etc. I at least showed enough respect for you to expect you to benefit from them. Was I wrong? Only time will tell.
You know, if he can't use Google he's really bad off.
Back in 1990 if you were an experienced C developer and hadn't looked seriously at OO languages it was understandable. In 2014, if you haven't at least dabbled with C++, Java or C# I think it shows a definite unwillingness to learn. So that's why the OP is getting "condescending" answers like "just hire someone"
Stay away from Objective-C (Score:2, Interesting)
Re: (Score:2, Insightful)
You could try using ARC (Automatic Reference Counting) and the retain-release difficulties [are suposed to] disappear. The code to interface to the low level code is added (transparently) by the compiler when ARC is enabled.
Re: (Score:3)
OP says he's familiar with C, so he's already used to manual memory management.
Regardless, modern Objective-C uses ARC, which means all the retain and release calls are automatically generated by the compiler. You actually get a compiler error if you try to write the calls yourself these days.
Aside from the fact that Apple provides excellent tools like Instrum
Re: (Score:2)
The Case For Swift (Score:2)
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 unde
Don't do apps. (Score:4, Insightful)
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.
Re: (Score:2)
Experienced C developer? Isn't that a no-brainer? (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Re:C# using xamarin (Score:4, Informative)
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.
Re: (Score:3)
Re: (Score:3)
.
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.
Re: (Score:2, Insightful)
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.
Re: (Score:3)
Re: (Score:2, Informative)
This is fading away. The better solution is something like PhoneGap [phonegap.com]. 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.
Re:Neither (Score:4, Insightful)
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.
Re: (Score:2)
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.