What's New

After several feature-heavy sprints, this one was deliberately about hardening - the same kind of dedicated stability pass as α 0.12, now that the surface area is far larger. No new headline feature; just making everything already built more reliable, more consistent, and more honest under bad conditions.

#Offline resilience

Library snapshot - The app keeps a local snapshot of your library so opening it offline shows your albums and recent media immediately, rather than a spinner waiting on a network that isn't there.

Graceful degradation across screens - A sweep of the main screens replaced "blank or broken when offline" with calm, explanatory states. Knowing why something is empty - "you're offline" versus "nothing here yet" - is the difference between a bug and a considered experience.

#Race-condition hardening

A focused audit of the app's optimistic writes - the places where the UI updates instantly before the server confirms (favourites, hearts, invites). The core primitives held up well, but several optimistic paths lacked a per-item in-flight guard, so a fast double-tap could fire two competing writes. Those paths now use the same guarded pattern, so the screen and the server can't disagree.

#One consistent notification surface

Every toast and snackbar in the app now renders through a single shared surface with the same frosted-glass chrome as the live-event activity toast - dropping in from the top, tinted by meaning (green for success, red for error, amber for warning), and sliding out gracefully instead of popping. Previously these were a patchwork of styles. Now a confirmation, an error, and a "Maya added a photo" all feel like the same product speaking with one voice.

#Measuring what matters

Analytics instrumentation was put on a proper footing this sprint, with a clear separation of concerns:

• The database remains the source of truth for anything that affects billing, usage, or limits - never an analytics tool.
• Behavioural funnels (activation, upgrades, credit-pack purchases) flow to a product-analytics layer keyed only by an anonymous user ID - never email, never media, never invite links or PINs.
• Errors continue to flow to crash reporting.

The privacy line is firm: nothing about what you share - no media, no filenames, no tokens - ever leaves for analytics. Only how the product is used, so it can be made better.

#Where things stand

Alpha continues. The product is broad and increasingly solid, and the work now is less about adding and more about deepening - making each existing feature feel inevitable. More to come.

The slideshow engine (α 0.5) has shown one photo at a time since day one. This sprint taught it to compose - and made sure it looks identical no matter what screen it's playing on.

#Smart Layout

Multi-photo mosaics - Smart Layout shows two to four photos at once, packed by orientation: a tall portrait beside a stack of landscapes, a balanced quad, a pair of verticals as columns. It advances group-by-group instead of photo-by-photo, so a wall of memories breathes the way a real photo collage does.

It's aspect-aware, not a fixed template - The planner scores candidate arrangements against the actual shape of the frame and picks the largest group whose worst-cropped photo still shows enough to be worth showing. Portraits tile as columns; a frame-filling 16:9 shot plays solo rather than getting butchered to fit a grid. Videos always play full-screen on their own.

Tunable per frame - Turn it on per frame and set the maximum photos per group (2-4). Off by default; the classic one-at-a-time slideshow is unchanged.

#Casting parity

This was the harder half. LumiFrame plays on this device, on remote LumiFrame devices, and cast to Chromecast, AirPlay, and Smart TVs - and Smart Layout had to look right on all of them.

Mosaics on third-party receivers - A Chromecast can't run our layout engine, so each mosaic group is composed into a single 1920×1080 image on the device and served to the receiver as one frame. The receiver just plays a slideshow; the intelligence happens before it gets there.

AirPlay advance, rebuilt - AirPlay timing was a long-standing source of drift - the app's timer and the receiver's player ran on independent clocks, causing index desync and prematurely-skipped videos. The receiver is now the source of truth for slide timing: it reports each advance, and the app realigns to it. The app-side timer was demoted to a stall watchdog that only steps in if the receiver queue dries up.

#Honest limitations

A couple of rough edges are documented rather than hidden:

• On AirPlay, a mosaic currently lingers a little longer than a single slide would, because AirPlay advances per-photo while a mosaic represents several. The image is correct; the cadence isn't perfect yet. A group-aware fix is on the list.
• Smart Layout looks best on photos that carry their dimensions in metadata (on-device photos do) - cloud photos missing that data are measured on the fly and the layout settles a beat later, gliding rather than snapping into place.

Calling these out is the point. They're real, they're known, and they're tracked.

Live events turned out to be the feature people got most excited about - which raised a real question. Hosting an event has a real cost (storage, delivery, moderation), and "unlimited everything" isn't honest for a product that intends to last. This sprint built a usage model that's fair, transparent, and impossible to fudge.

Current note: exact allowances, credit pack contents, and pricing live on /pricing and evolve over time. This entry describes the mechanism, not the numbers.

#What shipped

Event credits - Paid tiers include a monthly allowance of events. Need more than your plan includes in a given month? Buy a credit pack. Credits are consumed when an event is created, and your remaining allowance is always visible before you start one - no surprise mid-event wall.

