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.
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'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.
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.
can only deploy to ios7 or newer with swift
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.
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.
.
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.
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.
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.
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.
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 Instruments and a static analyser which lets you track down problems like this easily, so long as you understand one single principle, it's very difficult to go wrong with manual memory management on Apple platforms.
NARC. If a method begins with new, alloc, retain, or copy, then you own it and it's your responsibility to release it. Otherwise, you don't need to.
The only people who struggle with memory management are the ones that don't understand this very simple rule. Learn that, and it's effortless.
To be frank, it sounds like none of you have more than a beginner understanding of the language. How can you not be aware of NARC or ARC? It's the kind of thing you learn on day one.
Bogtha Bogtha Bogtha
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.