MacOS and iOS Internals, Volume I: User Mode

Ever wonder what's really going on inside your iPhone or Mac. Today, we're going deep, really deep into Apple's operating systems, and our guide for this little adventure is Jonathan Levin's OS Internals Volume one. Right, this book, it's pretty dense, it is, Yeah, but don't worry. We're here to break it down. Whether you're like a hardcore tech enthusiast or just curious about what makes your Apple devices tick. We're going to unpack it all for you.

Absolutely. Yeah. We're going beyond that sleek interface and that user friendly design, right, We're going to the core, the backbone of it all, okay, which is called Darwin.

Darwin is that like some kind of secret code name for Apple's OS?

Not really, no, okay. Darwin is the open source, UNIX based foundation of Apple's operating systems. Ah. Okay, so think of it as the engine under the hood.

Okay. So what's so special about Darwin being you and IX based.

Well, for one thing, yeah, it means that your I phone actually shares a lineage oh wow, with powerful server systems, like big server systems. Yes, and it has this very robust, well tested core okay. And Darwin's actually one of the last few UNX certified operating systems, which puts it in the same league as Lennux and Solaris.

Oh so you're saying that, like my phone is running on the same fundamental system as like supercomputer. Kind of Yeah, that's pretty wild.

It is. And this UNANAX heritage that we're talking about, it has some really real world implications. Okay, it makes Apple devices incredibly stable. Think about how rarely, if ever your iPhone crashes. True, and it means it can handle some really demanding tasks, yeah, very smoothly. Plus it makes it a lot easier for developers who are already familiar with UNANX to work with Apple systems.

Makes sense.

So it's not just this cool family tree. It actually affects the performance and the development of your Apple device.

I see. So it's not just about like a cool lineage. It's actually impacting like the performance and development of Apple devices. Yeah that's interesting. Yeah, so but how did Darwin like come to be? What's the story there?

Well, it's a fascinating story okay, that actually involves Steve Jobs and this company called next Ta Okay, and to think about it, imagine a branching tree Okay. The trunk of that tree is Next t Step, got it. This was the operating system okay, developed by Steve Jobs's company Next to You back in the late eighties, right, And when Apple acquired Next Tea in nineteen ninety six, they brought Next T Step along with them. Yeah, and that became the foundation for Darwin.

Oh. So, Garwin is like the seed that blossomed into like the entire Apple os ecosystem that we know today exactly, mac os iOS, wachos, and they all share this common ancestor exactly, and.

Each branch of that tree has evolved these unique characteristics for its very specific device.

That makes me wonder though, if they're all built on the same base, Like how much can developers actually share and reuse across those different Apple devices? Like could I theoretically write an app that would work seamlessly on my iPhone and Mymac.

That's a great question. Yeah, and it kind of gets at the heart of how Apple balances consistency and flexibility across its ecosystem. Okay, but before we get into app development, sure, I think it's important to understand how Apple structures its operating system. Okay, the architecture, so quick, got it.

So let's unpack the architecture then. Sure is it as sleek and minimalist as the design of their devices.

Well, Apple presents a very simple, five layered model. Okay, So you have the application layer, which is what you directly interact with, right. Then there's the Application Frameworks layer, which provides tools and libraries for developers.

Got it.

Below that is the core Services layer, which handles system level tasks. And finally you have the kernel and Device writer's layer, which is what interacts with the hard one.

So everything's really neatly organized, each layer with its specific role.

Very Apple on paper. Yes, it's clean, it's elegant, but the reality, as with most things, is a little bit more complex. Okay, if we look deeper, we're going to find a much more intricate, messier architecture.

MESSI you're telling me there's hidden complexity beneath Apple's famously polished surface. I knew it. It couldn't be that simple.

Like take the runtime environment for example. Okay, it's technically part of the core Services layer, but it actually spans multiple layers, blurring those very clean lines we saw before, and this complexity actually becomes even more apparent when you compare the architectures of mac os and iOS.

Oh interesting.

They share some similarities, of course, but there are these distinct differences as well, Yeah, which were the unique needs and constraints of each platform.

So it's more like a carefully choreographed dance than like a rigid hierarchy.

Apple wants to maintain a consistent user experience, I get it right, but it also needs to provide the power and flexibility that's required for all these different applications and hardware exactly. That's a tough balancing act, it.

