Most videos just load everything in ViewDidLoad and hope for the best. NEVER USE THIS. 

viewDidLoad, loads before appears, by nature the visual area hasn't been rendered, so you have massive race condition checks every time your app launches. Does it create the interface before it's been rendered? Fatal crash... so... just leave this blank, and initiate in viewDidAppear. The older the device, the more likely the crash. Corporate developers usually have the best devices to test on and don't see this error happen. 

To explain the fatal crash : If the compiler is trying to create a window, positioned on the screen, but the initial screen hasn't appeared yet... it doesn't know where or how to do it, and crashes. 

viewDidAppear: Use this to begin everything. Make 1 function "getOutOfAppear" or whatever you want... just don't paste all your stuff in the viewDiDAppear bracket. Once you start this practice, the rest of the flow will follow. 

Every interview has the baseline question about object oriented programming, architecture, and I have a feeling the interviewers can tell I'm reciting a script instead of speaking from wisdom. 

It's the dumbest question possible. Best practices create a new ViewController because it puts everything in viewDidLoad. You also don't realize compilers can handle more than 1 thing now. 

You also create multiple files making debugging harder. You're just going to cntrl F to find the function anyway, why make a new file? 

In addition, each new data manipulation requires the passing of data without losing integrity. I have the data saved in 1 array. You save it there too... then you pass it to the new view... do stuff with it, pass it back, and have to ensure it updates properly. I just do stuff at the index. 

Imagine you're a Marine in 'Nam. The fewer VC, the better. 

I hate APIs. 

In the physical world, structural stability is a thing. Japanese woodworking interlocks the joints of wood to create additional stability. I think there's a mathematical tradeoff : strength and friction. You need the friction to strengthen the structure, and the strength of the joint determines if it can handle the friction? The more structurally sound joints, the more friction, the stronger the structure.

IDK, I got a D in intro to engineering... it was 1st period, 2nd semester, 4 degree year. Final 40 is not fun. 

In the virtual world, that's all garbage. There is no structure. It's just pass/fail. Did you fully connect? So, make a flat surface. Instead of making each data point some massively unique thing that has to be uniquely coded, make your API offering just a flat string that can be easily consumed. 

Every data variation is not a joint creating strength, it's a piece of code that must be mirrored by your customer, and a chance to create a bug for their developer. Therefore, it's a vulnerability, not a strength. 

Stop making your API shit just because you think it's fancy. Make it easy for your customer to talk to you. 

Maybe I'm lazy. I was voted "biggest slacker" in high school. I haven't read through the SDKs I use. What that means is, I don't know everything they do.

However, the basics of cybersecurity are as follows: data are in 3 states : at rest, in transit, in use. 

For example: With my first responder app, I send data to the Google Firebase Cloud. It's in use on the app, in transit between device and cloud, in storage in cloud. While in transit and in storage, it is vulnerable. Also, Google basically can whatever it wants whenever it wants while in those 2 phases as I use Google's encryption to handle both phases. Technically so can Apple at the "in-use" layer. 

Example 2: All iOS apps now have a built in Siri integration and it feeds all other AI platforms because Tim Cook is a spineless globalist. Which NGOs gets access to your photo album because of Apple's new default Siri integration layer? 

Every API integration means you are outsourcing the storage, transit, and possibly even use of your data with unknown possible additional APIs added on top of it. Respect your customer and do the work to not have an API. Eventually you'll realize the maintenance of interfacing with some scrub's code is harder than writing it yourself. 

As a contract IT PM in the software space, I get paid to handle bad architecture. Oh, you have a COTS product for each function in your software so you now have to work with 10 different companies in India to make 1 change all while making all of your proprietary information and customer data vulnerable to the best salesman? Dumbasses. 

Use Case, IT Horror Edition: What would Jeffrey Epstein's homies do with any children oriented brand's online store customer list? 

I actually use it in every app for 1 very specific use. 

I also use it for 1 specific use case on cloud apps. (get the connection started)