I wonder if there is a way to correlate the number of bug / issues related to binaries with Swift. It’d be interesting to see if Swift correlates positively with bugs/crashes.
Of course, mixing with Objective-C may actually be the cause of issues or crashes? Who knows.
In fact, I would argue that this new trend of defensive programming in Swift will make software worse in the long run. We had a tradition of sending crash reports back to developers. If everyone now starts their methods with `guard let param = param else { return }`, software will silently fail on end user devices, and everything will look fine in Crashlytics/App Store Connect.
I'm not saying that this is what your apps are doing. But I know that Apple bragged about their record low in crash numbers at a time when I ran into different glitches across all of their apps every single day. It's a flawed metric.
Also, take into account that in Objective-C you can send any message to a nil pointer, and the result will be nil or 0 (for scalar types), as defined by the language standard.
I generally find it useful to have the concept of Optional, making me think about "could this thing be missing?" explicitly. But I've started to wonder if it is, rather than "preventing an entire class of bugs", actually just making them pop up elsewhere when Optional values start brushing up against that top level of user-visible stuff.
Maybe we (I) just need to get better at thinking about missing data conditions at the product design stage, or more robust defaults.
Perhaps you are under-using sum types - or enums with associated values as they are called in Swift. Difficult to get into details in this format, but for example, instead of:
`enum State { case connected(Connection, SomeOtherStateRelatedToConnected) case disconnected }
let state: State `
You have: ` var connection: Connection? var someOtherState: SomeOtherStateRelatedToConnected? `
I'd agree if Swift was a general-purpose C++ replacement, but most developers use Swift to write Cocoa apps. viewController.navigationController is optional, view.superview is optional, label.text is optional; all of Apple's frameworks are built on mutable state where almost everything can be or become nil.
(We can make sure that most variables and parameters aren't optional, but that only pushes the problem to other lines of code.)
If we know that we've loaded a view controller from a storyboard, is `self.storyboard!.foo` really a code smell? What else should we do? The type system doesn't let us express what we know/assume about the situation, unless we completely sidestep Apple's controller infrastructure and write our own thing.
> Also, take into account that in Objective-C you can send any message to a nil pointer, and the result will be nil or 0 (for scalar types), as defined by the language standard.
Right, I am not saying that Objective-C handled this any better. But it boggles my mind that we have Swift's complicated type system now, and use it to rebuild an implicit source of errors from Objective-C.
All the existing Apple frameworks where originally designed for Objective-C, and if redesigned with Swifts type system they could have a much safer API. But what are you suggesting Apple should do? Throwing thousands of man years of their own and third party developers code away, and ask everyone to start from a clean state? I prefer the current approach where, while the Swift language and tooling is maturing, Swift acts as an incremental improvement over Objective-C.
I should also add that if you avoid putting too much of your code in your views (networking, data storage ...) then you can put those components in embedded frameworks that can have a nice safe Swift API.
Apple could have spent less time on their new programming language if they hadn't insisted on reverting every single design decision in Objective-C: the way mutability and constness are handled, NSObject as a root class, naming conventions, the string class, creating their own package manager, etc. There's so much pointless bridging going on.
That would have given Apple plenty of resources to iterate on their current UI frameworks. If the IB/storyboard infrastructure leads to nil-heavy and stringly-typed code, why not push a first-party UI DSL? Why do we even need a third-party platform like Crashlytics to debug errors? Why is it so hard to write UI tests and have them run on a CI? Has IB_DESIGNABLE started working reliably at some point? Why is basic stuff like this not a blocker? [1]
And yes, at some point I think UIKit and AppKit should be scrapped in favor of a new framework (with a slow migration path, not a clean cut). I was hoping for UXKit to be just that, but instead we got the monstrosity that is Marzipan. Apple's focus is on the language, when it should be on the frameworks.
[1] https://bugs.swift.org/plugins/servlet/mobile#issue/SR-6795
But every one of these is arguably a good decision. Swift.String has a significantly better interface. immutable types are a huge win. It doesn't make sense to have a root class when you have non-class value types. You have to change the naming conventions if you change the calling syntax, which was a swift goal.
You also can't take LLVM gurus working on a new language and re-task them to take on UI framework feature adds without a lot of friction.
(BTW, my understanding was that NSObject isn't the only root)
Foo was rewritten in Swift, and bar was super buggy. Why would you blame that on Swift?
Turns out one of these bugs even has its own blog post: https://medium.com/@julioromano/working-around-an-infamous-m...
However if you adopt different patterns with Swift you can exclude a lot of optionals, for example if you give every View a State enum with associated values you can avoid quite a lot of optionals:
class PersonView: UIView {
enum State {
case empty
case loading(personId: String)
case loaded(person: Person)
}
var state: State = .empty {
didSet {
switch state {
/* handle all different states */
}
}
}
}
And it's applicable almost everywhere. I barely use optionals anymore unless I really can't replace them with an emum.
Have you tried
Crashlytics.sharedInstance().recordError(error)
Swift is not defensive, Swift can be defensive, but it can not if you don't want to.
It's much more "offensive" than Objective-C, for example.
Just a "!" and it's the same as Null Pointer Exception == Fatal Error.
Obviously, it's not Swift's fault for that, but even if people at Apple make rookie mistakes such as using force unwrap operator, it tells something about the language.
Actually I was wondering with Swift had a lot of these things I don't see much in other languages. Optionals for example. Is it because it us focused on coding highly responsive UIs where different states might not yet be available?
But most new languages has some variant of this stuff: kotlin, scala, rust.
I program a lot in Julia which is a script language and it does not have allow you to use null freely either. May seem odd for a language that does not type check at compile time. But it actually makes sense.
It's still often suggested by Xcode if you use an optional which has not been unwrapped in any way. "Click here to make error go away" adds an !.
--
[0] Unless you could invert the order of the unarchiving...not sure what difficulties that would cause.
C-family languages let you take off your whole leg with the slightest mistake.
In defence of Swift, it could still be that they spent less time bug-hunting than when they were developing in Objective-C, to reach the same, or inferior, level of program correctness.
Also, we're comparing a new product to a mature one. Were the original Objective-C programs stable in their first release?
Apple could have continued using the existing software, rather than just throw away stable code for the sake of new devs to use a new language.
Mandatory link to Spolsky's blog post on exactly this:
https://www.joelonsoftware.com/2000/04/06/things-you-should-...