Archive for November 2, 2019

Saturday, November 2, 2019

Efficiently Mutating Nested Swift Data Structures

Radek Pietruszewski:

That feel when you’re profiling a React Native app, and you’re sure JavaScript is the source of your problems… but no, it’s ridiculously misoptimized Swift doing… well… nothing much for two minutes.

[…]

Code does something that seems completely reasonable, but ends up creating a new copy of a large Set 10,000s times. Not entirely sure if Swift is supposed to be smart enough to figure out that it can safely mutate it, or it’s programmer’s responsibility.

The intention is to insert to a Set that’s in a Dictionary that’s a mutable variable on a class

Joe Groff:

Older versions could not modify values in dictionaries without copying them, but 5.0 and later should be able to.

Karoy Lorentey:

Yep, Array & Dictionary both support in-place mutations. For Dictionary, the recommended way is to use the defaulting subscript. E.g., this won’t make a CoW copy:

sets[key, default: Set()].insert(foo)

But this will:

var tmp = sets[key]
tmp.insert(foo)
sets[key] = tmp

The Dictionary.Values collection also supports this, and it may come handy if you need to distinguish between existing and new keys:

if let i = sets.index(forKey: key) {
  sets.values[i].insert(foo)
} else {
  fatalError("Unknown key \(key)")
}

I’ve written about this before, but I think it’s worth re-emphasizing how this works. It’s counterintuitive and unusual in programming for introducing a temporary variable, as people often do when debugging, to radically change the behavior of the code. Copy-on-write is a leaky abstraction.

Previously:

Update (2019-11-02): See also: Karoy Lorentey.

Preparing to Migrate From Aperture to Photos.app

John Gordon:

I’ll still be on Aperture into 2020, three years beyond my original plan. The Catalina catastrophe has made staying on Mojave more agreeable. I’ll have to switch sooner or later though, almost certainly by 2021. So I’m working on a list of what I need to do prepare. I’ll update this post with items I think about[…]

Previously:

Xcode 11.2 and XIBs With UITextView

Juri Pakaste:

Xcode 11.2: NSInvalidUnarchiveOperationException. Oh boy.

Nikita Zhuk:

Xcode 11.2 seems to cause havoc if you have XIBs which contain UITextViews. Beware!

Marcin Krzyzanowski:

This is really bad year for devtools at Apple

Peter Steinberger:

One more reason not to use Interface Builder.

Randy Reddig:

DEAD_CODE_STRIPPING = NO seems to fix it for the moment.

Previously:

Update (2019-11-05): Thomas Ricouard:

Xcode 11.2 retail fail to decode UITextView from Xib/Storyboard on any iOS lower than iOS 13.2.

Marc Palmer:

PSA: do not submit builds with Xcode 11.2 or you will have huge numbers of crashes on iOS releases older than 13.2. We luckily just hit this in our CI rather than in production.

XcodeReleases (9To5Mac):

#Xcode11.2.1 GM Seed is out!

[…]

To be clear, the UITextView issue is fixed for iOS and tvOS. It’s still an issue on macOS.

Update (2019-11-07): Paul Haddad:

Cool, deprecate the current version without releasing the new version to the App Store…

Update (2019-11-26): drunknbass:

Looks like Xcode 11.2 changes the way UIAlertControllers present on iPad. Now they are popovers. Popovers require additional APIs

Hope you have tests 🥶

Ivano Di Gese:

Quite simple: due to this known issue, this Xcode version is simply considered banned from Apple, so that you can’t distribute apps compiled with this setup.

Steve Troughton-Smith:

Where is the Xcode update on the Mac App Store? Seriously Apple, it's been a whole week since you banned store submissions from the MAS version of Xcode. How is this OK?

Luc Vandal:

The UITextView bug caused by Xcode 11.2 still seems to occur with Xcode 11.2.1 for users still on iOS 13.1.x.

Update (2019-11-27): Raphael Sebbe:

Seeing stalls (minutes long), and random Xcode crashes while doing nothing (background, not building).

Started with Xcode 11.2 and 11.2.1, occurs a few times per day. Was fine before.

Copyright © 2000–2024 Michael Tsai.