About a year ago, I started to brainstorm on how to solve this problem with Social Media...

The First Principles

When approaching complex problems, I often rely on First Principles thinking—a method rooted in physics that involves breaking problems down to their most fundamental truths and reasoning upward from there. Instead of relying on assumptions or copying what already exists, I ask: What is truly necessary? Why is this feature needed at all?

When building RealTime, I questioned common elements of social media apps—like 24-hour stories, appearance-altering filters, and algorithmic feeds. Do these features actually help people connect in a meaningful way? Or are they distractions? I challenged these assumptions and asked myself: How can I design a social experience that’s more authentic, more in-the-moment—while still keeping users engaged?

30分ストーリー

What if users’ content like stories were only available for a short time—like 30 minutes or so? I thought if users only had a short time to see stories, they would stay engaged with the app more, and content would be more in-the-moment rather than edited and in-the-past. What if after 24 hours, a compilation of all of your stories from the day gets made and shared with your friends?

I thought this approach could either be a huge failure or a success. So I decided to create the MVP for RealTime which included the above features to see how users would react. So I immediately headed to Figma to create a wireframe.

The design process

I aimed for simplicity—no cluttered interfaces, no overwhelming menus, and no endless setup. RealTime is built as an MVP (Minimum Viable Product), so I focused only on the features that truly matter: capturing a moment, sharing it instantly, and connecting with friends in real time. Rather than cramming in everything at once, I prioritized speed, clarity, and emotional connection. Every decision—from layout to navigation—was made to reduce friction and encourage users to be present. No filters, no endless scrolling—just raw, unedited moments.

  • What I Learned:
    • I learned how to use Figma
    • How to create wireframes and mock-ups
    • How to iterate and seek feedback from friends and family
  • Challenges:
    • Learning how to use Figma from a developer standpoint
    • How to brainstorm well-crafted designs for social media apps
    • Thinking about what social media users want

The Engineering Process

For the backend, I chose Firebase because of its reliability, real-time capabilities, and ease of setup. Since this was an MVP, scalability wasn't a primary concern—my goal was to ship fast and validate the concept. Firebase made it easy to handle authentication, database operations, cloud storage, and push notifications with minimal configuration.

One of the biggest challenges I faced was state management—especially making sure users’ content loaded properly and in sync across different views. SwiftUI introduces a lot of powerful tools like @EnvironmentObject, @State, and @Binding, which helped manage data flow within the UI. But syncing that smoothly with Firebase required careful coordination using Combine and async/await to ensure a responsive experience.

Debugging asynchronous data loading, handling view refreshes, and minimizing flicker or delay between content updates were all important areas I had to iterate on. These kinds of edge cases really taught me a lot about the subtleties of building a real-world SwiftUI app backed by a real-time database.

  • What I Learned
    • How to add multiple authentication features like Sign in with Apple, phone number, etc.
    • How to add push notifications using Firebase Cloud Functions and JavaScript
    • The importance of managing asynchronous data flow with async/await and Combine
    • How to quickly build an MVP while focusing on UX and core functionality
    • How to create an onboarding flow and save user info entered during onboarding
  • Challenges
    • State management issues causing delays and inconsistencies in content loading
    • Going back and forth with the Apple Review Team and iterating based on their requirements
    • Continuing with the same project for over 8 months without giving up

App Store Submission

With the development process taking about seven months—while balancing full-time college classes—there were definitely moments I felt like giving up. But eventually, RealTime was ready for submission to the App Store. Of course, any iOS developer knows that building the app is only part of the challenge—getting through App Store review is another battle entirely.

RealTime was rejected around six times for a variety of reasons: an incorrect developer website link, the absence of a content flagging/report feature, issues with the onboarding flow, and problems with Sign in with Apple. Each rejection felt frustrating, especially after putting in so much work over the months.

Still, I kept going. Over the course of two weeks, I carefully addressed each of Apple’s concerns, made the necessary adjustments, and resubmitted. After multiple rounds of iteration and communication with the review team, RealTime was finally approved and officially went live on the App Store.

It was a valuable reminder that shipping a product isn’t just about writing code—it’s about persistence, polish, and navigating the entire release process from start to finish.

Download