Why Replicating Your Desktop App On iOS Ain't The Best Approach

Kairn was a project management app for individuals and teams. If we say project for individuals, that means task management. So in that area, could you build a product without having a mobile app? Nah.

So early on we decide to prioritise a mobile app, and we went all in on iOS. However, the question arises: should an iOS app simply replicate the features and functionalities of its desktop counterpart? Let's chat about some challenges, limitations, opportunities, and learnings we got.

Why iOS Only?

When developing a mobile app you have two choices - go native or go multi platform. The latter is the fastest, you develop once and your app can be used on iOS / Android / whatever. To do so you use specific technology such as React Native or even the funny "new"comer Flutter (like our friends from Superlist).

Yet, we decided to build in Swift, for iOS only.

Why? Because we wanted to show that we could be incredible good in one platform and then replicate. Coding in Swift is a hassle (find out more here) but it allows you to tap into more personalisation such as haptic effects, it seamlessly integrate with Apple apps, and it creates lighter structures.

But most importantly, your code can be shared across all Apple devices. One of our key features - that brought and retained users - was our macOS app that created tasks from any tool. Our macOS app was also coded in Swift and we used parts of the code as a shared basis between our apps - this enabled better QA and ultimately, faster coding.

Ok, now that we've established why iOS, let's dig into feature choice.

Picking Features For Mobile - Follow The User Journey

So the idea to pick your features is pretty simple. You follow your user's journey on each platform. Will the user have the same intention for your app on desktop and on mobile? Do they interact with it in the same moment of the day? Where are they at that time? With whom? What's their attention level? By examining such factors we gained insights into the specific interactions our users required on mobile devices.

Our mobile usage predominantly revolved around two key scenarios: when users were on the go or at home, either before or after work hours. We focused on features that provided quick access to project status, facilitated task addition and sharing, and allowed users to check specific task statuses. We added platform-specific features like voice-to-text task creation and widgets, catering to users' on-the-go requirements and leveraging iOS-specific habits.

We excluded complex workflows such as project creation, integrations, member management, and view management.

4 Steps To Design Your SaaS Mobile Version

To sum-up! When designing your mobile version…

1. Define if there is a competitive advantage of coding for a single or multiple mobile platform (iOS/Android...). That depends on user target, performance needs, and code language of your desktop app, (among others…)

2. Define your user journey on mobile - when and why your user interacts with the mobile version

3. List features that are absolutely needed on mobile (and no fluff, any extra feature on a device might create the need to be coded on other platforms too and creates more maintenance!)

4. Start wireframing 🤓 (ideally re-using components to keep a uniform branding - check Booking cross platform design system!)

   
   

Hope that helps, and now have fun 👋
Cheers,
Pat 🩰