Allowance, at a glance - A summary card shows where you stand: events used this month, events remaining, and any purchased credits on top. The number you see is the number the server will enforce - they're the same source.

Concurrency limits - Plans cap how many events can run at once, separate from the monthly count. The app distinguishes "you've hit your monthly limit" from "you already have an event running" and says which - because they call for completely different actions.

#Server-authoritative by design

The cardinal rule established this sprint: the client never counts. Every allowance, every credit balance, and every limit is owned by the server.

• Event creation goes through a single atomic database function that checks the allowance, decrements the credit ledger, and creates the session in one transaction - so two devices can't both spend the last credit.
• Purchases are reconciled through the store's server-to-server webhook, not a client receipt the app could be tricked into trusting.
• The app's job is to display the state and explain it clearly. It is never the source of truth for anything you pay for.

#Why it's built this way

Billing logic that lives in the client is billing logic that can be bypassed. Putting the ledger, the limits, and the purchase reconciliation entirely server-side means the rules are the same for everyone and can't be gamed - which is the only way a usage model stays fair over time.

The biggest friction in any shared event is the ask: "download this app first." This sprint removed it. Guests at a LumiFrame event can now join, view, and upload entirely from a web browser - no install, no account.

#What shipped

The /share event page - Every event generates a guest link (and the QR code that encodes it). Open it on any phone and you land on a live event page on lumiframeapp.com: the event's hero, a countdown to when the window closes, and the gallery.

Guest join with just a name - A guest enters a display name and they're in - that's the entire gate. They can optionally pick an avatar. No sign-up wall stands between a guest and contributing to the night.

Browser uploads - Guests add photos and videos straight from the web page. Everything they upload flows through the same moderation gate (α 0.23) and the same R2 media pipeline as in-app uploads - a guest on the web isn't a second-class, unchecked path.

The live experience, on the web - The web gallery isn't a static snapshot. It polls for new activity and grows as the event happens - the same photos appearing on the host's frame appear in the guest's browser, with a live activity strip showing who just contributed and a countdown that genuinely ticks down.

#Why this matters

An event album is only as good as the photos it collects, and you collect the most when contributing is effortless. The web path means the cousin who'll never install another app, the friend on Android at an iPhone-heavy party, and the guest whose phone is nearly full can all still add their shot of the moment. The host gets a fuller story of the event; the guest does almost nothing.

#Under the hood

The share site is a statically-exported web client that talks to the same Supabase backend and edge functions the app uses, so an event behaves identically whether you're looking at it through the app or a browser tab. Guest identity is scoped to the event - a guest name lets you contribute to that event, and nothing else.

Next: with events driving real usage, it was time to make the economics of hosting them clear and fair.

Event albums shipped quietly back in α 0.18b - a time-limited album with a QR code for guests. They worked, but they were static: a place photos landed. This sprint turned them into something that feels alive while the event is happening.

#What shipped

Live activity toasts - While an event is running, the host and contributors see gentle toasts drop in from the top of the screen as photos arrive: "Maya added 3 photos." Tap one and it opens straight to what was just shared. It makes a party across the room feel present in your hand.

A growing live grid - The event album fills in real time. No pull-to-refresh - photos appear as guests upload them, with a soft arrival animation, so an event dashboard left open on a frame becomes a live mosaic of the night.

Event recap - When the window closes, the event doesn't just stop. A recap is generated - the highlights from everyone who contributed - so the morning after, there's something to look back on rather than a folder to sift through.

The "Live Event" border - Event albums are now unmistakable at a glance. Instead of a cluttered corner badge, a live album gets an accent border framing its cover with a label that breaks the top edge - ── LIVE EVENT ── in green while it's running, amber while the upload window is still open, slate once it's ended. During an active event, the card hides its other badges so the frame owns the card.

#Design decisions worth noting

The toast is contextual, not global. It only appears in the handful of places a live event is actually relevant - the album, the event dashboard, and the slideshow - rather than firing at you in Settings or an unrelated album. The slideshow stays in sync too: a photo a guest uploads can appear in the running show within seconds.

Safeguards against noise. A burst of uploads doesn't mean a burst of toasts. Per-contributor accumulation windows, cooldowns, and a global rolling rate cap keep the experience celebratory rather than spammy - the same restraint applied to push notifications back in α 0.7.

#What's next

Everything here lives inside the app. But the people at an event are holding their phones, not yours - and most of them don't have LumiFrame installed. The next sprint takes the live event experience to the open web.

The moment you let people post text - and especially the moment you let guests without an account upload to an event album - you've taken on a responsibility. This sprint built the moderation and abuse-prevention layer so that LumiFrame can host conversations safely by default, not as an afterthought.

#Automated moderation

OpenAI moderation on every comment - Every comment is screened by OpenAI's moderation model before it's ever visible to anyone else. Hate, harassment, sexual content, and violence are caught automatically.

