Why many developers still prefer Objective-C to Swift
hackingwithswift.com
hackingwithswift.com
If I had my way while were planning out a "big" app, it would be ObjC.
- ObjC isn't going anywhere, and it continues to receive improvements
- Xcode 9 can still barely handle large Swift apps; I consistently lose syntax highlighting and autocompletion
- Equivalently sized ObjC apps clean build in approximately 1/3 of the time
Swift as a language is fine. There were some neat new concepts it forced me to learn, and I look forward to writing it. But the tools make me want to work on anything else.
edit: Also I was really, really looking forward to Swift 4 & Xcode 9. I hoped there would be improvements in build time and less IDE problems, but I see no noticeable change in build time, and Xcode routinely leaves me unable to quickly make changes to Swift code, either because indexing failed and autocomplete is suggesting random shit or because autocomplete isn't there at all. Then I switch tabs and for a moment I'm looking at syntax highlighting until it just... disappears. Maybe changing a line will fix it, maybe it won't. Xcode 9 might actually be worse in this respect.
1. Use modules.
2. In Xcode, go to your target, go to Build Settings, and at Other Swift Flags, add the following flags: -Xfrontend -warn-long-expression-type-checking=400
This will issue a warning when the Swift compiler takes more than 400ms when deducing the type for a particular expression. If you get no warnings, lower to 300, and if necessary to 200.
Anyone have other tips?
Mobile software development isn't about a developer or two building "apps" anymore, it's grown much bigger than that.
I don't see what the obvious reasons would be. Swift is developed and discussed in the open for one.
There really is no excuse for an IDE developer not to support the latest swift syntax and runtime from day 1, given how there are nightly and weekly swift toolchain releases.
But aren't most iOS apps just thin clients? and if they are thickish isn't most of the code related to UI?
If the above is true, Swift and its currently un-robust tooling should be the solution for most/all projects.
Re: CAD software, I would consider them more productive, but only if they actually knew what the basics were and didn't just depend on the GUI doing all the work. If you can't get underneath the tooling and fix it, then I don't want to work with you, period.
Being tied to a single effective tool is not always bad. If the tool is indeed powerful, the need for other tools may not arise. Emacs and Vim users use their editors to work on a lot of different things, for example, and have enormous libraries of plugins and features at their disposal, ready to use no matter the language.
If someone asked me whether to learn an IDE for a specific language or Emacs, I'd say both. The larger your selection of tools, the better - with more tools the number of things you can do faster/better also increases, which leads to higher productivity.
In other words - don't try to code in Notepad forever and be prepared to spend some time on learning new tools.
I basically have to have the documentation open in a separate window at all times, because Command-Click hardly works, and syntax highlighting/completion is never long for this world.
At least Notepad doesn't have pretensions to being a programmer tool.
To be fair - XCode is a problem.
iPhone Apps are not rocket science.
There is no reason for the massive bureaucracy and confusion of XCode - or even Swift.
Not only does Swift try to do too much as a language - dealing with XCode is like dealing with the California DMV.
My god, man the compiler options. Pages and pages of options.
As far as I'm concerned, the biggest failure of the 'Swift' decision, was to be so tied to the old language standard, and to XCode.
The only possible advantage of XCode from a developer perspective is maybe the UI designer, but even then.
Obviously there's a huge investment in Xcode
But ...
Has anyone tried VSCode lately, or Atom? I mean it's possibly to have a 'light' editor and basic compile chain in which we can do powerful things. Or none at all.
I personally loathe using Android Studio or XCode - it feels like working for the government, on a team of 3000 people building a web-site for the local library that never gets into production. Anyhow, I jest.
I think there is rationality in wanting to be able to have a language work without an IDE.
But if I can "write" an 80 character line of code by pressing around 10 keys, I think that's pretty useful. If I can write a method, a class, faster than I would by manually typing and referring to docs all the time, why wouldn't I?
And clearly I'm still getting the work done. I'm complaining about the dissonance of trying to type a method name while the autocomplete dialog wants me to finish the name of a random C macro or an image name. It's frustrating and worth complaining about. Syntax highlighting is useful, the reason it exists is to help you differentiate tokens quickly.
Also nobody is saying that the tool is required to make you productive. The entire point is that it makes you more productive. I consider things like "What file is this datatype defined in?" to be menial work. It's merely a waste of time that requires no skills.
When I was out of the office this week, two server side java developers helped a Swift junior step through some code - they both were really surprised and impressed at just how approachable Swift is. As well, I notice daily how few runtime errors and issues we have with Swift code-bases comparatively.
I think a lot of these comments are straw-manning the language. Yeah, people don't like being beta testers, or using immature and changing software vs very mature and stable software - that's not comparing two languages themselves though.
Oh yeah, let me increase my compile times, the size of my SDK, add complications for my publishers, see zero performance benefit, build a ton of scaffolding code, add yearly tech debt until Swift is actually a mature stable language. Terrible idea!
It might be the gold standard some day, but for now it's just a kid compared to ObjC, and everything that comes with being a C based language. If you're learning to make apps, by all means, you should learn Swift, but it will be quite a long time before ObjC is dead and gone, so be prepared to learn both young padawan.
Not to mention, the hype train/bandwagon is really muddying the waters. It's probably a bad idea to take advice on how performant/powerful Swift is from a Zealot, or someone that's betting everything on it.
But if you want to keep up with the joneses - while delivering Apple a perfect 'big stick' to keep developer mindshare locked into their platforms - Swift is a pretty sweet deal .. for Apple.
Lots of fun compiler errors and deprecation warnings were had.
https://h4labs.wordpress.com/2016/09/17/my-ios-10-and-swift-...
If anything, Swift examples are more necessary because there's tricky things you can do with closures, manp, flatMap, etc.
ObjC is very straightforward.
In my experience, Swift has been great, I vastly prefer it to ObjC. What I don't prefer is SourceKit constantly crashing on me for example, but I wouldn't attribute that to Swift.
The article has a lot of very opinionated comments, some of them not true (e.g. ObjC development has not completely stopped). There are definitely some truths in there too, like how fluid the language has been so far (last year’s Swift code probably won’t just compile this year).
In general, I think it’s fair enough to say that Swift hasn’t matured yet. It’s not so stable, and tooling isn’t great. Large projects might suffer from that. ObjC on the other hand is rock solid, but lacks some of the more modern language features of Swift.
Personally, I’m all for Swift, because it’s the future. Tooling issues and stability can (will?) change. Turning ObjC into a modern, next generation language just isn’t something that seems feasible.
Aside from that, Swift is a really neat language - tooling aside, I find that Swift is (mostly) a great language to write in, with features that I’d sorely miss going back to ObjC. That’s purely opinion though, I’m sure there’s others that might say the same from an ObjC standpoint.
Using Swift feels like i'm back in college writing C++ code while following all the newest design patterns, and best practices, thinking about whether i should make two classes friends or not, instead of solving actual problems.
I think i'm a version or two behind the latest, so maybe it's better now, but that's been my experience so far.
Anyway, in spite of the above i still prefer it to ObjC.
if case .Success(let person) = personResult { ... }
Link: https://www.natashatherobot.com/swift-guard-better-than-if/
for case let (title?, kind) in mediaList.map({ ($0.title, $0.kind) }) where title.hasPrefix("Harry Potter") {
print(" - [\(kind)] \(title)")
}
I hate let, var, func. I hate the backwards variable definitions. I hate the crazy punctionation symbols (dots, question marks).
I agree with a lot of what Smith says about Objective-C. But my biggest personal reason is the above. I find Objective-C beautiful and Swift ugly.
> I hate let, var, func
For me it increases readability, for example when I see let, I can make assumptions about it not being mutated, which is a huge win in a large codebase.
> I hate the backwards variable definitions.
To me it says, "this is a variable called x of type String", which seems to make sense to me, definitely more so that the C way.
I hate the crazy punctionation symbols (dots, question marks).
Question marks denoting optionals seems very clear, like "is String? really there?"
> I find Objective-C beautiful and Swift ugly.
See, I am the other way, I don't really find [[]] all that beautiful.
What we know is that this won't work:
let p = Person("one")
p = Person("two")
p.name = "three"
> in terms of information content it is strictly worse than what const can do in C.
True, however the Swift community largely adopted a "use let first, only use var if absolutely necessary" approach, which is strictly better in terms of mutability-related bugs than what it was in ObjC/C, as mutability there is used much more liberally than in Swift.
Swift changed that completely. I finally find native iOS readable.
So I’m afraid that wasn’t the case.
It’s ugly for a reason but that still means it’s ugly.
I can see why people might thing square brackets are ugly, though I prefer it to the double-colon and angle bracket fest that is C++, but what else do you find uniquely ugly about Objective-C? Infix operators are nifty and promote clarity.
It’s not - thank god - so I don’t have to. So I won’t.
That's subjective. Unusual - yes, but ugly? Why? I'd say, it is quite beautiful, in its incomprehensibility (to the untrained eye).
Yes it expresses a subjective opinion.
Programmer preferences on languages, tooling and other things involve subjective opinion. We are all humans, not purely rational automatons.
There is nothing wrong with a purely subjective, and taste driven argument. How much weight you choose to give it is another matter.
struct Person {
var name: String
}
enum Result<T> {
case success(T)
case error(NSError)
}
func printName(personResult: Result<Person>) {
if case .success(let person) = personResult {
print(person.name)
}
}
In the case of printName() the success case contains a Person value. The if-case is simply saying that if the enumeration represents the success case then extract the associated Person value from the enumeration. The "let person" means make person a constant because you're not intending to modify it. If you wanted to modify it you'd use "var person" instead.
Hopefully this is pretty clear even to people not familiar with Swift style enumerations.
Tells you all you need to know about the future right there.
As a cranky senior engineer (and Swift fan), I'd say that junior engineers tend to overvalue novelty and undervalue stability.
> As a dev forced into web development, you're not kidding.
But he's not web programmer, he's mobile programmer.
Anything else is not under ARC support and thus fails under the same memory allocation patterns as C.
Additionally there are the C pointer manipulation, strings and arrays.
That's my view.
Oh yes, and Java bridge.
Merit and past lessons learned, are not really how concepts, practices and techniques become popular in computing. Alan Kay had it so right when when he said that computing is a "pop culture".
This is simply not feasible to do unless you are willing to open source your code base. I have been shipping closed source binary frameworks written in Objective-C for seven years. None of the companies I work for are willing to maintain binary releases for each version of Swift AND Xcode. It's simply too much.
I'd love to use Swift, but at this point it would only be a maintenance nightmare for my team and I to maintain.
If you don't want to open source your code, at least give it to your paying customers under a proprietary no-redistribution license.
Newness (which includes rapid, breaking changes in language and still-to-be-improved tooling) would be number two.
Difficult ness in a bad syntax. Also a primary reason.
1st. Don't look at it from the language perspective. Look at it from the point of view of the platform and dozens of SDKs that comes with it. It's lot easier to use those SDKs in an environment you are already comfortable with.
2nd. There's no financial incentive for an existing app to be ported to Swift or train experienced developers to this new language. In my manager's own words, "...you have to give me a business justification to port our app to Swift..."
3rd. I'm afraid to say that incredibly high inertia about learning and embracing a new language, and letting go of your stronghold.
Swift is an amazing language, and it's quite easy for you to switch between Swift and other C-style language e.g. ECMAScript. Objective-C has somewhat obfuscating syntax that makes it intimidating for beginners.
I am not a professional developer and I like to tinker, create my own tools. But it is uneconomical for me to pay all these fees just to run my own app on my own hardware. I ended up going the web app route.
The developer license is all you need to put it on your own phone. Source: Started developing iOS apps in 2008.
And you still have to pay a yearly fee, which creates a high barrier to entry for non professionals.
[1] https://developer.xamarin.com/guides/ios/getting_started/ins...
Clearly the free tier is pretty worthless in the grand scheme of things, and being able to write software for you but not being able to legitimately give it to anyone else not also paying the $100/yr "please let me own the piece of hardware you sold me instead of renting it" tax is not really acceptable for people trying to learn to write software as a big part of software is being able to give it to other people. In practice, though, a lot of people are seriously only learning to develop so that one day they can pay the full Apple developer tax and deploy their apps to the App Store under the Apple software approval process, and so it works out: like, to them, software development is all about writing software for Apple hardware under Apple's rules, and that's what Apple wants anyway. The entire scenario makes me feel a little sick: this shouldn't even be legal as far as I'm concerned.
For the first few days after the announcement I couldn't see the point of Swift, why did Apple feel they needed a new language? It's not like there was a dearth of developers in objc. I started reading the Swift book from Apple though, and when I finished it a few days later I was hooked. Since then I haven't voluntarily written a single line of objc.
Of course circumstances may vary but for us migrations between Swift versions, even the biggest ones, have never taken more than 2 hours. Learning the new syntax as a developer I see exclusively as a positive, it's exciting to see how it develops. WWDC is Swift Christmas.
Again, each project and each developer is different but I can't shake the feeling that at least some of the objections raised by obj c diehards sound like pretexts, especially the talk about the language being in flux. It's not like you're forced to adopt the new version immediately, and in any case APIs also change. It's just part of the job. And Swift can't improve if it's not allowed to evolve.
- Many examples are older, and don't compile anymore.
- Code maintenence costs increase for long term "write it and forget it" code.
I don't have a hrose in this race, but when I heard Swift was making breaking changes, I had an immediate negative reaction.
Migrating code to newer versions is seldom a big problem, and it’s even smoother now when you can run several versions in the same app.
Disclaimer: I’m a long time IntelliJ user so I find the environment more comfortable in general, not sure if that’s the case for long time Xcode users.
Combined with SpriteKit/SceneKit/GameplayKit/Metal, it's a decades-long dream come true.
I've got a game half done in Swift with SpriteKit that I did as a learning exercise, and it was a smooth experience, but I'm having a hard time justifying putting more time into it when I would rather spend it working on something that I could make a build for PC, Android, and consoles as well. Hence why my efforts are more in Unity now.
Not just iOS, but macOS, tvOS and watchOS as well. You can easily reuse like 90% of the code, save for the platform-specific windowing/views and player input subsystems. Xcode even comes with a cross-platform game template.
Although I do want to be able to develop for the Nintendo Switch as well, I don't mind being limited to the Apple ecosystem for now; it's the more lucrative market, and I get faster access to the latest tech, but most important of all, is that I know my potential users will have access to that latest tech (see Android fragmentation and adoption rate).
Sometimes, I don't even have to rewrite or do anything to have my games use the latest tech; when Metal was introduced, SpriteKit and SceneKit were updated to use it under the hood instead of OpenGL, giving a performance and efficiency boost to all existing games for free, without even recompiling!
Vulkan is basically a C API, defined at https://www.khronos.org/registry/vulkan/
There is a C++ wrapper, originally designed by NVidia, https://github.com/KhronosGroup/Vulkan-Hpp, but it isn't part of the specification as such.
Likewise the shading languages are either GLSL or HLSL, although in theory others could be created for SPIR-V.
Of course, Vulkan has the benefit of GNU/Linux, Desktop Windows (not on UWP) and about 14% Android devices (optional in 7+ versions), but middleware engines make it kind of irrelevant.
What I don’t like about Swift is that it evolves every year. I already need to maintain new OS updates and new devices. I don’t want to have another thing that I need to maintain... especially the language itself.
The real problem is getting puzzling regressions because of an accidental message to nil.
It's a shame that they have made so many changes that are not reverse compatible. They have $100 Billion in the bank - can they not sort this out?
It's a double shame that my comment is down-voted - I can't think of another bit of tech which has had so many backwards-breaking changes over the years. Not Node, not Java, not Javascript for example.
So cost plays an important role in the adoption of Swift as well.
However, what I learned is, if you want to leverage MIT or BSD licensed widgets, libraries and etc, Swift is where it is at. Way too many of the ObjC code available has gone fallow with iOS 8 or 9, so you can still use it now. But the writing is on the walls, sooner or later iOS 12 or 15 is going to break that code and then the ObjC choice turns into technical debt. It runs the gamut from code that isn’t AutoLayout aware, to using deprecated but still available methods. I’ve steered clear of any code that hasn’t seen an update in 18 months.
It shouldn't be a factor in the decision about using Swift or not.
(1) Time to market: how fast can you implement a “ship-able” feature, app
(2) Resource cost/availability: can you find delivery resources easily and cost effectively. Sometimes this resource is you, metric appropriately.
(3) Scalability: as you grow and features change, how do the other two things change. Do they change for the better or the worse.
The weighting of these depends on longitivtiy expectations. If your short sighted for immediate reward weigh (1) and (2) higher if your confidence is high on the outcome of what your doing then weigh (2) and (3) higher.
For this discussion Swift wins on almost all fronts. The exception might be legacy maintenance , and even then it might be a knife fight of when and how.
I really like Swift though and hope tooling improves so I can start doing more with it. I love its approach to type safety and offerings like ADTs.
i wonder if part of the IDE problem isn't to do with having the elaborate type system. it might make certain things easier but having to do inference could slow things down a lot.
my dream is that someday Swift will be a mature, well-funded, "enterprisey" language that is also weird and functional. Something to join the ranks of F#.
I guess Swift is popular with JavaScript developers, coming from web dev.
Why bother? Swift is the blessed language on Apple platforms going forward and ObjC is not.
- article queries developers of category X: why do you do Y?
- 1000 replies appear as variations on the theme 'no, it's just because Z!', clearly implying category X either lacks the ability to introspect on their own reasons for their choices, or are perhaps knaves or fools
So if it's not endorsed and spoon fed by Apple, he wants nothing to do with it.
Surely others will follow.
I don't see any sane new startup/projects using Obj-C, other than bullying by Obj-C devs.
Objective-C:
- (return_type) method_name:( argumentType1 )argumentName1
joiningArgument2:( argumentType2 )argumentName2 ...
joiningArgumentn:( argumentTypen )argumentNamen
{
body of the function
}
func funcname(Parameters) -> returntype {
Statement1
Statement2
---
Statement N
return parameters
}
function functionname(parameter-list)
{
statements
}
And it wasn't mentioned, but the if let myVar = optionalVar { ... } is a godsend for writing maintainable, crash-free code.
If you want to get a good idea of what good swift looks like, check out https://github.com/raywenderlich/swift-style-guide
Anyway the future isn’t Swift, it’s JavaScript for everyone :-)
Don’t dismiss visual similarities so out of hand.
Yet, many programmers love Smalltalk, which is where this "new" syntax came from.
It has made me really want to look into learning Smalltalk as a throwback hobby.