The good:
Overall, this is my favorite iPhone in a long time, and possibly ever. Design is about tradeoffs, and this particular phone is well balanced for my needs.
It feels great in my hand and in my pocket. I can once again hold it securely without a case.
Coming from an iPhone XR, which is physically much larger and also has Max resolution, I had been worried that the screen would feel too small. In practice, this has not been a problem. It feels much roomier than an iPhone SE (either model), perhaps because of the extra height from removing the forehead and chin.
Typing is also fine. It only took a few days to adjust to the much smaller keyboard.
The camera is way better, especially in low light.
The ultrawide lens is much more useful than I expected. I’ve gotten a lot of shots, especially indoors, that would not have been possible before because of walls or other obstacles blocking my feet.
The new Prioritize Faster Shooting option really helps.
Overall, it feels fast, especially booting and the camera. Some areas like share sheets and Siri still feel impossibly slow.
The blue color and pretty much everything about the physical design is great. I just wish the sides were a little more grippy.
The bad:
I don’t like the OLED display. I’m not running into the accessibility issues that some are, but I just don’t like the way text looks. Black and gray text has a colored halo reminiscent of ClearType, which I never saw on iPhones with LCD displays.
Despite Ceramic Shield, never dropping the phone, and only carrying it in an empty pocket, there are already two scratches—deep enough to feel—near the center of the display. The same thing happened with my iPhone XR, though my older iPhone displays remained essentially perfect for years.
Charging with the display on is much slower and doesn’t make progress at all with a regular speed power source, e.g. the USB hub I had been using, even when using Lightning rather than Qi. After multiple full workdays where it never got above 80% while plugged in, I contacted Apple’s support, who tested the phone and found it normal. After upgrading my chargers, the problem is “solved,” but charging still seems slower than with any previous iPhone.
Several times, with two separate chargers, Qi charging stopped working entirely until I rebooted the phone. I didn’t realize it wasn’t charging until I saw the red from Low Power Mode kicking in.
One-handed use is not as easy as I remember with previous iPhones, perhaps because with the taller screen I have to reach so much farther with my thumb.
Face ID still feels slower than Touch ID and doesn’t work with a mask.
Back Tap is hard to invoke and doesn’t offer many options.
I have yet to be able to make a local backup on my Mac. This is probably a Catalina issue rather than a problem with the phone. The interface makes it impossible to enter a password, and even an unencrypted backup never completes.
The battery life is only OK. With the iPhone XR, I never had to think about it. Now, I have to be mindful of charging and bring an external battery on longer excursions when I will be using the GPS and camera a lot. It remains to be seen how the battery will degrade over the next two years.
Previously:
Battery Life Camera COVID-19 Face ID iOS iOS 14 iPhone iPhone 12 iPhone 12 mini
McLaren Stanley (via Steve Troughton-Smith):
The reason the Uber app is that large [331 MB] is because of Swift. The Objective-C version was a third of that size.
[…]
Library bundling is not the problem (swift system libraries are only a few MBs per slice). It’s the actual machine code growth rate of user code that’s the issue. Practically speaking Swift can be as much as 2-4x larger than the equivalent Objective-C when compiled.
[…]
We almost rewrote everything back in Objective-C. If not for the limit increase [in the cellular download limit] we probably would have.
Staying under the limit is really important, and they did rewrite the watchOS app back into Objective-C. Why is the app so large? Because there’s a lot more to it than first appears. On the other hand, the Android version of the app is much smaller.
nobunaga:
Problem here with Swift came down to
- Apple not dogfooding its own tech. Hell they did not even help us or other major companies like AirBnB and LinkedIn (We formed a workforce on this problem with them which then forced the download limit to be upped by apple)
- Engineers deciding to adopt a language which they thought was great (and turned out not to be at the time) because they did not do the right analysis upfront for such a significant project. ‘Wow look at this shiny new cool tool, lets use it’ (Oversimplification, swift was more pleasant to write with and you could be more productive which was no doubt a factor here)
McLaren Stanley (Hacker News):
As a consequence of all these problems, there began to be a growing movement across all levels of the org that was rallying around the idea of “rewriting the app from scratch” The general sentiment was that the architecture was slowing us down, starting over would be faster.
[…]
On the iOS side of the world, the rewrite presented an opportunity to adopt Swift (which was in version 2.x during this timespan). Uber had tried Swift before, but like many who had adopted it that early on it was extremely problematic so it had been banned prior to the rewrite.
[…]
So this smaller core team of Design, Product, and Architecture went off in a room for with their new functional/reactive patterns, new language, and new app for a few months. Everything went well. The architecture relied heavily on the advanced language features of Swift.
[…]
But once Swift started to scale past ten engineers the wheels started coming off. The Swift compiler is still much slower than Objective-C to then but back then it was practically unusable. Build times went though the roof. Typeahead/debugging stopped working entirely.
There’s a video somewhere in one of our talks of an Uber engineer typing a single line statement in Xcode and then waiting 45 seconds for the letter to appear in the editor slowly, one-by-one.
Then we hit a wall with the dynamic linker. At the time you could only link Swift libraries dynamically. Unfortunately the linker executed in polynomial time so Apple’s recommend maximum number of libraries in a single binary was 6. We had 92 and counting.
[…]
We quickly discovered that putting all of our code in the main executable solved the linking problem at App start up. But as we all know, Swift conflates namespacing with frameworks; so to do so would take a huge code change involving countless namespace checks.
[…]
We also replaced all of our Swift structs with classes. Value types in general have a ton of overhead due to object flattening and the extra machine code needed for the copy behavior and auto-initializers etc.
[…]
So said brilliant engineer in Amsterdam, built an annealing algorithm in the release build to reorder the optimization passes in such a way to as minimize size. This shaved a whooping 11 mbs off the total machine code size and bought us enough runway to keep development going.
[…]
A bunch of folks burned out along the way. A ton of money was spent, hard lessons were learned, but still to this day most people insist the rewrite was all worth it. New engineers who joined up loved the architectural consistency and never knew the pain it took to get there.
There’s also this interesting bit on location data:
Without manual pickup location entry people’s location would just show up as whatever the GPS location was last received. This can be very inaccurate (especially in cities with tall buildings) and drivers would end up on the wrong block. This was a horrible customer experience.
So to improve location pickup we changed the location permission to collect signal in the background so we could send the drivers to your current location. People freaked out. Some of my ex-Twitter colleges called on me to quit such an evil company that would track you like this.
As a result of said freakout, (there’s a whole other thread about this involving
@gruber
and
@TechCrunch
that I’ll explain some other time) people turned off location permission. But the new app hadn’t designed any experience to handle this use case.
Previously:
Update (2020-12-16): Indragie Karunaratne:
A tradeoff less discussed is in hiring: not long after Swift came out, the majority FB’s pipeline of iOS candidates wanted to write Swift in their interviews, and wanted to join a team where they could write Swift.
We had to figure out nice ways to tell them that they probably weren’t gonna end up writing Swift.
[…]
FB had already been struggling with binary size and build times long before Swift came out with their Objective-C++ codebase; it was a practical impossibility to adopt it, and probably still is even now, at least in the larger app codebases (FB, Messenger, etc.)
Previously:
Compiler dyld GPS Hiring History iOS iOS 8 iOS 9 iOS App Objective-C Optimization Programming ReactiveCocoa Software Rewrite Swift Programming Language Uber
Matt Christensen:
I use Text Edit all the time for ephemeral notes. I’ve never liked how in recent macOS versions you get a file picker instead of a blank document.
No more!
defaults write com.apple.TextEdit NSShowAppCentricOpenPanelInsteadOfUntitledFile -bool false
Alternatively, you can uncheck System Preferences ‣ Apple ID ‣ iCloud ‣ iCloud Drive ‣ Documents ‣ TextEdit. I like to do that so that I don’t accidentally save files to iCloud. When TextEdit knows that it will never be saving anything in iCloud, it won’t prompt you at launch. Note that it can be hard to find TextEdit in this list since it isn’t sorted alphabetically.
Previously:
Esoteric Preferences iCloud Drive Mac macOS 11.0 Big Sur TextEdit