Fail-closed, not fail-open - This was the most important design decision of the sprint. If the moderation provider is configured but unreachable or erroring, a comment is held for review - never silently published. The safe default when the safety system is degraded is don't show it, not show it and hope.

Review queue - Held and rejected comments don't disappear into the void. They land in a moderation review queue that an administrator can list, approve, or dismiss. Nothing is lost, and a false positive can be released.

#Writes you can trust

Edge-function-only writes - Comments can no longer be written directly to the database from the client. Every comment post and edit routes through a dedicated edge function that runs moderation first. Direct database insert and update on the comments table were revoked entirely - there's no path that skips the check, including edits.

Rate limiting - Per-user write limits (a burst cap per minute and a ceiling per hour) are enforced server-side via a write-attempt ledger. Hitting the limit returns a clean "slow down" rather than letting a script flood an album.

GIF source restriction - The GIF picker only accepts URLs from a single trusted provider, and the picker itself requests a PG-13 content rating. There's no field for pasting an arbitrary image URL.

Idempotent posting - Each comment carries a request ID scoped to its author, so a retry on a flaky connection resolves to the one real comment instead of creating duplicates.

#Why build this now, not later

Moderation is the kind of system that's nearly impossible to retrofit safely once content is already flowing and write paths are scattered across the codebase. Building it before opening events to the public web (next sprint) means every guest upload and comment goes through the same gate from the very first one.

Appreciation reactions (α 0.17) hinted at it; the relational backend (α 0.21) made it possible. This sprint built the full engagement layer - the conversations and reactions that turn a shared album from a folder into a place people come back to.

#What shipped

Comments on memories - Any contributor can comment on a photo or video in a shared album. Threads are lightweight and inline - a quick "this is my favourite from the whole trip", not a forum. Comments support text and a GIF picker.

Reactions and hearts - Beyond the quiet Appreciation, members can react to a memory with a heart. Reaction counts are visible to the people in the album, surfacing which moments resonated without turning it into a popularity contest.

The Activity Feed - A single chronological feed of everything happening across your albums: new photos added, comments posted, reactions given, new people joining. It's the answer to "what did I miss?" - open the app, see what moved since you last looked.

Notifications feed - Notifications are no longer fire-and-forget pushes that vanish. They now persist into an in-app feed you can scroll back through, mark as read, and act on, so a missed push is never a lost event.

#Under the hood

Engagement data lives in proper Postgres tables - activity_comments, reactions, and an engagement repository the app reads through a single native path. Because everything is relational now, the Activity Feed is one indexed query rather than the fan-out it would have been on the old document model.

Every write is guarded by Row-Level Security: you can only comment in albums you belong to, and you can only edit or delete your own comments.

#What this sets up

Opening comments to a household raises an obvious question: what happens when something inappropriate gets posted - especially in event albums where guests upload without an account? That's the entire focus of the next sprint.

With the website live and the alpha feature set broad, this sprint paid down the biggest piece of architectural debt before layering on real-time social features: the backend moved from Firebase to Supabase and Postgres.

#Why migrate

Firebase was the right call on day one - it got identity, real-time data, and Cloud Functions working in days, not weeks. But as the data model matured, three problems kept recurring:

• Relational queries. Albums, contributors, media, reactions, and comments are deeply relational. Modelling them in a document store meant fan-out reads and denormalised copies that were easy to get out of sync.
• Server-authoritative rules. Enforcing tier limits, storage quotas, and event windows needed real transactions and constraints, not best-effort document rules.
• Cost predictability. Per-document read pricing made some of the most useful screens (activity, event dashboards) the most expensive to build.

Postgres answers all three. The decision was made deliberately, not casually - a migration mid-alpha is exactly the kind of thing that's painful now and impossible later.

#What shipped

Postgres data model - Users, albums, media, contributors, frames, and subscriptions are now proper relational tables with foreign keys and constraints. The shapes that used to live in nested subcollections are now joins.

Row-Level Security from the start - Every table ships with RLS policies. A user can only read and write rows they own or have been explicitly granted access to. The same rules that the app relies on are enforced at the database, not in the client.

Edge functions for privileged writes - Anything that must not be client-trusted - tier assignment, quota enforcement, event sessions - moved behind edge functions running with service-role access. The client asks; the server decides.

Realtime over Postgres - Frames and the app subscribe to Postgres change streams instead of document listeners. The delta-only sync model from α 0.8 carried over cleanly.

Storage stays on Cloudflare R2 - Media delivery was already on R2 behind signed URLs and a CDN, and that pipeline was untouched. Only the metadata and identity layer moved.

#How it went

The migration ran behind a compatibility layer so the app could be cut over table-by-table rather than in one risky switch. Auth moved first, then the album/media core, then subscriptions. A full read/write parity pass was run against both backends before Firebase was retired for each domain.

