Ask Slashdot: Objective C Vs. Swift For a New iOS Developer? 211
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 (Score:2, Interesting)
How many times are the slashbots going to post this same stupid question?
Learn both (Score:5, Interesting)
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.
Learn both (Score:4, Insightful)
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.
Professionalism Re:Learn both (Score:3)
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).
The language is not relevant (Score:2)
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
Re: (Score:2)
I'm sure that there are plenty of construction workers who know how to "build buildings" that don't think you need an archictecture/structural engineering professor to teach you how to build a building.
So it depends if you think "building a building" means physically building it, or properly designing a building.
That is as far from the truth as you can get (Score:2)
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 o
As I said, you are VERY WRONG (Score:4, Insightful)
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...
Further reading (Score:5, Informative)
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/... [slashdot.org]
Re: (Score:3)
To be honest, I would rather focus on .NET / Xamarin / Mono especially in light of the new open source announcement and the fact that it can be used to target multiple OS and form factors. The choice is also based on the assumption just you won't be doing anything really cutting edge in terms of programming. I have yet to run into a capability request that I couldn't make do in c#
Re:Further reading (Score:4, Interesting)
.NET with Xamarin is one of the better development/cross platform options for mobile development, the fact you dismiss it so quickly shows a great deal of ignorance on your part.
Re: Further reading (Score:2)
.net catches a lot of gried it doesnt deserve. Mono w/ xamarin is a great high level environment.
Concurrency is even easier than java.
Re: (Score:2)
Sorry if I came off as abrasive; I aim for humour, not insult. Any teasing is meant in good fun ^_^
First off, probably the majority of successful coders are largely or fully self-taught. This [xkcd.com] comes to mind. Don't worry about not having professors to hold your hand, but do make sure you take time to study the 'boring' parts like theory, testing and optimization.
If you're getting into iOS development today, you'd be wrong to pass up Swift. It may not be perfect yet but every language has flaws, and Swift will
Re: (Score:2)
An interesting summary, but you should really group Swift with Python/Ruby in terms of what you get from learning it from a pure language standpoint.
I totally agree with the sentiment it's better to know a number of languages...
Re: Further reading (Score:2)
iOS has a much larger paying audience...
http://bgr.com/2014/06/26/ios-vs-android-developer-revenue/
You're Never an Idiot (Score:5, Insightful)
For wanting to learn something.
Re:You're Never an Idiot (Score:5, Funny)
Except homeopathy.
Re:You're Never an Idiot (Score:4, Funny)
Homeopathy is not something, it is nothing.
Re: (Score:2)
LOL!!! Although I have to say, that even learning _about_ homeopathy would probably be a good idea... just to avoid it.
Re:You're Never an Idiot (Score:5, Funny)
Re: (Score:2)
The less you learn about it the more you know.
Re: (Score:2)
Or astrology, or scientology, or anything that has OOGY BOOGY aspects.
Basically Stay away from anything with oogy boogy aspects with one exception, Quantum Entanglement feels very much oogy boogy. but it has been demonstrated as real with real scientific process. It's simply something we do not understand but HAVE PROVEN does exist.
So if it has oogy boogy and no proof of it's existance, run away.
Re: (Score:2)
The problem with homeopathy is people not learning enough about it.
Aside from the people who just lie, of course.
Re: (Score:2)
Surely the less you learn about it, the more effective your knowledge will be...
Re: (Score:2)
The original "homeopath", Samuel Hahnemann, actually had useful things to say and was careful to document and test his claims. The modern followers of homeopathy seem to have completely lost touch with his original claims. He believed in _testing_ medical claims, and did his educated best to verify his work and older medical cleaims. Given that he was working in the lat 1700's, he deserves credit as an enlightened medical scientist.
What happened to his work after his death would clearly have shocked and hor
Re: (Score:2)
1) That is wrong. Most of the homeopathic medicines are not diluted at all
Would the outcome to the patient be any different if it were?
Re: (Score:2)
No idea, depends on the medicine I assume. E.g. chamomile or arnica based medicines are well known to work very well.
No idea what point you want to make.
No idiot.Go with ObjC (Score:5, Informative)
1 vote for objective-C (Score:5, Interesting)
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.
Re: (Score:2)
That is the biggest nonsense about programming languages I ever heared.
Objective C is unreadable bitch just like Perl or IBM/JCL.
To learn Objective C if you can do the same thing either with C or C++ or, that was the parents question: with Swift, is pure masochism!
Sorry, but who in his sane mind would learn Objective C? Did you even ever try to read a page of code written in that language?
Bottom line I don't get that fear about APIs repeated here on /. all the time. WTF, there are modern IDEs out there. The
Go with Swift (Score:3)
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 learn both of them (Score:4, Informative)
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.
Re: (Score:2)
As far as I can tell, Swift is just a new front-end to the Objective-C object system.
No, that's not true. Swift interoperates with Objective-C, but it's not any kind of front-end to it, it works perfectly fine by itself.
Most of the libraries and frameworks you will be working with are system components where you don't see the source code. Whether they are implemented in Objective-C or Swift is an implementation detail y
how to learn (Score:2)
Depends... (Score:5, Informative)
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.
Swift (Score:5, Insightful)
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.
Re: (Score:2)
There's going to be tons of Cocoa stuff to mess with. You're basically using all the Cocoa classes, just with a bunch of extra wrapper code, in a language that's slower than Objective-C, for little real benefit beyond syntactic sugar.
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. And when you get into trouble, you're going to go searching for code snippets on Stack Overfl
Not current, or accurate (Score:3)
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 [jessesquires.com] when optimized.
for little real benefit beyond syntactic sugar
I'm sorry, how are Tuples mere syntactic sugar over ObjC? Or operator overloading?
Re: (Score:2)
For most Objective-C classes, that's true, but I was under the impression that Swift's array and dictionary support consists of wrapper code around NSArray/NSDictionary; I'm not certain of that, though.
Operator overloading is, IMO, almost inherently a mistake. And tuples are pure syntactic sugar. Anything you can do with tuples can typically be done without tuples in just a couple more lines of cod
Re: (Score:2)
Operator overloading is, IMO, almost inherently a mistake. And tuples are pure syntactic sugar.
don't like operator overloading either but you can't just hand wave t away as syntax sugar because you don't like it.
Also tuples are way beyond what I consider syntax sugaring as they replace quite a lot of parameter nonsense and lots of extra method definitions because of elements being optional.
The entire networking stack has no Swift documentation except for a very trivial NSURLSession example.
NSURLConn [apple.com]
Re: (Score:2)
The uptake is unprecedented? Really? I imagine it will be approximately the same, or less, as the uptake for Obj-C when iPhones became a thing, which is "not terribly impressive". You're essentially forced to program in Obj-C for the iPhone, and it's still a niche language. People who write Mac-specific applications and iPhone apps use it, and essentially no one else.
And the thing is: Objective C could theoretically be used other places. The bindings are there for people to write an OSS GNUStep-based a
Re: (Score:2)
Suddenly becoming one of the fastest growing programming languages in use [stackexchange.com] and making several top ten lists isn't terribly impressive? Ok...
So, one of the mos
Re: (Score:2)
I'm mostly with this. My biggest problem with swift is there are still some holes in the compatibility with C code -- I was doing a project that called into CoreAudio to do some conversions, and the CoreAudio API required me to give it a
It's less about language and more about practice. (Score:3)
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.
Assembly (Score:3)
You'll get through Swift faster. (Score:2)
you're not totally an idiot (Score:2)
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, positiv
Re: (Score:3)
2) In this case, the first thing you need to learn is this: Fuck Slashdot.
I thought Slashdot BETA already took care of that :-)
Re: (Score:2)
Don't forget C++ is an option (Score:2)
You don't have to do things the way apple tells you to do things.
From an experienced iOS developer - Learn Swift (Score:2, Troll)
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 s
No Other Option - Go Swift (Score:3)
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.
Learn what you need, as you go (Score:2)
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 c
Learn both! (Score:2)
Re: (Score:2)
This isn't the case. It doesn't matter whether a framework is written in Objective-C or Swift, you can use it from either language regardless. You can write an application from start to finish in Swift without needing to know anything about Objective-C. Sure, if you do know it, the
11% market share (Score:2)
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.
Neither is the best plan to make money (Score:2)
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 m
Re: (Score:3)
For reference, no, they don't actually do a bunch of copying between objects, they just abstract pointers behind pass-by-reference semantics. Swift even takes this one step further, and for structs/enums (which, like C, are pass-by-value), it implements pass-by-value using copy on write, so it in fact does even fewer copies than a C program would (without the programmer jumping through hoops to implement copy on write himself).
There usually *are* more inefficiencies in high level languages (usually due to
Re: (Score:2)
You need to extend your frame of reference before the last decade.
P.S. Does your mom know you're using her slashdot account?
Re: (Score:2)
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 ma
Re: (Score:2)
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
iOS is free to play with also (Score:5, Informative)
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... [cubrid.org]
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.
Re: (Score:2)
Where do I start?
In case you haven't heard, decent android tablets are going dirt cheap. Quad core name brand tablets are now ~$140.00 (I've seen a few good ones as low as $125.00). That's what happens when you have an open market instead of a monopoly - competition makes prices drop.
He doesn't want to "find a job anywhere" so your remarks about "A few weeks of learning Java will be of little use in finding a job anywhere" are irrelevant. He wants to do this:
Several of my friends who were in similar situations after grad school have done so and are making a healthy living getting contract work.
The advantage to this is that even if it tak
Re: (Score:2)
In case you haven't heard, decent android tablets are going dirt cheap
Which, to be clear, is still going to be more than the $100 the dev program costs.
Cheap is relative... I can claim the dev program is dirt cheap also (which it is), and as I said you don't have to spend ANYTHING until you have an app you want on the store.
Several of my friends who were in similar situations after grad school have done so and are making a healthy living getting contract work.
Which means they learned iOS development, not Ja
Re: (Score:2)
In case you haven't heard, decent android tablets are going dirt cheap
Which, to be clear, is still going to be more than the $100 the dev program costs
And after one year, you have to fork out another $100 to Apple, so your cost over 13 months is $200. And the approval process through Apple is ... well, just google for the pitfalls. And if he needs a smartphone anyway ...
Several of my friends who were in similar situations after grad school have done so and are making a healthy living getting contract work.
Which means they learned iOS development, not Java generally.
And as I pointed out elsewhere, one thing he can do to "get his feet wet" is to ask them if they would mind if he converted their apps to android. This way, they don't see him as potential competition, and he has a specific project to follow from the get-go.
he needs to be flexible enough so that he isn't locked into just mobile development,
thought you said he didn't have enough time to learn two things, how your tune changes as you dance...
And that's the beauty of it
Re: (Score:2)
And after one year, you have to fork out another $100 to Apple
Even a cheap Android tablet that's realistically useful for dev is $200+, and it's certainly not going to be useful for dev after two years. So that's at best a wash.
But AGAIN, you don't have to pay $100 until you have a shippable app, not true with the state of Android emulation.
The majority of app store devs fail to make a profit, the top half of 1% make 99% of the revenue, the gold rush is now over.
The easy money is over, but what you say is
Re: (Score:3)
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 (ev
Re: (Score:2)
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.
Re: (Score:3, Informative)
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 d
Re: (Score:2)
Corrections and Refinements (Score:5, Insightful)
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...
Re: (Score:2)
The code was written for production consideration. In the end, the Obj-C version was retained. Yup. NSJsonSerializer. The was a level of abstraction around it to allow using a different (and faster) engine but not during those tests.
The wrapper includes facilities to map the resulting NSDicts to corresponding classes if they existed, or use custom class maps for customizing recipient objects based on calls. This conversion of dictionaries to class instance is recursive. Meaningful keys are also trapped on a
Re: (Score:2)
That was the part that Swift had shortcomings.
So a bit like RestKit (which I hate BTW, though not because of what you are trying to do), it doesn't seem like that should have been more code in Swift.
RestKit itself is a massive bloated thing, which would be way easier to have a lean version of written in Swift..
About them enums, I'm saying that havng to use a specific toRaw() to access the value is effin idiotic
It's not because mostly you are using the symbolic values from the enums - it's handy to also be a
Re: (Score:3)
Actually, it was the other way around.
I started with a blank project to write a Swift framework in order to learn the language and reach a usability goal of signing into a production server, make a couple of REST calls and yield out Switch class instances in a hierarchy, through unit tests. No UI.
Then I proceeded to replicate the same thing in Obj-c using the same class hierarchy, same object model. There was a near 1:1 correspondance in the whole thing. Where things differed were where Switft could not dir
Re: (Score:2)
and the type of 'version' will be inferred all right. This misunderstanding of the language shows that your code maybe that long because of you, not because of Swift.
Re: (Score:2)
> What's wrong with being explicit in casting?
Nothing, but why do we need more syntax for it? That's my real complaint with Swift - lots and lots of one-off syntax in places where it didn't seem to be needed. What's wrong with:
var view: NSView = (NSView)anyObject
It's just as explicit, yet this uses familiar syntax that everyone already knows and uses. For that matter, why did they decide to use this syntax:
var view: NSView = (NSView)anyObject
When:
NSView view = (NSView)anyObject
It exactly the same in term
Re: (Score:2)
> 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
Re: (Score:2, Informative)
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.
Re:Objective-C (Score:4, Interesting)
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.
Re: (Score:2)
> presents itself as a WebDAV option
Lolz. And you get to it using a QR code!
Re: (Score:2)
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).
Re: (Score:2)
And on top of that you get nice insanity and ultra-low coding skills in the bargain!
Re:Objective-C (Score:4, Insightful)
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.
Re: (Score:2)
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/stor
Re:Objective-C (Score:4, Insightful)
5 years of experience in Swift (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:3)
Re: (Score:3)
Most people do not have a clue how to use Objective C right. What "world" is that you are talking of?
Re: (Score:2)
A world in which a man is judged by the bullets on his resume, not by the knowledge in his head.
Re: (Score:2)
> world in which a man is judged by the bullets on his resume, not by the knowledge in his head
This world, then.
Re: (Score:2)
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.
Re: (Score:2)
Depends on if it's a generic floor or a dynamic floor.
API all has Swift translation (Score:2)
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)...
Re: (Score:2)
Only the API reference documentation, not the conceptual docs, the sample code, etc.
Re: (Score:2)
Only the API reference documentation, not the conceptual docs, the sample code, etc.
All new sample code (since WWDC) has swift examples.
Also any example code you may need for any framework (CoreData, MapKit, etc). is easily found online now.
The conceptual docs, being conceptual, hardly matter as to language mentioned... the concepts are easily used.
Re: (Score:2)
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.
The problem is that the poster isn't even at the bottom of the ladder. He hasn't stepped on even the first rung. And pay at the bottom won't pay your bills. Not when you're competing with everyone else who finds themselves in the same situation - new to the field, no practical experience, etc. And even when he gets to the point where he can make an app, the numbers are awful [techcrunch.com]:
Accounting for 47% of app developers, the “have nothings” include the 24% of app developers – who are interested in making money, it should be noted – who make nothing at all.
Meanwhile, 23% make something, but it’s under $100 per month
and this [ibtimes.com]
How Do You Make Money When Less Than 1% Of Apps Are 'Financially Successful'
and this [arstechnica.com]
There is no shortage of stories about lone developers who made an app for the iPhone or iPad and had runaway success. But in the real world, the majority of app makers struggle to break even, according to a recent survey by marketing firm App Promo. Though the survey's methodology is a bit on the light side, numerous developers that we spoke to agree that the results -- 59 percent of apps don't break even, and 80 percent of developers can't sustain a business on their apps alone -- are close to accurate.
I'd be shouting "It's a trap!" but I think with these numbers, I don't have to. And the numbers are only going
Re: (Score:2)
Right. Because every time I visit a small town I can't walk out the door without bumping into an economist.
Re: (Score:2)
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... [dilbert.com]