December 14, 2025 • 18 mins
A comprehensive guide for learning iOS app development, starting with the fundamentals of the Swift programming language, including variables, control flow, and collections. The book thoroughly explains the use of Apple's development tools, such as Xcode and Playgrounds, and covers key application architecture concepts like Model-View-Controller (MVC), design patterns, and memory management. The later sections progress into core iOS UI development topics like Auto Layout, protocols, the delegate pattern, and an introduction to the declarative UI framework SwiftUI.
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/Swift-30-Days-Learning-SwiftUI/dp/9391030106?&linkCode=ll1&tag=cvthunderx-20&linkId=3a2deef167e53e41372bfca9a9750ba0&language=en_US&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
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/Swift-30-Days-Learning-SwiftUI/dp/9391030106?&linkCode=ll1&tag=cvthunderx-20&linkId=3a2deef167e53e41372bfca9a9750ba0&language=en_US&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Welcome back to the deep dive. Today, we're really jumping in,
launching straight into the well, the bedrock of the Apple ecosystem.
Our goal isn't just to skim the surface. We want
to pull out those foundational pillars, the architecture, the tools,
and really the philosophy behind Swift.
Speaker 2 (00:18):
Yeah, the core ideas exactly the.
Speaker 1 (00:19):
Stuff any aspiring iOS dev needs to get. This is
about understanding the why behind the code.
Speaker 2 (00:26):
You write, right, And I think for anyone starting out,
the key takeaway is that Swift isn't just another language
thrown out there. It was built very deliberately with specific goals.
Specific goals safety, clarity, and performance that shapes everything, how
you declare variable, how memory works, all of it.
Speaker 1 (00:44):
Okay, so let's unpack that starting big picture. Yeah, an
iOS app. Yeah, it's like its own little world, right,
what's at its core?
Speaker 2 (00:50):
Fundamentally, you can think of any app as having let's
say three main parts the screen what the user interacts with, Okay,
the code, the logic, the instructions, and the data the
information it holds onto screen code data simple enough, and
the whole thing operates in what we call an event
driven paradigm.
Speaker 1 (01:08):
Right, Event driven. That's important. It's not just running top
to bottom like a script, not at all.
Speaker 2 (01:13):
The phone or iPad is basically just sitting there waiting,
waiting for an event like a button tap, a button tap,
a notification, maybe a timer firing. Something happens. The operating
system catches that event, figures out which bit of your
code needs to handle it, and runs that.
Speaker 1 (01:29):
Code, and that code changes something always.
Speaker 2 (01:32):
It leads to a change in state, maybe updating what's
on the screen, maybe changing the stored data. This constant
loop weight respond update. That's the pulse of an iOS app.
Speaker 1 (01:44):
Got it, and the place we orchestrate all this code
UI configuration, that's xcode. Can you walk us through the
essential parts of that environment. It can look a bit
intimidating at first.
Speaker 2 (01:55):
Sure xcode is your main hub, your ide. Think of
it in like four main zones you'll use constantly. On
the left, the navigation pain. That's for finding things, your files,
your classes, images.
Speaker 1 (02:04):
All that, your project structure exactly.
Speaker 2 (02:07):
Then the big area in the middle that's the editor
pain where you actually write the code. Sense Down at
the bottom, you've got the debug pain super important. That's
where you see print messages, check variable values. When the
app is running, find.
Speaker 1 (02:19):
Crashes, your troubleshooting area yep.
Speaker 2 (02:21):
And then on the right the inspector pain. This one's
context sensitive. If you're looking at code, it might show documentation.
If you're designing UI, it shows all the settings and
attributes for buttons, labels, whatever.
Speaker 1 (02:33):
So navigator, editor, debug, inspector get comfortable with those four.
Speaker 2 (02:37):
That's pretty much your core workflow.
Speaker 1 (02:39):
Yeah, okay, one quick but crucial thing before we dive
into Swift itself. The bundle identifier. What is that exactly?
Speaker 2 (02:46):
Ah? Yeah, the bundle ID. It's basically the app's unique
social security number. You could say, okay, it has to
be globally unique. It's how the app store and the
device itself identifies your specific app from all the millions
of others.
Speaker 1 (03:00):
Like a web address for an app.
Speaker 2 (03:02):
That's a great analogy, and it usually follows that reverse
domain name style like calm dot your company dot your
rap name. Super important to get right right.
Speaker 1 (03:10):
Okay, Now into Swift itself. This is where as you said,
the philosophy really shows this focus on safety and clarity,
sometimes even prioritized over maybe raw speed in some micro benchmark.
How does that show up right away? Just in declaring
basic values.
Speaker 2 (03:27):
It shows up immediately with let versus var immutability, constants
and variables right VARs for variables values that can change later.
Let is for constant values you set once and they
never change after that.
Speaker 1 (03:39):
And the swift way is the swift way.
Speaker 2 (03:41):
The strong recommendation is always use let unless you absolutely
know you need to change the value later, default to immutability.
Speaker 1 (03:48):
Why is such a strong push for let, I mean,
besides just preventing accidental changes, are there technical benefits?
Speaker 2 (03:54):
Oh? Definitely. Predictability is huge obviously, but also performance. When
the Swift compiler sees let, it knows that piece of
memory is fixed.
Speaker 1 (04:02):
Ah, so it can optimize.
Speaker 2 (04:04):
Exactly, It can store it more efficiently, maybe inline, It
skip checks it might need for a variable. And for
other developers reading your code, let me as a clear
signal this value is stable. Don't worry about it changing unexpectedly.
It's safer coding.
Speaker 1 (04:18):
Fundamentally, That safety focus carries right over to types, doesn't it.
Swift is called statically strongly typed. Sounds kind of strict.
What does that actually mean when you're coding?
Speaker 2 (04:29):
It means two key things. Statically typed means the compiler
must know the exact type of every variable and constant.
Is it an integer, a string, a custom object for
the app even runs at compile time?
Speaker 1 (04:40):
Okay, checks happen early, right.
Speaker 2 (04:42):
And strongly typed means you can't play fast and loose
with those types. If you declare something as a string,
you can't suddenly decide to put a number and int
into it.
Speaker 1 (04:51):
Later The compiler will just say nope.
Speaker 2 (04:53):
Exactly compile time error. Swift wants to catch those kinds
of mistakes before they can cause crashes when a user
is running the app. But hang on, if it's static,
why don't I always have to write like let name
string alice. Sometimes I can just write let name alice
and it works. How does it know?
Speaker 1 (05:10):
Ah? That's the magic of type inference. Swift is clever
enough in many cases to look at the value you're
assigning initially and infer or deduce.
Speaker 2 (05:19):
The type It guess is the type.
Speaker 1 (05:21):
It makes an educated guess based on the value. If
you write alice, it knows that's a string. If you
write ten, it knows that's an int. You get the conciseness,
But the key thing is the type is still figured
out and locked in at compile time, it's still static
and strong.
Speaker 2 (05:35):
Okay, that makes sense. So Swift is strict about types.
That brings up a huge historical problem in programming. What
about missing values, null pointers, undefined the billion dollar mistake? Right?
How does Swift handle needing to represent nothing?
Speaker 1 (05:52):
This is one of Swift's absolute killer features. Optionals indicated
by that question mark after.
Speaker 2 (05:57):
A type like string or int exactly.
Speaker 1 (06:00):
And optional is like a little box. It might contain
a value of the specified type, like a string, or
it might contain nil, which is Swift's way of saying
no value here. And the crucial difference.
Speaker 2 (06:10):
Is the crucial difference is that the type system knows
about the possibility of nil. A regular string cannot be nil.
A string can be nil. It forces you, the developer,
to explicitly deal with the possibility that the value might
be missing.
Speaker 1 (06:26):
You can't just use it directly assuming it's there.
Speaker 2 (06:28):
Nope, you have to unwrap it, check if the box
has something inside before you try to use it. Now
you can force unwrap with an exclamation mark.
Speaker 1 (06:35):
Which everyone says is dangerous.
Speaker 2 (06:37):
It is. It's like saying, I swear this isn't nil.
Trust me if you're wrong, your app crashes instantly, So yeah,
avoid it unless you are absolutely positively certain.
Speaker 1 (06:47):
So what are the safe ways to unwrap?
Speaker 2 (06:49):
The main safe ways are if let and guardlet Okay,
difference with if let you basically say, if this optional
contains a value, let's assign it to a temporary constant
and then run this block of code. That unwrapped constant
is only usable inside the fin if blocks curly braces.
Speaker 1 (07:05):
So it's very contained, like a little safe zone exactly.
Speaker 2 (07:08):
Now. Guard let is often preferred, especially inside functions. It
works kind of like a bouncer at a club. You
use guardlet to check preconditions. At the start of a function,
guard that we have a value here. If we don't.
If it's nil, then we must exit immediately. The else
block of a guard statement has to exit the current scope,
(07:29):
usually with return or.
Speaker 1 (07:30):
Throw, So it's for checking requirements early on.
Speaker 2 (07:32):
Precisely, and the big advantages. If the guardlet check passes,
meaning the optional did have a value, the unwrapped constant
is available for use throughout the entire rest of the function,
not just in a nested.
Speaker 1 (07:45):
Block that avoids nesting. If it's deeper and deeper, the
pyramid of doom. Exactly guard let keeps your code flatter,
clear and enforces that fail fast mentality. If inputs aren't valid,
it's generally considered cleaner for handling requires options.
Speaker 2 (08:00):
That's a really clear explanation. It forces you to be
honest about missing data. Okay, Moving up a level from
individual values, how do we organize code into bigger chunks.
We have struct and class. Big difference there, right, value
versus reference types.
Speaker 1 (08:14):
Huge difference, probably one of the most fundamental distinctions in Swift.
Let's start with structures. Struct Yeah, there are value types.
Speaker 2 (08:20):
Meaning when you pass a struct around, assign it to
a new variable, pass it into a function, you are
always working with a copy of the data. Think of
it like making a photocopy.
Speaker 1 (08:30):
Changing the copy doesn't affect the original.
Speaker 2 (08:32):
Not at all. They are completely independent. Plus, structs get
a handy default initializer called the member wise initializer for free,
which is nice.
Speaker 1 (08:41):
Okay, So structs are copies. What about classes? Class?
Speaker 2 (08:45):
Classes are reference types. Think of this like sharing a
link to a Google doc instead of emailing a word file.
If you have a variable holding a class instance and
you assign that to another variable, both variables now point
to the exact same object in.
Speaker 1 (09:00):
Memory, so if one variable changes.
Speaker 2 (09:02):
Something, the other one sees the change immediately because they're
both looking at the same underlying instance. Classes also support inheritance,
which structs don't. But this shared nature brings complexity, especially
with memory management, which we'll get to right.
Speaker 1 (09:17):
I often hear the advice prefers structs over classes that
generally sound.
Speaker 2 (09:23):
It's a very common and generally good rule of thumb
in swift development. Because value types strucks are copied, they
are inherently simpler and safer. You don't have to worry
about side effects some other part of your code unexpectedly
changing the data out from under You use structs unless
you specifically need. The shared reference behavior of classes or
inheritance makes sense.
Speaker 1 (09:43):
Safety first again. Okay, let's shift to the visual side
the UI building interfaces for iPhones iPads, the screen sizes
are all over the place. You can't just say put
this button a pixel X pixel y right. That old
frame based layout seems impossible.
Speaker 2 (10:00):
Now autoly impossible. It would break immediately on a different
device size or orientation. Apple solution is.
Speaker 1 (10:05):
Auto layout, which uses constraints exactly.
Speaker 2 (10:08):
Instead of giving fixed coordinates, you define rules relationships constraints
between UI elements, like.
Speaker 1 (10:14):
This label should be eight points below that image.
Speaker 2 (10:16):
View precisely, or this button should be centered horizontally in
its container, or these two text fields should have the
same width. You define the layout using these relationships, so.
Speaker 1 (10:25):
You tell the system the rules, not the exact positions.
Speaker 2 (10:28):
You got it, and then when the screen size changes
or the device rotates, the auto layout engine recalculates all
the frames based on the constraints you provided. It makes
adaptive layout possible. UIs that adapt gracefully to different environments.
Speaker 1 (10:42):
And that ties into size classes, right that compact regular widthing.
Speaker 2 (10:46):
Yeah. Size classes are a higher level abstraction Apple provides.
They group different device sizes and orientations into categories like
compact with regular height. You can then use these size
classes to provide different sets of constraints or even different
y or arrangements for say an iPhone in portrait versus
an iPad and landscape. It adds another layer to adaptivity.
Speaker 1 (11:06):
Okay, this feel like we're building up the layers. We
have safe data types, ways to structure code ADAPTI VII.
But underlying all this, especially with classes, is memory. Things
get created, They take up space. How do they get
cleaned up? What's the mechanism.
Speaker 2 (11:20):
The mechanism is automatic reference Counting or ARC.
Speaker 1 (11:24):
ARC, not garbage collection like in Java.
Speaker 2 (11:26):
No, it's different. ARC isn't a separate process that periodically
scans memory. It's more of a compile time feature where
swift automatically inserts memory management code, retain and release calls
into your compiled program.
Speaker 1 (11:40):
And it only cares about certain types.
Speaker 2 (11:42):
Crucially, yes, ARC only manages memory for instances of classes
reference types. It doesn't need to worry about structs or
enoms value types because they are copied and their memory
is handled automatically when they go out of scope. It's
only the shared referenced class in instances that need explicit counting.
Speaker 1 (12:02):
Okay, so how does this counting work? How does ARC
know when it's safe to get rid of a class instance.
Speaker 2 (12:07):
It keeps a reference count for each class instance. When
you create an instance and assign it to a variable
or constant, that creates a strong reference.
Speaker 1 (12:14):
By default strong reference, and.
Speaker 2 (12:16):
That increments the instance's reference count, usually from zero to one.
If you assign that same instance to another variable, the
count goes up again to two.
Speaker 1 (12:24):
So it counts how many variables are actively pointing to it.
Speaker 2 (12:27):
Basically, yes, how many owners it has? You could say,
as long as that reference count is greater than zero.
ARC knows the instance is still needed, so it keeps
it in memory.
Speaker 1 (12:36):
And when does it get deallocated?
Speaker 2 (12:37):
When the last strong reference to it is removed? Maybe
a variable goes out of scope, or you explicitly set
it to nil, the reference count drops when it hits zero,
ARC knows nothing is using the instance anymore and immediately
deallocates it, freeing up the memory.
Speaker 1 (12:53):
Okay, seems straightforward enough, But there's a catch, right the
infamous strong retained cycle.
Speaker 2 (12:59):
Ah yeah, yes, the classic memory leak scenario. In reference
counted systems. This happens when two or more class instances
hold strong references to.
Speaker 1 (13:09):
Each other, like a circular dependency.
Speaker 2 (13:11):
Exactly. Imagine a person class that has a property for
their apartment and the apartment class has a property for
its tenant, the person. If both those properties are default strong.
Speaker 1 (13:21):
References, they're holding on to each other.
Speaker 2 (13:23):
Precisely, the person keeps the apartment alive reference count one,
and the apartment keeps the person alive reference count one,
even if nothing else in your app points to either
the person or the apartment anymore. Their mutual strong references
keep their counts from ever reaching.
Speaker 1 (13:38):
Zero, so they just stay in memory forever leaking.
Speaker 2 (13:41):
Yep, memory leak. ARC can't clean them up because their
counts never drop to zero.
Speaker 1 (13:46):
Okay, so how do we break these cycles? We need
a reference that doesn't increase the count, right.
Speaker 2 (13:51):
We need to tell AARC, hey, this link exists, but
don't count it towards keeping the object alive and swift
gives us two ways to do this and unowned references
week and unowned.
Speaker 1 (14:03):
What's the difference when do you use which?
Speaker 2 (14:05):
The choice depends entirely on whether the reference could legitimately
become nil during its lifetime. You use weak, usually written
weekvar when the other instance might be deallocated before the
instance holding their reference.
Speaker 1 (14:17):
So the reference itself needs to be able to become nil.
Speaker 2 (14:19):
Exactly because the thing it points to might disappear. This
means weak references must always be declared as optional types
like weak var delegate my delegate. The class example is
a delegate pattern. A child object shouldn't keep its parent
controller alive, so the reference back to the delegate is
often weak.
Speaker 1 (14:40):
Okay, Week means it can be nil, so it must
be optional. What about unowned?
Speaker 2 (14:46):
You use unowned when you can guarantee, absolutely guarantee that
the reference will never be nil during the time you're
using it. The other instance will definitely outlive or live
exactly as long as the instance holding the reference.
Speaker 1 (14:58):
But you're making a promise to the compiler.
Speaker 2 (15:00):
You are because unowned references are assumed to always point
to something valid, they are not optionals. Think of our
person apartment example. Maybe an apartment must always have a
tenant while it exists in our system, the apartment's reference
back to the person could potentially be unowned.
Speaker 1 (15:14):
What happens if you're wrong If you use unowned and
the other instance does get deallocated crash.
Speaker 2 (15:20):
If you try to access an unowned reference after the
instance it ports too has been deallocated, your app will crash.
So you use unowned for that slight performance gain. No
optional unwrapping only when the relationship guarantees non n illness.
Weak is generally safer. If there's any.
Speaker 1 (15:35):
Doubt, well, okay, that's a deep dive into memory. So
summarizing the pillars, we've got language levels, safety with let
var and strong typing crash prevention with optionals and safe
unwrapping like guardlet structure with value types, struct and reference types,
class adaptive UI with auto layout and constraints, and finally
managing class memory carefully with ARC using weak or unowned
(15:58):
to prevent retained cycles.
Speaker 2 (16:00):
That really covers the foundational philosophy. Getting these concepts, especially
optionals in ARC, is what separates developers who write robust,
stable apps from those whose apps might be prone to
crashes or unexpected behavior.
Speaker 1 (16:12):
So, with this foundation laid, where does this lead us?
For years, iOS development mostly used imperative programming for UI,
right like with UIKit and patterns like MVC. We were
telling the system how to change the view step by
step exactly.
Speaker 2 (16:25):
You'd get some data, and then you'd write code to
find the label on the screen and manually update its
text property, find the image view and set its image,
and so on, very step by step instructions.
Speaker 1 (16:36):
But the wind is shifting, isn't it towards something more declarative?
Speaker 2 (16:40):
Massively shifting the new standard Swift UI flicks the model completely.
It uses declarative programming, meaning instead of telling the system
how to update the UI piece by piece, you simply
declare what the UI should look like for any given
state of your data.
Speaker 1 (16:55):
So you define the end result for each state precisely.
Speaker 2 (16:59):
You say, the data looks like this, the screen should
look like that, and you do this for all possible states.
Swift UI then figures out the most efficient way to
transition between those states automatically when the data changes. You
don't manage the individual updates anymore.
Speaker 1 (17:13):
That sounds like a fundamental paradigm shift less manual control.
More describing the outcome.
Speaker 2 (17:19):
It absolutely is. And understanding the imperative world of UIKit
and the principles we discussed today, especially type safety, value types,
and immutability, actually provides the perfect grounding to appreciate why
the declarative approach of swift UI is so powerful and efficient.
It builds directly on those core swift philosophies.
Speaker 1 (17:39):
So a provocative thought for listeners. Yeah, master these fundamentals
the imperative way things were done, because it prepares you
perfectly for the declarative way things are going. Explore youikit,
understand arc and then get ready for swift UI.
Speaker 2 (17:52):
Couldn't have sent it better myself. That's the journey.
Speaker 1 (17:54):
Excellent. A lot to digest there, but absolutely crucial knowledge
that wraps up this deep dive
Welcome back to the deep dive. Today, we're really jumping in,
launching straight into the well, the bedrock of the Apple ecosystem.
Our goal isn't just to skim the surface. We want
to pull out those foundational pillars, the architecture, the tools,
and really the philosophy behind Swift.
Speaker 2 (00:18):
Yeah, the core ideas exactly the.
Speaker 1 (00:19):
Stuff any aspiring iOS dev needs to get. This is
about understanding the why behind the code.
Speaker 2 (00:26):
You write, right, And I think for anyone starting out,
the key takeaway is that Swift isn't just another language
thrown out there. It was built very deliberately with specific goals.
Specific goals safety, clarity, and performance that shapes everything, how
you declare variable, how memory works, all of it.
Speaker 1 (00:44):
Okay, so let's unpack that starting big picture. Yeah, an
iOS app. Yeah, it's like its own little world, right,
what's at its core?
Speaker 2 (00:50):
Fundamentally, you can think of any app as having let's
say three main parts the screen what the user interacts with, Okay,
the code, the logic, the instructions, and the data the
information it holds onto screen code data simple enough, and
the whole thing operates in what we call an event
driven paradigm.
Speaker 1 (01:08):
Right, Event driven. That's important. It's not just running top
to bottom like a script, not at all.
Speaker 2 (01:13):
The phone or iPad is basically just sitting there waiting,
waiting for an event like a button tap, a button tap,
a notification, maybe a timer firing. Something happens. The operating
system catches that event, figures out which bit of your
code needs to handle it, and runs that.
Speaker 1 (01:29):
Code, and that code changes something always.
Speaker 2 (01:32):
It leads to a change in state, maybe updating what's
on the screen, maybe changing the stored data. This constant
loop weight respond update. That's the pulse of an iOS app.
Speaker 1 (01:44):
Got it, and the place we orchestrate all this code
UI configuration, that's xcode. Can you walk us through the
essential parts of that environment. It can look a bit
intimidating at first.
Speaker 2 (01:55):
Sure xcode is your main hub, your ide. Think of
it in like four main zones you'll use constantly. On
the left, the navigation pain. That's for finding things, your files,
your classes, images.
Speaker 1 (02:04):
All that, your project structure exactly.
Speaker 2 (02:07):
Then the big area in the middle that's the editor
pain where you actually write the code. Sense Down at
the bottom, you've got the debug pain super important. That's
where you see print messages, check variable values. When the
app is running, find.
Speaker 1 (02:19):
Crashes, your troubleshooting area yep.
Speaker 2 (02:21):
And then on the right the inspector pain. This one's
context sensitive. If you're looking at code, it might show documentation.
If you're designing UI, it shows all the settings and
attributes for buttons, labels, whatever.
Speaker 1 (02:33):
So navigator, editor, debug, inspector get comfortable with those four.
Speaker 2 (02:37):
That's pretty much your core workflow.
Speaker 1 (02:39):
Yeah, okay, one quick but crucial thing before we dive
into Swift itself. The bundle identifier. What is that exactly?
Speaker 2 (02:46):
Ah? Yeah, the bundle ID. It's basically the app's unique
social security number. You could say, okay, it has to
be globally unique. It's how the app store and the
device itself identifies your specific app from all the millions
of others.
Speaker 1 (03:00):
Like a web address for an app.
Speaker 2 (03:02):
That's a great analogy, and it usually follows that reverse
domain name style like calm dot your company dot your
rap name. Super important to get right right.
Speaker 1 (03:10):
Okay, Now into Swift itself. This is where as you said,
the philosophy really shows this focus on safety and clarity,
sometimes even prioritized over maybe raw speed in some micro benchmark.
How does that show up right away? Just in declaring
basic values.
Speaker 2 (03:27):
It shows up immediately with let versus var immutability, constants
and variables right VARs for variables values that can change later.
Let is for constant values you set once and they
never change after that.
Speaker 1 (03:39):
And the swift way is the swift way.
Speaker 2 (03:41):
The strong recommendation is always use let unless you absolutely
know you need to change the value later, default to immutability.
Speaker 1 (03:48):
Why is such a strong push for let, I mean,
besides just preventing accidental changes, are there technical benefits?
Speaker 2 (03:54):
Oh? Definitely. Predictability is huge obviously, but also performance. When
the Swift compiler sees let, it knows that piece of
memory is fixed.
Speaker 1 (04:02):
Ah, so it can optimize.
Speaker 2 (04:04):
Exactly, It can store it more efficiently, maybe inline, It
skip checks it might need for a variable. And for
other developers reading your code, let me as a clear
signal this value is stable. Don't worry about it changing unexpectedly.
It's safer coding.
Speaker 1 (04:18):
Fundamentally, That safety focus carries right over to types, doesn't it.
Swift is called statically strongly typed. Sounds kind of strict.
What does that actually mean when you're coding?
Speaker 2 (04:29):
It means two key things. Statically typed means the compiler
must know the exact type of every variable and constant.
Is it an integer, a string, a custom object for
the app even runs at compile time?
Speaker 1 (04:40):
Okay, checks happen early, right.
Speaker 2 (04:42):
And strongly typed means you can't play fast and loose
with those types. If you declare something as a string,
you can't suddenly decide to put a number and int
into it.
Speaker 1 (04:51):
Later The compiler will just say nope.
Speaker 2 (04:53):
Exactly compile time error. Swift wants to catch those kinds
of mistakes before they can cause crashes when a user
is running the app. But hang on, if it's static,
why don't I always have to write like let name
string alice. Sometimes I can just write let name alice
and it works. How does it know?
Speaker 1 (05:10):
Ah? That's the magic of type inference. Swift is clever
enough in many cases to look at the value you're
assigning initially and infer or deduce.
Speaker 2 (05:19):
The type It guess is the type.
Speaker 1 (05:21):
It makes an educated guess based on the value. If
you write alice, it knows that's a string. If you
write ten, it knows that's an int. You get the conciseness,
But the key thing is the type is still figured
out and locked in at compile time, it's still static
and strong.
Speaker 2 (05:35):
Okay, that makes sense. So Swift is strict about types.
That brings up a huge historical problem in programming. What
about missing values, null pointers, undefined the billion dollar mistake? Right?
How does Swift handle needing to represent nothing?
Speaker 1 (05:52):
This is one of Swift's absolute killer features. Optionals indicated
by that question mark after.
Speaker 2 (05:57):
A type like string or int exactly.
Speaker 1 (06:00):
And optional is like a little box. It might contain
a value of the specified type, like a string, or
it might contain nil, which is Swift's way of saying
no value here. And the crucial difference.
Speaker 2 (06:10):
Is the crucial difference is that the type system knows
about the possibility of nil. A regular string cannot be nil.
A string can be nil. It forces you, the developer,
to explicitly deal with the possibility that the value might
be missing.
Speaker 1 (06:26):
You can't just use it directly assuming it's there.
Speaker 2 (06:28):
Nope, you have to unwrap it, check if the box
has something inside before you try to use it. Now
you can force unwrap with an exclamation mark.
Speaker 1 (06:35):
Which everyone says is dangerous.
Speaker 2 (06:37):
It is. It's like saying, I swear this isn't nil.
Trust me if you're wrong, your app crashes instantly, So yeah,
avoid it unless you are absolutely positively certain.
Speaker 1 (06:47):
So what are the safe ways to unwrap?
Speaker 2 (06:49):
The main safe ways are if let and guardlet Okay,
difference with if let you basically say, if this optional
contains a value, let's assign it to a temporary constant
and then run this block of code. That unwrapped constant
is only usable inside the fin if blocks curly braces.
Speaker 1 (07:05):
So it's very contained, like a little safe zone exactly.
Speaker 2 (07:08):
Now. Guard let is often preferred, especially inside functions. It
works kind of like a bouncer at a club. You
use guardlet to check preconditions. At the start of a function,
guard that we have a value here. If we don't.
If it's nil, then we must exit immediately. The else
block of a guard statement has to exit the current scope,
(07:29):
usually with return or.
Speaker 1 (07:30):
Throw, So it's for checking requirements early on.
Speaker 2 (07:32):
Precisely, and the big advantages. If the guardlet check passes,
meaning the optional did have a value, the unwrapped constant
is available for use throughout the entire rest of the function,
not just in a nested.
Speaker 1 (07:45):
Block that avoids nesting. If it's deeper and deeper, the
pyramid of doom. Exactly guard let keeps your code flatter,
clear and enforces that fail fast mentality. If inputs aren't valid,
it's generally considered cleaner for handling requires options.
Speaker 2 (08:00):
That's a really clear explanation. It forces you to be
honest about missing data. Okay, Moving up a level from
individual values, how do we organize code into bigger chunks.
We have struct and class. Big difference there, right, value
versus reference types.
Speaker 1 (08:14):
Huge difference, probably one of the most fundamental distinctions in Swift.
Let's start with structures. Struct Yeah, there are value types.
Speaker 2 (08:20):
Meaning when you pass a struct around, assign it to
a new variable, pass it into a function, you are
always working with a copy of the data. Think of
it like making a photocopy.
Speaker 1 (08:30):
Changing the copy doesn't affect the original.
Speaker 2 (08:32):
Not at all. They are completely independent. Plus, structs get
a handy default initializer called the member wise initializer for free,
which is nice.
Speaker 1 (08:41):
Okay, So structs are copies. What about classes? Class?
Speaker 2 (08:45):
Classes are reference types. Think of this like sharing a
link to a Google doc instead of emailing a word file.
If you have a variable holding a class instance and
you assign that to another variable, both variables now point
to the exact same object in.
Speaker 1 (09:00):
Memory, so if one variable changes.
Speaker 2 (09:02):
Something, the other one sees the change immediately because they're
both looking at the same underlying instance. Classes also support inheritance,
which structs don't. But this shared nature brings complexity, especially
with memory management, which we'll get to right.
Speaker 1 (09:17):
I often hear the advice prefers structs over classes that
generally sound.
Speaker 2 (09:23):
It's a very common and generally good rule of thumb
in swift development. Because value types strucks are copied, they
are inherently simpler and safer. You don't have to worry
about side effects some other part of your code unexpectedly
changing the data out from under You use structs unless
you specifically need. The shared reference behavior of classes or
inheritance makes sense.
Speaker 1 (09:43):
Safety first again. Okay, let's shift to the visual side
the UI building interfaces for iPhones iPads, the screen sizes
are all over the place. You can't just say put
this button a pixel X pixel y right. That old
frame based layout seems impossible.
Speaker 2 (10:00):
Now autoly impossible. It would break immediately on a different
device size or orientation. Apple solution is.
Speaker 1 (10:05):
Auto layout, which uses constraints exactly.
Speaker 2 (10:08):
Instead of giving fixed coordinates, you define rules relationships constraints
between UI elements, like.
Speaker 1 (10:14):
This label should be eight points below that image.
Speaker 2 (10:16):
View precisely, or this button should be centered horizontally in
its container, or these two text fields should have the
same width. You define the layout using these relationships, so.
Speaker 1 (10:25):
You tell the system the rules, not the exact positions.
Speaker 2 (10:28):
You got it, and then when the screen size changes
or the device rotates, the auto layout engine recalculates all
the frames based on the constraints you provided. It makes
adaptive layout possible. UIs that adapt gracefully to different environments.
Speaker 1 (10:42):
And that ties into size classes, right that compact regular widthing.
Speaker 2 (10:46):
Yeah. Size classes are a higher level abstraction Apple provides.
They group different device sizes and orientations into categories like
compact with regular height. You can then use these size
classes to provide different sets of constraints or even different
y or arrangements for say an iPhone in portrait versus
an iPad and landscape. It adds another layer to adaptivity.
Speaker 1 (11:06):
Okay, this feel like we're building up the layers. We
have safe data types, ways to structure code ADAPTI VII.
But underlying all this, especially with classes, is memory. Things
get created, They take up space. How do they get
cleaned up? What's the mechanism.
Speaker 2 (11:20):
The mechanism is automatic reference Counting or ARC.
Speaker 1 (11:24):
ARC, not garbage collection like in Java.
Speaker 2 (11:26):
No, it's different. ARC isn't a separate process that periodically
scans memory. It's more of a compile time feature where
swift automatically inserts memory management code, retain and release calls
into your compiled program.
Speaker 1 (11:40):
And it only cares about certain types.
Speaker 2 (11:42):
Crucially, yes, ARC only manages memory for instances of classes
reference types. It doesn't need to worry about structs or
enoms value types because they are copied and their memory
is handled automatically when they go out of scope. It's
only the shared referenced class in instances that need explicit counting.
Speaker 1 (12:02):
Okay, so how does this counting work? How does ARC
know when it's safe to get rid of a class instance.
Speaker 2 (12:07):
It keeps a reference count for each class instance. When
you create an instance and assign it to a variable
or constant, that creates a strong reference.
Speaker 1 (12:14):
By default strong reference, and.
Speaker 2 (12:16):
That increments the instance's reference count, usually from zero to one.
If you assign that same instance to another variable, the
count goes up again to two.
Speaker 1 (12:24):
So it counts how many variables are actively pointing to it.
Speaker 2 (12:27):
Basically, yes, how many owners it has? You could say,
as long as that reference count is greater than zero.
ARC knows the instance is still needed, so it keeps
it in memory.
Speaker 1 (12:36):
And when does it get deallocated?
Speaker 2 (12:37):
When the last strong reference to it is removed? Maybe
a variable goes out of scope, or you explicitly set
it to nil, the reference count drops when it hits zero,
ARC knows nothing is using the instance anymore and immediately
deallocates it, freeing up the memory.
Speaker 1 (12:53):
Okay, seems straightforward enough, But there's a catch, right the
infamous strong retained cycle.
Speaker 2 (12:59):
Ah yeah, yes, the classic memory leak scenario. In reference
counted systems. This happens when two or more class instances
hold strong references to.
Speaker 1 (13:09):
Each other, like a circular dependency.
Speaker 2 (13:11):
Exactly. Imagine a person class that has a property for
their apartment and the apartment class has a property for
its tenant, the person. If both those properties are default strong.
Speaker 1 (13:21):
References, they're holding on to each other.
Speaker 2 (13:23):
Precisely, the person keeps the apartment alive reference count one,
and the apartment keeps the person alive reference count one,
even if nothing else in your app points to either
the person or the apartment anymore. Their mutual strong references
keep their counts from ever reaching.
Speaker 1 (13:38):
Zero, so they just stay in memory forever leaking.
Speaker 2 (13:41):
Yep, memory leak. ARC can't clean them up because their
counts never drop to zero.
Speaker 1 (13:46):
Okay, so how do we break these cycles? We need
a reference that doesn't increase the count, right.
Speaker 2 (13:51):
We need to tell AARC, hey, this link exists, but
don't count it towards keeping the object alive and swift
gives us two ways to do this and unowned references
week and unowned.
Speaker 1 (14:03):
What's the difference when do you use which?
Speaker 2 (14:05):
The choice depends entirely on whether the reference could legitimately
become nil during its lifetime. You use weak, usually written
weekvar when the other instance might be deallocated before the
instance holding their reference.
Speaker 1 (14:17):
So the reference itself needs to be able to become nil.
Speaker 2 (14:19):
Exactly because the thing it points to might disappear. This
means weak references must always be declared as optional types
like weak var delegate my delegate. The class example is
a delegate pattern. A child object shouldn't keep its parent
controller alive, so the reference back to the delegate is
often weak.
Speaker 1 (14:40):
Okay, Week means it can be nil, so it must
be optional. What about unowned?
Speaker 2 (14:46):
You use unowned when you can guarantee, absolutely guarantee that
the reference will never be nil during the time you're
using it. The other instance will definitely outlive or live
exactly as long as the instance holding the reference.
Speaker 1 (14:58):
But you're making a promise to the compiler.
Speaker 2 (15:00):
You are because unowned references are assumed to always point
to something valid, they are not optionals. Think of our
person apartment example. Maybe an apartment must always have a
tenant while it exists in our system, the apartment's reference
back to the person could potentially be unowned.
Speaker 1 (15:14):
What happens if you're wrong If you use unowned and
the other instance does get deallocated crash.
Speaker 2 (15:20):
If you try to access an unowned reference after the
instance it ports too has been deallocated, your app will crash.
So you use unowned for that slight performance gain. No
optional unwrapping only when the relationship guarantees non n illness.
Weak is generally safer. If there's any.
Speaker 1 (15:35):
Doubt, well, okay, that's a deep dive into memory. So
summarizing the pillars, we've got language levels, safety with let
var and strong typing crash prevention with optionals and safe
unwrapping like guardlet structure with value types, struct and reference types,
class adaptive UI with auto layout and constraints, and finally
managing class memory carefully with ARC using weak or unowned
(15:58):
to prevent retained cycles.
Speaker 2 (16:00):
That really covers the foundational philosophy. Getting these concepts, especially
optionals in ARC, is what separates developers who write robust,
stable apps from those whose apps might be prone to
crashes or unexpected behavior.
Speaker 1 (16:12):
So, with this foundation laid, where does this lead us?
For years, iOS development mostly used imperative programming for UI,
right like with UIKit and patterns like MVC. We were
telling the system how to change the view step by
step exactly.
Speaker 2 (16:25):
You'd get some data, and then you'd write code to
find the label on the screen and manually update its
text property, find the image view and set its image,
and so on, very step by step instructions.
Speaker 1 (16:36):
But the wind is shifting, isn't it towards something more declarative?
Speaker 2 (16:40):
Massively shifting the new standard Swift UI flicks the model completely.
It uses declarative programming, meaning instead of telling the system
how to update the UI piece by piece, you simply
declare what the UI should look like for any given
state of your data.
Speaker 1 (16:55):
So you define the end result for each state precisely.
Speaker 2 (16:59):
You say, the data looks like this, the screen should
look like that, and you do this for all possible states.
Swift UI then figures out the most efficient way to
transition between those states automatically when the data changes. You
don't manage the individual updates anymore.
Speaker 1 (17:13):
That sounds like a fundamental paradigm shift less manual control.
More describing the outcome.
Speaker 2 (17:19):
It absolutely is. And understanding the imperative world of UIKit
and the principles we discussed today, especially type safety, value types,
and immutability, actually provides the perfect grounding to appreciate why
the declarative approach of swift UI is so powerful and efficient.
It builds directly on those core swift philosophies.
Speaker 1 (17:39):
So a provocative thought for listeners. Yeah, master these fundamentals
the imperative way things were done, because it prepares you
perfectly for the declarative way things are going. Explore youikit,
understand arc and then get ready for swift UI.
Speaker 2 (17:52):
Couldn't have sent it better myself. That's the journey.
Speaker 1 (17:54):
Excellent. A lot to digest there, but absolutely crucial knowledge
that wraps up this deep dive
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
My Favorite Murder with Karen Kilgariff and Georgia Hardstark
My Favorite Murder is a true crime comedy podcast hosted by Karen Kilgariff and Georgia Hardstark. Each week, Karen and Georgia share compelling true crimes and hometown stories from friends and listeners. Since MFM launched in January of 2016, Karen and Georgia have shared their lifelong interest in true crime and have covered stories of infamous serial killers like the Night Stalker, mysterious cold cases, captivating cults, incredible survivor stories and important events from history like the Tulsa race massacre of 1921. My Favorite Murder is part of the Exactly Right podcast network that provides a platform for bold, creative voices to bring to life provocative, entertaining and relatable stories for audiences everywhere. The Exactly Right roster of podcasts covers a variety of topics including historic true crime, comedic interviews and news, science, pop culture and more. Podcasts on the network include Buried Bones with Kate Winkler Dawson and Paul Holes, That's Messed Up: An SVU Podcast, This Podcast Will Kill You, Bananas and more.