Next: with a relational backend in place, the planned social engagement layer finally has the foundation it needs.

Today lumiframeapp.com went live - a proper home for LumiFrame on the web.

#What's on the site

Landing page - A page that explains what LumiFrame is, who it's for, and how it works. The same glassmorphism design language carries over from the app so it all feels like one product.

Account portal - Sign in at /account to see your profile, stats, and manage basic account settings. This is the first cross-platform web presence for LumiFrame accounts.

This changelog - Eight months of development, documented from concept to today, in one place.

#Cross-platform account sync

The web portal and the mobile app share the same Firebase auth backend. Profile photo, username, album count, and frame count from the app appear in the web portal automatically. Changes to display name on the web propagate to the app within the hour.

#What's next

Twenty sprints. Nine months. With the app, the backend, and now the web all in place, the next stretch of alpha is about depth - consolidating the foundation and building out the social, live-event, and playback features that make LumiFrame more than a photo viewer.

For the first time, LumiFrame is running on devices that aren't the development machine. A TestFlight build was pushed to a handful of personal devices to catch the things that only surface outside the simulator.

#What surfaced in testing

The headline finding: the first-run experience of setting up a frame and album was smooth, but there was no clear "pull" to come back the next day. The retention loop wasn't obvious enough, which immediately shaped priorities around activity notifications and the default album-assignment prompt.

#Bug fixes from real-device testing

Testing on physical hardware uncovered 43 issues that never appeared in the simulator. The most impactful:

• Frame registration failed on certain Android 14 devices - A permissions change in Android 14 affected background network access during initial setup. Fixed.
• Albums sticking after contributor removed - When a contributor was removed, their local copy of the album still appeared briefly. Firestore rules enforcement was correct; the local state management wasn't. Fixed.
• Clock mode resuming at wrong brightness - Fixed a state restoration bug where display brightness set via the app wasn't persisted across frame reboots.
• Invitations not delivered to some Gmail addresses - Firebase's email domain was triggering Gmail's spam filter. Resolved by configuring a custom sending domain.
• Video audio playing on frames that should be muted - Frames default to muted per the spec, but a codec path for certain video formats bypassed the mute flag. Fixed.

#Sentry integration

Sentry was connected for crash reporting this sprint. Error capture is already paying dividends - several nil-dereference crashes that were low-frequency enough to have been missed in simulator testing are now captured and tracked.

This is the feature that opened up an entirely new way to use LumiFrame. Until now, albums were something you and the people you'd invited curated over time. Event albums are different: a shared album built for a single moment - a wedding, a birthday, a reunion - that anyone present can contribute to, even if they've never heard of LumiFrame.

#What shipped

Time-limited collaborative albums - Any album can be turned into an event album for a defined window. Set a duration (up to 7 days), optionally schedule when it starts, and optionally protect it with a PIN. When the window closes, the album quietly returns to a normal album - the memories stay, the open door doesn't.

Guest contribution by QR code - Converting an album generates a QR code and a share link. A guest scans it, and they can start adding photos and videos - no LumiFrame account required. The friction that kills most "send me your photos" group efforts simply isn't there.

Host controls - The owner stays in charge throughout: see who's contributing, watch photos arrive, set the PIN, and close the event early or extend it. Guest access is scoped to the event and nothing else - contributing to the party doesn't grant access to the rest of your library.

Premium and Elite - Event albums are a paid-tier feature. The mechanics of how events are allocated and metered would be formalised later (see α 0.26), but the capability lands here.

#Why this is a big deal

The hardest part of any group occasion is afterwards: everyone has a few great shots on their own phone, and they almost never end up in one place. Event albums invert that. Instead of one person begging for everyone's photos for a week, the photos collect themselves as the event happens - and the host walks away with the whole story, contributed by everyone who was there.

It also reframes what LumiFrame is. A digital frame is something in your home. An event album is something you can hand to a room full of people. That reach is why this became one of the most important features on the roadmap.

#Where it goes from here

What shipped this sprint is the foundation - the album that opens, collects, and closes. Two things were always going to follow, and both did:

• Making it feel alive. An event happening right now should feel live, not like a folder slowly filling. That became the focus of α 0.24 - real-time arrival, a growing gallery, and a recap when it's over.
• Removing the last install. A QR code is great, but a guest still needed the app to contribute. Taking the whole experience to the open web came in α 0.25.

Building the durable mechanism first, then the delight, then the reach - in that order - is exactly how this feature was meant to grow.

Several features shipped in quick succession between the media format sprint and TestFlight. They were small enough individually to not warrant a full sprint writeup, but together they represent a meaningful expansion of what LumiFrame can do.

#Cast support

Chromecast and AirPlay - You can now cast your slideshow to any Chromecast, AirPlay, or Smart TV device on your local network. A CastService handles mDNS discovery, a local media server for content delivery, and integration with the PlaybackCoordinator so cast playback stays in sync with the app's controls. Cast sessions support play, pause, next, and stop commands.

