For me, I have spent many years, writing code that presents UI, or controls devices.

That has some aspects of software development that I rarely hear discussed, like testing, usability, accessibility, aesthetics, graphic design, error handling and recovery, documentation, support, configuration management, and lots of system framework knowledge.

If I am supposed to be writing apps for iOS devices, then I’d think knowledge of UIKit would be a heck of a lot more important than balancing a binary tree. I can tell you, from personal experience, that it takes a long time to learn, and is very important, if you want actual, shipping apps.

Even so, I have often encountered obsession with “büzzwürd du jour,” and people get hung up on things like MVVM/MVP, VIPER, etc.

I remember once, getting a “take home” test that asked me to implement an iOS app that employed MapBox, which is an excellent library, but, at the time, I had never used. I was instructed to use MVVM. I have no idea why.

In four hours, I had a completely functional, localizable, well-code-documented, nearly ship-ready (including a custom app icon and splash screen), high-quality app that implemented MapBox (again, I had never even looked at MapBox before this test), using Dependency Injection (basically, the “D” in “SOLID”). If I incorporate dependencies, I always encapsulate the dependency, and DI is an excellent way to do that.

Oh, also, while I was working on the app, we had a household emergency that required urgent attention. The app would have taken less time to write, otherwise.

It was not received well. To this day, I have never learned why. I suspect that I was supposed to spend a couple of days, creating some kind of chimera that illustrated every buzzword on Earth. No matter. I wasn’t what they wanted, and, after that experience, I realized I would probably not enjoy working with them; which was a bit disappointing, as I liked their product. I felt that I could have had a fairly significant impact on their Apple software.

In my experience, I have found it’s always best to use the development model a framework is designed to support; even if it isn’t particularly “buzzwordy.” If we use UIKit, then MVC is the most practical and simplest approach, as that is how the SDK was designed. If we use SwiftUI, then we have a great deal more flexibility with our models, but very few companies are willing to ship SwiftUI apps (yet).

Shipping is all about practical approach. Ship software should be done quickly, as simply as possible, and needs to be robust, well-documented, organized, testable, Extensible, and maintainable. If we are talking Apple apps, then they should also be performant, responsive, secure, highly usable, intuitive, aesthetically pleasing, accessible, and that employ familiar (to the user) idioms. They also need to pass App Store Review muster, so that means being careful about how we incorporate dependencies and frameworks, as well as not using private APIs.

Since I’ve had over twenty apps in the App Store that I’ve written from scratch (but I'm down to seven, right now: https://littlegreenviper.com/AppDocs/), this is something I do know a bit about.

That usually requires a great deal of frugality, practicality, user empathy, experience, and self-discipline. It’s difficult to figure that out with “Draw Spunky” binary tree tests.