Slashdot Mirror
Ask Slashdot: Objective C Vs. Swift For a New iOS Developer?
RegularDave writes: I'm a recent grad from a master's program in a potentially worthless social science field, and I've considered getting into iOS development. Several of my friends who were in similar situations after grad school have done so and are making a healthy living getting contract work. Although they had CS and Physics degrees going into iOS, neither had worked in objective C and both essentially went through a crash courses (either self-taught or through intensive classes) in order to get their first gigs. I have two questions. First, am I an idiot for thinking I can teach myself either objective C or Swift on my own without any academic CS background (I've tinkered in HTML, CSS, and C classes online with some success)? Second, if I'm not an idiot for attempting to learn either language, which should I concentrate on?
You don't need a professor to teach you how to program. Most of us who started using computers in the 70's and 80's were hobbyists, and we were self taught before going to college for CS. I don't use either one, so I'm not an expert, but in the immortal words of Yogi Berra - "when you come to a fork in the road, take it".
It will only take you 20-30 hours each to learn the basics of the language, so try both, and at some point you'll gravitate towards one.
Support microSD: in a post 9/11 world, it is unwise to carry your data on media that you cannot comfortably swallow.
There's a site you may not know about which had a long discussion on this very subject not so very long ago. A lot of people weighed in and you may find it enlightening:
http://ask.slashdot.org/story/...
How can I believe you when you tell me what I don't want to hear?
For wanting to learn something.
Helping with organizational effectiveness is our job.
You are not an idiot for going for this. There's a vibrant market out there for products based on these languages, with a great community and it serves at least two plattforms which by all accounts won't be going away anytime soon. I would go for Objective C, since it's a more mature language, with lots of good documentation, learning materials, and all the frameworks in iOS and OSX is using this. Swift is still finding it's way.. so while you are learning ObjC, Swift will mature, and you will be established when the time comes for Swift. Let the bleeding edge developers work out the kinks first.
- Henrik
- when the Shadows descend -
It's better to try and fail than never try at all.
But since you have very little experience programming in any language, you're going to have to do a lot of learning and you're going to have to get a lot of help.
Objective-C has been around a lot longer; there will be more people available to help and there will be more books, tutorials and example code.
Considering there is a large and valuable legacy code base, it's going to be around for quite some time to come.
Languages aren't that difficult to switch, assuming you're familiar with the paradigm (procedural, object-oriented, functional).
API's are the hard part, but they'll be pretty similar between Objective-C and Swift.
By the time you're proficient with Objective-C, switching to Swift (if necessary) should take just a couple of months at the very worst.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
I agree, as long as you pick up some guides or literature focusing on best practices, rather than just the semantics of the code. There are just toooo many "self-taught" programmers who cannot write professional quality code in a team environment because they were never really exposed to doing it properly. It's perfectly fine to teach yourself - just try to be flexible and adaptable and not get stuck in horrible bad habits - and for god sakes, if someone says you're doing it wrong, at least consider what they have to say.
As far as I can tell, Swift is just a new front-end to the Objective-C object system. So knowing how Objective-C works will be beneficial to working in Swift.
Also most of the libraries and frameworks you will be working with are Objective-C and most of the current tutorials and online resources probably use Objective-C in their examples. That's not to say you need to start with ObjC, but be prepared as you use Swift to learn a bit about it, at least enough to read and translate example snippets you see.
If my understanding of Swift is accurate, one can intermingle Swing and ObjC libraries and modules. They should have the exact same calling convention and object semantics. Perhaps Swift is easier to remember without some of the more unusual aspects of ObjC's syntax.
Depends on your goals, really. I think a big pitfall most people think is that the goal is to learn a language, when you really should be aiming to learn confidently learn as many as possible. You'll soon start to see how similar they are, and it becomes a lot easier to pick up.
The hard part actually isn't learning a language, but a framework. Frameworks are very platform specific, concepts are less reusable. And because Cocoa Touch is so intimately designed around Objective-C, even if you chose to learn Swift first, you'll need to know Objective-C anyway because of a) the amount of code/books/resources that exists on the internet in Obj-C vs Swift and b) a solution to your problem may only be written in Objective-C in a StackOverflow search result.
As for skipping academic CS, at some point you need to learn the stuff that almost every CS grad is expected to know at some level (data structures/algorithms, operating systems I & II, algorithm complexity (aka Big O notation), software design, etc...) not so much because they'll be explicitly required of you, but as you build larger and more complex apps, without them, code readability, maintainability, and performance are going to go to total shit. Granted, there are some, heck many, CS grads who somehow evade actually knowing this stuff, and things don't turn out so great for the code they write in the end.
My advice, tackle building an iOS app with a goal in mind, written in Objective-C due to the sheer number of resources out there, then expand from there.
I've been doing Obj-C for a few years now and I'm using Swift in a new project.
Swift all the way, mainly because Swift is just a much nicer language. Obj-C has a bizarre late 80's syntax which is not found anywhere else so it's very strange. Except for random places where it's not. There was a half-assed "Objective-C 2.0" which introduced dot notation but not everywhere or consistently. There's tons of things you can do with it that are unsafe and shouldn't work (found out a lot in translating some Obj-C code to Swift)
There's still going to be a bunch of Cocoa stuff to mess with (i.e., there's no intrinsic date concept so you have to mess with NSDate) but at this point learning Objective-C is a waste of time. At best you will have a few more online resources to consult with versus Swift but Swift is the biggest new language in a long time - a language designed by the biggest company on earth for one of the most popular platforms on the planet. The uptake is more or less unprecedented.
Anyone who prefers Obj-C just doesn't want to learn something new. Apple didn't invent a new language because of hipness reasons, they did it because their platforms are saddled with this shitty language which is missing modern conventions and is difficult to learn and use.
Just use Swift.
Schnapple
The noob has a problem with obj c: everybody in the world is already good at it. At least with swift, everybody is a noob and w six months of work you already know more that most. Also I highly recommend classes as a supplement to independent learning.
HR will still demand five years of experience in Swift.
No header files confuscate passed-on intended usage by exposing ALL class details rather than the intended consumable APIs.
Which is OK within the same app, especially since you can mark methods as private now.
Visibility is limited to what you can use when using a framework written in swift, you get what is essentially an automatic header view.
The idea is to write more small frameworks for more modularity.
Real-world test code being written showed you end up peppering your code with ? and ! symbols.
Not as true since the iOS frameworks were re-worked to indicate properly to Swift when something is an optional or not. The choice to use an optional should be a thoughtful one in your own code.
var view: NSView = anyObject as NSView
What's wrong with being explicit in casting? You had to do that a lot in ObjC also ( NSView view = (NSView *)myObject ) only now without the pointer syntax... as the tested casting is a much nicer concept since it fails gracefully if wrong, instead of just proceeding and crashing.
Your code end up having full of "as othertype" in it.
No, it really hasn't, not in real use.
Integration with existing code: Obj-C require Swift mangled name
Don't know where you got that, but just no. I've worked with mixed Swift/ObjC code, there is no need to use the mangled name - that has not come up in any way for real use.
String-types enums are a major fubar
Oh no, you have to call toRaw()? Never mind that in ObjC enums can ONLY be integers, not strings at all, which means you have to write a whole method somewhere to translate those ints into strings if you want an enum of strings, and also figure out where that method belongs... enums in Swift are a HUGE advancement.
The localized strings would thus expose the structure layout
Now that's just plain silly given that format strings in ObjC are simply passed the various objects in the call to format, and structure discerned from those pass parameters every bit as easily.
In fact what is REALLY silly is that ObjC is way more hackable, since it's all message passing... Swift takes that aspect away unless you re-enable it with things you mentioned like explicitly enabling KVC for methods.
I created a REST/JSON multi-threaded transaction framework with full JSON object parsing through an object factory that returned fully instantiated objects
That's interesting but sounds dubious since all of the JSON parsing Swift code I've seen is really compact, and I've been dealign with a lot of REST/JSON code in a production app myself, using swift. It's smaller. I've not measured speed but it's not much slower, if any.
Of course is real life you are just using NSJSONSerializer, right? Right?
That test framework was built with a multi-programmer, globally-spread coding team such as what I have to deal with at the office
I have to deal with the same stuff all the time, I'm a full time iOS consultant who has worked with a number of very large teams. I like the idea of a more modular app with more internal frameworks myself, it will REALLY help in a case like that.
I really think you are greatly mistaken about swift, you should use it in real development and not just a test case. Swift has already seen a lot of advancement and uptake...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
one of the advantages of Android that I haven't seen anyone mention is that you don't need to know C or C++ or ObjectiveC/ObjectionableC. Just a subset of Java
I was a Java developer for around a decade. Now I've been doing iOS development full time for several years, most with ObjC and recently in Swift.
The thing is, from a language standpoint all of those are comparable in terms of effort to learn - so if he doesn't know Java it's no harder to pick up ObjC over Java, or Swift over Java (and Swift has the advantage of being a lot lees verbose than the Java or ObjC, while still maintaining the good descriptive aspects of ObjC [named arguments]).
The real effort is in learning the frameworks for whatever system you are developing for, Java was actually the first platform I know of where that mattered more than the language because the frameworks were extensive - but so are the iOS frameworks.
As a bonus, you can develop for free on any laptop.
You can with iOS/Swift also, the simulator is very good and you could realistically write an entire app ready to ship to the store then pay for a dev license only when you felt you had something worth using.
What you gloss over is that with Android development you often NEED to have a device to develop, because the Android simulators are so poor/slow. If he doesn't already have an Android device where is that $100 advantage? Gone, and more than gone because to buy a reasonable test device (or several test devices which is more realistic) is going to cost way more than $100... I have an Android device I bought when abroad for around 70 EU, that is utterly worthless for development or even running apps.
Maybe you'll decide that, until you get that sorted out, you want to take a (probably low-paying, but with your degree, who knows where that will lead) job at some humanitarian organization
Which will have even worse politics going on than in a normal company, and probably be very draining for the soul... those are the kinds of places you want to volunteer for, not work for. They will eat you up rather than giving you the uplifting you speak of. Have you really worked for one or does it just seem like a good idea?
you don't have to worry too much about this
iOS developers have not had to worry about THAT because we have THIS.
Which is Infinitely better than having to research the dreaded other thing because your app just locks up at times...
Seriously, have not had to look for leaks in years.
it will give you the basics of OOP
Swift will give you the basics of OOP *and* functional programming, which is far more valuable going forward. And it's much more interactive since you can use Playgrounds to explore.
The demand for Java developers is either for people who know the Android frameworks really well, or incredibly seasoned IT developers with years of service experience. A few weeks of learning Java will be of little use in finding a job anywhere.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
No one's going to run a high availability web server, database or number-cruncher on a mobile.
Yes in fact they do. In fact if you stopped to think about it, all aspects of mobile computing correlate strongly to "high availability" concepts because the user wants an application that works fluidly, with as little delay or error as possible, and because it's a small portable device always with them, is less tolerant of said delay/error than with a desktop where we are all used to applications being slow at times.
Also of course, many mobile apps are simply arms of a larger system that is considered a high availability system, so the applications by default fall under that umbrella.
I've worked on mobile applications that have very large datasets, or a tremendous amount of processing of data from a server... it's not that uncommon.
Lag due to an algorithmic choice would be an even more unlikely occurrence
You are SO naive. That is in fact a HUGE problem for new developers on mobile platforms, something I have helped correct for many times, making a HUGE difference in how an application responds to the user. Any number of times it has been the difference between a feature even being possible on a mobile device.
A programmer will always be better with a solid grounding in CS, obviously; but your argument is misdirected.
Sorry if I only speak with several years of real world mobile development behind me, including some J2ME work in the past...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
There are some good things about the iOS ecosystem. For starters, if you require the latest iOS version, the piracy rate for apps will be at 0%. If you allow multiple iOS versions, just do a write or read outside your app's sandbox to check for a JB or not. Android has a non-zero piracy rate, but LVL and device-based APK encryption do reduce it to a dull roar.
You can still earn money as a developer. However, you can't follow the herd. If everyone is making fart apps, don't waste the time in making one.
Find a market segment and go with that. For example, Torque is an app that makes a lot of money. It isn't mainstream, but for the task at hand, it is extremely useful, and people will pay for it.
Some ideas/suggestions of what to do:
1: Make a GOOD PGP/gpg program. One that not just does the usual signing/encrypting/validating/decrypting, but uses the operating system's encryption (KeyChain) to stash the private keys. Coupled with an optional passphrase, this provides good protection.
2: Make a utility that can store files on multiple cloud providers at once. That way, if I stash documents and some sync error trashes one provider, I still have the documents saved somewhere else. If there are sync mismatches, give the user the option of using the document with the latest timestamp with saving the old one in an archive directory to be safe.
3: Create an app that is based on option #2, but also encrypts and presents itself as a WebDAV option. This way, one can use their phone as a drag and drop cloud storage device, with the app doing the backend encryption and distributed storage work.
4: A statistical analyzer similar to Minitab or SAS, but scaled down to a device.
5: A device that does TKIP/SKIP authentication like Google's Authenticator, but can use TouchID on iOS, a PIN/passphrase on iOS/Android, and can back the seeds up securely. This way, if I re-ROM my phone, I don't have to redo all my 2FA stuff... just re-import an encrypted backup and be back and running. With the option of a PIN, even if the device is stolen, one's 2FA IDs are still protected.