I've been an iOS dev professionally since 2009! I just found Skip via Dave Verwer's newsletter today. Finally, finally! This is precisely what Apple should have built years ago!!!
I have just started a new iOS app and didn't want to do the Android app in React Native, Flutter, etc! Write in SwiftUI once! Nice, Nice!
Having spent 10 years as a Navy Nuclear Propulsion Operator on two different submarines operating the reactor plant, I can tell you I am not surprised by incidents like these. In order of importance:
1) Lack of sleep (it wasn't unusual to operate on no sleep over a 36-48 hour period)
2) Poor or insufficient training. Just because you are "trained or qualified" doesn't mean you know how to operate.
3) Poor or missing procedures (let's call it UI/UX for today's lingo). Many procedures were vague, and drawings were hard to understand. The Navy has a feedback system for this, but it often takes months/years to resolve.
Having said all that, the issues pointed out in the comments and the article, including my comments, have existed for decades in the Navy. At some point, it comes down to the command's leadership and superiors to ensure these issues don't happen. A poorly designed checkbox is the last thing that caused this issue.
> Many procedures were vague, and drawings were hard to understand. The Navy has a feedback system for this, but it often takes months/years to resolve.
When I worked for a DoD contractor I worked on a system that was designed to tighten one such feedback loop. The publicly-available copy regarding this unclassified effort [1] says that it was
> [a] framework for an end-to-end Change Request (CR) workflow system that will improve turn-around time and speed to the fleet. We are leading the innovation of a paperless cockpit through the design and development of an eFC mobile application that will provide responsive, reliable information for our aircrews on mobile devices at the touch of a button.
I thought that it was a pretty novel idea - it was certainly the most technically-progressive project I worked on when in defense contracting by a country mile. When I attended a program picnic at the Captain's house, however, I found no shortage of people who were skeptical of what we were building. When I pressed them for reasons why it basically amounted to "I learned what we have years ago and I don't want to change". Institutional rot is very real.
That said, there's something to be said about being resistant to change; "if it ain't broke, don't fix it". I don't know what "eFC" means, but "mobile application" implies they would need a new device with everything that entails.
As a career military aviator (about half and half flying and non-flying air ops jobs), there are definitely a surprising amount of Luddites in green flight suits. But there are also legit security concerns bringing modern mobile devices into a cockpit for the same reasons as the concerns around bringing one into a SCIF.
Having spent ~10 years each active and reserve in Naval Aviation, it still boggles my mind that the rest of the Fleet hasn't understood the concept of crew rest yet, or is at least only now beginning to understand it 60-70 years later.
We adopted it in the mid-20th century post-WWII because we were literally killing people for dumb reasons. I don't know if it's the well-known aviator hate among a significant minority of blackshoes that's the roadblock, or what.
There were also issues surround group dynamics and trust. A constant parade of ragged junior officers arriving and leaving leads directly to breakdowns in communication. Teams (driving a ship is a team effort) require stability.
The military doesn't really have the autonomy to reduce their own mission set. The major missions in terms of maintaining certain capabilities or protecting against certain adversaries are assigned by Congress and the President. The military then has to figure out how to execute within a budget that, while enormous in absolute terms, is still inadequate for everything they're tasked to do. There is no political will to fix this problem.
> A poorly designed checkbox is the last thing that caused this issue.
Indeed. The checkbox, the lack of sleep, the insufficient training and the cryptic instructions are all symptoms.
Lack of sleep is one thing I would think about deliberately employing to get a notion of what is the safe margins of individual crew members. For instance, I work very well under stress, but fail early on sleep deprivation.
Having been developing iOS apps since 2009, hard to believe 15 years, this is one of the finest writeups from a developer I've seen. Congrats on your hard work and the decisions you made developing your app. You made some great decisions, i.e., sticking to native development, no 3rd party dependencies, and sticking with Obj-C.
I made the move to Swift when it came out. However, there are many times I miss Obj-C and many of the advantages you mentioned. I often wonder what Obj-C would look like today if Apple had put the time and effort into it instead of Swift.
I was not aware of your app. I just downloaded it on my Mac and iPhone. It is really nice! I like the little things you have done, like the hints on the menu bars for using the Option key, and the hint disappearing when you do. I am going to continue to use it.
Thanks for sharing your experiences. Best of luck!
> I often wonder what Obj-C would look like today if Apple had put the time and effort into it instead of Swift.
It would largely look like Swift, since the goals of Swift (and most modern languages), safety and expressiveness, are fundamentally incompatible with C languages. There's really no point to basing a language on Obj-C if you're not keeping 100% compatibility, so they didn't.
There are a bunch of design decisions in Swift that make it more C++ with the corresponding binary bloat + other issues than reference counted Java/Smalltalk with a C FFI that Obj-C is.
You could've had Obj-C without the C for example, ADTs (enums), strong nullability enforcement and a nicer syntax while reusing most of the Obj-C core and retaining the compile speed, rock solid / fast debugging, function calls as data (selectors), easy mock creation and so on.
The systems programming capabilities is lost on %99.9 actual usage of swift. The swift project should've been split into two different projects IMO, where they modernized Obj-C into a successor language without making the C++ choices they did and created SwiftRust where the %0.1 that want system programming and nondeterministic multithreading capabilities can go do so. Apple second system effect-ed themselves hardcore with the Swift project, and it shows everywhere.
Sounds like you want Mojo, Lattner's statically typed language built on Python. In any case, the language you describe wouldn't be compatible with Obj-C except through an import layer like Swift. "Obj-C without the C" is meaningfully impossible.
And it's funny you mention systems programming, since Swift is still relatively bad at that compared to C++ or Rust, and most of its improvements in that area are recent and ongoing. It'll be another release or two before the memory movement features are fully in place and the language allows full control over ownership (without unsafe heroics at least).
Chris Lattner is on record that isn't something that Apple really cared about, and all Objective-C improvements starting with Objective-C 2.0 were already steps into improving the interoperability with what be later known as Swift.
Safe system programming is one of the key design goals from Swift.
