Speculation on Apple Silicon in upcoming Macs

Ever since WWDC, we’ve been eagerly awaiting Apple’s first Macs running on Apple Silicon. Will they be drastically redesigned? How well will Apple Silicon Macs perform?

Along with announcing the transition in June, Apple provided a Developer Transition Kit to help developers prepare for building their apps for the new architecture. It was provided as a Mac mini enclosure running an A12Z chip, the same in the latest iPad Pro models. While (presumably) designed just for the iPad, the chip worked well enough to run macOS Big Sur. From developer chatter on Twitter, it seems to run fairly well. The benchmarks were decent, outperforming the MacBook Air in a device that isn’t intended to showcase the power of Apple’s Mac-intended silicon.

Apple builds a lot of custom silicon. Even the S-series chips used in the Apple Watch are based on A-series designs. Might this basis allow for a clearer understanding of macOS support on Macs?

This morning, a post by MacRumors shared information about an iMac coming in 2021 running an “A14T” chip. If true, what might this mean for Macs on Apple Silicon? While we are less than a month away from knowing details about the first available Macs with Apple Silicon, here are some thoughts I have.

Stronger Tie to iOS Devices

When Apple announces a new version of iOS, by announcing the devices that support it, they also clearly signal what devices can’t. Occasionally, a release will drop support for one or more devices, typically devices with the same chipset. For instance, iOS 11 dropped support for the A6, and iOS 13 dropped the A7 (and devices with 1GB of RAM running on an A8). If Mac chips are based on A-series designs, we may see similar drop offs with devices. Instead of saying an OS release requires Macs from some year and up, they could just say Macs with a particular chip.

With this change, I also suspect that we will see Macs and iOS devices from a particular year, running on the same chip, to lose new OS support at the same time. For instance, should iOS 20 drop support for the A14 (announced this year in the iPad Air 4 and iPhone 12), the macOS release of that year could also drop support for the Macs running the Mac-equivalent chip.

Now, why would that happen? Why can’t Macs, with higher specs, support OS releases for longer? They technically could. But I think one thing to consider is a big feature of running Big Sur on Apple Silicon: Running iOS and iPadOS apps natively on a Mac. When an iOS app is built with a minimum supported version of iOS 14, for example, the Apple Silicon Mac must also support the APIs required to run that app. That means a stronger tie between macOS and iOS. It also implies a strong connection between the hardware.

Apple devices already are known for incredible support when it comes to OS updates. No other manufacturer ensures their smartphones get as many major releases as iPhone. And this isn’t anything new. Even the second generation iPad supported 6 major versions of iOS during its lifetime! Right now, the average for iOS devices seems to be between 5 and 6 years. However, macOS Big Sur is available for some Macs that are 7 years old. So, I see this tighter relationship between Macs and iOS devices to culminate in one of two changes:

  • Macs start supporting only 5-6 major OS releases, in line with iOS/iPadOS devices – I don’t see this as likely, as Apple would not want to be seen as reducing support of their most expensive computing product line. Then people might say, “When it ran Intel, they would support 7 year old Macs. Now they barely can last 5 years!” I think Apple would want to show that their Macs have better support on Apple Silicon than Intel.
  • iOS/iPadOS devices start supporting OS releases for more than 6 years – Should macOS stay at supporting Macs that are 7-8 years old, perhaps one day we’ll have an iOS device that can be said to have supported 7-8 major OS releases now. They support 5-6 now, and the A14 in this year’s products is so far ahead of the A8 and A9 currently supported at the low end with iOS 14 that I can see it easily lasting to iOS 21, 22, or beyond.

Performance vs Battery Life

Already, Apple is comfortable with making variants of their chips for different products. This has been true ever since the A5X in the third generation iPad. Apple continues that trend to this day, with the iPad Pros running the A12Z (virtually identical to the A12X, with one additional core). These improvements typically are for the benefit of the iPad while retaining great battery life.

General expectations are that Macs running on Apple Silicon will have better battery life and better performance than their Intel counterparts. How will that be delivered?

I’m curious if we’ll see trade-offs made between the portable and desktop lines. For instance, perhaps we would find the A14T (the rumored Mac chip) in both the MacBook Pro and iMac. This chip might be the Mac-specific version of the A14, given additional cores to power what people expect from a Mac. It may even be an offshoot of the A14X (if one such chip launches later this year). So you would see an A14, A14X with improved graphics, and A14T with additional changes for the Mac.