Is, and understanding this tension between user friendliness and capability helps us really appreciate how Apple makes these design choices that you, as a user experience every day. But to really grasp the inner workings of the OS, we need to go even deeper to the heart of what's called the kernel environment.

Okay, this is called X and U X and U. What is that is that like the Apple version of a.

Kernel, Well, the kernel is the core of an operating system. It's responsible for managing the system's resources and inner acting directly with the hardware. Xn U is particularly interesting because it's a hybrid kernel that combines elements of a microkernel called MOCK with components from.

BSDON, another UNAX derivative.

Okay, I'm losing you a bit microkernel BSD. What are we talking about here?

Think about it this way. MOCK is this tiny, highly flexible kernel that was originally designed to be incredibly adaptable. Okay, it could even run on top of other kernels.

Wow.

Now, BSc, on the other hand, is known for its robustness, its stability, and its performance.

So they kind of took the best of both worlds exactly. So X and U is like a hybrid car. Yes, it combines like the fuel efficiency of a microkernel with the power and reliability of a more traditional kernel.

That's a really great way to put it. Actually, And this hybrid approach that we're talking about, yeah, it allows out to really achieve that balance between flexibility and performance, got it, which is critical for a modern operating system.

This is all fascinating stuff, but I'm starting to wonder, like, Yeah, why should I, as like a regular user, care about all these technical details about kernels and architectures. What's like the takeaway for me?

Well, understanding how the OS works under the hood can actually enhance your user experience. They Okay, it helps you appreciate why your Apple devices are so responsive, why they rarely crash, and why they can handle a wide range of tasks.

Okay.

It also gives you this deeper understanding of the decisions that Apple makes about app management, security, overall system design.

Interesting. So it's not just about like geeking out over the technical specs. It's about understanding the forces you're shaping our digital experiences. I like that.

And speaking of shaping experiences, let's move on to another crucial aspect of Apple's OS. Ok and that's the file system.

The filesystem. Okay.

Now you might think of this as just storage space, right, but it's actually so much more than that. Okay. It's this carefully structured system that has a very profound impact on how your device functions.

Gotcha, Okay, I'm intrigued. How does apples approach to file systems differ from say, Windows or Android.

One key difference is how Apple partitions it's filesystems. Okay, they separate the system partition from the data partition.

Wait, so there are separate sections for the operating system itself and my personal files? Exactly Why is that important?

Well, the separation is actually quite clever.

Okay.

This is what allows for those very seamless system updates that Apple's known for.

So that's why I can update my iPhone and not have to worry about losing all my photos and messages exactly because the system is getting updated on one partition and my data is safe on the other one.

Exactly.

Thought about it that way. That's actually a really elegant solution.

Yeah, it is. And speaking of elegant solutions, let's talk about Apple's discimages. Those dot DMG files.

Yeah, dot dmg files.

You encounter them all the time when you're downloading software.

I usually just like click through them without really giving them much thought. Yeah, special about them.

What's fascinating about them, Yeah, is that dot dmg files are not merely archives like dot zip files. They are, in essence, mini file.

System mini filesystems. You mean, like a tiny, self contained drive inside.

Of a file. Precisely, you can mount a dot dmg file and explore it just like you would any other drive on your system.

That's pretty cool. But why go through the trouble of creating a custom image format like this? Why not just use like standard archives.

That's a good question. It could be about security, okay, ensuring that the software hasn't been tampered with. It could also be about maintaining that consistent user experience, giving Apple more control over how the software is presented and installed.

So there's more two dot dmg files than meets the eye. It's another example of how Apple's design choices, even like these seemingly small ones, really reflect their overall philosophy of control and user experience.

Absolutely, and this control becomes even more apparent when we look at how Apple manages applications on its platforms yep, from installation to uninstallation. Ah.

App management the gatekeeper of the Apple ecosystem. You could say that it's how they maintain that famous walled garden, right, yeah, you could say that. But before we delve into the walled garden and all its implications, let's trace the evolution of app management on Apple platforms. Okay, remember back in the early days of Macois, when installing an app was as simple as dragging an icon to your applications folder.

Those were the days, simpler times.

It was a simpler time, yeah, it was. But as the Mac platform grew in popularity and the Internet became a more let's say complex and sometimes even like a dangerous place. Sure, the need for increased security became very apparent, and that's where things like code signing and sandboxing come in.

Right.