Web client casting - A browser-based cast option was also added for devices that don't support Chromecast or AirPlay natively.

#App security

Passcode lock - A 4–6 digit PIN can be set to lock the app on launch. Available on Premium and Elite tiers. A separate slideshow passcode protects frame controls from accidental changes.

Current note: The app passcode is a 4-digit PIN; the 4–6 digit range described above does not match the current implemented behavior, which auto-submits after 4 digits.

Biometric authentication - Face ID, Touch ID, and fingerprint unlock are available as alternatives to the passcode via the local_auth package. Biometric data never leaves the device - the app verifies a cryptographic result from the secure enclave, not the biometric itself.

Security notifications - An optional Cloud Function sends push notifications when security events occur (passcode changed, new device login, etc.).

#Product policy update

No ads, ever - LumiFrame does not show ads on any tier. See /pricing for the current plan structure.

This sprint expanded the range of media LumiFrame handles well and improved how the existing pipeline deals with edge cases.

#New format support

HEIC/HEIF - The native photo format from iPhones since iOS 11. HEIC files are now fully supported for upload, display, and thumbnail generation across the entire pipeline - from the native media handler to Dropbox/OneDrive imports and event album uploads.

#Upload and ingestion improvements

Deduplication across sources - The SHA-256 hash pipeline now runs consistently across all import paths - camera roll, Dropbox, OneDrive, and event albums. Duplicates are caught before upload regardless of source.

EXIF orientation handling - Profile photo uploads now respect EXIF orientation data and auto-rotate before cropping and display. This eliminates upside-down or sideways photos from older cameras when users set a profile picture.

#What didn't ship this sprint

Server-side video transcoding (ProRes → H.264, for example) and RAW camera file support were explored and scoped, but both require infrastructure that doesn't exist yet. They remain on the roadmap but weren't worth pretending were done.

This alpha continued internal experiments for helping people revisit shared-album activity. Those experiments were not part of the public release, so the original feature preview has been removed until the work is ready to launch.

Happy New Year. 2026 started by tackling one of the most natural next features: getting photos off of cloud storage services and onto frames without any manual work.

#Dropbox integration (Elite tier)

OAuth connection - Connect your Dropbox account from LumiFrame settings. A secure OAuth 2.0 PKCE flow stores only a refresh token - no password, no full access to your Dropbox.

Folder selection - Choose one or more Dropbox folders to sync. LumiFrame monitors them for new photos and videos and imports them to linked albums.

Import history - A log in settings shows every file imported, when it arrived, and from which folder. Any item can be removed from LumiFrame without affecting the original file in Dropbox.

Conflict handling - Files already in LumiFrame (matched by SHA-256 hash) are skipped silently rather than creating duplicates.

#OneDrive integration (Elite tier)

OneDrive was built alongside Dropbox using the same cloud-source architecture. Microsoft OAuth 2.0 PKCE flow, folder browsing, and the same import/dedup pipeline. Both services share the same CloudSourceService abstraction, which made adding the second provider significantly faster than the first.

#Google Photos (in progress)

Google Photos integration is also underway, using the Google Photos Library API. The implementation exists but requires navigating a more restrictive API review process before it can ship to users.

The holidays felt like the right moment to step back from features and make everything more beautiful. This sprint was a full UI pass - new design language, new onboarding, and the kind of polish that makes an app feel considered.

#Design language: Glassmorphism

LumiFrame adopted a glassmorphism visual language: frosted glass panels, translucent layers, soft violet gradients, and generous blur effects. The result is a UI that feels premium without being heavy. Every screen now has visual depth.

Key tokens formalised this sprint:

• Blur radius: 12–24px for panels, 40px for modal overlays
• Primary accent: #7C3AED violet with a soft glow
• Glass surface: white/8–12% opacity over a dark base layer
• Radius: 20–28px for cards, 16px for buttons

#Onboarding redesign

The original onboarding was functional but forgettable. The new flow:

1. Welcome screen - Full-bleed ambient video showing LumiFrame in a real home
2. What is LumiFrame? - Three illustrated feature cards, swipeable
3. Account creation - Streamlined to three fields, social login first
4. First frame setup - Guided setup with a spotlight tutorial walking through the four-phase flow (frame → album → activity → slideshow)
5. First album - Prompt to add photos immediately; the first win comes fast

#Animation system

A formalised animation library was built: LumiEntranceAnimation, LumiVisibility, LumiPressable, LumiPulse. Consistent easing and duration tokens replace scattered custom animations across the codebase. The app now feels unified in motion.

Happy holidays. Back in the new year with more to show.

LumiFrame needs to sustain itself long-term. This sprint introduced subscription tiers that gate advanced features while keeping the core experience genuinely useful for free.

Current note: pricing, limits, and packaging have evolved since this alpha entry. See /pricing for the live plan structure and current product policy.