This same chip might be able to scale across Apple’s entire Mac line. On the MacBook Pro, it would be tuned for better battery life with moderate performance. But for the desktop, with constant power and better cooling, it might be tuned for higher performance. Pair it with additional RAM and Apple’s custom GPUs, and you’d have a singular chip to track for Apple’s Macs during any given generation. Gone would be the days of choosing to buy a new MacBook with an i3, i5, or i7 processor. Instead, you’re buying a Mac with an A14T. You just are choosing how it’s tuned.

Is this how it’ll all turn out? Again, we will have to wait and see. But however it ends up, I’m excited to see what this new generation of Mac will bring.

Future App Development on iPad

With less than 24 hours until Apple unveils iOS 14 and a slew of software updates at WWDC 2020, I wanted to briefly get my thoughts down regarding something that has been in my head.

Many feel that, with the iPad positioned as a computing platform, the iPad itself needs to do more things like a Mac can. One of those is app development. While it’s not a totally useless platform for development, there are limitations. But I think there will be some lingering limitations for a while, and in a way, those limitations might help us see the direction Apple is taking their platforms.

Current State

Right now, the iPad has a limited availability for development. This is in the form of the Swift Playgrounds app, which is a great way to learn Swift within a playground environment. Since last year, it has supported SwiftUI, Apple’s new declarative UI framework.

Swift Playgrounds is useful but comes with some obvious limitations:

  • No actual app creation
  • IDE only – No Interface Builder/SwiftUI Preview canvas
  • Missing some SwiftUI functionality when running your code

It’s not totally useless. If you’re a fan of playgrounds like me, then you may already be used to building a lot of Xcode playgrounds to test various ideas and concepts. Doing the same on the iPad is no different.

iPad as ARM Mac?

With Apple’s rumored transition to ARM processors for their Mac line, some were speculating that the iPad Pro would be a good test device until actual ARM Macs ship later this year. However, this was shot down as the iPad Pro has only 6 GB of RAM, while the typical Mac starts with 8 GB.

From John Gruber at Daring Fireball:

iPad Pros only have 6 GB of RAM — no Mac has shipped with less than 8 GB in many years, and developers aren’t buying machines with 8 GB of RAM. Honestly, I think the RAM is a deal-breaker on the iPad Pro-as-ARM-Mac-dev-kit idea.

I also agree with this point. I don’t think the iPad Pro is itself a good candidate for testing macOS on ARM hardware. However, if we take the above limitation into account, let’s reason on some possibilities.

The Future of iPadOS

Why did Apple break out iPadOS from iOS? Sure, there are differences at the UI/UX level. For instance, you can drag and drop items between apps on the iPad, but on the iPhone this is limited to within the scope of a single app.

Even during the iOS 13 timeframe, the builds for iOS and iPadOS were similar in terms of foundation. There’s no surprise there. But this begs the question: is iPadOS just a marketing term?

With the recent release of the Magic Keyboard for the iPad Pro, I wonder if we’ll truly see the iPad move into more of a Mac-like direction. It will never become the Mac. It will never replace the Mac. But we might see some additions to the iPad that make it more compelling to use with something like the Magic Keyboard.

For one, let’s consider the initial transition in bringing iOS apps to the Mac. This was done by bringing UIKit from iOS to macOS. Last year, Apple announced Mac Catalyst as a way for iPad apps to easily come to the Mac, and improvements were made throughout iPadOS 13 to support mouse cursors and keyboard input.

The next stage in that transition is supposedly bringing support for iPhone apps to the Mac.

But that sounds so trivial. Why is that a separate stage in the release? If someone can easily make an app that supports iPhone and iPad now, what does this bring for developers?

iPadOS Windows

Last year, Apple added support for multiple windows (called “Scenes”) of the same app to exist at the same time. What this means is you can have two windows from the same app side by side in multitasking. Or have multiple windows from an app paired with multiple other apps. Example: You can have two Notes windows side by side, or two Messages windows, or two Safari windows.

However, there are still limitations on how windows can be arranged. Right now, you can have an app (or two, paired) take up the full display, and have an app visible via Slide-Over on the side.

What if the idea of iPhone apps coming to Mac is really intended for iPhone apps to come to the iPad? Imagine Slide-Over but refined and expanded, allowing iPhone-sized apps to live on your iPad screen, perhaps even when you’re on the home screen. With cursor and keyboard support, this would bring some added capabilities to iPadOS, bringing it closer to the Mac without actually running macOS.

