Archive for December 10, 2020

Thursday, December 10, 2020 [Tweets] [Favorites]

Upgrading From an iPhone XR to an iPhone 12 mini

The good:

The bad:

Previously:

Rewriting the Uber App in Swift

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:

Making TextEdit Create an Untitled Document at Launch

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: