TIL I finally learned when to use unowned as opposed to using weak. Differences Under the hood: unowned is essentially a force-unwrap of a weak capture, with all that it entails. Because of this using it slightly more dangerous. Crash danger: Accessing an unowned reference while it’s nil will cause a crash. Compilation error: Every weak reference, must be an optional property. Otherwise you’ll get a compilation error: weak var delegate: DataEntryDelegate = DataHandler() // ERROR: 'weak' variable should have optional type 'DataEntryDelegate?' Call site: Unlike weak references, it’s not mandatory for unowned references to be an optional. This makes the call site cleaner i.e. you don’t have to do the optional unwrapping dance. Similarities Both don’t keep a strong hold on the instance it refers to. Don’t Use unowned for async/network operations. Because the object may become nil and then accessing it would crash! ...

I know this blog is mainly an engineering blog, but this is something I struggled to learn and thought blogging my findings would be helpful for my friends who want to learn about their investments or evaluate and compare offers. The following are a result of my findings after an hour long phone call with Fidelity representative. I opened the chat section in my browser and asked to speak with someone. They gave me a phone number. And they’re available Monday - Sunday til midnight EST. I was waiting on the line for about 7-8 minutes. I had an hour long great conversation + along with some follow up questions with some friends. After 3 yrs of being an employee I finally got answers. Please note I made some changes to the actual numbers. The screenshots are just for demonstration purposes. ...

1 - The sync closure func processTwoNumbers(_ num1: Int, _ num2: Int, handler: (Int, Int) -> ()) { handler(num1, num2) } processTwoNumbers(10, 22, handler: { num1, num2 in print(num1 + num2) }) In the above, the handler is called in a sync matter. Same as below (1...100).forEach { val in print(val) } print(101) Uniqueness: The block passed in is executed immediately at the call site. 2 - The async closure — block isn’t stored. enum Result { case success(Data?) case failure(Error?) } func startFlow(handler: @escaping (Result) -> ()) { let url = URL(string: "https://i.imgur.com/7oZTmIC.jpeg")! let task = URLSession.shared.dataTask(with: url) { data, response, error in if error == nil { handler(.success(data)) } else { handler(.failure(error)) } } task.resume() } Uniqueness: handler block is called by the startFlow function. Execution of the block is within the function itself. It gets called after some asynchronous operation. ...

I used to find it super hard to read git syntax. I didn’t know what what --, <>, [], ..., |, (), etc meant. Turns out, it’s a whole lot easier than you think. The synopsis contains a list of most likely forms you’d try. But sometimes the synopsis is just one big long synopsis where all the options are thrown in at once. This can make it hard to understand the different ways of using the options and commands. ...

When you get on a plane, the crew members make sure everyone that checked in, is actually on the flight. If someone doesn’t board, then the plane either stays until they board or remove them and their luggages from the plane. It’s a safety check. CocoaPods does something similar. But before we dive deep into what a Manifest.lock file is, we should learn about the two schools of thoughts when it comes to dependencies. ...

I was using Xcode’s View Hierarchy and noticed this UITransitionView in my view hierarchy. ... UIWindow UITransitionView FooVC UITransitionView BarVC This was odd because I was expected a view hierarchy as such: ... UIWindow UITransitionView FooVC BarVC What made it more perplexing was that the canvas was showing things correct, but the View Hierarchy didn’t make sense. To be clear on jargon, the following is the name of each section of Apple’s view debugger: ...

Edit Ever since I’ve upgraded to Xcode 16.1 I’ve experienced significant issues with finding callers. Yet aside from Xcode being broken, this post is still applicable for having a correct understanding of when / why / how Xcode should and shouldn’t work. Sample Project Download the sample project if you want. You don’t have to though. The project doesn’t even need to be ran. It’s just provided for context. I’m going to discuss two gotchas I hade with Xcode. For quite some time I thought a fix was coming, then I realized this is because I didn’t fully understand the difference between an interface (or protocol) with a concrete type. ...

I always thought that if you just use {get} on a protocol variable, then you can still set it i.e. it doesn’t matter if you give it a setter or not. That’s not true. It really depends on which compiler checks come in to place. Compiler checks are different depending on the type you want a variable to be. Can you guess which of the two snippets will compile? Snippet A ...