|
Catalyst is a hybrid framework stack which provides iOS APIs on macOS. You can build for it directly, but it can also just launch apps built for iOS (only on Apple Silicon Macs, though; there’s no ARM/ARM64 emulator involved). In either case, you’re using the Catalyst framework stack, which shares some but not all dylibs with the “normal” macOS stack (and also changes some behaviors). There aren’t any designed behavior differences between Catalyst and iOS AFAIK, but of course it’s far too complex for that to be possible.
|
#
¿
Jan 15, 2023 23:36
|
|
|
|
| # ¿ May 16, 2024 21:34 |
|
|
It’s not specifically for Facebook, but yes, the idea is to eliminate some of the overhead and surface area of ObjC methods in cases where it’s not needed or wanted. The overhead is, briefly, (1) the binary-size cost of selectors and method table entries, (2) the load-time execution cost of eagerly uniquing selectors, (3) the call-time execution cost of message send, and (4) the call-time memory cost of keeping methods in method caches. The surface area impact is that normal ObjC methods are overridable and swizzleable, which can create accidental binary-compatibility headaches (and, admittedly, also allow clients to work around bugs) and potentially even introduce security problems.
|
|
#
¿
Apr 19, 2023 18:37
|
|
|
Think of it as two levels of hierarchy. Each view has a local hierarchy of views, which is described by the value of the body property. That’s the level at which changes to State are tracked: if State changes, body is re-read, and the new value is compared to the last one to see how the local hierarchy changes. The same thing happens separately for any child views (assuming they survive the changes above them in the hierarchy). But that’s the granularity that happens at, and in general there’s no machinery for figuring out that, like, only one portion of the body getter uses a particular piece of state and so the rest of the body doesn’t change. If that’s an important optimization for you, you should split out that portion of the body as its own view (or alternatively, the portions you specifically don’t want to re-run so often) so that the tracking there will naturally be more targeted.
|
|
#
¿
Sep 19, 2023 00:01
|
|
|
The great thing about Swift/C++ interop is that a ton of Swift APIs can be exposed to C++ automatically and for free: the C++ header directly declares the public ABI of the Swift module, then wraps as much of it as currently possible in idiomatic C++. That approach doesn’t work for C or ObjC because of the limitations of those languages: APIs have to fit into what the languages can express, and it has to be opt-in because the compiler has to generate new symbols for the C/ObjC compiler to call. Exporting to ObjC at least has a little bit of power because the ObjC object model is mostly compatible with Swift, but exporting to C would be so limited. It’s something we’ve talked about a little, but it’s hard to build momentum behind doing work there. Instead of “converting” to ObjC, I’d suggest incrementally converting a few files to C++. That will require some headers to use extern “C” properly, but that’s probably a lot less work (and very mechanical) than trying to force everything through an ObjC-style API if it doesn’t look like that now.
|
|
#
¿
Jan 15, 2024 06:22
|
|