[4eleven7]

Actually I disagree. Since I started writing new apps exclusively in Swift, my apps have crashed exactly zero times according to Fabric/Crashlytics. I adopted day one, never looked back. It is an incredibly safe language when used correctly (never force unwrap for example, ever). While previously my Objective-C apps did have numerous crashes in them. I took on an Objective-C contract recently, and it was a nightmare.

Of course, mixing with Objective-C may actually be the cause of issues or crashes? Who knows.

[gurkendoktor]

As a counter-example, the macOS Dock was rewritten in Swift in macOS 10.12, and Mission Control was super buggy for me then. I'm not blaming this on Swift, most rewrites are buggy at first. And it never outright crashed, but getting stuck in inconsistent states is not much better.

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.

[dep_b]

True, I think Crashlytics still doesn't work very well for logging unusual but not crashing program situations. I would like to have an elegant solution for that. I always throw assertionErrors in case something weird happens handling an optional.

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 */
                }
            }
        }
    }

Every time you switch state you need to give the right associated value and every time you are in this state this value is guaranteed to be there where before you would have an optional personId and an optional person.

And it's applicable almost everywhere. I barely use optionals anymore unless I really can't replace them with an emum.

[Unknoob]

> I think Crashlytics still doesn't work very well for logging unusual but not crashing program situations.

Have you tried

    Crashlytics.sharedInstance().recordError(error)

I use it to log errors on API calls in my projects. It comes in handy when I'm using third-party services and they decide to break something on their end.

[jchb]

The idea of an option type (Optional in Swift) is to use it only for a variables truly assume a "none" value at some point. With the guarantees of such a type it is easier to reason about the correctness of a program - compared to Objective-C where a pointer anywhere may be null at any time. Optional shouldn't be used for most variables and parameters. `guard let param = param else { return }` should be something pretty rare. I would mostly expect to see that for weak self variables in completion blocks.

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.

[gurkendoktor]

> Optional shouldn't be used for most variables and parameters.

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.

[jchb]

Replying to your specific examples, I would say `storyboard!.foo` and `viewController.navigationController!` (when you know the view controller is in a navigation controller) is the correct thing to do. And if your assumptions are false that is going cause a trap at runtime, and you will get your crash report.

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.

[gurkendoktor]

> But what are you suggesting Apple should do?

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

[dwaite]

>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.

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)

[dep_b]

I did notice that a lot of Objective-C's uncertainties were paved over when the years passed. Most libraries feel a lot more Swift-y but there are some problems and it's a pity that Storyboards are one of them. I hope they'll revise the system some day.

[wool_gather]

The point stands, however, that just because developers are forced to handle the `nil` somehow, doesn't mean they're handling it in a sensible way that makes for consistent UX. Crashing sucks from a user perspective, obviously data corruption is even worse, but just throwing up your hands and returning early from a view controller method doesn't really do anything for the user either.

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.

[jchb]

> when Optional values start brushing up against that top level of user-visible stuff

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? `

[lewisj489]

j

[bunnycorn]

> In fact, I would argue that this new trend of defensive programming in Swift

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.

[Someone]

”the macOS Dock was rewritten in Swift in macOS 10.12, and Mission Control was super buggy for me in that version. I'm not blaming this on Swift”

Foo was rewritten in Swift, and bar was super buggy. Why would you blame that on Swift?

[gurkendoktor]

Mission Control is part of Dock.app.

Turns out one of these bugs even has its own blog post: https://medium.com/@julioromano/working-around-an-infamous-m...