#The tier structure

Free

• 2 devices
• 1 GB cloud storage
• No ads

Premium - $5.99/month or $29.99/year

• 10 devices
• 15 GB cloud storage
• No ads
• Clock mode
• Passcode security

Elite - $9.99/month or $79.99/year

• 25 devices
• 50 GB cloud storage
• No ads
• Cloud source imports (Dropbox, OneDrive, Google Photos)
• Event albums
• Extended batch operations

#What shipped under the hood

AccessTierService - A single service in the app that gates every premium feature. No feature checks are scattered across the codebase; they all route through AccessTierPolicy. Changing a tier rule is a one-line change.

Firestore-based subscription management - Subscription state lives in the user's Firestore document and is managed through Cloud Functions that handle tier assignment, expiry, and lifecycle events. In-app purchases are processed through the Apple App Store and Google Play Store.

Paywall UI - A contextual paywall appears when a free-tier action hits a premium boundary. It's informative rather than aggressive - explaining what gets unlocked without blocking the rest of the app.

Server-side enforcement - Firestore rules and Cloud Functions enforce tier limits independently of the client. Storage quotas can't be bypassed from the client side.

Pricing will be finalised closer to launch.

This alpha focused on internal prototypes for helping people revisit recent shared-album activity. Those experiments were not part of the public release, so the original feature preview has been removed until the work is ready to launch.

After five months of feature sprints, a full two weeks were dedicated to doing nothing but making LumiFrame faster and more reliable. The output was significant.

#Performance improvements

Cold start time reduced by 38% - Profiling the startup path identified three blocking operations that could be deferred. The app now reaches a usable state in under 1.8 seconds on a mid-tier Android device.

Memory footprint at steady state - Long-running frame sessions were showing memory growth over 48+ hours. The media cache eviction strategy was rewritten using an LRU policy with explicit size limits. A 72-hour soak test now shows a flat memory graph.

Firestore read cost audit - Every Firestore read the app performs was audited, and 14 redundant reads that were firing on every navigation event were eliminated. An in-memory cache layer now serves repeated lookups of stable data.

Image render pipeline - Thumbnails were being decoded on the main thread in some grid layouts. All decode operations were moved to a background isolate. Grid scrolling is now consistently 60fps on all test devices.

#Stability fixes

• Fixed a race condition in the upload queue that could cause a photo to be uploaded twice
• Fixed frame status listener not resuming after app moves to background and returns
• Fixed crash when opening an album that was deleted by another user while you were viewing it
• Fixed notification delivery failing silently when FCM token refresh coincided with a cold start
• 23 additional minor fixes surfaced from extended dogfooding

#Lessons from this sprint

Every product benefits from a dedicated stability sprint before expanding scope. These fixes would have been much harder to isolate later. Take the time.

Update (June 2026): Frame groups were retired. LumiFrame now uses a flat frame list with per-frame permissions. This post is kept for history.

If one frame is good, several should be even better. This sprint added the ability to organise frames into groups - essential for households with displays in multiple rooms.

#What shipped

Frame groups - Create named groups ("Downstairs", "Bedroom", "Office") and assign any combination of your frames to them. Groups appear alongside individual frames in the app for easy organisation.

Group album assignment - Set an album on a group and all member frames display that album's content. This is the most common multi-frame use case: your entire home showing the same shared album.

Group management - Add or remove frames from a group at any time. Drag-and-drop reordering keeps groups tidy. A frame can belong to multiple groups simultaneously.

#Implementation note

Group state is maintained in Firestore alongside individual frame documents. The grouping layer is primarily an organisational tool in the current implementation - individual frame commands (play, pause, next) are still issued per-frame. True fan-out group commands are planned for a future sprint.

Frames aren't always actively displaying photos. This sprint made the idle state worth looking at.

#What shipped

Clock mode - When you pause the slideshow or want a cleaner display, the frame switches to a full-screen clock. It's a minimal digital clock - light type on an OLED-black background - designed to look good in any room without drawing too much attention. Clock mode is available on Premium and Elite tiers.

Current note: Clock mode is now available on all tiers including Free. The Premium/Elite restriction described above applied at the time of this sprint but was later lifted. See /pricing for the live plan structure.

Display brightness control - A manual brightness/dim slider per frame, adjustable from the app without touching the frame. This lets you dial down the display for nighttime or dim rooms so the screen isn't a distraction.

#What this means for daily use

A digital frame that goes dark or shows a jarring screensaver at night is a frame that gets unplugged. Having a useful, calm idle state dramatically increases the hours-per-day a frame is genuinely pleasant to have in the room.

Clock mode is intentionally simple in this sprint. More display modes and scheduling capabilities are on the roadmap.

LumiFrame is fundamentally a social product - shared memories between people who know each other. This sprint invested in the social infrastructure that makes that meaningful.

#What shipped

