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?
How many times are the slashbots going to post this same stupid question?
I do not fail; I succeed at finding out what does not work.
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.
100,00,000!!!! *bwahahahaha*
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?
Or Swift. But definitely one of the two.
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 -
No matter what, -ALWAYS- learn C first.
Every language out there has it's origins in C. If you can't understand C, you will have a hard time understanding any program language.
The main thing that C is confusing for, is the concept of pointers. In higher level languages, you tend to stop using pointers and instead just keep copying data between objects, which is incredibly wasteful, but safer.
Degrees are next to useless, by now unless you've written your own pet project, then you're wasting your time, else you should go and be a project manager ...
At this point, Swift is actually reasonably stable in terms of the compiler not crashing all the damn time.
In general, I would learn Swift first - it is significantly higher level than Obj-C, and teaches you to think about good solid programming practices. Its type system is a lot more sane, and gives you extremely useful proofs (like that you're not going to dereference a null pointer).
That said, beware, there are a couple of headaches to look out for:
1) The language is not completely final. You can fully expect that with future Xcode versions, the language will change, and you will end up changing a few bits of your code.
2) When using very low level APIs like OpenGL, things can end up kinda clunky - basically anywhere where you need to pass around pointers to buffers that can't be abstracted away more, you're in trouble.
Finally, you will want to learn both (and C as well) in the end anyway, so in reality, a lot of this question is somewhat irrelevant.
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.
You could probably pull it off and due to the Dunning-Kruger effect you might even enjoy it.
But you would suck at it.
When full-on apps can be written in Swift (like when the language is up to it) iOS and all of the API stuff and most of the books and documentation and example code will still be in Objective-C, so you'll have to understand it. Once all of that starts getting converted to Swift then you will have to know Swift. It can be done on your own, but it is an uphill battle. Understand C and that will be half the battle.
potentially worthless social science field
So it's not worthless yet. Just potentially worthless. Maybe you've written it off because your idea of jobs that fit your training is too narrow? It would be nice if you could post what degree you have (not just so that we can give a better answer, but also to warn others if necessary).
Also, what sort of slack time can you allow yourself to get up to speed? Are you working either part or full-time to pay the bills, so you can do it at your own pace, or are you under the gun to get up to speed and make an income quickly? (if it's the latter, as we say, "good luck with that.")
These "ask slashdots" always degenerate because the questioner never gives enough relevant info.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
I would suggest going with Swift.
The problem is not so much learning the language. You need to learn how to solve certain types of problems and there is a lot of background knowledge you will need. You also need a way of thinking, the Tao of the Programmer.
My biggest suggestion is that you do not sit around or even shop around looking for 'gigs' but rather start creating stuff.
Good luck.
You should do the xCode anyway that your heart desires. It's all just 0s and 1s anyway. Think Binary. Think Apple. Think Different.
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.
I would learn objective-c first because you can get more help with it. People all over the internet have been doing it for a long time. It won't be obsolete for at least a decade, so don't stress about swift being the new way to do the same things. Find tutorials online or get torrents of books/buy them. Dream up your own micro-projects, when you get stuck http://stackoverflow.com/ is your friend. This site has saved me MANY times, usually within minutes. take a look at other peoples micro-projects and full fledged ones on https://github.com/ but above all, right some code EVERYDAY.
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
Practical professional stuff to learn about: design patterns, refactoring and test-driven development. Start learning this stuff as soon as possible otherwise you'll make all kinds of awful mistakes when your doing your first professional gigs (assuming you get to that point).
Helping with organizational effectiveness is our job.
It won't take you too long to learn how to write crappy code in either language. What you really need is a place to work that has focused goals, a clear set of programming guidelines that are built around writing code that others can read later, and the sitzfleisch to do the work.
Find a job with a boss who is passionate about his/her work and are demanding enough to make you want to do a good job. There is no quick rich scheme in the next couple of months, programming quality apps is about art as well as science, and both take a lot of effort.
But I promise you, your education isn't worthless, there may be unrealized benefits awaiting your team if you are willing to work at their level.
"Who are you?" "No one of consequence." "I must know." "Get used to disappointment."
Thanks for the comment. My degree is in public policy. I haven't given up hope on that either and am currently applying and interviewing. I've got enough money to give myself three to six months to get up to speed.
I would like to say this post is not intended to offend you, but I would be partially lying. I was an Economics major in college that send my free time fascinated by computing. The reason I was not in computer science is that I did not know there were jobs in the field and I thought I would live in my small town forever. You can read a few things and hack up some programs at a level similar to code shops in second world countries. With your education level it is likely you will understand the needs of a customer more than an off shore team. In the end you will hit a wall at some point. That wall may be good enough to pay more than your bills and you should then consider being a project manager, being good or bad at it barely matters. If you get enough tech knowledge then you could be a Technical Project Manager at a top 5 company. All of this will be harder as a contractor as you will not get as much exposure to new ideas.
Keep in mind that any skill that is easy to learn with no barrier to entry will eventually be worth very little. Computer Science has value because the same skills that make a great engineer make great lawyers and high finance analysts. Meaning, you have to keep paying them or they will do something different.
The good news for you is that at the bottom of the profession is enough money to feed a family and pay off what you fear is a worthless degree.
Good luck and if you want to be legit, go back and take the intro courses people are mentioning in theses threads.
Best course I took at university was assembly on a simulated CPU which showed me exactly what was going on when I issuing commands. Made me realize what was happening down in lower levels. While I don't touch assembly at all anymore (and never did after that course) the way it made me think about how the computer works definitely turned me into a better developer today. For a very basic example, because I had the experience with the simulator and saw what happened with function calls it's easy to explain why a factorial implementation that uses recursion will be slower than one that just uses a loop.
And on top of that you get nice insanity and ultra-low coding skills in the bargain!
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I second that. As an added benefit, you will not be locked into an environment and will get to know the smalltalk-OO model really well.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Or Swift. But definitely one of the two.
Not necessarily. You can write some C++/Objective-C wrappers for Apple's APIs, and then write the other 95% of your app in pure C++. Objective-C is a preprocessor, not a real language, and can be mixed with either C or C++.
Anyway, good luck making money as an iOS developer. It isn't as easy as it used to be.
Recent EDU Apple Tech Update led a bunch of us educators with mostly ancient programming skills through a simple app build in remarkably little time. Then see if you want to continue on to Obj-C.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
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.
1) There are plenty of books, and plenty of sources online. You can teach yourself. However, to become really good is probably more work than you can imagine, simply because you can have no idea the complexity of it all until you're well into it. But if you're willing to work hard and be patient, then go for it.
2) In this case, the first thing you need to learn is this: Fuck Slashdot. Go to www.lists.apple.com, sign up for the cocoa-dev mailing list, and ask your questions there. That is absolutely, positively THE first place for you to be looking for help. See you there ;-)
definitely c ironically the most modern programming language of the bunch.
maybe some day apple will finally get with the times and use an existing popular modern object orientated programming language like c++ or java.
you know, shortcut the whole process f making a feature-incomplete idiosyncratic and verbose programming programing language with inconsistent syntax and skip ahead to what everyone else had half a century ago.
why oh why don't they just use c++ or java?
sigh.
Depends on your form factor
Definitely Objective-C, unless your intent are for small home projects no one else will ever have to deal with.
Here is a bunch of random notes I took when evaluating Swift...
- No header files confuscate passed-on intended usage by exposing ALL class details rather than the intended consumable APIs.
Q: Is there any private/public scoping in the language?
A: None! It's wide open. Apple promised at the WWDC to fix that. But it will probably take the form of private/protected keywords much like C++ in the class definition. They seem hard-bent on not having public header files.
- Access Control
In Xcode 6 beta 4, Swift adds support for access control. This gives you complete control over what part of the code is accessible within a single file, available across your project, or made public as API for anyone that imports your framework. The three access levels included in this release are:
private entities are available only from within the source file where they are defined.
Internal entities are available to the entire module that includes the definition (e.g. an app or framework target).
public entities are intended for use as API, and can be accessed by any file that imports the module, e.g. as a framework used in several of your projects.
Ie: public class ListItem { // Public properties. public var text: String public var isComplete: Bool
}
Problem with that is regardless of access control, you are still exposing your entire class code and layout to users of it, preventing any restriction on class access for "consumable non-internal" implementations.
- optional means object can be nil. But they're just a wrapper.
Real-world test code being written showed you end up peppering your code with ? and ! symbols.
Using ! unwraps a var to it's value. CHECK FOR NIL or use if let
Ig target.foo?() unwraps to if [target respondsToSelector(foo)] target.foo()
-weak reference need to be optional
-Swift "module" import uses the project group name; change a file from group and suddenly is out of the module
-AnyObject = id or Class type
Can't upcast AnyObject to a static type
wrong: var view: NSView = anyObject
need to upcast using as
var view: NSView = anyObject as NSView
or tested
var view: NSView = anyObject as? NSView
- Arrays upcast arrays: for item in myItems as NSButton[]
Your code end up having full of "as othertype" in it. So much for inferred type.
Random bridging nastiness:
-NSError** gets magically translated as NSErrorPointer
and you still need to pass by reference: &error
and then receiver must unroll pointer using !
- useless notations like optionals:
foo?.prop?.prop?.prop.ToInt()
vs foo.prop.prop.prop.intValue;
Saved nothing. Obj-C can already handling nil object dereferencing
- Integration with existing code: Obj-C require Swift mangled name
SWIFT_CLASS("_TC5MyApp10MyDocument")
-STL-style templates
@objc func myGeneric(x:T)-> (String,String) {} ensures
func can be expressed in Obj-C at compile type
Need I say more?
- Specify obj-c accessor:
var enabled : bool
{
@objc(isEnabled) get {...}
}
further obfuscate the .swift file (remember: NO HEADERS!)
- Swift does not fix the CF bridging issue
Unmanaged for manual memory management. ie
let color = CGColorGetRandomColor().takeUnretainedValue()
Force the memory convention by annotating the header
CF_IMPLICIT_BRIDGING_ENABLED() //header content
CF_IMPLICIT_BRIDGING_DISABLED()
- String-types enums are a major fubar
Given
enum Method : String
{
case GET = "GET"
case POST = "POST"
case DELETE = "DELETE"
case PUT = "PUT"
case PATCH
You can work out the syntax in under a week. It's an academic exercise at worst.
The real problem lies in the language itself.
The playground is a cool nifty feature but it's not something that could not be done with clang/obj-c. There was a time we could fix-and-continue code at runtime. They removed the feature instead of fixing it (at a time it was based on GCC).
Even today, using framework for custom views in Obj-C, you can code changes in your view code and see live changes in your layout files (xibs/storyboards) as you work in the code (I love this new features).
Speaking of IB_DESIGNABLEs, while they are awesome for special view coding for drawing custom content, they still lack the ability of interacting with their subviews in IB (the code is being called to render the view, without it's content), making its use for layout views not possible (such as a content-sorting or layout view).
You should concentrate a learning some other language like C or C++ and using as little Swift / Objective C as possible to interface with the OS. That way your code is portable to other platforms. Either that's Windows, Android, XBox, Wii, PS4, Linux, whatever.
Depends on if it's a generic floor or a dynamic floor.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
HR will still demand five years of experience in Swift.
iOS and all of the API stuff and most of the books and documentation and example code will still be in Objective-C
This is not really correct.
The entire Objective-C based iOS SDK now presents a swift-translated version of the API.
Also ALL of Apple's documents currently present side by side the ObjC and Swift API.
There are also a LOT of books and online courses now that are swift specific, with the side benefit that you won't be confused about which ones are two years old (or older)...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Using tools like Openframworks and especially cocos2d-x you can make things for iOS in C++ that are extremely easy to port to Android, or Windows, Mac desktop, linux, and the Windows mobile OS.
You don't have to do things the way apple tells you to do things.
I've been doing iOS development full time since before the release of the Apple App Store.
At this point, anyone trying to get into iOS development should, no question, learn Swift.
Apple has indicated as clearly as they can Swift is the primary language moving forward. All of the most experienced iOS developers I know are rapidly learning swift, much new work is being done in Swift.
There's also no shortage of Swift books either available or soon to be released, and lots and lots of online courses covering swift specific stuff for people new to iOS development.
One other benefit of going with Swift is you get to use Playgrounds to dynamically play with Swift code and see what things do. There's a ton of benefit to that interactivity when learning a new system...
I would recommend starting with the 6.2 beta version of XCode (the one that was released with WatchKit support) since the current XCode in the app store can get a little crashy with some Swift code. By the time you have anything written you might want to release, 6.2 will be out of beta (sometime in January I'd guess).
ObjC is still useful to know as some philosophy behind it is embedded in the SDK - but what is useful to know will easily be learned in snippets as you go along learning iOS development, Swift is a better choice for primary language for new projects.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Swift must be a really good language. Every so often, I get E-mails from recruiters with positions demanding five years of Swift programming skills as part of the core position.
Objective C will be dropped in the future. Once Apple says "This is the way to go," it *will* drop the old one sooner rather than later. Carbon, Rosetta, and WebObjects are examples of previous technologies that Apple has killed off.
The above has been my strategy. Admittedly I've never done coding for pay, however I've been coding my web site, I've written some Android apps, etc.
When I first learned to program, it was BASIC. Later in college Turbo Pascal - which was dead easy to me as I knew BASIC, meaning I knew about the key paradigms of programming. Another decade or so later I had the need to write some small software, and in a few days I got myself going in Python - to this day my language of choice. HTML was added when the need came to design a web page, and the moment it needed more complexity the python module for Apache appeared together with MySQL. I wanted to write an app for my phone, so got myself going on Android and learned the Java that goes with it.
I've taken the same approach with my current business as tour operator. I know my way around my area well, I know many interesting hidden spots, and decided to just start doing tours. The learning how to do it, came as I went. I started by getting some general advice on the Internet, followed by just doing some tours, and see how it went. I learned a lot, really fast. I found out I miss parts of knowledge, and dove into those specific subjects.
Anyway, long story short: my general advice is to learn what you need, as you go.
Your disadvantage is that you don't know any language yet; Python is considered one of the easiest ones to learn these days, and can give you the basics of object oriented and procedural. I can't say "if you know one, you know them all", but that's not too far from the truth. All languages use, at their core, the same paradigms, and those paradigms are the hard part of programming. Understand them, and the language is just a way of expressing it. Also the more languages you know, the easier it gets to learn yet another one.
In this case, based on the comments, maybe you should start learning Swift first. Or try both, spend an afternoon browsing some tutorials in both langauges, and see which you find easiest to grasp. The moment you need the other language it'll come easy. Maybe you'll get a request to add an Android version to an existing iOS app - I'd say just take it, grab the dev kit, learn Java as you go - by then at least you already have a basic understanding of the pitfalls of mobile development, you just have to learn a new language. You may risk pissing off your first employer for Android apps because you're too slow (learning takes time) but the next such job will go a lot easier already.
Interesting read, thanks. Wish I had something more insightful to add, but I haven't had the pleasure of giving Swift a try. From what you describe though, it sounds like it would drive me bonkers!
Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
1. looking at the "nuts and bolts" issues - pros and cons of each language. The problem with that is that you don't have enough experience to properly evaluate the answers. I know, it's a catch-22 - if you had that experience, you wouldn't be asking, right? Which brings us to:
2. stepping back and looking at methodologies - the hows of developing maintainable code, refactoring, etc. The problem with this is that, until you have some language experience, all this is theoretical and won't mean much to you except as abstract ideas. Which brings us to:
3. arguing for different platforms -- iThingies vs AndroidThingies - and 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 (language syntax, some boilerplate for how to make a class, the manifest files, resources, and a few other things). As a bonus, you can develop for free on any laptop, put any android phone into dev mode, and load/run your app on your phone quicker than you can launch it in the emulator. And no license fees. (cue everyone who says the average iPhone app earns more than the average Android app. The fact is that most earn either nothing or less than $100/month - see my post here with links to citations). Which brings us to:
4. taking a step back and asking "Do I really want to do this?" "What else can I do?" "What really floats my boat?" 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 that will give you a different perspective on life while you brush up on your code skills in your spare time.
Before you do decide to get into it, I'd suggest taking a few weeks to learn Java first (plain Java, not Android), even if you decide to go into iThing apps - not only is there still a demand for Java developers, but it will give you the basics of OOP, which you'll need anyway, the syntax is pretty much the same as the C family of languages, you don't have to worry too much about this, and there are plenty of free tools out there. You should be able to get started with a simple "Hello, world!" command-line Java program your first hour.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
You can't realistically do iOS development without knowing Objective-C; its just no feasible since all Apples frameworks are written in it, all the open source libraries use it, and all of the stackflow answers are for it. And fortunately, it is not a bad language. Swift is a much better language, at least potentially. It is still a bit rough to use. But it is sure to replace Objective-C over the next few years, so you would be a fool to ignore it. To address the larger question - you should get some formal computer science instruction if you ever expect to land a job. You have to have something on your résumé.
Basically the overlap between CS and iOS programming of apps, is near zero.
Wow, is that ever wrong.
Programming a mobile device, where many aspects are constrained (memory, CPU), means CS knowledge matters WAY more than it has for some time in desktop or even server programming.
All of the various frameworks in iOS can be used badly, or they can be used intelligently, a knowledge of CS being the difference between an annoying lag app and a responsive one that doesn't take a week to handle a realistic amount of data from a user.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
You're basically using all the Cocoa classes, just with a bunch of extra wrapper code
You are using the frameworks directly. There is no "wrapper code". How the API's look to swift has been refined, but there on no layers over said API's...
in a language that's slower than Objective-C
An explicit goal of Swift is performance, and it's already faster than Objective-C when optimized.
for little real benefit beyond syntactic sugar
I'm sorry, how are Tuples mere syntactic sugar over ObjC? Or operator overloading?
That's either a hell of a lot of sugar, or a new dish.
The fact is that Swift is a truly new language that brings a lot of functional programming concepts into play for iOS development.
Worse, as things stand right now, if you start out using Swift, you're going to quickly start running into walls where the introductory documentation you need just doesn't exist yet.
What intro documents are those exactly? Apple has two free books on Swift, there are countless "getting started with Swift" resources online, there are also many books either out or just about to be published.
Point at one aspect of iOS development that has no Swift documentation. Just one.
learning Swift requires a fair degree of masochism right now
That was true a month or two after Swift launched, but is not at all true now.
You simply have no concept of the speed of uptake Swift has had in the realm of the most serious iOS developers, who have already suffered the slings and arrows of misfortune and have draw everyone else a nice map of where to go based on experience...
So no, new developers to the platform should definitely start by learning Objective-C
I've been programming only for iOS since before the App Store was launched, and worked on scores of real world applications. Have you?
My advice is 100% the opposite of yours, because Swift offers so many benefits to someone new to either ObjC or Swift and Apple has clearly moved to make Swift the primary development language going forward.
In two or three years, assuming Apple doesn't drop Swift like they did their last three or four scripting language bridges
And I'll leave you with that dangling statement for the ages... *facepalm*
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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
I would argue that learning how to teach yourself new skills and seeking out best practices, while being aware of what you don't know, is absolutely the key to becoming a skilled programmer.
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
an offtopic thought on this... you describe your degree as "potentially worthless". I can see in your posts the frustration and the urgency in landing a job. But before giving up on your degree, I urge you to take a longer view. First off, the science of public policy is basically the study of governance, what has worked well and what has gone horribly wrong. This knowledge is urgently needed today more than ever. Further, without public policy experts, the govt would be run by plutocrats and warmongers (even more-so than today), and the ranks of govt agencies would be be filled with patronage toadies and syncophants. You must have chosen the grad program because you had a passion for the topic; please don't give up now when your knowledge can have a great impact.
second, jobs suck and job searches suck. I was in a similar boat, coming out of a graduate program with a somewhat specialized degree. Some suggestions based on my own learnings and failings:
* general HR job posting are not a big win. This is a hard way for somebody with a specialized degree to find something that's a good fit.
* lean on your classmates and alumni. Your classmate cohort, where did they end up? Recent graduates of your program, where did they end up and how did they get their jobs?
* informational interviews. These are awesome. its where you schedule a call with somebody not to get a job or talk about a potential opening, but just to talk with them about what they do, and how they got there. Often these can lead to other networking connections.
* be prepared to move. when you're specialized, you may need to move to where is the epicenter for your specialty. I don't know anything about public policy, but presumably DC, state capitals, etc?
Anyway, some unsolicited advice. I hate it when people give me unsolicited advice. Nosy fuckers. Best of luck.
Given his background, who in their right mind would employ him in any of those roles? Perhaps he has a nice hairstyle or something. http://dilbert.com/strips/comi...
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
Learning Objective-C takes a couple of days - a week at most. Leaning the frameworks takes a lot longer. Swift has a new core library, but most of the other frameworks are the same, so the experienced programmers still has an edge.
I am TheRaven on Soylent News
Objective-C is a preprocessor, not a real language
Objective-C is as much a preprocessor as C++. As in, an early implementation of the language that is very different from the modern version was implemented as a translator that emitted C (StepStone's Objective-C compiler, the 4Front C++ compiler).
I am TheRaven on Soylent News
iPhone has a 11% market share, Android has 85%. At the same time, there are more ios developers than Android developers. If you want to plan your career, you learn Android.
no, I don't have a sig
Most people do not have a clue how to use Objective C right. What "world" is that you are talking of?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The API is. By faaaaaaaaaar the most work is going to be to learn all the NS_xxx classes and how you write and plug together an IOS app. The language on which this is built is small in comparison. The libraries and APIs and things that you manipulate is where the action is.
Same goes for Java. the Java APIs are waay more work than Java, the language. If you learn Groovy or Clujure, which both run on the Java platform, you still need to learn the APIs or you won't achieve much.
And so on for Ruby and any other language.
That said, I would shoot for Swift if I was a beginnner.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
HR will still demand five years of experience in Swift.
There are, RIGHT NOW people with 5 years experience in Swift. Most of them work at Apple. If HR is willing to pay REALLY high wages, they may be able to lure them to work elsewhere.
*** Suerte a todos y Feliz dia!
A world in which a man is judged by the bullets on his resume, not by the knowledge in his head.
just learn swift (if you are too lazy to learn both).... if you are trying to be employed as a professional at a company you need to learn both. ideally you should learn both. the funny thing is that the most complicated part about ios is not what language you use... its how cocoa and uikit work. once you understand that then you will find that the language is secondary.
> world in which a man is judged by the bullets on his resume, not by the knowledge in his head
This world, then.
> presents itself as a WebDAV option
Lolz. And you get to it using a QR code!
> No header files confuscate
Ugh. More inside-the-box thinking. You don't need header files to do this right, which is your implication, and ideally you want more than one API for another. Dylan, yes, *Dylan*, did this way better than any language I've seen since. You could have a private API, a public API, a beta API and a release API all from the exact same code.
While it's true that using headers makes certain aspects simpler for the compiler author, it's also true that it pushes that work onto the end user - you - by forcing you to keep your headers up to date with manual edits. One could semi-automate this, but that's precisely the purpose of public/private. I have yet to see a real-world use-case where public/private didn't work.
> you are still exposing your entire class code and layout to users of it
How is that?
Businesses that will pay you for a simple iOS app will also want an Android app. So you want to learn a cross platform toolkit like Cordova, where your existing HTML/CSS knowledge will help. Big players like Facebook that can invest in separate codebases for a sophisticated app will not hire you without a C.Sci degree and relevant experience. At this point, also consider that mobile development is difficult and is only a small part of consulting jobs. Good money can be had writing Hadoop jobs that require much less code and no lengthy tweaking needed for good UX.
Now, if you just want to get your hands dirty and see what mobile development is about, without expectation of immediate payoff, Swift is as good of a place to start as any. Definitely not Objective C for the first language. It's not bad, but it's a conglomerate of C and OO parts, and it takes time to learn each one separately.
Not always, but unfortunately in the majority of cases. So advice to the OP would be to put both languages on his CV and learn none.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Both are incredibly well-designed languages with some tricky parts but a lot of smooth sailing.
Swift seems to be solid enough that it's ready for most use cases - or perhaps closer to a quarter or a third of what you need to do every world-class app out there.
If you focus your next few months on Swift you'll be fine. There are lots of good examples, courses, lessons, blogs, and clever people who can answer questions.
However you will find yourself missing out on a lot of easy wins - particularly in cases where you read some Objective-C code and want to know how to translate it into Swift for your projects.
Objective-C is easy enough to learn - if you are going to be mostly just reading it. If you are writing it, of course, there are some tough things.
Either way you absolutely cannot go wrong and you will end up knowing both very well within a year.
Objective-C is a preprocessor, not a real language,
From which we can deduce you know very little about Objective-C.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Because credentials matter to people that will hire you:
http://www.networkworld.com/ar...
Computer Science (CS)Rank: 8; Starting salary: $59,800; Mid-career salary: $102,000
Median salary for a non-degreed programmer is lower and chances for promotion are poorer and chances of getting hired in the first place as a programmer are lower if you don't have some kind of degree. With no degree, you'd likely have to work your way into that from some lower-ranked position.
Also because a CS degree really does expose you to different things that just programming does. You wind up knowing things that you're unlikely to discover on your own in a programming job, or likely to take much longer to discover.
I agree a CS degree may not be the best course. Software engineers start higher and have a higher median salary so that's probably a better use of a college education if you're able to take that path.
An associate's degree may also be a good compromise because it's a lot cheaper, quicker and has lots of formal training focused on core skills rather than the sprawling educational experience that is any four year degree.
Also an advantage of the associate's degree is that you can apply that as credit toward a BS if you later decide that you want or need more credentials to get the job you want.
But the idea that you are going to learn enough to be usefully employable in a couple of months is not realistic. With a background in a social science field, he's got some understanding of basic math and probably a good grounding in statistics and how to do research and maybe formal logic if he's lucky. He won't be able to become a competent-enough-to-hire programmer without years more study, whether or not it's self-study. He should think about leveraging what he knows. A MS in any science field has studied and (if he was a good student) knows a lot of different things that he can apply to jobs in many fields. But unless he has done quite a bit of programming, that's not one of them.
But it's not answering his question. He just spent five or six years getting an MS in a social science field. How can he use that? It won't help him program, but it could help him do a lot of other things.
Just in the past month or so I decided to make the jump and learn iOS programming. My experience is not at all similar to yours in that I have a CS degree and have been a full-time programmer since '94, and have been developing Android apps for over a year, and Blackberry apps before that, and PalmOS before that. Had I known Apple was in the middle of a language switch, I would have put it off a lot longer. It should be obvious that the one to learn is whichever one will win out in the end. There is no since in learning a language that will never take off, nor in learning a language that is being phased out.
So your goal is to predict which one will win. And, statistically speaking, the odds aren't in Swift's favor as almost all new languages fail. Granted, most of those don't have the power of a company like Apple behind it, but VBScript is one example that failed to catch on with an even more powerful company behind it. Microsoft had tried and failed several times to introduce VBScript in different environments. So, just because Apple wants it to succeed, and says it's the "new thing" in their documentation, doesn't mean it's going to. On the contrary, JavaScript is a good example of a language that likely would have failed, but has been immensely successful solely due to Netscape's adoption of it. So, which language is better really won't matter as far as which one wins in the end.
My current take on Swift is that it's too difficult to find working examples on how to call the framework libraries. That's not to say they don't exist, I just haven't been able to find them. Most of what you find on Google today is from the beta versions of Swift, and they're not syntactically compatible with the current version. It's certainly possible to figure it out yourself, but takes quite a bit of time. So the question boils down to: "If Swift wins, will you waste more time trying to figure out Swift today, or will it be more efficient to learn Objective-C today and switch to Swift after it's won?". IMHO, Objective-C is the answer today, and if you combine it with the fact that Swift will likely fail just by playing the odds, then Objective-C is the clear winner. If Swift wins, you'll likely spend a lot less time learning it later than you will spend learning Objective-C today.
Reading the comments above, there's obviously no shortage of people who think they absolutely know which language is the future, but I'll be the first to admit that I don't know. You'll have to hedge your bets they best you can. But if I were a betting man, I'd say Swift will fail as it's got several serious strikes against it:
- Most new languages and platforms fail
- It's a proprietary language with only one use case.
- The one use case it has (iOS) is declining in market share.
- The launch appears to have been botched with few sources of documentation available on how to actually use it for iOS programming.
- The language has already been polluted by the beta versions, leaving newcomers with no way to discern from the old and the new.
- Apps in the App Store are no longer the cash cow they once were, reducing the benefit for people to spend time learning it.
- Since iOS is declining, even if Swift wins the iOS language war, it's possible it won't be relevant.
- For existing programmers, there is no economic benefit to switching to Swift
- Swift brings no new functionality to the table, so there's no reason to switch to it other than Apple wants you to.