Okay, time for a quick security lesson. Okay, code signing, as I understand it, is like a digital signature that verifies the identity of the developer, ensures that you know that the software hasn't been campered with. And then sandboxing is basically like putting the application in a little walled garden, right, restricting its access to system resources and your personal data so that prevents malicious or poorly coded apps from causing

Well, while you can still drag and drop applications onto your system, mac Os now actually enforces code signing for applications that are downloaded from outside the MacApp Store. Okay, so if you try to open up an unsigned application, you're going to get a security warning, got it, and the system will just prevent it from running unless you very specifically override those security settings.

That makes sense. Better to be safe than sorry, right, But what about applications that are downloaded from the MacApp Store?

Yeah?

Are they also subject to these security checksutely?

In fact, Apple takes security even further. Oh wow, with those app store applications. Okay, they've got this rigorous vetting process that scrutinizes application for both security and quality. Got it, and all applications distributed through the MacApp Store are sandboxed by default, further limiting their potential impact.

Interesting. So it sounds like Apple has created this multi layered security fortress around macOS applications. But what about uninstallation? Is it still as simple as dragging an app.

To the trash in most cases? Yes? Okay, but it's worth noting that applications can install components in various system locations, not just within their own application.

Bundle, So simply deleting the application might not actually remove all of its associated files and settings, and that could lead to like clutter and wasted disk space.

You got it.

So that's why a lot of developers now provide like uninstaller scripts or utilities to ensure like a clean and complete removal exactly. And of course there's those third party uninstaller applications that can help clean up any like lingering remnants. So even though macOS allows for some flexibility and how you manage applications, it's clear that security is a top priority. But what about iOS? How does app management differ on Apple's mobile platform?

Well, iOS was designed from the ground up with a much more controlled environment in mind. Oh okay, think about it as that walled garden ah we talked about earlier, carefully curated, Okay, tightly controlled by Apple.

Right, the infamous walled garden. Yeah, so no more drag and drop freedom on iOS then not really? Yeah.

While you can technically sideload apps onto iOS devices using developer tools and enterprise certificates, for the vast majority of users, the app store is the only way to install applications, so Apple.

Has complete control over what apps are allowed on its mobile platform.

Right.

I can see how some people might see that as like a restriction, but it also provides a certain level of safety and consistency.

And this control yeah, actually extends to the uninstallation process too. Oh Okay, Uninstalling an app on iOS is incredibly simple.

Yeah.

You just tap and hold its icon until it wiggles, and then you tap the little X that appears. No need to worry about those residual files or settings. Yeah, iOS handles all that behind the scenes.

It sounds pretty seamless and user friendly, but it also kind of raises some questions about the trade offs between you know, like user freedom and Apple's control over the app ecosystem. What are like the implications of this approach for both developers and users.

That's a really big question, yeah, and one that deserves a deeper dive. On the one hand, this control allows Apple to curate this high quality, secure app ecosystem, which benefits users by minimize their exposure to malware and ensuring that consistent experience. Now, on the other hand, it can limit developer freedoms and sometimes stifle innovation by imposing those strict guidelines and fees. Okay, it's a complex issue with no easy answers.

It sounds like there are valid arguments on both sides. Maybe we can explore those nuances in a future episode that's straight, but for now, I think we need to shift gears and dive back down to the lower levels of the operating system. We talked about Darwin, the Unix Foundation, and xn U hybrid kernel, but I think it's time we really explore the microkernel legacy of MOCK right in a bit more detail. MOCK the tiny kernel that could.

To understand Mock's significance, we need to take a little trip back in time to the mid nineteen eighties. This was a time of just rapid innovation in the world of operating systems. At Carnegie Mellon University, there was a team of researchers led by Richard Rashid, and the embarked on this ambitious project to create a new kind of kernel, a microkernel they called mach. Their goal was to.

Welcome back before we took that little detour into app management, we were about to learn about MOCK and its journey to the heart of xn U. I'm really curious to hear what the researchers at Carnegie Millon were trying to achieve.

Well back then, operating systems they were typically monolithic, meaning that all the core functions were very tightly integrated into a single large kernel, and this made them really difficult to modify and maintain. Oh okay, So the Mock team wanted to break free from this monolithic model by creating a smaller, more streamlined kernel that delegated as much functionality as possible external servers.

Gotcha. So instead of one giant brain doing everything, yeah, you have this network of like a smaller brains, each specializing in a specific task.

