Meld: For Sapphic Couples

Meld gives sapphic couples a private, low-pressure way to put desire, curiosity, and intimacy on the table and start conversations that can be hard to begin.

Comment

Inspiration

Some conversations are hard to start even when there is nothing wrong.

You might want something, be curious about it, already like it, or simply wonder whether your partner would be open to talking about it. But being the first person to bring it up can make a small question feel much bigger than it is.

I wanted to build something that lowered that pressure.

Meld is made specifically for sapphic couples. I did not want to build a generic couples app and simply change the pronouns. I wanted the product, writing, visual identity, and interaction model to feel like they were designed for this audience from the beginning.

The idea that eventually became the foundation of Meld was simple:

Create moments where things that already exist between two people can become visible.

Not a compatibility test. Not a relationship score. Not therapy. Just a private way to put something on the table and see whether there is openness on both sides, so that a conversation that is hard to begin has somewhere to start.

What it does

Meld is a private, one-phone experience for sapphic couples.

Each partner answers a short sequence of prompts alone with the same phone. For each one, the question is: "Want to put this on the table?" They can answer Yes, Maybe, or Leave it. Then they pass the phone to their partner, who answers privately too.

Only after both people are finished does Meld reveal anything, and it reveals only the prompts where there was openness on both sides. Neither partner sees the other's individual answers. Because nobody has to explain or defend a single answer, it becomes easier to answer honestly, and easier to start talking about what opens up.

Sometimes that is enough to start a conversation that might not have happened otherwise.

The first version includes 75 authored prompts across 8 Experiences, organized into three Territories:

  • Between Us: affection, care, and everyday intimacy
  • Wanting: desire and how each person wants to be wanted
  • Try Together: curiosity and things to explore together

The full Between Us territory is free. Wanting and Try Together are unlocked through Meld Pass, a one-time purchase powered by RevenueCat.

There are no accounts, no login, no backend of my own, and no cloud relationship profile. Names, answers, sessions, and Reveals stay on the device.

How I built it

Meld is a native iOS app built in Swift and SwiftUI, with everything stored locally using SwiftData.

I deliberately designed V1 around a single shared phone instead of starting with accounts, pairing codes, a backend of my own, and synchronization. That constraint became part of the product. One person answers privately, hands over the phone, and the other person takes their turn. The physical handoff creates a small ritual, and it also lets the entire experience stay local and private.

The product architecture changed significantly while I was building it.

What started closer to a set of large prompt decks evolved into a hierarchy of Territories → smaller Experiences. That made the app feel less like a card deck and more like choosing what kind of conversation you want to open.

RevenueCat handles the Meld Pass entitlement. The purchase is a single non-consumable one-time unlock rather than a subscription, because recurring billing did not feel appropriate for the product.

RevenueCat in practice

A one-time non-consumable purchase sounded like one of the simpler parts of the app. Most of the interesting problems appeared in the edges, and several only became obvious when I tested real sandbox purchases on a physical device.

  • Reinstall needed a real restore path. My first silent entitlement refresh relied on customerInfo(). After a reinstall, however, the app had a new anonymous RevenueCat identity, so simply fetching CustomerInfo was not enough to recover the previous App Store purchase. I changed that path to RevenueCat's restore flow, which re-validates the App Store purchase history and recovers the entitlement.

  • Release builds fail closed. During development I had a stub purchase provider that made premium flows easy to test. It is now compiled only under #if DEBUG. In Release, if RevenueCat cannot be configured correctly, the app uses an unavailable purchase provider instead of accidentally granting premium access.

  • I verified the API key in the actual Release product. The project is generated with XcodeGen, and an early configuration attempt did not put the RevenueCat key into the final generated Info.plist the way I expected. I caught it by inspecting a clean Release build rather than assuming the build settings had propagated correctly.

  • I pinned the SDK version I had actually validated. RevenueCat is pinned to 5.84.0 so clean checkouts and Release builds use the same dependency I tested end to end.

Before submission I tested nine purchase and restore scenarios, including a fresh non-purchaser, purchase, relaunch, explicit Restore, reinstall, cancelled and failed purchases, and Release fail-closed behavior. By then, the app's automated test suite had grown to 79 tests overall.

Challenges I ran into

The hardest part was not the code. It was deciding what Meld should and should not reveal.

An early version separated results into stronger and weaker categories based on the exact combination of answers. That was technically accurate, but emotionally wrong. It made the experience feel like a scoring system.

Eventually I arrived at a much simpler rule: We only show what both people leaned into.

A "Maybe" is not a weaker Yes. It can mean "talk about it first," "start smaller," "if you start it," or "just curious for now." Those nuances stay attached to the result without exposing who chose what.

Another important challenge was defining Leave it.

It is intentionally not "No." A person might leave something because it is already good, because it is irrelevant to them, or because they simply do not want to put it on the table right now. The How This Works screen says it plainly:

"Already good as it is? Leave it. That's not a no."

That distinction changed both the product language and the Reveal.

I also spent a lot of time resisting feature creep. It would have been easy to add accounts, partner invitations, messaging, scores, streaks, reminders, or multiple simultaneous sessions. Most of those ideas would have moved Meld into a different category of product.

The question I kept coming back to was:

Does this make something between two people more visible?

If the answer was no, it probably did not belong in V1.

Accomplishments that I'm proud of

I'm proud that Meld shipped as a small but complete product rather than a prototype.

It has:

  • a complete free end-to-end experience
  • 75 original prompts across 8 Experiences
  • a private two-person Reveal model
  • an on-device history called What's ours now
  • a one-time premium unlock through RevenueCat
  • no account, and no backend of my own
  • a visual and editorial system built specifically around the product's intimacy and privacy
  • an automated test suite of 79 tests

Most importantly, Meld is now live on the App Store.

Getting there included one more lesson in shipping. The first submission was returned under Guideline 2.1 because my developer account had limited App Review history. Apple requested a physical-device screen recording and detailed information about the product, privacy, regional behavior, and in-app purchase.

I supplied the requested information, replied to App Review, and Meld was approved.

It was a useful reminder that shipping also means explaining your product clearly to someone who has never seen it.

What I learned

One of the biggest lessons was that privacy can be part of the interaction design, not just a settings screen or a compliance checkbox. Meld works because each person can answer honestly without immediately having to explain or defend an individual choice.

The Reveal is valuable precisely because of what it does not reveal. That is also what makes it easier to begin: when nothing individual is exposed, the pressure to go first mostly disappears, and what is left is a shared starting point for a conversation.

Privacy is not the goal here. It is what lowers the pressure enough for the conversation to start.

I also learned how much product meaning can live in very small pieces of copy.

Changing "No" into "Leave it", treating "Maybe" as its own meaningful response instead of a weaker "Yes", or replacing "what you both want" with "what opened between you" changed how the entire product felt without changing the underlying mechanics.

And building specifically for sapphic couples forced me to ask a more useful question than "Is this inclusive?"

The better question was:

Would this product still feel like it was made for sapphic couples if I removed the label?

That influenced the prompts, tone, visual system, and the situations the app chooses to make visible.

What's next for Meld: For Sapphic Couples

The next step is not to immediately add more features. I want to learn how real couples use Meld. Do they understand the one-phone ritual immediately? Does the Reveal feel worth the vulnerability of answering? Which Experiences create conversations? Does Maybe feel as useful in practice as it did in design? Do people return to What's ours now? And do they want to use Meld again with the same partner?

Those answers will decide what Meld becomes next.

Built With

  • ios
  • revenuecat
  • storekit
  • swift
  • swiftdata
  • swiftui
  • xcodegen
  • xctest
Share this project:

Updates

Submission history