The room summary provider subscription only delivers its current state through an
async main queue hop, which can end up queued behind the first render. On a warm
launch, where the cached rooms have already been published before the home screen
exists, that leaves the skeletons up for the whole duration.
Read the current state at the end of init instead, alongside the rooms which were
already being read there.
The room summary provider publishes its loading state and its rooms through two
independent streams, so the state can report loaded before the first summaries
have been applied. Flipping the room list mode to .rooms at that point renders
an empty list until the summaries arrive.
Combine the two publishers into a single subscription so that the mode and the
rooms are always updated from the same pair of values, and keep the skeletons up
until the rooms have published. Only the initial transition is held back, an
empty list later on is a filter or a search result and must not send the mode
back to the skeletons.
* Fix an issue with macro compilation when using Xcode previews.
* Update the Chats/Spaces toolbars to match the Figma.
Fixes a bug with the status emoji in the liquid glass button.
- Resolve the send handle at tap time and pass it through the alert,
removing the duplicated lookup and the stale-itemID window between
tapping the indicator and pressing Retry.
- Route 'Remove message' through the existing timeline item menu redact
action instead of a bespoke redact path with a fatalError.
- Surface a retry failure to the user with an indicator toast rather
than only logging it.
- Only set the send-info accessibility identifier when the label has a
tappable status, so plain timestamps don't create ambiguous matches.
Tapping the red (!) on a message that failed to send used to show a bare
"Sending failed" alert with only an OK button. Now the alert includes the
failure reason from the SDK (e.g. the HTTP error that caused it) and offers
Retry sending, Remove message and Cancel actions, wired to the send handle's
resend and to redacting the local echo respectively.
- Room heroes weren't being updated when their status changed.
- A user's own profile would go missing after removing their avatar (or setting any field to null).
The suite intermittently hung on CI, most recently for the full 2 minute time
limit on lifetimeIsCapped(). A spindump from a failed run shows the process
suspended rather than spinning (0.247s of CPU over 190s) with a background
priority worker thread sitting runnable for roughly 145 seconds without ever
being scheduled.
That band is exactly what swift-clocks' TestClock depends on to make progress:
both advance() and checkSuspension() await Task.megaYield(), which serially
awaits 20 detached tasks at background priority. On an oversubscribed runner
those never run, so the test waits forever instead of failing. The same
mechanism, less starved, is why two of the passing tests took 1.0s and 0.77s
for what is otherwise pure logic. checkSuspension() made it worse, since
asking whether a timer was armed cost a megaYield per poll.
ManualClock replaces it. It holds a single pending sleep, since that is all a
test needs to step through: the sleep registers a continuation, advance(by:)
resumes it synchronously once its deadline passes, and waitForScheduledSleep()
suspends until the timer is armed instead of polling for it. Nothing in the
path touches background priority and no loop's iteration count depends on the
scheduler. The suite now runs in 0.019s, and under a locally saturated CPU the
old version took 1.005s against the new one's 0.037s.
Also drops the now unused Clocks package, removes the 2 minute time limit that
was papering over the starvation, re-enables callIsTimingOut() which the same
flakiness had disabled, and has lifetimeIsCapped() assert the 90 second cap
directly rather than inferring it from when the timer fires.
The home screen's filter observation fires on every view state change, so setFilter was repeatedly pushing the same filter down into the SDK. Cache the last applied filter and skip the SDK call when it hasn't changed.
Continue grouping the standalone modules under Components. The MapLibre
frameworks were nested inside the app folder even though they are separate
targets, so move them alongside the other components and update the
XcodeGen includes.
Continue grouping the standalone modules under Components. Updates the
preview asset paths and the media resource references in the app and unit
test targets.
Continue grouping the standalone modules under Components. Updates the
Secrets.swift references in the app, NSE and Share Extension targets along
with the SwiftLint, SwiftFormat, gitignore, post-checkout hook and forking
documentation paths.
Continue grouping the standalone modules under Components. Updates the
nightly.yml include path and the app icon banner path used by the
configure-nightly CI command.
Group the standalone modules that live outside of the app targets under a
single Components folder. Updates the XcodeGen include, the Codecov ignore
path and the Sourcery output path used by the generate-sdk-mocks tool.
* Update Project Dependencies
* Run XcodeGen, update Package.resolved and Settings.bundle
* Run XcodeGen, update Package.resolved and Settings.bundle
* Opt out of PostHog's ridiculous new notification tracking.
Shouldn't be necessary given we have swizzling disabled, but just to be safe.
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Element CI <ci@element.io>
Co-authored-by: Doug <douglase@element.io>
The shim is embedded but not linked, so nothing at build time proves it is
still there. If it stops being copied into the bundle, or the class is renamed,
dlopen simply fails at runtime and the user gets a blank map behind an error
alert. Nothing in CI would notice.
The test asserts the framework loads and the shim resolves, which is exactly
the pair that breaks if either side of the arrangement is disturbed.
MapLibre ships as a dynamic framework, so being named in the app's load
commands means dyld loads it before main runs on every launch: 7.3 MB paged in,
133 C++ static initialisers run and its classes registered, all for a map that
only appears once a location screen is opened.
Measured on an iPhone 17 Pro with two otherwise identical probe apps launched
alternately, linking MapLibre takes pre-main from 11.1 ms to 23.2 ms, and on a
cold launch from 32.9 ms to 60.7 ms. Loading it on demand brings pre-main back
to the 11.1 ms baseline and moves the roughly 11 ms it costs to dlopen to the
moment the map first appears.
MapLibreShim is now embedded but not linked, and the app resolves the shim
through the ObjC runtime after dlopen-ing it. MapLibre stays in the bundle as
an embed-only framework reference so the shim's load command can resolve
against it, expressed as an implicit framework because xcodegen can't describe
embed-without-link for a package product.
Timeline location messages already use the static tile view, which never
touched MapLibre, so the shim only loads for interactive maps.
Second step towards loading MapLibre on demand: everything that touches it now
lives in one framework, so that framework can later be left unlinked.
The interactive map view, its annotation view and the coordinate animator move
into MapLibreShim, which reaches the app through MapLibreShimProtocol. The app
side keeps its MapLibreMapView call site and becomes a thin wrapper that builds
a MapViewConfiguration, passing the app-only pieces (map style URLs, marker
views, tint colour) across as closures so the shim needs nothing from the app.
LocationAnnotation loses its MapLibre conformance and becomes a plain struct,
with the shim mapping it onto its own annotation type. MapLibre's log
forwarding moves into the shim as well, since TargetConfiguration can no longer
reach it.
Stefan Ceriu
Doug
Element CI
Doug
Matthew Hodgson
ElementRobot
renovate[bot]