Exactly. In this approach, it's known as like a client server model, and it offered several advantages. Okay, like what, Well, First, it enhanced flexibility by decoupling kernel functions into these independent servers, Developers could modify or replace these servers without affecting the stability of the core kernel itself.

So it's like swapping out parts of a machine without having to shut down like the entire operation exactly. Yeah, okay, that makes sense. Yeah, but wouldn't that also create potential security risks? Like if any server can be replayers, couldn't a malicious ones slip in?

That's a valid concern. Yeah, and security is always a consideration of system design. But the Mock team they believed that the benefits of nodularity outweighed the risks, especially you know, if you had proper security measures place. Plus, remember that MOCK at this point was really just a research project, so exploring these trade offs was really a big part of the process.

Okay, so flexibility was one advantage. What were some of the other benefits of this client server model?

Another key benefit was portability. Mock was designed to be adaptable, capable of running on a variety of hardware platforms. This was achieved by isolating that hardware specific code in external servers, which allowed that core MOCK kernel to remain relatively platform agnostic.

So it's like having a universal translator for operating systems. It could speak the language of different hardware platforms without having to rewrite its core code. Yeah, that's pretty impressive for a project from the nineteen eighties.

It really was. Yeah, it was a groundbreaking approach and it laid the foundation for the microkernel based operating system that we see today.

Got it. But how did this innovative kernel make its way into the world of Apple. Well, you mentioned earlier that Apple's X and U kernel is a hybrid like that incorporates Mock. How did that come about?

Well, as Mock matured, it found its way into a number of operating system projects, okay, including next T step. This is the OS developed by Steve Jobs company next T okay. Yeah, or that branching tree we talked about before I do. Next step was one of those branches okay, and it had Mock at.

Its core, got it. So when Apple acquired next T in nineteen ninety six, they inherited not only Steve Jobs but also his Mock based operating system exactly.

Yeah. And Apple recognized the potential of Mock's microkernel architecture, but they also knew that it needed to be adapted to really meet the demands of a commercial operating system.

Right, Like a research project is one thing, yeah, but a real world operating system used by millions of people is a whole other ballgame.

It is, Okay. So they took the mock microkernel from next step and combined it with components from BSD, another Unix derivative, to create a hybrid kernel XNU hybrid.

So it's not a pure microkernel like the original MOCK, that's right.

XNU is a blend of Mock's modularity with bsd's proven stability and performance.

Ah.

Taking the best aspects of both approaching right to create this kernel that's both flexible and robust. It's kind of like combining the agility of a sports car with the reliability of a truck.

I like that analogy. So, what are some like real world examples of how this hybrid approach plays out in the Apple ecosystem. How does it affect the performance of my iPhone?

For example, Well, mock's message passing system, which allows different parts of the OS to communicate very efficiently. That actually contributes to like the responsive TOOS.

Oh Okay.

Meanwhile, bsd's focus on stability ensures that your iPhone rarely crashes even when you're running multiple applications.

So it's like a well coordinated team. Each member has their strengths, yeah, and they work together seamlessly to deliver that smooth user experience exactly. I'm starting to appreciate just how much thought and engineering goes into creating an operating system. Yeah, that feels so intuitive and effortless to use.

It is, and it's a testament to the ingenuity of the engineers at Apple and to the legacy of researchers like Richard Rashid and his team over Carnegie Mellon, who paved the way for these microkernel based systems.

Speaking of letacies, let's go back to the filesystem for a moment. Sure, Earlier you mentioned that Apple's approach to partitioning the file system is quite clever. Can you elaborate on that a little bit?

Sure, As you may recall, Apple separate it's the system partition where the operating system is from the data partition where all your personal files and apps are stored. Okay, Yeah, Now this separation might seem like a minor detail, Okay, but it has some pretty significant implications for both security and usability.

Got it? I remember you mentioned that this is what allows for like, yeah, there's really seamless system updates, But how exactly does that work?

Well, Because your personal data is stored on a separate partition, the system update process can really focus solely on updating those system files without touching your photos, your videos, your documents, or your app data. This means you can update your device without worrying about losing any of your precious information.

Ah. That's such a relief. I've definitely had my fair share of update nightmares on other platforms where I had to back up everything before installing an update, just in case something went wrong. Right, It sounds like Apple's approach is much more friendly.

