# iOS 10 Programming Fundamentals with Swift: Swift, Xcode, and Cocoa Basics

An episode of [CyberSecurity Summary](https://invisiblenetwork.ai/podcast/1816777677), 24 Sep 2026, 25 min.

Audio: https://dts.podtrac.com/redirect.mp3/api.spreaker.com/download/episode/73879985/the_logic_of_swift_objects_and_functions.mp3

A technical guide for aspiring mobile developers. It introduces the Swift programming language by emphasizing its object-oriented nature, where every linguistic entity is treated as an object. The material outlines the three primary flavors of object types—classes, structs, and enums—and explains foundational concepts like variables, functions, and scopes. Additionally, the source details the physical structure of a Swift file and the role of modules and namespaces in organizing code. By distinguishing between type declarations and instances, the text prepares readers to interact with the broader Cocoa framework and the Xcode IDE. This instructional overview serves as a systematic primer for building a rigorous understanding of the tools required for iOS development. You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cyber_security_summary Get the Book now from Amazon: https://www.amazon.com/dp/1491970073?lv=shuf&channelId=500&plpRedirect=mhFallback&linkCode=ll2&tag=cvthunderx-20&linkId=9a4cf31085b2a483542d51ea8bfe6f9b&language=en_US&gaOptInStatus=true&ref_=as_li_ss_tl Discover our free courses in tech and cybersecurity, Start learning today: https://linktr.ee/cybercode_academy

## Transcript

[0:00] Speaker 1: You know, if you were building iOS apps before before
[0:04] Speaker 1: twenty fourteen, imagine your development environment was sort of like
[0:07] Speaker 1: living in a grand historic mansion.
[0:10] Speaker 2: Oh yeah, a very very old mansion.
[0:13] Speaker 1: Right, and this house had been in the family for decades.
[0:15] Speaker 1: It had these amazing foundations, but over the years people
[0:18] Speaker 1: had just you know, bolted on these weird editions patches
[0:22] Speaker 1: everywhere exactly like there was a room you can only
[0:25] Speaker 1: access by climbing out a window, or the plumbing is
[0:29] Speaker 1: a total maze, and you constantly had to remember which
[0:32] Speaker 1: lights which shorted out the microwave.
[0:34] Speaker 2: That is an incredibly accurate description of the objective C
[0:37] Speaker 2: ecosystem back then.
[0:39] Speaker 1: It really was for a long time. That is exactly
[0:41] Speaker 1: what programming with objective C felt like. I mean, you
[0:43] Speaker 1: had bracket syntax everywhere, header files you had to manage.
[0:46] Speaker 2: Manually, oh of the header file.
[0:48] Speaker 1: Yeah, just so much historical baggage.
[0:50] Speaker 2: It was what you call a venerable legacy language. I mean,
[0:52] Speaker 2: it gave developers immense power and these really dynamic run
[0:55] Speaker 2: time capabilities, but it was absolutely full of tricky syntac
[1:00] Speaker 2: and well just traps for the unwary.
[1:04] Speaker 1: Yeah, you had to tread lightly.
[1:05] Speaker 2: You really did you just accepted that managing pointers manually
[1:09] Speaker 2: and dealing with super verbose method calls was you know,
[1:13] Speaker 2: the price of admission for building on an Apple platform.
[1:15] Speaker 1: And then at the WWDC keynote in twenty fourteen, Apple
[1:19] Speaker 1: just sent a massive shockwave through the entire developer community.
[1:23] Speaker 1: It was huge. They'd just announced like a new framework
[1:27] Speaker 1: or a minor syntax update for the old house. They
[1:29] Speaker 1: announced a total teardown, a complete blank slate, exactly, a clean, modern,
[1:35] Speaker 1: ground up rebuild that prioritized absolute clarity and safety. And
[1:40] Speaker 1: they called it Swift.
[1:41] Speaker 2: The audible gasp in the room when that slide hit
[1:44] Speaker 2: the screen is like legendary in the tech world.
[1:47] Speaker 1: I can imagine.
[1:48] Speaker 2: Nobody outside of a very small core team at Apple
[1:50] Speaker 2: saw it coming. I mean, developers were just completely accustomed
[1:53] Speaker 2: to the warts.
[1:54] Speaker 1: And the weight of objectivec They just figured they were
[1:56] Speaker 1: stuck with it forever.
[1:57] Speaker 2: Yeah, pretty much so. The idea that Apple had been
[2:00] Speaker 2: secretly developing this modern replacement for years was fundamentally paradigm shifting.
[2:05] Speaker 1: Okay, let's unpack this today. We are taking a deep
[2:08] Speaker 1: dive into the foundational architecture that clean rebuild.
[2:11] Speaker 2: It's going to be a fun one.
[2:12] Speaker 1: It really is. We are using Matt Nuberg's incredibly comprehensive
[2:16] Speaker 1: guide iOS ten programming fundamentals with Swift. Our mission here
[2:21] Speaker 1: is to give you a shortcut to understanding the matrix
[2:24] Speaker 1: behind modern iOS apps.
[2:26] Speaker 2: The real core rules.
[2:28] Speaker 1: Right. We're going to decode the underlying rules of Swift,
[2:31] Speaker 1: specifically looking at how objects, variable scopes, and functions operate.
[2:36] Speaker 1: And we're going to do it without drowning you in
[2:38] Speaker 1: dense code.
[2:39] Speaker 2: Nobody wants to hear raw code read aloud anyway, No,
[2:42] Speaker 2: definitely not.
[2:43] Speaker 1: Yeah, but if you want to understand how software architecture
[2:46] Speaker 1: actually dictates performance and safety, you are in the right place.
[2:50] Speaker 2: And Newbird's text is honestly the perfect roadmap for this.
[2:52] Speaker 2: He doesn't just show you how to write an app.
[2:54] Speaker 2: He deconstructs the actual philosophy of the language. Swift is
[2:58] Speaker 2: designed to be highly readable, documenting almost English like in.
[3:02] Speaker 1: Its method calls super friendly on the surface.
[3:04] Speaker 2: Exactly, But beneath that friendly modern surface is a very strict,
[3:09] Speaker 2: highly optimized engine. It has a rigid compiler that just
[3:12] Speaker 2: refuses to let you make the kinds of careless mistakes
[3:15] Speaker 2: objective c used to permit.
[3:16] Speaker 1: It won't let you get away with anything, not a chance.
[3:19] Speaker 1: So to understand that engine, we really have to start
[3:22] Speaker 1: with Swift's most radical foundational rule, and it's a structural pivot.
[3:28] Speaker 1: Swift is a purely object oriented language. Everything is an object,
[3:32] Speaker 1: right like, there are no exceptions.
[3:34] Speaker 2: And to fully grasp why that matters, you kind of
[3:36] Speaker 2: have to realize how different it is from older C
[3:39] Speaker 2: based languages.
[3:40] Speaker 1: Okay, how so, well, in C or.
[3:43] Speaker 2: Objective C you have primitive or scaler built in beta types,
[3:48] Speaker 2: things like simple integers or booleons.
[3:50] Speaker 1: Its raw data exactly.
[3:52] Speaker 2: They aren't objects. They're just raw pieces of data sitting
[3:54] Speaker 2: in memory. They don't have methods, they don't inherit from anything.
[3:58] Speaker 2: But in Swift there are no scalers, none at all. None.
[4:01] Speaker 2: Everything right down to a simple integer or a true
[4:04] Speaker 2: false boolean is treated as an object, which.
[4:06] Speaker 1: Means we are dealing strictly with three main flavors of
[4:09] Speaker 1: object types, right classes, strucks, and enoms.
[4:13] Speaker 2: That's the trio.
[4:14] Speaker 1: And here is where the architecture gets really interesting. Because
[4:17] Speaker 1: even a basic number like the digit one is a
[4:20] Speaker 1: struct behind the scenes, it's an object. And because everything
[4:24] Speaker 1: is an object, you can send messages to literally anything
[4:27] Speaker 1: using dot notation exactly.
[4:29] Speaker 2: The syntax model is totally uniform across the entire code base.
[4:33] Speaker 2: It's always the object than a dot, then the message
[4:36] Speaker 2: or method you're calling.
[4:37] Speaker 1: So the number one isn't just a raw digit sitting
[4:39] Speaker 1: in memory. You can write one dot description to immediately
[4:43] Speaker 1: get a string representation of it just like that. But
[4:46] Speaker 1: Newberg points out something even cooler. You can extend base types.
[4:50] Speaker 1: You could write an extension for the integer type in
[4:52] Speaker 1: your project so that you could literally type one dot
[4:56] Speaker 1: say hello, and the program would output hello, I'm one.
[5:00] Speaker 2: Yeah, you are modifying the fundamental behavior of numbers in
[5:03] Speaker 2: your app.
[5:03] Speaker 1: That's wild.
[5:04] Speaker 2: What's fascinating here is that this uniform structure creates extreme predictability.
[5:10] Speaker 2: In Swift, every noun in the language is an object,
[5:13] Speaker 2: and every verb is a message sent to that object.
[5:15] Speaker 1: Mounds and verbs. That's a great way to look at it, right.
[5:19] Speaker 2: There are no loose primitives floating around that require like
[5:22] Speaker 2: special handling. It forces a very clean mental model for
[5:26] Speaker 2: you as a developer. You always know exactly how entities interact,
[5:30] Speaker 2: whether it's a massive network controller or just the number
[5:34] Speaker 2: forty two.
[5:34] Speaker 1: Wait, I want to push back on that uniform model
[5:36] Speaker 1: for a second, though.
[5:37] Speaker 2: Okay, lay it on me.
[5:38] Speaker 1: If the number one is an object, yeah, and all
[5:41] Speaker 1: verbs are messages sent via dot notation. What about simple math?
[5:47] Speaker 1: What is the plus sign in one plus two? There's
[5:49] Speaker 1: no dot notation there. It looks exactly like c or
[5:52] Speaker 1: you know, third grade math class.
[5:54] Speaker 2: Yeah, that is where the compiler does some heavy lifting
[5:56] Speaker 2: to keep things readable. The plus sign is actually just
[5:59] Speaker 2: syntactic show. It's something called operator overloading.
[6:02] Speaker 1: Wait. Really, so the plus sign is literally just a
[6:04] Speaker 1: disguised method being called on the.
[6:06] Speaker 2: Object precisely under the hood. Operators like the plus sign,
[6:10] Speaker 2: the minus sign, or equality checks, they are just special
[6:13] Speaker 2: syntax for sending a message.
[6:14] Speaker 1: That's crazy.
[6:15] Speaker 2: When you write one plus two, you are literally sending
[6:18] Speaker 2: a message to the struct representing one, saying, execute your
[6:22] Speaker 2: internal addition method, pass in this other object the two
[6:26] Speaker 2: as the parameter, and return the result. Okay, Wow, The
[6:30] Speaker 2: language's internal logic remains perfectly consistent. It's all objects and messages,
[6:35] Speaker 2: but it hides that messaging behind familiar math symbols, so
[6:38] Speaker 2: your algorithms remain readable.
[6:40] Speaker 1: It doesn't look like a mess of dots in parentheses exactly.
[6:43] Speaker 2: And the LVM compiler optimizes this down to raw CPU
[6:47] Speaker 2: instructions anyway, so you don't take a performance hit for
[6:49] Speaker 2: the object oriented abstraction.
[6:51] Speaker 1: That is a massive architectural shift. It keeps the domain
[6:54] Speaker 1: model pure without sacrificing performance. Yeah okay, so if everything
[6:58] Speaker 1: in Swift is an object type, it's helpful to think
[7:01] Speaker 1: of those types as blueprints. Good analogy, But a blueprint
[7:04] Speaker 1: of a house isn't a house. Yeah right, you can't
[7:06] Speaker 1: live in it doesn't use memory. We need to move
[7:08] Speaker 1: from the abstract blueprint to concrete.
[7:11] Speaker 2: Reality, which brings us to the concept of instantiation. Declaring
[7:15] Speaker 2: an object type like a class or a struct just
[7:18] Speaker 2: tells the system what kind of thing could exist. It
[7:20] Speaker 2: defines the properties and methods. But to actually get one,
[7:24] Speaker 2: to allocate memory for it and use it in your app,
[7:26] Speaker 2: you have to instantiate it.
[7:28] Speaker 1: Newberg uses a classic example of a dog class. The
[7:31] Speaker 1: blueprint says, here is what a dog is. It has
[7:34] Speaker 1: a name property, and a bark method.
[7:37] Speaker 2: Basic dog stuff exactly.
[7:39] Speaker 1: But when you call dog with parentheses in your code,
[7:43] Speaker 1: you are telling that blueprint instantiate yourself. You're allocating memory
[7:47] Speaker 1: on the heap or the stack and bringing a specific, living,
[7:51] Speaker 1: breathing digital dog into existence.
[7:53] Speaker 2: And the primary reason we need these concrete instances is
[7:56] Speaker 2: to maintain what programmers call state state. Yeah, the dog
[8:00] Speaker 2: blueprint dictates that all dogs share the same behaviors, but
[8:03] Speaker 2: the instance is what holds the unique.
[8:05] Speaker 1: Data, right, the specific details.
[8:07] Speaker 2: That is what allows your first instance to hold the
[8:09] Speaker 2: name Fido its memory space, while your second instance holds
[8:12] Speaker 2: the name Rover. They share the logic, but their state
[8:15] Speaker 2: is entirely isolated.
[8:17] Speaker 1: And that isolated state is protected by a core principle
[8:19] Speaker 1: called encapsulation.
[8:21] Speaker 2: Yes, crucial concept.
[8:23] Speaker 1: The object hides its internal memory and mechanics from the
[8:26] Speaker 1: rest of the app. Newberg uses the example of a
[8:29] Speaker 1: stack data structure, like a stack of plates. You can
[8:32] Speaker 1: send it a push message to add an item or
[8:35] Speaker 1: a pop message to remove one, but the outside world,
[8:38] Speaker 1: the rest of your app, has absolutely no idea how
[8:42] Speaker 1: that stack is storing the items. Internally.
[8:44] Speaker 2: It could be in array, it could be a linked list.
[8:47] Speaker 1: Exactly, but the caller doesn't know and honestly doesn't care.
[8:50] Speaker 2: And that is a massive advantage for you when you're
[8:53] Speaker 2: maintaining a large codebase. Because the internal workings are hidden,
[8:56] Speaker 2: you can completely refactor how the stack stores data behind
[9:00] Speaker 2: the scenes.
[9:00] Speaker 1: You can totally get the inside of it right.
[9:02] Speaker 2: Maybe you find a much more memory efficient way to
[9:05] Speaker 2: handle the internal data. You can rewrite the inside of
[9:07] Speaker 2: that class, and you are guaranteed not to break the
[9:10] Speaker 2: rest of the application because the outside world only ever
[9:13] Speaker 2: interacts with the public API the push and pop methods.
[9:17] Speaker 1: It makes me think of like a high end restaurant kitchen.
[9:20] Speaker 2: Oh, I like that.
[9:21] Speaker 1: An object is basically the kitchen, the public API, the
[9:25] Speaker 1: methods you're allowed to call is the menu and the waiter.
[9:29] Speaker 1: You can order a meal that's sending a message, but
[9:31] Speaker 1: you are absolutely not allowed to walk through the swinging
[9:34] Speaker 1: doors into the kitchen, shove the executive chef aside, and
[9:38] Speaker 1: secretly swap out the salt for sugar.
[9:41] Speaker 2: That would end badly, very badly.
[9:43] Speaker 1: That private state the ingredients is strictly off limits.
[9:47] Speaker 2: Which brings us to access control, specifically the private keyword.
[9:51] Speaker 2: In Swift, you can explicitly lock the doors of your
[9:55] Speaker 2: object's namespace.
[9:56] Speaker 1: Just throw a dead ballt on it.
[9:57] Speaker 2: Pretty much. If your dog instance has a property for
[10:01] Speaker 2: say internal bark volume, you can market private. The dog
[10:04] Speaker 2: object can use it internally to calculate how loud to
[10:07] Speaker 2: bark based on its state, but no other part of
[10:10] Speaker 2: the code base can reach in and manipulate that integer directly.
[10:13] Speaker 2: It protects the integrity of the object's state.
[10:16] Speaker 1: Okay, so we spun up a concrete instance like Fido
[10:19] Speaker 1: the dog, we've protected his internal state using encapsulation and
[10:22] Speaker 1: private access control. But if we are spinning up thousands
[10:26] Speaker 1: of these instances in a complex app, how does iOS
[10:29] Speaker 1: track them without just drowning in memory leaks. We need
[10:33] Speaker 1: a way to reference them.
[10:34] Speaker 2: And this brings us to variables and scope.
[10:37] Speaker 1: Right.
[10:37] Speaker 2: Variables are essentially the named pointers we give to objects
[10:41] Speaker 2: or values so we can refer to them in our code.
[10:43] Speaker 2: They are the handles that let us grab onto the
[10:46] Speaker 2: memory we've allocated.
[10:47] Speaker 1: But in Swift, variables aren't just loosely created whenever you
[10:50] Speaker 1: feel like it. You have to declare them explicitly, and
[10:54] Speaker 1: you are forced to make a very specific architectural choice
[10:57] Speaker 1: right at the moment of creation, using one of two
[11:01] Speaker 1: keywords right.
[11:02] Speaker 2: Let or var let or var. This is one of
[11:04] Speaker 2: the most fundamental paradigm shifts. If you're coming to Swift
[11:07] Speaker 2: from an older language. If you declare your variable using let,
[11:11] Speaker 2: you are creating a constant.
[11:12] Speaker 1: It's locked thin.
[11:13] Speaker 2: The pointer is completely locked. The object or a value
[11:16] Speaker 2: you assigned to that variable can never be reassigned. But
[11:19] Speaker 2: if you use var for variable, you are explicitly allowing
[11:23] Speaker 2: that pointer to be reassigned to a new object later
[11:26] Speaker 2: in the execution.
[11:27] Speaker 1: And the Swift compiler is like completely obsessed with this distinction.
[11:30] Speaker 2: Oh, totally obsessed.
[11:31] Speaker 1: If you declare a variable with var, but the compiler's
[11:34] Speaker 1: static analysis notices you never actually reassign it anywhere in
[11:38] Speaker 1: your code, it will literally throw a warning just nagging
[11:42] Speaker 1: you to change it to let.
[11:43] Speaker 2: It's very boss.
[11:44] Speaker 1: It demands strictness. But why why does the compiler care
[11:48] Speaker 1: so much about whether I use let or var? If
[11:51] Speaker 1: the app works find either way.
[11:53] Speaker 2: It comes down to memory optimization and thread safety. When
[11:56] Speaker 2: the compiler knows a value is immutable, meaning it will
[12:00] Speaker 2: absolutely never change because it's marked with let, it doesn't
[12:03] Speaker 2: have to generate extra machine code to monitor that memory
[12:06] Speaker 2: space for changes. Like it doesn't have to worry about
[12:09] Speaker 2: two different background threads trying to change the variable at
[12:11] Speaker 2: the exact same millisecond and crashing the app. It can
[12:14] Speaker 2: store the data more compactly and access it faster at runtime.
[12:18] Speaker 2: It's pushing you to write CURD that is inherently safer
[12:21] Speaker 2: and highly optimized by default.
[12:23] Speaker 1: Here's where it gets really interesting. Let's talk about the
[12:26] Speaker 1: life span of these pointers. Variables have a scope and
[12:30] Speaker 1: a lifetime. In Swift, scope is usually dictated by structural
[12:34] Speaker 1: curly braces. So if I initialize a new dog instance
[12:38] Speaker 1: and assign it to a variable, but I do all
[12:40] Speaker 1: of that inside a simple if statement block, what happens
[12:44] Speaker 1: when the compiler hits the closing curly brace of that
[12:47] Speaker 1: if statement the end of the line. Do the pointer
[12:50] Speaker 1: and the memory just vanish?
[12:51] Speaker 2: They absolutely do. Newberg describes it perfectly. They vanish in
[12:54] Speaker 2: a puff of smoke that.
[12:56] Speaker 1: Feels almost ruthless compared to languages with looser memory management.
[12:59] Speaker 2: It is strict, but it's the bedrock of Swift's automatic
[13:03] Speaker 2: reference counting or ARC. The variable only lives as long
[13:06] Speaker 2: as the structural scope the curly braces surrounding it, So.
[13:10] Speaker 1: The second it steps outside those braces, once.
[13:12] Speaker 2: The program's execution steps out of those braces, the variable
[13:15] Speaker 2: goes out of scope. If that variable was the only
[13:17] Speaker 2: thing holding onto your dog instance, ARC immediately frees up.
[13:21] Speaker 1: That memory just deletes it.
[13:23] Speaker 2: It forces you to be very deliberate about the hierarchy
[13:25] Speaker 2: of your data, ensuring objects live exactly as long as
[13:28] Speaker 2: they are needed and not a millisecond longer, which prevents
[13:31] Speaker 2: memory blow.
[13:32] Speaker 1: Okay, so we have our instances, we store them securely
[13:35] Speaker 1: with strong memory constraints using variables, and we understand their lifetimes.
[13:39] Speaker 1: But an app isn't just static data.
[13:41] Speaker 2: No, it has to do things right.
[13:43] Speaker 1: It has to calculate, update the UI, fetch JSON from
[13:46] Speaker 1: a server. That executional logic happens exclusively inside functions.
[13:51] Speaker 2: Functions are the execution blocks of Swift. All your operational code,
[13:56] Speaker 2: the actual logic of your application, must live inside a
[13:59] Speaker 2: function or a method.
[14:01] Speaker 1: Newberg breaks down the anatomy of function into distinct parts.
[14:04] Speaker 1: He describes it kind of like an elementary school math
[14:07] Speaker 1: textbook machine. Right.
[14:08] Speaker 2: I love that imagery.
[14:09] Speaker 1: You have a hopper at the top for input the parameters.
[14:12] Speaker 1: You have gears in the middle where the body of
[14:13] Speaker 1: the function executes, and a tube at the bottom for
[14:16] Speaker 1: the output the return value.
[14:17] Speaker 2: And what governs that entire process is the function signature.
[14:21] Speaker 2: Think of it as a strict, unbreakable memory contract, a
[14:25] Speaker 2: contract yeah. For example, a signature that looks like int
[14:28] Speaker 2: int arrow int dictates exactly what types enter the function,
[14:32] Speaker 2: in this case two integers and exactly what type is
[14:35] Speaker 2: repern one integer, and Swift.
[14:38] Speaker 1: Puts a massive premium on readability here. It automatically externalizes
[14:43] Speaker 1: parameter names.
[14:44] Speaker 2: Yes, this is such a great feature.
[14:46] Speaker 1: So when you call the function in your code, it
[14:48] Speaker 1: reads clearly. You don't just pass random digits like echo
[14:52] Speaker 1: parentheses two comma three. You write out echo string col
[14:56] Speaker 1: and high times colon three.
[14:57] Speaker 2: It acts as self documenting code.
[15:00] Speaker 1: So a developer reading it six months later instantly knows
[15:03] Speaker 1: what the parameters do exactly.
[15:05] Speaker 2: Though it's also important to note that sometimes there is
[15:08] Speaker 2: no output. A function might return absolutely nothing, which Swift
[15:12] Speaker 2: denotes as void or just empty parentheses.
[15:15] Speaker 1: Why would you want a function that returns nothing?
[15:17] Speaker 2: You invoke these functions purely for their side effects. Maybe
[15:20] Speaker 2: they trigger an animation on the screen or save a
[15:23] Speaker 2: file to the disk, but they don't hand a piece
[15:25] Speaker 2: of data back to the caller out of that bottom too.
[15:28] Speaker 1: Got it? Now I want to ask about the rigidity
[15:30] Speaker 1: of these contracts. Why is Swift so incredibly strict about
[15:33] Speaker 1: these function signatures like if I pass a float instead
[15:36] Speaker 1: of an integer, it just flat out refuses to compile.
[15:40] Speaker 2: If we connect this to the bigger picture, it goes
[15:41] Speaker 2: right back to the flaws of objective C.
[15:44] Speaker 1: The old mansion.
[15:44] Speaker 2: The old mansion. In objective C, message passing was dynamic.
[15:49] Speaker 2: You could accidentally pass the wrong type of object to
[15:51] Speaker 2: a method. The compiler might just give you a mild
[15:54] Speaker 2: warning and let you build the app anyway.
[15:56] Speaker 1: That sounds dangerous, it was.
[15:59] Speaker 2: Because when the user runs it and the method tries
[16:01] Speaker 2: to operate on a text string when it actually expected
[16:03] Speaker 2: a number, it throws an unrecognized selector exception.
[16:07] Speaker 1: And the app hard crashes in the user's hands exactly.
[16:10] Speaker 2: Swift's strict static typing prevents this entirely. If the signature
[16:15] Speaker 2: demands an integer and you try to pass a string,
[16:18] Speaker 2: it simply will not build. It shifts the burden of
[16:22] Speaker 2: catching type errors from the user's run time back to
[16:25] Speaker 2: the developer's compile.
[16:26] Speaker 1: Time, which completely eliminates whole categories of crashes.
[16:29] Speaker 2: It's a lifesaver.
[16:30] Speaker 1: But let me ask a logic question about chaining these
[16:33] Speaker 1: execution blocks together. If a function requires an integer as
[16:36] Speaker 1: an input and another function returns an integer as an output.
[16:40] Speaker 1: Can I just shove a function inside a function like
[16:43] Speaker 1: nesting them? Yeah? Newberg has this example some and in
[16:47] Speaker 1: the parentheses four comma some parentheses five comma six foot
[16:52] Speaker 1: Does the compiler evaluate that seamlessly?
[16:55] Speaker 2: Yes, and it's completely reliant on that type safety we
[16:58] Speaker 2: just discussed. The compiler of evaluates the innermost function. First,
[17:02] Speaker 2: it runs the sum of five and six, verifies that
[17:05] Speaker 2: it returns an integer, in this case eleven, and then
[17:08] Speaker 2: drops that integer directly into the parameter of the outer
[17:11] Speaker 2: function alongside the four clean Because the compiler can mathematically
[17:15] Speaker 2: guarantee the types match the contract at every single step,
[17:18] Speaker 2: it allows for infinite safe composition of functions.
[17:22] Speaker 1: Strict type signatures, scope limits, constants that cannot mutate. But
[17:29] Speaker 1: just as you get comfortable with all these rigid boundaries,
[17:31] Speaker 1: Swift reveals it has some incredibly powerful mechanisms to subvert
[17:34] Speaker 1: these very rules when necessary.
[17:36] Speaker 2: This is where Swift goes from being merely a safe
[17:39] Speaker 2: language to a highly flexible, expressive one.
[17:42] Speaker 1: Let's look at modifiable parameters. We established earlier that when
[17:45] Speaker 1: you pass a value into a function's parameters, it's treated
[17:48] Speaker 1: as a constant inside that function.
[17:50] Speaker 2: Right, It is a let variable.
[17:53] Speaker 1: By default, the function can't change the original data you
[17:55] Speaker 1: passed in. But by using the keyword in out in
[17:59] Speaker 1: the function signature and passing a variable's memory address using
[18:02] Speaker 1: an ampersand symbol, a function can permanently alter a variable
[18:06] Speaker 1: that lives entirely outside of its own scope.
[18:09] Speaker 2: Yes, the amber sand is a critical piece of syntax here.
[18:12] Speaker 2: When you use it at the call site, it acts
[18:14] Speaker 2: as a mutation warning, like a red flag. Exactly. It
[18:17] Speaker 2: tells anyone reading the code, be careful. This function isn't
[18:20] Speaker 2: just reading this variable. It's going to mutate its underlying
[18:24] Speaker 2: memory directly. Newberg uses an example of a removed character function.
[18:28] Speaker 2: Oh right, You pass a string variable with an amber san.
[18:32] Speaker 2: The function processes, it strips out specific characters, and when
[18:36] Speaker 2: the function completes, your original string in the outer scope
[18:39] Speaker 2: is permanently modified.
[18:40] Speaker 1: It reaches right out of its own curly braces to
[18:42] Speaker 1: mutate external state. That's powerful, But the most mind bending
[18:47] Speaker 1: architectural feature has to be the concept of functions as
[18:51] Speaker 1: first class citizens.
[18:52] Speaker 2: This is a huge paradigm shift, especially for developers use
[18:55] Speaker 2: to languages where methods are just static blocks of execution.
[19:00] Speaker 2: In Swift, a function is not just an action. A
[19:03] Speaker 2: function is actually a value itself.
[19:05] Speaker 1: Meaning a function has a type, just like an integer
[19:07] Speaker 1: or a string has a type. Yes, the function's signature
[19:10] Speaker 1: is its type. And because it is treated as a
[19:13] Speaker 1: value in memory, you can assign an entire function to
[19:16] Speaker 1: a variable pointer. Or even crazier, you can pass a
[19:20] Speaker 1: function directly into the parameters of another function.
[19:22] Speaker 2: A classic example in everyday iOS development is uiview dot animate.
[19:27] Speaker 2: When you want to transition a button across the screen,
[19:29] Speaker 2: you don't just call a method and hope it works.
[19:31] Speaker 2: You pass an anonymous function, a block of executable code
[19:35] Speaker 2: often called a closure that doesn't even have a name,
[19:38] Speaker 2: directly into the animation methods parameters Wow, and you can
[19:41] Speaker 2: pass a second closure to tell the operating system exactly
[19:45] Speaker 2: what code to execute after the animation completely finishes. This
[19:49] Speaker 2: raises an important question, though, why would we ever want
[19:52] Speaker 2: to pass a function into another function. Isn't that just
[19:55] Speaker 2: adding unnecessary complexity to the code base.
[19:57] Speaker 1: Well, based on Newberg's text, it's actually about drastically reducing
[20:02] Speaker 1: complexity and solving the problem of boilerplate code. He use
[20:06] Speaker 1: is the example of drawing graphics contexts. If you want
[20:09] Speaker 1: to draw three different images. The steps to open a
[20:12] Speaker 1: drawing context, allocate the memory, extract the final image, and
[20:16] Speaker 1: close the context are perfectly identical every single.
[20:19] Speaker 2: Time, just repetitive, dizzy work exactly.
[20:22] Speaker 1: The only thing that changes is the specific lines, circles,
[20:25] Speaker 1: or colors you draw in the middle.
[20:27] Speaker 2: If you didn't have first class functions, you would have
[20:29] Speaker 2: to copy and paste that identical setup and tear down
[20:32] Speaker 2: code everywhere, which violates the dry principle don't repeat yourself.
[20:36] Speaker 2: But by passing a function as a parameter, you write
[20:39] Speaker 2: the repetitive context management once in a utility function. Then
[20:43] Speaker 2: you simply pass the unique drawing instructions in as a
[20:46] Speaker 2: closure parameter. The utility function sets up the canvas, executes
[20:50] Speaker 2: your custom closure, and cleans up the memory. It abstracts
[20:54] Speaker 2: away all the repetitive work.
[20:56] Speaker 1: So what does this all mean? Let me try an
[20:57] Speaker 1: analogy here, go for it. Passing a function as a
[21:00] Speaker 1: value into another function is exactly like handing a coworker
[21:04] Speaker 1: a sealed envelope with a list of instructions. You hand
[21:07] Speaker 1: them the envelope and say, don't read this right now,
[21:10] Speaker 1: don't execute these steps, just hold on to it. But
[21:13] Speaker 1: when the database finally finishes loading, open this envelope and
[21:17] Speaker 1: execute exactly what is written inside.
[21:19] Speaker 2: That is a brilliant way to conceptualize it. You are
[21:22] Speaker 2: passing the potential for.
[21:23] Speaker 1: Execution, the potential. I like it that.
[21:25] Speaker 2: You are packaging up a block of logic, capturing the
[21:28] Speaker 2: state it needs, and handing it off to be executed
[21:30] Speaker 2: at a later time or under specific asynchronous conditions by
[21:34] Speaker 2: whatever system you pass the envelope to. It is the
[21:37] Speaker 2: absolute backbone of asynchronous programming in Swift.
[21:41] Speaker 1: It's just an incredibly elegant way to handle execution flow.
[21:44] Speaker 1: We've covered a massive amount of architectural ground today.
[21:47] Speaker 2: We really have.
[21:48] Speaker 1: We started with a shocking pivot at WWDC, tearing down
[21:51] Speaker 1: the fragile dynamic house of objective C to build the
[21:54] Speaker 1: strictly typed compiled foundation. We explored the radical unifying idea
[21:59] Speaker 1: that absolutely everything, even a simple number, is an object
[22:03] Speaker 1: capable of receiving messages.
[22:04] Speaker 2: We looked at how abstract blueprints are allocated in memory
[22:07] Speaker 2: as concrete instances managing their own private state through strict
[22:11] Speaker 2: encapsulation right, and we decoded how scope dictates exactly when
[22:16] Speaker 2: that memory vanishes in a puff of smoke.
[22:18] Speaker 1: And Finally, we looked at how the ironclad contracts of
[22:21] Speaker 1: function signatures not only prevent run time crashes, but can
[22:25] Speaker 1: actually be leveraged to pass executable logic around your app
[22:30] Speaker 1: like sealed envelopes of instructions.
[22:32] Speaker 2: All ties together.
[22:33] Speaker 1: It does the next time you were using an app
[22:36] Speaker 1: and you cap a button that triggers a flawless, smooth animation.
[22:40] Speaker 1: I want you to visualize what's happening under the hood.
[22:43] Speaker 1: Think about the hidden instances managing their protected state, the
[22:46] Speaker 1: strict scope boundaries keeping the memory footprint perfectly optimized, and
[22:50] Speaker 1: those anonymous closures passing logic behind the scenes to make
[22:53] Speaker 1: the interface feel like magic.
[22:55] Speaker 2: It genuinely gives you a profound appreciation for the matrix
[22:58] Speaker 2: of rules and compiler opizations operating silently in your pocket
[23:02] Speaker 2: billions of times a second.
[23:03] Speaker 1: It really does. But before we wrap up, I want
[23:06] Speaker 1: to leave you with one final fascinating puzzle to mole over.
[23:09] Speaker 1: Straight from Newberg's text. We learned earlier that everything in
[23:13] Speaker 1: Swift is an object, and that includes strings, massive blocks.
[23:17] Speaker 2: Of texts right text strings.
[23:19] Speaker 1: But in Swift strings are specifically built as value types,
[23:23] Speaker 1: meaning they are strucks, not classes, and the defining rule
[23:26] Speaker 1: for value types is that they are not shared by
[23:28] Speaker 1: a single pointer. They are effectively copied entirely every single
[23:33] Speaker 1: time they are assigned to a new variable or passed
[23:35] Speaker 1: into a function.
[23:36] Speaker 2: That's right. Unlike classes, which are reference types that just
[23:39] Speaker 2: pass around appointed to the exact same instance in memory,
[23:42] Speaker 2: structs technically demand a brand new copy of themselves every
[23:46] Speaker 2: time they cross a scope boundary.
[23:48] Speaker 1: So think about the architectural implications of that. If a string,
[23:51] Speaker 1: say a massive ten page article of text in a
[23:54] Speaker 1: news app, is technically being copied over and over and
[23:57] Speaker 1: over again every single time gets passed around the complex
[24:00] Speaker 1: labyrinth of functions in an iOS app, how does your
[24:03] Speaker 1: iPhone not run out of memory instantly?
[24:05] Speaker 2: That sounds like it should, right exactly.
[24:08] Speaker 1: How does the processor survive the overhead of all that
[24:11] Speaker 1: constant memory duplication. It's a brilliant question about how the
[24:16] Speaker 1: Swift compiler secretly manages memory under the hood with a
[24:19] Speaker 1: trick called copy on write, A very clever trick, and
[24:22] Speaker 1: it just goes to show how much more depth there
[24:24] Speaker 1: is to explore when you dig into the differences between
[24:26] Speaker 1: value types and reference types on your own. Until next time,
[24:30] Speaker 1: enjoy exploring the clean modern architecture of Swift

Shows are listed from Apple Podcasts' charts and directory, and Podcast Index where it is used. Every show and episode belongs to its publisher and plays from the publisher's own feed; this site hosts none of them.