I have no knowledge of future roadmaps, but I wouldn’t be surprised if that’s the direction iPadOS takes.

Now, what does this have to do with developing apps on the iPad?

The Future of App Development on iPad

Right now, app development is done on the Mac. Xcode lets you build apps for iOS, watchOS, iPadOS, tvOS, and macOS. And the Mac can simulate all of those environments.

If we were to expand iPad to be able to develop apps, we have to ask the question: What platforms can we simulate on an iPad?

If iPhone apps will soon be able to run on an iPad, I’d argue that being able to develop iPhone apps on an iPad version of Xcode is a possibility. And much like the Xcode for Mac is capable of building Mac apps, Xcode for iPad will be able to build iPad apps. In fact, I can see Watch and tvOS apps just as easily.

But what about Mac apps? While it could be possible, how would you test it? Mac apps have the most access to their platform than any other Apple OS, by far. Would you simulate a Mac environment to test a Mac app?

While not impossible, I find it highly improbable that you would be able to simulate a Mac environment on an iPad to test a Mac app.

Then you have the question of UI development. While you can programmatically build UI, Apple wouldn’t want to leave that as the only way to do so. And while many apps are still built with UIKit/AppKit and Interface Builder, Apple has showed us a new way to build UIs: SwiftUI.

With SwiftUI, we’re able to build apps for all of Apple’s platforms (including the Mac). With SwiftUI, I also think Apple is slowly laying the foundation for eventually supporting a version of Xcode for iPad.

While the iPad won’t be able to build everything Xcode for Mac can, it’ll eventually be able to build apps for the iPad, iPhone, Apple Watch, and possibly tvOS. But you would have limitations: SwiftUI would be your only route for UI.

If this ends up being true, it also shows Apple’s priorities: Enable developers to build apps for their more popular platforms with limited, more specialized tools, and leave the larger development picture to the Mac.

So will Xcode come to the iPad? I think so. Will it replace Xcode for Mac? No. Will the iPad replace the Mac? No.

But what we will definitely see is a separation of iOS and iPadOS. Last year was just marketing. This year and beyond, we’ll see it in practice.

WWDC 2020 Expectations

Everyone has their own expectations when WWDC comes around. Here is what I’d like to see come from Apple and their various platforms.

SwiftUI improvements

Whether they call it SwiftUI 2, or just say they’ve made it better, I fully expect to see a “What’s New in SwiftUI” session this year, including some much needed additions. Of those, I’m hoping to see:

  • First party support for two-dimensional data grids. If List is to UITableView, then I want whatever is the equivalent of UICollectionView. There are a few interesting third-party solutions out there, and I’m not against using them, but I feel something like this would benefit from being provided by Apple themselves.
  • Fixed TabView. Right now, while you can easily create tabbed navigation, the SwiftUI TabView doesn’t behave like a normal UITabViewController. Specifically, if you navigate to another tab and come back, it’s up to the developer to maintain the hierarchy. So if I’m 3 views deep in tab 1, go to tab 2, then go back to tab 1, I’m back at the root by default.
  • Fixed NavigationView. This is more-so when it comes to master/detail on iPad. If I navigate a layer deep in a detail, then rotate the iPad, it resets the detail view while retaining the navigation stack. So I can push a view, rotate, push again, rotate, push again, and end up with what seems to be a navigation stack three or four views deep when in reality my hierarchy is just one or two.

What I do not expect to see is a complete replacement of everything available in UIKit or AppKit. What I mean: I don’t think we’ll see SwiftUI versions of WKWebView, MKMapView, or similar views. The current SwiftUI<->UIKit/AppKit functionality seems to cover situations like this.

“Swifty” Core Data

In Swift 3, Swift gained a huge improvement when it came to JSON Serialization: Codable. Codable is really two protocols: Encodable and Decodable. But together, they take the concept of serializing data, such as to/from JSON, and made is super easy to support.

I would love to see something similar done with Swift classes and Core Data. Could we make a data model conform for Core Data storage by just adding a protocol conformance? If that were possible, I know I’d love to use it.

I’d also hope that any such improvements would allow us to make a Core Data managed object that automatically conformed to Codable without requiring a custom init/decoder.

A Gamer’s GameCenter