Profile photo upload - Upload a profile photo directly from your camera roll. The image is processed through the same R2 thumbnail pipeline used for album media: multiple sizes generated, the smallest used in contributor lists and notifications, the largest shown on your profile.

@username handles - Every user has a unique, lowercase handle. Handles are 3–30 characters, alphanumeric with underscores only, and reserved against a list of protected names. Once claimed, handles are permanent.

Album-based connections - The social model in LumiFrame is built around shared albums, not follows or friend requests. You connect with someone by inviting them to one of your albums (or accepting an invitation to theirs). Once you share an album, that person becomes a connection - visible in your profile and available for future invitations without needing to re-enter their details.

Invite by username - When inviting someone to a shared album, you can enter their @username directly. The system resolves the username to a user account, and they see who you are before accepting. This makes invitations more trustworthy than anonymous links alone.

#What this enables

The social layer isn't a vanity feature. It supports activity, reactions, comments, and future shared-memory experiences between connected people.

Media needs to be everywhere - on the phone, cached on the frame, and backed up safely in the cloud. This sprint the sync layer was rebuilt from scratch with a proper architecture instead of the rough prototype from 0.4.

#What shipped

Two-way sync engine - Changes made on any device propagate to all others within seconds. The frame doesn't poll; it listens to Firestore for change events and fetches only the delta.

Offline queue - Photos added while offline are queued locally and uploaded automatically when connectivity restores. The queue is persistent across app restarts, supports adaptive concurrency, battery-aware throttling, and handles partial uploads gracefully with retry logic and cancel tokens.

Storage quotas - Each account tier has a storage ceiling enforced server-side via Cloud Functions. The app shows a live storage usage indicator in settings and warns as you approach capacity. Uploads are gated at the limit.

Media deduplication - A SHA-256 hash is computed client-side before upload. If the exact same file already exists in the library, the upload is skipped silently. This prevents duplicate storage without the complexity of near-match detection.

Thumbnail generation pipeline - Cloud Functions listen for new media uploads and generate multiple sizes for different use cases: small thumbnails for grids and notifications, medium for frame-quality display, alongside the original.

LumiFrame now tells you when things happen. Push notifications seem straightforward until you think about all the ways they can go wrong - stale tokens, duplicate sends, notification fatigue. This sprint focused on getting them right rather than just getting them shipped.

#What shipped

New photo notifications - When a contributor adds a photo to a shared album, all other members receive a quiet notification: "Jamie added 3 photos to Summer Trip."

Frame status alerts - If a frame you own goes offline for more than 5 minutes, you get a notification. When it comes back online, another one. Both are off by default; opt in from frame settings.

Batch notification throttling - For people in active shared albums, individual upload notifications can get noisy. The system batches rapid uploads (within a short window) into a single grouped notification instead of firing per-upload.

FCM token lifecycle - Tokens are registered on login, refreshed when they expire, and cleaned up on sign-out. Multiple devices per account are supported - each gets targeted notifications individually.

#What didn't ship

Marketing/promotional notifications were deliberately skipped for now. The notification channel should earn trust by delivering consistently useful in-product notifications first. People who never find notifications annoying are people who stick around.

LumiFrame is meant to be shared. This sprint introduced the collaboration model that makes it possible for a everyone to contribute to a frame - with clear boundaries around what each person can do.

#What shipped

Contributor roles - Three levels: Viewer (can see the album), Contributor (can add and remove their own photos), Admin (full album management including inviting others and changing settings).

Invite by link - Generate a shareable invite link for any album. Recipient taps the link, creates or signs in to their account, and they're in at the role you specified. Links expire after 7 days.

Pending invite management - Album admins can see pending invites, cancel them, and resend them. Invitees see their pending and accepted invitations in one place.

Contributor photo attribution - Every photo in a shared album shows who added it. Names and avatars appear in the media detail view.

Remove contributors - Admins can remove a contributor. Their previously uploaded photos optionally stay (owner decides).

#On the data model

Contributor state is stored in users/{owner_uid}/albums/{albumId}/contributors/{contributorUid}. This keeps album ownership clear - the album lives under the owner, not in a neutral shared space - while still letting contributors query their own memberships. It's unconventional but it scales.

Photos are on the frame. Now they needed to look great in motion. This sprint was all about the playback experience - the thing people will stare at every single day.

#What shipped

Custom slideshow engine - VideoPlayerManager and PlaybackCoordinator were written from scratch rather than relying on an off-the-shelf slideshow library. This gives full control over prefetching, memory management, and transition timing.

Transitions - Multiple transition styles implemented: fade (crossfade between slides), elastic (scale-and-bounce entrance), dissolve (native video layer dissolve), swipe (film-strip slide in four directions), crumble, and flash. Transitions are configurable per album.

Playback settings - Display interval (configurable per album), shuffle mode, loop, and fit/fill behaviour for different aspect ratios.