It is. Yeah, and this focus on user experience is evident in many aspects of Apple's OS design. Okay, for example, let's revisit those dot dmg files we talked about earlier. Okay, Yeah, remember how they're essentially mini file systems.

Yeah, it's like having that tiny, self contained drive within a file. Yeah, this is a pretty interesting concept. Well.

This approach to software distribution has several benefits. First, it allows Apple to create a more controlled and consistent installation experience. It can package the application, it's resources, any necessary documentation within a single, easily manageable unit.

So it's like a neatly packaged gift box. Yeah, everything you need is right there, ready to go exactly. Yeah.

Okay, I like that. What else? In Second, it enhances security. By using a custom image format like dot DMG, Apple can implement security measures, help prevent tampering, and ensure that the software year installing is legitimate and hasn't been modified in any way.

So it's like another layer of protection for the user. It's interesting to see how all these seemingly small design choices all contribute to Apple's overall philosophy of creating a secure and user friendly ecosystem.

Absolutely. Yeah, and this philosophy is perhaps most evident in how Apple manages applications platform right. Yeah, we touched on this earlier. Yeah, but I think it's worth diving a little deeper into the implications of Apple's walled garden approach, particularly in the context of iOS.

Okay, let's talk about the waldgarden. As a user, I really appreciate like the sense of security and consistency that it provides, knowing that you know, every app I download from the App Store has been vetted by Apple. But I can also see how this approach could be seen as like, especially from a developer's perspective.

You've hit the nail on the head. It is a trade off, and there are definitely valid arguments on both sides. On the one hand, apples tight control over the app ecosystem allows them to create this highly curated experience for users. They can set these very strict guidelines for app quality, security content, which helps ensure that users have a positive

So it's like a well maintained park. You might not have the freedom to do whatever you want, but you can be sure that it's safe, clean, and enjoyable for everyone.

That's a great analogy. Yeah, But of course there's a flip side to this coin. Of course, Yeah, apples strict control can also stifle innovation. Developers have to adhere to Apple's guidelines, which can sometimes be seen as arbitrary or even restrictive. They also have to pay a commission on every app they sell through the App Store, which of course cuts into their profits, and they have very limited control over how their apps are marketed and distributed.

So it's a balancing act. Apple wants to create a safe and enjoyable experience for users, but they also need to provide developers with the freedom and flexibility to innovate. It's a tough challenge. There's no easy answer, it really is.

Yeah, and this debate is likely to continue as the app ecosystem evolves and new technologies emerge. But for now, it's clear that Apple's walled garden approach has been successful in creating a thriving app market that benefits both users and developers.

It's a fascinating topic and one that we could probably spend hours discussing. Oh yeah, but for now, I think we need to wrap up this deep dive into the core of Apple's OS. We've covered a log ground today, from the historical roots of Darwin to the architectural complexities of mock, the file system, and the ever evolving world of app management.

It's been quite a journey, yeah, exploring those hidden days. It really has of these systems that we interact with.

Every day, and hopefully our listeners have come away with a newfound appreciation for the complexity and ingenuity that goes into creating those sleek, user friendly devices that we all rely on.

Absolutely Yeah, So the next time you pick up your iPhone or sit down at your Mac, just take a moment to reflect on that incredible legacy of innovation and engineering that made it all possible.

And remember, we've only scratched the surface we have. There's a whole world of knowledge waiting to be explored within every Apple device. So stay curious.

Stay curious.

Yeah, keep learning, keep learning, and keep diving deep, Keep diving deep. Welcome back, to the final part of our deep dive into the world of Apple's operating systems. Before we got sidetracked by the whole Walled Garden debate. We were about to travel back in time to explore the origins of mach microkernel that lies at the heart of XNU.

Right, Yeah, mock. It was born in the mid nineteen eighties at Carnegie Mellon University. It was the brainchild of Richard Rashid and his team, and they had this vision for a new breed of Colonel Yeah, a microkernel designed specifically for flexibility and modularity.

Now, we talked a bit about these concepts earlier, but I'm still a little bit fuzzy on the details. Okay, what exactly itam microkernel? And how does it differ from a traditional monolithic kernel?

Okay, Well, imagine a large complex organization like a corporation. Now, a monolithic kernel is like having a single CEO making all the decisions, managing all the departments, controlling all the resources.

Got it.

Now, It's efficient in some ways, but it can also be very slow and inflexible.

So one person trying to micromanage everything, I can see how that could get pretty messy.