I think GameCenter was one of Apple’s squandered opportunities. They offer a powerful Apple TV box that, if powered by newer iOS chipsets, can rival console performance. Yet they have nothing on their platform that resembles the social interactions and networking like you’d see on Xbox or Playstation. I keep hoping they’ll wisen up, revive that platform, and provide a better way for people to find their friends and game together.

An Improved Development Experience on iPad

Swift Playgrounds shows that it’s possible to do coding on the iPad. I’d like to see this turned up a notch, even if it isn’t a full-blown Xcode for iPad. With SwiftUI, perhaps we’ll see some middle-ground. Use your iPad to develop a SwiftUI app? Great. Want to integrate legacy components? Take your project to your Mac.

Even if that doesn’t happen, I’m curious to see what new features and enhancements come to the Swift Playgrounds app this year.

I’m sure that, with whatever Apple announces, I’ll be eager to install the latest betas and try things out. Even if none of my expectations are meant, I’m going to enjoy WWDC 2020.

iPhone SE performance versus Android Flagships

Jerry Hildenbrand at AndroidCentral:

Apple has updated the little iPhone SE for 2020, and even an Android fan has to see that it’s a great phone at an even greater price of $399 for the base model. It’s essentially an iPhone 8 with one big difference: it has Apple’s A13 Bionic chip buried inside. And that’s a big deal for a number of reasons.

I expect that some people are going to tell me about single thread versus multi-threaded performance and how the A13 GPU isn’t that great or how iPhones have much lower resolution screens so the chips don’t have to work as hard. All this is true, but another thing is true: the A13 is a stronger chip than the Snapdragon 865 for daily use in every category — we’ve seen this applied in real life in the iPhone 11 already.

Jerry does a nice job summarizing the performance of the A13 Bionic in the iPhone SE against the Snapdragon 865 found in many Android flagship phones. While it’s not been a specs game for many years, in terms of raw specs, the iPhone SE outperforms top-of-the-line Android phones at a third to a half of the price.

What sounds less crazy, and great to consumers, is that by using the A13 Apple can support the iPhone SE for years — and this phone will outlive the iPhone 8 it is slated to replace for a handful of extrayears because of the new chip. Basically, if the iPhone 11 can get updated, so can the iPhone SE. This is cool to hear today, but it will be really important in three years when another version of iOS is released and your $399 iPhone gets it on day one.

Android devices, typically, still get less than 3 years of updates. And it can take months between the time a new version of Android is released and it is made available on supported devices. And many devices, especially lower priced ones, may barely see one major software update.

And yet, the $399 iPhone SE is likely to get 5 years of major software updates, including new features.

John Gruber, at Daring Fireball:

And on the flip side, what do you get for $400 in Androidtown? Amazon sells the Motorola Moto Z4 for $500. Let’s just spot the Android side $100. The Moto Z4’s single-threaded Geekbench 5 score is about 500. That falls short of an iPhone 6S, a phone from 2015.

For the same price, you can buy an Android that performs about as well as a 5 year old iPhone. An iPhone that still supports the latest version of iOS.

Where are the popular Android phones from 2015 now?

  • Samsung Galaxy S6 – Last software update was 2016’s Android 7 Nougat, made available in 2017, with the last security patch in September 2018.
  • Sony Xperia Z5 Compact – Latest supported version is 2016’s Android Nougat.
  • Google Nexus 6P – Google’s flagship for the year, it got its last update at the end of 2017 with Android 8.0 Oreo.
  • Samsung Galaxy Note 5 – Last update, Android 7 Nougat, in 2017

It’s pretty clear to see: If you need a phone on a modest budget, the iPhone SE is the smartest choice. Best performance with the longest support means you’ll get the most for your money.

Appearance: Not Another Swift Podcast #16

This week, I joined Matt and Jason on their show, Not Another Swift Podcast. As usual, Matt is discussing his journey as he learns iOS development. This week we discussed project 16 of 100 Days of Swift. It was a chance to talk a little bit about MapKit, a framework I remember really enjoying when I worked with it over a year ago. I also got to open the show with a dad joke. How often can you say that?

It’s been years since I’ve been on a podcast, and it was great to be ‘back on the air’.

Using a Binding in SwiftUI – Simple Example

In my original post on Bindings in SwiftUI, I had mentioned when we might want to use a binding:

You would use a binding to create a two-way connection between a property that stores data, and a view that displays and changes the data.