Tap to pause / swipe to advance - Gesture controls on the frame display itself for moments when you want to linger on a photo or skip ahead.

Preloading - The next items in the queue are pre-decoded in memory so transitions are instantaneous. This was the single biggest perceived-quality improvement of the sprint.

#Why build a custom engine

Third-party slideshow packages either couldn't handle mixed photo/video sequences reliably, or they introduced memory leaks at longer runtime. For a frame that runs for hours at a time, memory stability isn't optional. The engine was tested across extended continuous runs before it was called done.

You can now add photos and videos to LumiFrame. This sprint was the most feature-dense one so far and required deep coordination between the Firestore data model, Cloudflare R2 storage, and the app UI.

#What shipped

Albums - Stored in users/{uid}/albums. Each album has a title, cover photo, visibility setting, and metadata. Albums can be assigned to one or more frames.

Photo and video upload - Media flows from your camera roll through a signed upload URL to Cloudflare R2. Thumbnail generation happens server-side via a Cloud Function triggered on upload. The app stores a reference in users/{uid}/media linking the R2 key to the album.

Media grid - A responsive grid in the app showing your photos and videos per album, with lazy loading and smooth scroll performance.

Assign album to frame - Tap a frame, pick an album. The frame starts pulling and displaying that album's media within seconds.

#Storage architecture

The storage approach settled on a tiered model:

• Thumbnails (256–512px) served from media.lumiframeapp.com CDN - fast, cached, cheap
• Full resolution served via time-limited signed URLs for privacy
• Frame-quality renditions generated at upload and cached for frame delivery

Getting this pipeline right early means no media migration will be needed later. It already feels solid.

LumiFrame is finally living up to its name. This sprint built the core of the product: turning any device into a connected display.

#What shipped

Device-to-frame conversion - Any device running LumiFrame can be converted into a frame. Log in on a spare phone or tablet, open the "Create Frame" dialog, give it a name, and the device registers itself as a managed frame on your account. No QR codes, no network configuration - just sign in and convert.

Frame registration in Firestore - Each registered frame gets a document at users/{uid}/remote_frames/{frameId} containing its name, status, last-seen timestamp, and assigned album. A deterministic short ID is generated via ShortIdService for human-readable identification. The phone updates this document; the frame listens for changes and reacts immediately.

Frame health monitoring - A UnifiedHeartbeatService reports each frame's online status, battery level, playback state, and connectivity on a regular interval (default: every 2 minutes). The app surfaces a badge when a frame goes offline so you always know what's happening.

Rename and delete frames - Basic management from the app: rename a frame to something meaningful ("Living Room", "Kitchen"), or remove it from your account entirely.

#Lessons from this sprint

The hardest part was ensuring the frame's Firestore listener recovers gracefully after a network dropout. A reconnect strategy with exponential backoff was added - something that becomes increasingly important as more real-time features get layered on.

Next up: the media side. Albums, uploads, and getting photos onto the frame.

You can now create an account in LumiFrame. That sounds modest, but the auth system built this sprint is the backbone everything else will sit on.

#What shipped

Sign-up flow - Three-step onboarding: email + password, then display name and @username claim, then you're in. Usernames are globally unique, enforced both client-side and in a Firestore usernames registry to prevent races.

Google Sign-In - OAuth with Google works end-to-end, including the edge case where a Google-authenticated user and an email user could theoretically collide on the same address. Handled safely.

Firestore user document - Every user gets a users/{uid} document that stores displayName, username, email, tier, photoUrl, and timestamps. This doc is the source of truth across every platform that will ever know about this user.

Security rules - Firestore rules written from the start, not bolted on later. Users can only read and write their own documents. Username registry is append-only from clients.

#Under the hood

A deliberate choice was made to require email verification before most write actions are permitted. OAuth providers (Google, Apple) are auto-verified. Password users must confirm their email. This small friction point eliminates a large class of abuse.

Next sprint: frame connection - the core product feature that makes all of this worth building.

Today the first real line of LumiFrame code was committed. After a month of planning, the architecture felt solid enough to start building.

Flutter was the choice for the mobile client - one codebase for iOS and Android, with the performance profile needed for smooth media playback. Firebase was the obvious backend pick: Firestore for real-time data, Firebase Auth for identity, and Cloud Functions for server-side logic that the phone should never touch directly.

#What landed in 0.1

• Flutter project initialised with a clean folder structure (controllers/, services/, screens/, models/)
• Firebase project created: lumiframe-1
• Firebase Auth wired up with email/password sign-in
• Basic navigation shell with placeholder screens
• CI pipeline configured for automated builds on every push
• Cloudflare R2 bucket provisioned for media storage

It doesn't do much yet. But the foundation is right, and in early-stage development, that matters more than features.

The next sprint is authentication - user accounts, usernames, and the profile document that will follow a user across every device and platform they ever use.