Exactly. Yeah. Now, a microkernel, on the other hand, is like having a smaller, agile executive team that delegates tasks to specialized departments. Each department has its own responsibilities and resources, and they communicate with each other through well defined channels.

So instead of like one central authority, you have this network of smaller, more specialized unit working together.

Exactly.

It sounds like a more decentralized and adaptable.

Approach precisely, and that was the key insight behind mock. By breaking down the kernel into smaller, more manageable components, the researchers at Carnegie Mellon they were really aiming to create this more flexible, portable, and maintainable operating system.

This all sounds like very forward thinking for the nineteen eighties. It was what were some of the specific challenges that they were trying to address with this whole microkernel approach.

One of the biggest challenges back then was portability. At the time, operating systems were often very tightly coupled to specific hardware architectures, and this made it extremely difficult and time consuming to port an operating system to a new type of computer.

So if you wanted to run the same operating system on say like a desktop computer and a laptop, you'd practically have to rewrite the entire thing essentially.

Yeah. Wow, Okay, the Mock team wanted to create this kernel that could be very easily adapted to different hardware platforms, making it way more versatile and future proof.

That makes sense. Yeah, but whatn't breaking down the kernel into smaller pieces also introduce, you know, sure, new challenges like how do you make sure that all these different components work together seamlessly?

That's a great question. Yeah, and it's one of the key areas where the Mock team really made significant contributions. They actually developed this very sophisticated message passing system that allows those different kernel components or servers to communicate with each other efficiently and reliably.

So it's like having this secure and efficient communication network within the kernel itself. Each component can basically send messages to other components, requesting services or sharing information exactly. That seems really clever.

Yeah. It was a groundbreaking innovation at the time. Wow, And it leads to the foundation for those microkernel based systems that we still see today.

So Mark, was this like revolutionary microkernel? Yeah, designed for flexibility portability. How did it end up becoming like the heart of Apple's operating systems Well.

As we discussed earlier, when Apple acquired next T in nineteen ninety six, they inherited next T STEPH, which of course was built on that mock microkernel. And Apple's engineers, Yeah, they saw the potential of mach okay, but they also recognized that it needed to be adapted to meet the demands of a commercial operating system, right, Like.

A research project is one thing, but a real world operating system used by millions of people is a whole other ballgame.

It really is. So Apple's engineers they took that mock microkernel and they combined it with components from BSc, another Unix derived system known for its stability and performance. The result was xn U x U, a hybrid kernel.

Hybrid kernel that takes advantage.

Of both the microkernel and monolithic approaches.

So it's not like a pure microkernel like the original moch No, it's.

More of a hybrid, a blend of different approaches. Does that mean it's not as flexible or portable as mock was initially designed to be? This is a valid question now. While XNU is not a pure microkernel, it retains many the benefits of Mock's modularity. For example, that message passing system developed for MOCK is still a very core part of XNU.

Wow.

It allows the different components of the kernel to communicate very efficiently.

So even though it's been adapted and integrated into this more complex system, Mock's legacy lives on. It does in the heart of Apple's operating systems precisely.

Yeah, and this blend of approaches, Yeah, it's proven to be remarkably successful.

That's pretty cool.

XNU provides that foundation for the responsiveness, the stability, the security that Apple devices are known for.

It's amazing to think that, like a research project from the nineteen eighties continues to shape the digital experiences of millions of people today.

It's incredible.

Yeah, it really shows like the enduring power of innovation and the importance of building on the work of those who came before us.

Couldn't have said it better myself.

Well, I think it's time to wrap up our a deep dive into the core of Apple z os. We've covered a lot of ground today, from the historical roots of Darwin to the architectural complexities of MOCK. The file system, and the ever evolving world of app management.

Absolutely yeah, it's been quite a journey. It really has, exploring those hidden depths of these systems that we interact with every day.

It really has, and hopefully our listener have come away with a newfound appreciation for the complexity and the ingenuity that goes into creating those sleek, user friendly devices that we all rely.

On every day. So the next time you pick up your iPhone or sit down at your Mac, just take a moment to reflect on that incredible legacy of innovation and engineering that made it all possible.

And remember we've only scratched the surface.

We as a.

Whole world of knowledge waiting to be explored. There is within every Apple device, absolutely so stay curious, stay curious, keep learning, cap learning, and keep diving deep.

Keep diving deep,