I showed an example of how we could bind one of our local @State properties to a Toggle. The Toggle could update the state of our property through it.

We can use other system controls, such as TextField or Picker, to also update our local variables. But what if we want to have another one of our views update a variable owned by another? Let’s solve a simple example and, in doing so, we’ll see when we will make use of @Binding.

I have a simple view that displays my name. I am storing it locally as a variable.

struct NameDisplayView: View {
    var name: String = "unknown"
    var body: some View {
        Text("Your name is \(name)")

It simply takes the text there and outputs "Your name is unknown". It works, but I want to be able to update that name so I can have it show me and not assume I have no name.

Well, we know how we can bind to something from our original post. So let’s make a view where we can change some text.

struct NameChangeView: View {
    @State var text: String
    var body: some View {
        TextField("Type Here", text: $text)

So far, this is a simple example. If we loaded up NameChangeView, we could tap into the TextField and, as we type, text would be updated. Why? Because we have it bound to the text property on TextField, which is of type Binding<String>. So as the TextField updates the text, our view can get the latest values.

But let’s say we want to present this view as a sheet, let the user update the text, and then send it back to our original view. Can we do it? Yes!

What do we need to change so that our NameChangeView can pass changes back from itself to another view? All we have to do is change @State to @Binding. With that change, we now have two way communication via that variable.

Let’s add a little styling and a way to dismiss the view. That gives us our final form:

struct NameChangeView: View {
    @Environment(\.presentationMode) var presentationMode
    @Binding var text: String
    var body: some View {
        TextField("Type Here", text: $text, onCommit: { self.presentationMode.wrappedValue.dismiss() })

Now, how can we use this in our original view?

We’ll add a button to trigger a sheet. This happens by binding a local Bool to the .sheet(isPresented:) modifier. Lastly, we add our NameChangeView as what is being presented modally as a sheet. We pass our local name variable as a binding to that view, so it becomes $name.

struct NameDisplayView: View {
    @State var name: String = "unknown"
    @State var showNameChange = false
    var body: some View {
        VStack {
            Text("Your name is \(name)")
            Button("Change") {
                self.showNameChange = true
        .sheet(isPresented: $showNameChange) {
            NameChangeView(text: self.$name)

Now, we can tap on “Change”, which will present our text field. We can tap on it, change our name, hit “Return”, and be taken back to our original view but with our name in place.

Bindings might seem like a new concept to iOS developers, but they open up a lot of possibilities in Swift. Explore various ways that you can use bindings to communicate between views. You’ll find them very useful, especially in cases of user input as we saw in our example.

You can find the example code in this Github Gist.

‘Frolicking around in excess’

Matt Birchler, writing about what matters in a phone:

So when I see the $399 iPhone SE with 5 years of likely updates, with a really good single lens camera, and with it’s processor that’s faster than all 2020 $1,000+ Android phones, and will likely still be faster than all 2021 Android phones…well, it just looks like a good phone, and it makes it look like we’ve been frolicking around in excess for years now.

I’m one of those people with an iPhone 11 Pro. I enjoy Face ID. I like the ways I can interact with my phone without a home button. I like the triple camera system. I don’t regret owning it. But I also know it’s not for everyone.

For everyone else, people that are just looking for the best deal on a smartphone in general, Matt hits it right on the head: The new iPhone SE is likely the best purchase you can make right now. Maybe even the best purchase next year.

Bindings in SwiftUI

Property wrappers were one of the recent additions to Swift. SwiftUI makes use of several very useful property wrappers. One of them is @Binding. The @Binding property wrapper is really just a convenience for the Binding<T> type.

But before we go into using bindings, what are bindings?

Per Apple’s documentation, a binding connects a property to a source of truth stored elsewhere, instead of storing data directly. You would use a binding to create a two-way connection between a property that stores data, and a view that displays and changes the data.

In SwiftUI, you’ll find this to be a fairly common pattern, especially with built in input fields.

Binding Example

Let’s say we want a view with a switch for the user to interact with. How do we build it?

struct BindingExample: View {
    @State var switchIsOn = false

    var body: some View {
        Form {
            Toggle(isOn: $switchIsOn) {
                Text("Switch 1")

First, we need a mutable variable to hold the state of our switch. In this case, we have a Bool, named switchIsOn. We have to use the @State wrapper so it can be modified in our view.

Next, when we build our Toggle, we need to provide a binding to a property that will hold the state of the toggle. When we pass in the variable, we use the dollar sign to denote that we’re binding to it. So our view holds the current state of switchIsOn, while the Toggle has a binding internally. When the state of the Toggle flips, it is propagated through $switchIsOn back into our view.

Creating a manual binding

If we again look at Apple’s description of a binding, we see that it involves a two-way connection. The binding needs to know the value to get, and where to set the new value when it is changed.

With that knowledge, we can look at how Binding workings. Let’s look at our example again. This time, we’re going to make a binding ourselves.

struct BindingExample: View {
    @State var switchIsOn = false 

    var body: some View {
        Form {  
            Toggle(isOn: Binding(get: {
            }, set: { newValue in
                self.switchIsOn = newValue
            }) ) {
                Text("Also Switch 1")

Binding has an initializer that takes a couple of arguments. One, with the get label, is a closure explaining where the binding gets its value. In our example, this is our switchIsOn variable. The other, set, is given the new value for the binding. This gives us the opportunity to do something with it now that it has changed. In our case, we’re setting switchIsOn to the new value.

In its most basic form, Binding opens up a lot of interesting possibilities. In later posts, I’ll talk about when we might want to create a binding between our views, as well as some interesting problems a manual binding can solve.

Portrait Mode and the Neural Engine on iPhone SE

Apple finally announced the successor to the iPhone SE. Also called the iPhone SE (and from here, the one I am referring to with that name), it built on the expectations that many were thinking: A reuse of an existing design with newer internals. This is exactly how Apple approached the first SE model. So it made since that the new iPhone SE followed suit.

Design wise, the iPhone SE is identical to the iPhone 8 that it replaced. But internally, it contains a lot of technology found in the iPhone 11: A13 Bionic chip with the third generation Neural Engine, support for WiFi 6, Gigabit class LTE, etc. It also made some changes from the iPhone 8 in line with the iPhone 11, such as the removal of 3D Touch.

But there are some camera differences with the iPhone SE, especially when compared to the iPhone 8, that made me really think.

Portrait Mode

The iPhone SE, like the visually identical iPhone 8, has a single camera on the back side. If you compare the specs between the iPhone 8 and iPhone SE, you’ll see no difference:

  • Single 12MP Wide camera
  • Wide: ƒ/1.8 aperture
  • Optical image stabilization
  • Digital zoom up to 5x
  • True Tone flash with Slow Sync

The iPhone 8 camera was really good, so keeping that same sensor, especially to reduce cost, makes sense.

But there’s something the iPhone SE has than its predecessor didn’t have:

  • Portrait mode with advanced bokeh and Depth Control
  • Portrait Lighting with six effects (Natural, Studio, Contour, Stage, Stage Mono, High‑Key Mono)

The iPhone SE adds Portrait mode, something that initially came to the iPhone 7 Plus because of its dual cameras. Bringing this to a 4.7-inch iPhone like the iPhone SE is a first.

Now, this isn’t the first time a single camera iPhone has received Portrait Mode. The iPhone XR, released in 2018, had a single backside camera and supported Portrait Mode. If we compare the stats of the XR’s backside camera against the iPhone 8 and iPhone SE, we’ll see that it’s identical. However, there is a notable difference with the iPhone XR:

  • Portrait Lighting with three effects (Natural, Studio, Contour)

The iPhone XR only supports three effects in Portrait Mode on the single backside camera. What gives?

Apple explains in their press release:

iPhone SE features the best single-camera system ever in an iPhone with a 12-megapixel f/1.8 aperture Wide camera, and uses the image signal processor and Neural Engine of A13 Bionic to unlock even more benefits of computational photography, including Portrait mode, all six Portrait Lighting effects and Depth Control.

The neural engine in the A13 is able to do much better with the single camera sensor input to process all of the available effects for Portrait Mode. So much so that it enables all six effects on the single camera!

But it doesn’t stop there!

A First on an iPhone

Let’s compare the front camera on the iPhone 8, iPhone XR, and iPhone SE.

The iPhone 8 and iPhone SE both have identical specs:

  • FaceTime HD camera
  • 7MP photos
  • ƒ/2.2 aperture
  • Retina Flash
  • Auto HDR for photos
  • 1080p HD video recording at 30 fps

Since it doesn’t include the TrueDepth camera system, which uses a camera and additional sensors to detect facial features and depth, the iPhone SE has Touch ID instead of Face ID for unlocking the device. It also makes sense that it doesn’t have Portrait Mode on the front camera.

Except it does.

  • Portrait mode with advanced bokeh and Depth Control
  • Portrait Lighting with six effects (Natural, Studio, Contour, Stage, Stage Mono, High‑Key Mono)

Again, from Apple’s press release, just after the earlier quote:

Using machine learning and monocular depth estimation, iPhone SE also takes stunning Portraits with the front camera.

The iPhone SE is the first iPhone without the TrueDepth camera system with front facing Portrait Mode. It’s using a single camera, like the backside, to enable the same level of Portrait Mode, using the same cameras as found in the iPhone 8.

It’s amazing what the A13 Bionic chip is able to enable. It and the third generation Neural Engine definition power the most powerful smartphones in the world. In the words of Apple SVP Phil Schiller: “It’s a big deal.” And to be able to include their fastest chip in their cheapest iPhone? An easy win for Apple.

Property Wrappers in Swift

With Swift 5.1 and Xcode 11, many new features came to Swift. A lot of these were built in to help enable SwiftUI in Apple’s latest OS releases. While diving into SwiftUI is a great way to understand those features, there are some that we don’t need to go into SwiftUI to understand. One of these is property wrappers.

I like to explain property wrappers by a literal definition of the phrase: They wrap properties in functionality. While there are some built into various Apple frameworks (ie SwiftUI), it’s easy to create your own, and they can give you a lot of neat functionality.

How to create a property wrapper

To define a property wrapper, you need to have a custom type (I typically use structs) that you mark as a property wrapper with the @propertyWrapper keyword.

struct Wrapper { 


By adding that attribute, my type now must conform to its requirements. To do so, I need to add a non-static property named wrappedValue. The type of this property will depend on the kind of wrapper you are building. Let’s look at some practical examples and see what we can build.

Easily decoding an ISO 8601 Date

Since Swift 3, we’ve had the very convenient Encodable and Decodable protocols. The type alias Codable is how we typically see it. Having our models conform to Codable allows us to easily encode and decode our models to and from JSON for API communication.

The Date type conforms to Codable. But how does it encode/decode by default?

struct DateTest: Codable {
    var date: Date = Date()

let dateTest = DateTest()
let data = try JSONEncoder().encode(dateTest)
let json = try JSONSerialization.jsonObject(with: data, options: [])

// {
//    date = "608081487.019236";
// }

Okay. At least Date can encode automatically. I can live with that. But it looks like it’s turning a date into a number. What if we want to work with different standard, such as an ISO 8601 Date?

What is an ISO 8601 Date? It a popular date format presented as a string where a date like 10:43 pm on April 4, 2020 would appear like this:

So can Date decode this by default? Let’s find out!

let isodateJSON = """
    "date": "2012-07-14T01:00:00+01:00"

let isoDecodeTest = try JSONDecoder().decode(DateTest.self, from: isodateJSON.data(using: .utf8)!)

So using a multi-line statement in Swift, I’m going to try and decode an instance of our DateTest struct with this JSON object. Will this work? If you saw how Date encoded itself, then you won’t be surprised by the response we get from trying to decode this JSON.

ERROR: typeMismatch(Swift.Double, 
    Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "date", intValue: nil)], 
    debugDescription: "Expected to decode Double but found a string/data instead.", 
    underlyingError: nil))

While we have a valid date format, Date is expecting a Double. What can we do?

We could create a custom JSONDecoder when decoding our type. But if we want to support ISO 8601 dates across various models, then we have to create custom decoders for all of them. That could end up being a lot of manual decoding work. OR… we could create a property wrapper to automatically decode the string coming from our JSON into a valid Date.

We start by creating our property wrapper. Ultimately, we want to provide a Date. So that will be our wrapped type.

struct ISO8601Date {
    var wrappedValue: Date

This satisfies the basic requirements of @propertyWrapper. Now we have to add our own functionality. In our case, here is where we will build our custom encoding and decoding capabilities.

We start by declaring ISO8601Date itself as conforming to Codable. This will let us wrap properties in a Codable-conforming model and not cause any errors about a model needing to manually provide such conformance.

Next, we create our custom Codable conformance within our ISO8601Date struct.

init(from decoder: Decoder) throws {
    let value = try decoder.singleValueContainer()
    let stringValue = try value.decode(String.self)
    if let date = ISO8601DateFormatter().date(from: stringValue) {
        wrappedValue = date
    } else {
        throw DecodingError.typeMismatch(Date.self, DecodingError.Context(codingPath: [], 
                        debugDescription: "Failed to decode ISO Date. Invalid string format."))

func encode(to encoder: Encoder) throws {
    var container = encoder.singleValueContainer()
    let string = ISO8601DateFormatter().string(from: wrappedValue)
    try container.encode(string)

Our initializer will try and decode a string. If this string can be used to decode a date in the ISO 8601 standard format, it will do so. Otherwise, it will throw an error. Meanwhile, our custom encode function takes the stored date and encodes it into a string using the ISO8601DateFormatter.

Lastly, we add a simple init to allow the user to set a default value with our property wrapper.

init(wrappedValue: Date) {
    self.wrappedValue = wrappedValue

Put all of this together and what do we get? If we look at our original DateTest model, we can now prepend the @ISO8601Date attribute to our date property and it will encode to and decode from an ISO 8601 string automatically.

struct DateTest: Codable {
    @ISO8601Date var date: Date = Date()

Using UserDefaults for property storage

You may be using UserDefaults in your app to store simple properties. Perhaps it’s a Bool saying if a user has enabled or disabled some feature. Or perhaps you’re storing a String of the last logged in user. You may have built convenience properties to read and write these values. In doing so, you may have ended up with a pattern like this:

class SettingManager {
    static var userViewedWhatsNew: Bool {
        get {
            UserDefaults.standard.bool(forKey: "userViewedWhatsNew")
        set {
            UserDefaults.standard.set(newValue, forKey: "userViewedWhatsNew")
    static var lastLoggedInUser: String? {
        get {
            UserDefaults.standard.string(forKey: "lastLoggedInUser")
        set {
            UserDefaults.standard.set(newValue, forKey: "lastLoggedInUser")

There’s nothing wrong with the above code (except maybe hard-coded key values). But as you add support for more and more properties, things get to be real tedious. So if we were to abstract this out, what pattern do we see?

For each property, we are both (a) getting the value from UserDefaults and (b) setting the value to UserDefaults using the same (c) key. With this pattern in mind, let’s approach our property wrapper.

struct UserDefault<StoredType> {
    public let key: String

    var wrappedValue: StoredType {
        get {
            UserDefaults.standard.object(forKey: key) as! StoredType
        set {
            UserDefaults.standard.set(newValue, forKey: key)

Instead of using wrappedValue to store a value we initialize, like in our first example, we have a computed getter and setter. It is performing our reading and writing with UserDefaults. The key used for those transactions? We provide it in our property wrapper.

What data type does this work with? You’ll see that we are using a generic type (StoredType). It will inherit the type from whatever you end up wrapping.

But wait! What if you wrap an optional type, like String?. Won’t the getter crash if there is no object for key? Nope! Because it’s coming back as an optional, or Optional.none case (if you look at how Optionals work in Swift), which is a valid value for something of type String?. But if we did try to read a String that wasn’t there, then it would crash.

So how about we add a default value?

struct UserDefault<StoredType> {
    public let key: String
    public let defaultValue: StoredType

    var wrappedValue: StoredType {
        get {
            UserDefaults.standard.object(forKey: key) as? StoredType ?? defaultValue
        set {
            UserDefaults.standard.set(newValue, forKey: key)

Now we will attempt to return a value of type StoredType from UserDefaults but, in the event no such object exists, we will return our defaultValue.

How can we use this in our SettingManager above?

class SettingManager {
    @UserDefault(key: "userViewedWhatsNew", defaultValue: false) 
    static var userViewedWhatsNew: Bool    

    @UserDefault(key: "lastLoggedInUser", defaultValue: nil) 
    static var lastLoggedInUser: String?

If we were to add support for a new property stored in UserDefaults, it is super simple.

Now, notice how we are setting the key and defaultValue properties when declaring our property wrapper. This is making use of the synthesized initializer on our struct. You could make your own init function and use it when declaring the property wrapper.


Property wrappers are super helpful. They can help you take repeated code and patterns away from your properties and move them into a reusable component. As we’ve seen here, you can make various Codable edge cases easy to solve. They can also help you with code you find yourself repeating in things like a set, didSet, or other such case.

Like other Swift features, property wrappers are just another tool that are worth having in your developer tool box. I hope this post helped demystify them a little bit and make them more approachable for you.

You can find the code for this post in this Github Gist.