Apps have to show what data is used in what way — categorized by such things as third-party advertising and developer marketing. Some data is shown in more than one category, but it was easy enough to de-dupe them in the above apps. With Facebook Messenger, in contrast, the list is so long I have to list it in full.
Does anyone other than Facebook leech so much of our personal information?
Gordon Mah Ung at PC World doesn’t believe Apple’s claims about the M1’s performance:
Let me just say it outloud, OK? Apple is full of it. I’m referring to Apple’s claim that its fanless, Arm-based MacBook Air is “faster than 98 percent of PC laptops.” Yes, you read that correctly: Apple officials literally claimed that the new MacBook Air using Apple’s custom M1 chip is faster than 98 percent of all PC laptops sold this year.
This is a totally reasonable point. After all, have Windows PCs running on ARM shown themselves as being stellar devices? Not so much.
But we’ve had benchmarks for the A14 for a month now. The iPhone 12 and iPad Air definitely smoke the Surface Pro X. Why would a custom Mac chip be expected to be inferior to that?
When Apple makes its claims, my guess is they are comparing the new M1 to Intel-based processors ranging from Atom to Celeron N to Core i3 and up, all with integrated graphics. But by not defining the word “performance,” all this becomes just pure marketing spin. And is it really fair to compare a $999 MacBook to one that costs $150? Because $150 PCs are included in the 98 percent of laptops sold.
Apple’s claim likely included all of the lower powered Intel offerings. Of course, looking up benchmarks for Atom, Celeron N, and Core i3 show these to be no challenge for 2020 devices. The two year old A12 matches or exceeds their performance, especially in single-core. But what about the beefier options?
Does that mean the new fanless MacBook Air is faster than, say, Asus’ stupidly fast Ryzen 4000 based, GeForce RTX 2060-based Zephyrus G14? Does it mean the MacBook Air is faster than Alienware’s updated Area 51M?
The answer, I’m going to guess is “no.” Not at all. Is it faster than the miniLED-based MSI Creator 17? Probably not, either.
The implication here is that Apple can out-perform the low powered Intel offerings but is far behind the powerful Windows laptops. “Could a fanless Mac with a low power chip truly be faster than these higher power, cooled systems?”
I tried to look up each of these and compare benchmarks.
Against the Zephyrus G14, the M1 blows it away in single-core performance. In terms of multi-core, it’s about even, with the M1 barely behind. The G14 is “stupidly fast”, he says? Guess that means the new MacBook Air and M1 are “stupidly fast”, too.
For this comparison, I used the 10-core option of the Area 51M. That seemed to give it a more substantial lead over the M1 in multi-core. Again, in single-core performance, the M1 takes the lead. And while not as fast in multi-core, I think it’s fair to again point out that the M1 is doing this in a fanless design starting at $999. Meanwhile, the Area 51M R2 is marketed as having “advanced cooling” and, for the 10-core model from Dell, can be purchased for $3,700. Did the Alienware win this one? I’d say it barely did, but at almost 4 times the cost. That’s telling.
The Creator 17 looks more like the G14. M1 wins single-core again. Multi-core is close. If you think the MSI Creator 17 is a fast machine, then again, the MacBook Air and M1 are going to easily match or outpace this (depending on whether your operations rely on single or multi core performance). And, like the Area 51M R2, the Creator 17 has a 3-fan design and starts at a more reasonable price of $1499.
So, is the M1 faster than 98% of laptops sold in the last 12 months? If it can closely match (or, in single-core, crush) these ‘top 3’ options, it likely is faster than any Intel offering with a lesser CPU. In which case, it’s not just marketing spin: Apple is telling the truth about the performance of the M1.
And this is all in a fanless design (it specs similarly in the Mac mini and 13-inch MacBook Pro, both which have a fan). When Apple starts churning out chips for the larger MacBook Pro, iMacs, or eventually the Mac Pro, these are going to embarrass the rest of Intel’s line.
Meanwhile, I don’t think that PC World article is going to age well.
While today was all about Macs with Apple Silicon, the M1 chip in those Macs is likely based on the A14. AnandTech today dove into the A14, found in the iPhone 12 and latest iPad Air:
In the overall mobile comparison, we can see that the new A14 has made robust progress in terms of increasing performance over the A13. Compared to the competition, Apple is well ahead of the pack – we’ll have to wait for next year’s Cortex-X1 devices to see the gap narrow again.
What’s also very important to note here is that Apple has achieved this all whilst remaining flat, or even lowering the power consumption of the new chip, notably reducing energy consumption for the same workloads.
One further note is the data of the A14’s small efficiency cores. This generation we saw a large microarchitectural boost on the part of these new cores which are now seeing 35% better performance versus last year’s A13 efficiency cores – all while further reducing energy consumption. I don’t know how the small cores will come into play on Apple’s “Apple Silicon” Mac designs, but they’re certainly still very performant and extremely efficient compared to other current contemporary Arm designs.
Apple chip team continues to lead. Increased performance without increasing power consumption is no small feat. And again, this is looking at the A14 in the iPhone 12. The M1 chip in the new Macs no doubt build on this, which is why those Macs can claim such performance increases while reporting almost double the battery life for operations with previous generation Macs.
The performance numbers of the A14 on this chart is relatively mind-blogging. If I were to release this data with the label of the A14 hidden, one would guess that the data-points came from some other x86 SKU from either AMD or Intel. The fact that the A14 currently competes with the very best top-performance designs that the x86 vendors have on the market today is just an astonishing feat.
In the overall SPEC2006 chart, the A14 is performing absolutely fantastic, taking the lead in absolute performance only falling short of AMD’s recent Ryzen 5000 series.
The fact that Apple is able to achieve this in a total device power consumption of 5W including the SoC, DRAM, and regulators, versus +21W (1185G7) and 49W (5950X) package power figures, without DRAM or regulation, is absolutely mind-blowing.
One thing I love with AnandTech are their charts. Their benchmarks of the A14 against typical PC silicon are amazing to see. And Apple is doing that with a chip that uses a fraction of the power. If Apple were to scale their designs into something that did use 20+ Watts, you can imagine how it would handle such benchmarks.
Whilst in the past 5 years Intel has managed to increase their best single-thread performance by about 28%, Apple has managed to improve their designs by 198%, or 2.98x (let’s call it 3x) the performance of the Apple A9 of late 2015.
Apple’s performance trajectory and unquestioned execution over these years is what has made Apple Silicon a reality today. Anybody looking at the absurdness of that graph will realise that there simply was no other choice but for Apple to ditch Intel and x86 in favour of their own in-house microarchitecture – staying par for the course would have meant stagnation and worse consumer products.
Today’s announcements only covered Apple’s laptop-class Apple Silicon, whilst we don’t know the details at time of writing as to what Apple will be presenting, Apple’s enormous power efficiency advantage means that the new chip will be able to offer either vastly increased battery life, and/or, vastly increased performance, compared to the current Intel MacBook line-up.
Apple has claimed that they will completely transition their whole consumer line-up to Apple Silicon within two years, which is an indicator that we’ll be seeing a high-TDP many-core design to power a future Mac Pro. If the company is able to continue on their current performance trajectory, it will look extremely impressive.
The future of the Mac is exciting.
Apple claims the M1 to be the fastest CPU in the world. Given our data on the A14, beating all of Intel’s designs, and just falling short of AMD’s newest 5950X Zen3 – a higher clocked Firestorm above 3GHz, the 50% larger L2 cache, and an unleashed TDP, we can certainly believe Apple and the M1 to be able to achieve that claim.
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.
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:
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.
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.
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:
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.
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.
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?
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?
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.
Everyone has their own expectations when WWDC comes around. Here is what I’d like to see come from Apple and their various platforms.
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:
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.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. 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.
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.
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.
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.
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?
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.
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’.
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)")
}
}Code language: JavaScript (javascript)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)
}
}Code language: JavaScript (javascript)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() })
.textFieldStyle(RoundedBorderTextFieldStyle())
.padding()
}
}Code language: PHP (php)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)")
Divider()
Button("Change") {
self.showNameChange = true
}
}
.sheet(isPresented: $showNameChange) {
NameChangeView(text: self.$name)
}
}
}Code language: PHP (php)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.
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.