Archive for February 8, 2023

Wednesday, February 8, 2023

Swift Proposal: Custom Reflection Metadata

SE-0385 (discussion):

In Swift, declarations are annotated with attributes to opt into both built-in language features (e.g. @available) and library functionality (e.g. @RegexComponentBuilder). This proposal introduces the ability to attach library-defined reflection metadata to declarations using custom attributes, which can then be queried by the library to opt client code into library functionality.

[…]

Registering code to be discovered by a framework is a common pattern across Swift programs. For example, a program that uses a plugin architecture commonly uses a protocol for the interface of the plugin, which is then implemented on concrete types in clients. This pattern imposes error-prone registration boilerplate, where clients must explicitly supply a list of concrete plugin types or explicitly register individual plugin types to be used by the framework before the framework needs them.

[…]

To support advanced schema customization, the [Realm] property wrapper could store a string that provides a custom name for the underlying database column, specified in the attribute arguments, e.g. @Persisted(named: "CustomName"). However, storing this metadata in the property wrapper requires additional storage for each instance of the containing type, even though the metadata value is fixed for the declaration the property wrapper is attached to. In addition to higher memory overload, the metadata values are evaluated eagerly, and for each instantiation of the containing type, rendering property-wrapper instance metadata too expensive for this use case.

Git Tower 9.2

Tower:

Working Copy and Branches Review: On macOS 13, the width of the middle pane in the Working Copy and Branches Review sections always reset themselves to the default after leaving the view.

This has been annoying me every day since Ventura was released—glad to see it fixed.

Previously:

New WWDR Intermediate Certificate and Receipt Verification

Apple:

Starting January 18, 2023, the App Store receipt signing certificate will use a new WWDR intermediate certificate. The existing intermediate certificate expires on February 7, 2023. In most cases, this certificate change won’t require changes to apps. However, we recommend reviewing how you verify the sale of your apps and in-app purchases from the App Store to make sure your apps aren’t impacted.

James Thomson:

Confirmed - my Mac TestFlight build receipts are still being signed with the Apple certificate that expired yesterday.

Sören:

Certificates are such a fun show case of “can a corporate bureaucracy handle something that happens every few years and few people have access to” (the answer may surprise you).

Ivory:

Some of you with active subscriptions have reported issues with the app thinking you aren’t subscribed or unable to “Restore Purchases” on another family device. This is because Apple is currently having some issues with Receipt Verification. We will try to fix this temporarily on our end until Apple sorts the issue out.

Previously:

Update (2023-02-13): Rich Trouton:

Mac admins who have previously installed macOS apps from the Mac App Store (MAS) or the Volume Purchase Program (VPP) may be seeing some of those apps displaying warning messages on launch that the application is damaged.

James Thomson:

And that’s Dice on Mac rejected for crashing at startup because receipt validation is failing.

So, it seems like they’ve fixed the receipt certs for TestFlight, but not yet in the App Review testing setup.

This is tedious.

Matthias Gansrigler:

PSA: If you’ve recently seen “this app is damaged” or “sign in to the App Store” dialog on your Mac, the following link might explain why[…]

The Evolution of Facebook’s iOS App Architecture

Dustin Shahidehpour:

After years of iteration, the Facebook codebase does not resemble a typical iOS codebase:

  • It’s full of C++, Objective-C(++), and Swift.
  • It has dozens of dynamically loaded libraries (dylibs), and so many classes that they can’t be loaded into Xcode at once.
  • There is almost zero raw usage of Apple’s SDK — everything has been wrapped or replaced by an in-house abstraction.
  • The app makes heavy use of code generation, spurred by Buck, our custom build system.
  • Without heavy caching from our build system, engineers would have to spend an entire workday waiting for the app to build.

[…]

The dylib solution worked beautifully. FBiOS was able to curb the unbounded growth of the app’s startup time. As the years went by, most code would end up in a dylib so that startup performance stayed fast and was unaffected by the constant fluctuation of added or removed products in the app.

The addition of dylibs triggered a mental shift in the way Meta’s product engineers wrote code. With the addition of dylibs, runtime APIs like NSClassFromString() risked runtime failures because the required class lived in unloaded dylibs. Since many of the FBiOS core abstractions were built on iterating through all the classes in memory, FBiOS had to rethink how many of its core systems worked.

[…]

With the new Buck-powered plugin system. FBiOS was able to replace most runtime failures with build-time warnings by migrating bits of infra to a plugin-based architecture.

[…]

Ultimately, the FBiOS team began to advise that product-facing APIs/code should not contain C++ so that we could freely use Swift and future Swift APIs from Apple. Using plugins, FBiOS could abstract away C++ implementations so that they still powered the app but were hidden from most engineers.

Louis Gerbarg:

I am to say the exact same thing I said to to them when they asked me about some of these choices:

They are large developer with dedicated QA and perf who releases dozens of app updates a year for a network service that can force uses to upgrade.

Which means a number of potentially labor intensive or high risk optimizations are appropriate for them because if they become an issue later they will notice them early and have the ability to undo them.

Having said that, the more elaborate these things are and the less like other apps built with the normal tools are the less likely the future optimizations we are building will improve your apps perf. We knew were doing dyld3 and page in linking years before we shipped them.

And the advice we were giving people on how to structure their apps was to set them up to work well in that future environment we were not ready to discuss.

Eric Schwarz:

The post gets into a bit of technical details that are fascinating, but the tone strikes me as weird. While it’s great to celebrate milestones, it seems a little odd to be happy about layers of legacy code and nonstandard, custom choices that lead to a 300MB app that does most of the same things as a web page.

Big cross-platform apps still seem like an unsolved problem. No one wants to write multiple native versions of the same app, so we either get wrappers and in-house abstractions or something like Electron. I guess Microsoft Office probably does it the best. It’s strange to think about this because intuitively it seems like Office does a lot more than the Facebook app, but (as far as I know) Microsoft hasn’t had to go to these lengths.

John Gruber:

As Eric Vitiello commented on Mastodon regarding this post, if we assume “thousands of engineers” means just 2,000, that means a new engineer has started adding code to Facebook’s iOS app every two days, nonstop, for a decade. It’s closer to one new engineer every day if we count only weekdays.

Previously:

Update (2023-02-13): Nick Heer:

I am sure there are valid reasons for Meta to treat these applications [Facebook (blue) and Facebook Messenger] differently, but reading these posts back to back sound like they are from two completely different companies.

Copyright © 2000–2024 Michael Tsai.