I think the author misses the fact that Swift wasn't truly 'done' when it was introduced, (and still isn't). Objective-C had some 30+ years to evolve, but Swift can't have 3?
I get that if you're shipping Swift in production you want to refactor as little as possible, but it is pretty hard to come up with the ideal design straight out of the gate. Swift can stop evolving, but it will be THEN when it loses the reason to exist. If Swift is just going to be ObjC with a nicer syntax, (or the features that YOU personally find desirable), then why bother with it at all? Swift is trying to get its design right and that takes time, at the same time I wouldn't want to be stuck with a poorly designed language for the next 30 years, so it's worth the current turbulence for me.
(Rust was the same way 2011-2015 to a MUCH bigger degree and it did in fact eventually stabilize as promised.)
If it's that much of a problem, ObjC isn't going anywhere, it's your choice.
Its fair to say that if you adopted Swift as soon as it was announced you should have expected some pain, especially given all the warnings Apple put out about it.
I think the issue is that for the last year or two all of the tutorial websites and the third party library ecosystem have moved from Objective-C to Swift in a big way. If you are new to iOS development this might lead you to have a false sense of security with regard to the overall stability/quality of the language.
Swift is a lot of fun when it works. I hope this year's WWDC will mark a big turning point for the language. Last year it was pretty painful, especially if you needed to use third party Swift libraries.
Maybe it is just a question of analytics, I mean if you have a bunch of Objective-C articles with 100 readers per month and a set of Swift articles with 10000 readers per month, as an author, you will probably chose to invest your time in updating the Swift version.
The comparison with Rust's period of instability is very mistaken. Before 1.0 we were emphatic in telling you that you should not use Rust in a production capacity. The rust-lang.org homepage loudly proclaimed that the implementation was a prototype that would "eat your laundry". Coming into the IRC channels, anyone asking whether Rust was production-ready would be told that it wasn't, and we suggested alternative languages for those needing stability. In contrast, you don't see anyone calling Swift an experimental prototype despite it being as trigger-happy with breaking changes as ancient Rust. I take issue with the messaging that Apple has used to describe Swift's level of stability; just saying "we warned you there were going to be breaking changes :shrug:" drips with contempt. Just because one has given oneself license to break something does not mean that one should exercise that right wantonly.
I do think the Swift developers are getting better about that, fortunately, but a lot of developer goodwill has been burned in the meantime.
> the rust-lang.org homepage loudly proclaimed that the implementation was a prototype
I get what you're saying, but a 'prototype' is perhaps a bit far. Rust was far from being called a prototype years before being declared stable, however I do agree that branding Swift 1.0 in 2014 was a mistake.
Personal theory is that if you want to release something at Apple to the public, and Chris wanted to get feedback, you have to brand it 1.0
> just saying "we warned you there were going to be breaking changes :shrug:" drips with contempt
Ouch, that's going a bit too far, Chris Lattner definitely doesn't strike me as someone who has contempt for developers. He gave us LLVM, (which BTW Rust uses as its backend) and by all signs he worked very hard in the background to get Swift open-sourced. Now they're taking a lot of feedback from the community via their Swift Evolution process and the Swift community wants the language to continue to evolve, so it does, not sure what could've they done better in this regard.
Yes indeed, I don't blame Chris for any of this. Given his pedigree with LLVM, I'd believe that if he had his way Swift would have been open and available for comment from day one. I squarely blame Apple's management, a misapplied corporate culture of extreme secrecy, and an executive allergy to the word "beta" for the issues that I perceive. I apologize if it seemed that I was blaming the Swift developers themselves or denigrating their abilities.
Anyone shipping swift code one day one had to be pretty masochistic. I just couldn't understand why people were doing it. It was obviously not ready for production use, and still isn't.
But I'm happy that people are playing with it and the language is being refined so that I can start using it in a few years.
>Anyone shipping swift code one day one had to be pretty masochistic. I just couldn't understand why people were doing it. It was obviously not ready for production use, and still isn't.
Obviously because "production" is not some monolithic reality.
What's "production" standards for NASA or Google, might not be for some small team making an iOS app or an one-person indie shop.
They might prefer to experiment with the language in their app, and get a leg up on learning it starting from the initial release, even if there's gonna be pain.
Even for actual commercial code, the supposed "pain" this article mentions is really nothing to write home about.
Having to spend a week doing manual code changes because APIs were renamed is no biggie at all in the grand scheme of things.
Contrast with whole full blown languages and libraries used in production change completely or get deprecated/abandoned. Things from Microsoft inventing new stacks and deprecating others every few years, to J2EE dropping the crappy EJBs that tons of programmers had based their code on, to React Router being redone in a new style every year, to GTK/QT N to GTL/QT N+1 transitions, ...
> They might prefer to experiment with the language in their app, and get a leg up on learning it starting from the initial release, even if there's gonna be pain.
I agree, but I suppose these kinds of shops wouldn't then write blog posts complaining about this, I think the OP meant shops that do it anyway and then complain...
Developers are shipping both small and large projects with Swift. You may have a different opinion, for reasons that you haven't stated, but shipping production Swift apps is not an anomaly.
It's fine if you don't mind using rudimentary, buggy tools, and converting your whole code base to the latest language changes every 6 months, and you don't mind bloating your app with a mandatory 8Mb runtime. Great for small projects, people coding for fun, learners, and early adopters/neophiles who enjoy keeping up with all the changes. But substantial projects need solid, stable tools. Swift will get there very soon, I'm sure.
Admittedly I'm basing my opinion on Swift as it was about 12 months ago so hopefully someone can tell me how wrong I am and that the frequent IDE crashes and compiler bugs are fixed, refactoring is now available, autocomplete works really well, compile times have improved, and the language has no more breaking changes, etc.
It's just that I have work to do and Objective C is still solid and dependable. Playing with Swift was fun but I kept running into too many yak-shaving diversions to get even basic things done.
Great for small projects, people coding for fun, learners, and early adopters/neophiles who enjoy keeping up with all the changes. But substantial projects need solid, stable tools.
Lots of projects more important and substantial than anything you and I have worked on have been shipped with Swift. So that argument doesn't really fly. Apps redone/adopting Swift include Twitter, Pandora, Groupon, Fitbit, etc.
(Heck, major billion-dollar companies had built parts of their production infrastructure on Node when the thing was just on very early stages).
LinkedIn gave a tech talk some time ago at the SF NSMeetup. The LI app was written since Swift 1.2 and has had a good deal of growing pains since then.
I shipped my first Swift App with version 1.2, and have written or helped write a half dozen since. Anyone who is still using Objective C and dealing with dangling pointer bugs and difficult to maintain code is missing the point that most software development is bug fixing and maintenance.
I never have the IDE crash and haven't for the last year+, never have problems with compiler bugs. Autocomplete is fine, compile times are ok, and the changes for each version have almost always been automatically converted for me.
Refactoring would be nice. A faster compiler would be very nice, but there are build settings (see Uber lead engineers recent blog) that can massively improve build times in large apps.
If you actually believe I offered you a magical bug free future, can you at least pay me for it?
Swift is far more readable and a bit more concise than objective c, that makes it more maintainable. The bigger win is of course optionals, which, (if you embrace them properly), can mean your app will never have a dangling pointer or runtime crash from a nil pointer.
I spent nearly 20 years writing object oriented C and Objective C apps for personal computers and phones, and dangling pointer crashes were the biggest possible sinkhole of time, and worse degradation of product quality.
I'd say it's ready, but it's a bit iffy because of the tooling. The compiler is way too easy to crash, the debugger is often worse than useless, and larger projects can be extremely slow to build.
You can put up with these, and I think it's worth the tradeoff, but you should definitely consider them carefully before putting a lot of effort into build a real-world Swift code base.
Unfortunately, the rise of frameworks has led to another, often ignored problem: app startup time. Carthage and CocoaPods, while great tools, became enablers and I'm hoping static library support will be announced this WWDC.
Because Swift 1.0 was far superior to Objective C in maintainability and code quality.
Now I do admit the build times were awful and I had a couple puzzling crashers that were only cleaned up by Swift 1.2 (thankfully didn't ship till after 1.2 was final), but the transition was worth it.
> Because Swift 1.0 was far superior to Objective C in maintainability and code quality.
You can take Objective-C code written three years ago, open it up in Xcode today, and compile it. The same cannot be said for Swift. So saying Swift 1.0 was "far superior" in terms of maintainability is a bit of a stretch, in my opinion.
Sure, in the edge case where you actually don't maintain code except for once every three years, it's closer. But even in that example, after a couple bad hours/days (given size of your project) updating your swift code, you then have many good days working in much more readable code.
I'm actually pretty happy swift moves the server side story forward, because i'm convinced the "next big language" will have to run on mobile and server. Actually, i think they don't go fast enough, especially regarding concurrency ( which on the server goes beyond just providing async await, as lattner said they were aiming at something closer to the actor model).
I don't think the "maybe objc is still relevant for new project" trend we've been seeing the last few months on HN is going anywhere. I'm currently in the process of converting a large codebase from objc to swift, and there is absolutely no doubt that the language is WAY better, and brings a lot of safety enhancements as well.
The only big remaining pain point now is clearly in the tooling, but now that they're stabilized the language a bit more, it's probably going to get better fast.
"Async/await are effectively proven at this point and would fit well with the Swift type system and structure, we should probably just do it.
Erlang/Akka have proven actor models. Swift providing syntax yields a declarative model which enables programmers to reason about what mutable state goes with each task. Each actor is effectively a DispatchQueue + state it manages + operations that act on it.
Actor approach also generalizes well to future. It could be a great way for handling heterogenous compute (e.g. GPU tasks), distributed compute, etc since each async “call” to an actor really is a message send (thus could be DMA or IPC)."
The author mentions that Apple often nudge their idea of the future forward each year at WWDC. I see no different with Swift: the introduction of Playgrounds, teaching resources, finesse over small details, etc - to me indicate Apple wants to make this a language that the next generation of developers grow up learning and using.
Quite a good move on their part if it is successful. If kids start learning Swift at school, they get exposed to Apple devices (not necessarily but this is where the teaching resources are aiming), and they've got developers in their arena from an early age.
Yeah, Swift needs ABI stability, but I also understand that they don't want to screw it up by adding it too soon. Because the goal of Swift seems more long term oriented, short term ABI stability isn't worth risking a 10 year goal for.
"Quite a good move on their part if it is successful."
I haven't used it, nor do I work in education, but what I have read of it, it at least is successful in the sense that those who use Apple's Swift training material find it to have good quality.
"In times past the experience was that, if you were an able student in Computing, you would get your programs working. If you were not an able student, your experience would be almost insurmountable challenges to get anything working. Working or not-working was the differentiator in the class.
In the Learn to Code curriculum, I found that everyone got something working. The difference between the stronger students and the weaker students then was more to do with evaluations of the complexity of their solution, the understandability and style of their solutions or other factors like memory and time efficiency.
I have never really had these kinds of conversations in classes at this level before. It has been an incredibly satisfying year to get the opportunity to debate which of three possible solutions is the 'best' for a given problem and, further, what definition of 'best' we should accept."
"Apple is working with leading device makers to make it easy to connect to Bluetooth-enabled robots within the Swift Playgrounds app, allowing kids to program and control popular devices, including LEGO MINDSTORMS Education EV3, the Sphero SPRK+, Parrot drones and more. The Swift Playgrounds 1.5 update will be available as a free download on the App Store beginning Monday, June 5."
I use Swift daily in a mixed application of both languages. I worked with ObjC since back in the NeXT days and I used to like the language but today nothing could ever drive me back. Xcode on the other hand is nightmare I despise daily but that's a different issue. The sooner ObjC goes away the better.
I'm the exact opposite. I have been forcing myself to use Swift daily to rewrite utilities and help with an iOS app. I hate their take on the Smalltalk-style selector (the unnecessary parentheses is a pain) and other parts of the language. I'll use it, but it is much like Transact-SQL or Perl was for me (become an expert but not really like the language or programming in it).
Swift on iOS and Kotlin on Android are a great update from their predecessors both in terms of syntax and safety, (Optionals etc.), which I really appreciate. I also like how they both provide just enough functional tools to be interesting and useful, yet at the same time remain firmly in the familiar OO land, makes the adoption cost a lot lower.
After developing Android apps for a while and finally taking an iOS class, XCode felt like such a step back compared to Android Studio. I ended up downloading AppCode and only using XCode for UI related task.
If you follow the Apple dev community, there is a group of folks that make their living on books and speaking. That's fine, but they are using the platform differently than someone shipping software. They are also often the authors of some of the more ideological, less pragmatic proposals. This has a large impact on the disconnect the author describes - which incurs a cost on folks who ship software. I do wish the Swift team said no more often, but as with any dependency, you're never gonna get 100% alignment.
Maybe I'm in the wrong part of the Apple dev community, but I don't know of anyone who makes a living on books and speaking. I know many who write books and do a lot of speaking, but there isn't enough money in it for it to be anything more than a side gig.
Yeah, there's certainly some people who would like to make a living on books and speaking, but every single one of them that I know of has a job as an iOS (or macOS) developer of some sort and no one's even in the range where they can pretend that maybe one day they'll be able to quit their day job.
Very distracted by the lack of the accusative case in the name of the site. Unless he is instructing the water to seize, I think it should be carpe aquam.
I didn't have a really rough time with the Big Rename but some subtle differences bit me, simply the way how strings are constructed for example:
var someId: Int!
...
let urlString = "\(baseUrl)/\(route)/\(someId)"
Result in Swift 2:
"http://ac.me/products/123"
result in Swift 3:
"http://ac.me/products/Optional(123)"
Happy hunting! Some of this ended up in production :(
They've changed it to a warning in later versions of Xcode 8 at least. But that was too late for me.
Apart from that it's a big step forward, less wordy than Objective-C yet it's still "readable language" instead of a bunch of almost random generic English words.
I'm not sure about async / await. Whenever I deal with it in .Net languages I never find it that intuitive compared to blocks. But you know every programmer suffers from Stockholm Syndrome at least a bit so it could just be my mind warped to not only accepting but even glorifying the flaws in a language.
There are people out there that genuinely like JavaScript for instance!
You should be using the methods on the URL struct to compose a URL, rather than string interpolation. You wouldn't use string interpolation or concatenation to compose an SQL query, would you?
Actually it's behaviour seemed to be geared more towards debugging than actual string formatting. The expected behaviour should be either a compile error, or the value when it's set and nothing, nil or None if it would be allowed to compile.
Just give it a try. While Swift is not perfect, it really is great for macOS/iOS development and continuously getting better. I'd never go back to ObjC.
as much as I like swift, wait for it to become stable. Don't subject yourself to the pain yet. That said do take advantage of using literally all the things that have been added to Objective-C for compatibility as they provide useful information and diagnostics.
I am actually working on a react native app with native modules in objc, swift, and a combination of the two. It is stable and easy to work with all three. Just use what you want to use. You wanna make it full swift, go for it. React native, go for it. Stick with objc you know, go for it. No wrong choice here.
ps: Well, maybe pure objc is not the best choice, since it's on its way out, but it's a long way to its end.
> I see few advantages of switching my large existing codebase to swift
There are none. Don't transition an existing, stable ObjC project. I don't understand why this is a thought anyone would entertain, especially since ObjC itself isn't going anywhere.
If you are starting a new project in Swift and it will be pure Swift, that's fine. Go for it. Do not attempt to migrate existing ObjC projects or use Swift in them.
This post hits it right on ... the renaming thing and the removal of traditional for loops ... I'm just bewildered by it. When I saw it, my reaction was ... WHY??? The incompatibilities between swift 2 and swift 3 made me thankful I did not invest the language prior to 3. While I stepped into it at this point, and think the language has a lot of potential (not changing the damn language .. I mean having a large eco system of useful libraries around it). Apple still has an opportunity if they don't screw it up further.
There is never a better time to make a breaking change than right now.
Why does make treat tabs and spaces differently? Because Feldman's original version had that bugs and he didn't want to disrupt the <10 users and their <100 makefiles. That was the wrong decision, though he didn't know it at the time.
However many users Swift has today, tomorrow there will be more. However many lines of code are written in it, tomorrow there will be more. The pain of making a change will only increase.
Apple was up front with everyone about Swift 1: there will be source-breaking changes in the future. Swift 3 was targeting source stability so it was the last chance to make such large changes.
In contrast, Swift 3.2 and Swift 4.0 are compiled by the same compiler and can be linked together. That means you can upgrade each module separately and don't have to wait for dependencies to upgrade. That's a huge win.
Swift 4 also brings Codable which will shave a massive amount of boilerplate from many codebases. The String overhaul is great too, along with generics improvements. These all affect the standard library and thus ABI stability.
The Law of Exclusivity is in, which is the core of the upcoming memory ownership model, which itself will enable async and other concurrency paradigms. This also affects ABI.
Once ABI stability lands the pace of standard library changes will necessarily slow dramatically. It is important to take the time to get things right, rather than rushing and locking bad or insufficient designs into stone.
Thanks for sharing that link. I found it quite an interesting read. (I much prefer Swift to ObjC after a conversion of about 10k lines in an iOS app).
C style for loops come pretty early in most programming tutorials, but I wonder how much non-C programming does actually use them nowadays (from the Community Responses, it seems not much Swift courtesy of other options). Usually, a C style for would be to loop over an array, and a safer way to do that probably could have stopped countless vulnerabilities & bugs occurring over the years.
> C style for loops come pretty early in most programming tutorials
Meh. Many languages don't have c-style for loops in the first place. Neither Python nor Ruby do for instance. I don't think Rust ever had them either[0].
I agree. Looping over a numeric sequence is simply a specific case of looping over any collection. A language should reflect this. It feels so natural to write:
for thing in collection: process(thing)
and very easy to move from that to a functional style:
map(collection, process)
or
collection.map(process)
The number of times I also need a integer counter is fairly small.
When you do need an integer counter, the best way to have it is to create a new collection consisting of (index, element) pairs. Swift (and many other languages) make this easy:
for (index, element) in collection.enumerated()
There are some cases where the C style for loop is the most natural way to express something. For example, looping over NULL-terminated array of pointers is nicely expressed with one (Swift 2-ish pseudocode):
for var cursor = ptr; cursor.pointee != nil; cursor += 1
But these situations are really rare, and when you do encounter them, it's not a big deal to transform them into a while loop:
var cursor = ptr
while cursor.pointee != nil {
defer { cursor += 1 }
...do stuff...
}
result := collection collect:[ :a | a process ].
result := collection collect process.
collection do process.
1 to: 10 do: [ :i | stdout println:i ].
stdout do println: (1 to: 10).
All just plain messages and plain message syntax, no special control structures needed.
As you indicate, the renaming may be a net loss for those who have to do he renaming, but, from Apple's viewpoint, is more than offset by the expected gains when writing new code by both current developers (where the gain may be small, zero, or even negative because they already are familiar with the API) and developers yet to start using Swift.
So, the question should be whether Apple should have prioritized new users of the language over their existing language users. I think they made the right call, more so because they pre-announced it. Not only didn't they claim the language was frozen, the specifically said it would see changes.
I like the renaming, even though I don't like the way they went about it (the migration was, and continues to be a huge headache). I also like that they removed traditional for loops — what would be your reason for keeping them?
> The biggest travesty was the "Great Renaming" which touched every line of Swift code I had and burned a week of my life on tedium
The sheer amount of churn in Swift between v1 and v3 was what has kept me on the sidelines. It was only that Apple plainly stated last summer that they were done radically changing the language that I was willing to get into Swift at all.
Will Kotlin Native be able to compete with Swift on iOS? The syntax is very similar and it would make for a nice cross platform PL.
I was holding off on Swift to see where it was going, but I'd like to add iOS to my dev targets.
Objective-C was too verbose for me years ago, but I've heard it has changed a bunch.
I don't think so. Mobile development is almost more about the underlying frameworks than the language itself. At some point Kotlin etc will have to wrap these things. The internal apple swift dev team will always be one step ahead of them as they will have access to the new frameworks before they are released to the public.
Also swift and kotlin are very similar. The folks from kickstarter gave a great presentation about their android/iOS app being written in Swift/Kotlin at a conference I spoke at (UIkonf). Their whole mobile team writes/reviews for both platforms.
Kotlin Native doesn't exist beyond pre-alpha software at this point, so the the question is a bit premature.
In 3-5 years Kotlin might be where Swift is now, but there's nothing guaranteed, just coming up with a GC solution alone is a gigantic engineering effort -- Kotlin, like Scala, Clojure, etc. all benefit from world class GCs, just by being hosted on the JVM. With LLVM you essentially start from scratch, same for porting Java libraries, there's a ton of work involved.
tl;dr; for now it's separate languages for iOS and Android unless you cut some corners with React Native to avoid writing the same app twice.
On a technical level, it's easy to see how someone might ship a Kotlin compiler that targets LLVM the same way you can e.g. C# via Xamarin.
Practically, though, any solution like that is going to be a second-class citizen in a world where Apple jumps and you ask how high. Xamarin's a great example here, even if Kotlin might be sexier as a language: there are certainly teams building good native iOS apps using Xamarin / C#, but it's hard to see it ever being anything more than a niche tool.
I'm curious to see if the porting from Java to Kotlin on Android apps will prove to be as challenging- and frustrating- as people have described the shift from Objective-C to Swift.
There is literally zero friction between Kotlin and Java since they're interoperable. You can even translate Java files to Kotlin files by selecting a menu option in Android Studio or even cutting and pasting Java into a Kotlin file. Sure, the code may not be optimized fully, but it's a good starting point. Additionally, you can even mix Java and Kotlin files in a project.
The author says they lost a week of their life to the Swift 3 renaming but wasn't there a utility that helped with that?
I agree that Swift has seemed to been infected with the disease so many open source projects get; focusing on over polishing instead of big picture and innovation but it's still my favorite new language.
Edit: I missed the author mentioning the utility sucked. Sorry!
The automated tool couldn't even automate the conversion of the Apple examples on their developer cleanly. Those examples were fundamental demonstrations (e.g. table with views), so that indicates a pretty big problem if you are trying for a complicated app. It also makes it difficult for people just starting.
He mentions it: "The migration tool caused more issues than it automatically resolved, leaving a manual migration as the only sane path forward. How that migration tool ever made it through QA is beyond me, but I'd have felt better if Apple just said 'good luck' instead of offering a half-baked utility."
> but wasn't there a utility that helped with that?
Yes, but in the article he writes, "The migration tool caused more issues than it automatically resolved, leaving a manual migration as the only sane path forward."
For small projects and if you don't use third party libraries (who doesn't ?) the Xcode migration assistant may work. Otherwise, manually doing the conversion is the law of the land.
The biggest problem Swift has is breaking changes from a version to another. Took me about 10 days to manually convert a Swift 2.5 project to Swift 3 to find out that Swift 4 will also introduce at least two breaking changes.
I'm all for progress and modern ideas in a programming language, just don't break my old code!
They were pretty clear about this from the beginning... Sometimes you need to break a few things here and there to make it a more pleasant language for the decades to come.
And for the skeptics, C++ evolution is a strong statement for why keeping old cruft just for the sake of the early adopters maybe is not the right thing to do.
I prefer the Swift way, and had to move 2ish to 3ish code myself and it didnt suck that bad.
> I'm all for progress and modern ideas in a programming language, just don't break my old code!
I doubt that they want to, but it is really hard to redesign something you didn't get right the first time in a programming language, without breaking some code. The choice is then to leave the bad design as is, but be stuck with it for the next few decades, (which would be kind of terrible, given Swift was meant to eventually replace ObjC precisely because of this), or you can suffer the pain now, while relatively early, to not have to suffer latter.
I think they made the right choice, in terms of prioritising long-term benefit over short-term gain.
ObjC is still fully supported for those who want it and in the meantime, we can get a more perfect Swift.
"Apple's path with Swift doesn't seem to solve the problems I have as a day-to-day iOS developer. "
That's the key take-away for me.
Of course Swift has an easier time with some syntactic issues than Objective-C, which is two languages crashed into each other. And yes, Objective-C was way, way overdue for a better replacement. Heck, just dropping the "C" part from the language syntax and reducing it to type annotations in a nice typed Smalltalk (see Strongtalk, or TS) would have fit the bill.
It's not as if there aren't lots of problems (and your list will almost certainly be different). For example, applications are no longer just code, non-code resources are just as important, but support for them is at best rudimentary. So with pluggable scheme handlers and polymorphic identifiers, we could write
checkBoxImage := img:checkbox.
And have the "img" scheme handler statically check resource availability against a list automatically imported from Xcode's resources (pluggable, see F# type providers). Of course, the internet also happened, so
shoppingPage := http://amazon.com/
should also work, because why should obtaining resources outside your machine have so much extra ceremony. Abstracting should of course also work:
And of course you can compose scheme handlers, so you add JSON or XML decoding and then use the resulting scheme handlers as if the original data source
Then there is keeping UI and model in sync. There were bindings, but these were hacky, somewhat unreliably, undebuggable etc. Much better to generalize and integrate a constraint mechanism into the language:
That's actual code for a temperature converter app, setting up relationships that get automatically maintained. And if you make constraint handling support pluggable as you should, you also have a proper syntax for writing autolayout constraints. And Makefiles.
Together with composable scheme handlers (see above), this gets rid of the vast majority of your view controller code.
Then there's the nib vs code dance. Or storyboards. All semi-solutions to problems that are largely (but not entirely) architectural in nature. All can be aided tremendously by good linguistic support, putting to rest many of the recurring problems we have with these technologies (or conversely with not adopting them).
I get that if you're shipping Swift in production you want to refactor as little as possible, but it is pretty hard to come up with the ideal design straight out of the gate. Swift can stop evolving, but it will be THEN when it loses the reason to exist. If Swift is just going to be ObjC with a nicer syntax, (or the features that YOU personally find desirable), then why bother with it at all? Swift is trying to get its design right and that takes time, at the same time I wouldn't want to be stuck with a poorly designed language for the next 30 years, so it's worth the current turbulence for me.
(Rust was the same way 2011-2015 to a MUCH bigger degree and it did in fact eventually stabilize as promised.)
If it's that much of a problem, ObjC isn't going anywhere, it's your choice.
EDIT: Fixed a typo.