loading...
Cover image for The Challenges of Building Own MacOS App

The Challenges of Building Own MacOS App

alex_barashkov profile image Alex Barashkov ・4 min read

Two years ago, we began the process of building a simple, open-source MacOS app as a side project, but this turned out to be a much more challenging journey than we initially thought. Here, we talk about the various stages of this journey, including:

  • how we built the app to mute/unmute microphones using the shortcut or touch bar icon;
  • why taking an open-source approach did not meet our expectations;
  • what limitations Apple placed on the touchbar that rendered it useless for our needs.

We've just released our Mutify app on Product Hunt, so now we’re waiting for your feedback and support!

https://www.producthunt.com/posts/mutify

💡Initial Idea

I often spend a lot of time on calls in the middle of work days discussing tasks, solutions and future plans with tech teams working on various different projects. While on these calls, I prefer to mute my mic anytime I’m not speaking. However, I often switch between browser tabs or look at presentations while in these meetings, which makes it hard to quickly unmute myself as I search for the tab and unmute icon I need. To resolve this, I began using a MacBook 2016 with the touchbar, thinking that adding a mute button to the touchbar could be an effective solution. This is what sparked the journey that eventually led to our new app.

From Open Source to Paid App

We’re pretty happy with open source in principle, so we initially developed the first version of the app as an open source project, investing in the costs ourselves. We released it and made some promotions, and got positive feedback, but also noticed some bugs. MacOS turned out to be more of a problem than we thought. Particular problems we faced include:

  • problems with other apps attempting to control the mic
  • compatibility between different versions of MacOS
  • limitations put in place by Apple that needed careful investigation

We on the app’s community regularly growing so that we could get some contributors able to help handle issues that arose. Unfortunately, this didn’t happen. From day one, all development was done by ourselves; open-source development on Swift turned out to be quite different than the JS or PHP communities, where you can rely on small bug fixes from outside devs. This lack of helpful community is a major weakness of MacOS development.

We got 159 stars on Github, more than 8000 installations, and zero contributors. The app, however, still needed lot of work to complete, so we decided to rebuild it from scratch and change to a paid model to guarantee at least some support for future development and app improvements. That how Mutify was born.

Mutify Features

Mute and unmute microphone

Mute and unmute with a hotkey or touchbar icon available at all times.

Noise level

Display the current ambient noise level, helping you track when you need to mute yourself.

Variety app support

Use it with Hangouts, Zoom, GoToMeeting, Skype, Telegram, etc. Different calls apps try to control the mic, but the app allows you to keep control.

Difficulties of MacOs App Development

We encountered problems at almost every step of development. It was hard to build a fully customized UI, as we didn't want to use standard components. When we developed a method of low-level muting apps, some apps unmuted without user input or notification. For example, when attempting to mute a microphone and showing it disabled at all in MacOS settings, GoToMeeting or GoToWebinar simply unmuted the mic again when detecting it had been muted. After discussing this with the support team for these apps, they insisted that this is correct behaviour. From our perspective, this is dangerous, since it suggests that meeting apps just want to listen you all of the time. We had to find complicated workarounds to ensure that the mic was always muted when we wanted it to be.

Since the day one, we thought that Apple would extend the functionality of the touchbar API, but there are no changes as yet. Touchbar API has a lot of limitations that prevent developers using it to build potentially useful software.

For example:

  • Third party apps can’t be displayed in the list of actions for the touchbar in the “Cutomize Touchbar” settings;

  • You only could add one third-party app icon that is always displayed in the touchbar together with Apple developed tools;

Those limitations significantly reduce the possible options for extending touchbar functionality. That’s why we also support mute by hotkey functionality. Even for a simple, one-action app, you need time to build features like the following:

  • Onboarding screens
  • Update functionality
  • Integrated payment functions
  • Open at login functions
  • Hotkey support
  • Website

Effort = Quality

The main lesson we learned from this project is that doing something well always means a lot of hard work from different people with different skills, including some that don’t always relate to the primary functionality of the app. In the end, however positive feedback from our customers and personal satisfaction of using using our own application made it feel worth the effort.

Support us on Product Hunt for a 30% discount! Mutify also has a seven-day free trial, so feel free to test it out and we hope you enjoy!

Posted on by:

Discussion

markdown guide
 

It always amazes me how many simple, one-action apps there are for Macs because doing seemingly simple things is made prohibitively difficult by the OS.

Even for a simple, one-action app, you need time to build features like the following:

Are some of these things not simply artifacts of switching to a paid model? The GitHub README would do just as good a job for the Onboarding screens and website for most people. The integrated payment functions are their own problem - kind of like how adding fuel to a rocket means you have to add more fuel to compensate for the fuel you've just added. The update functionality problem goes away if you distribute using a package management system; homebrew is used by a lot of people these days. Do you mean you had to put in your own "check for updates" button?

The problem it looks like your app solves is one of confidence - I have no confidence that my Mac has the microphone muted at any time. I don't trust Apple and I don't trust any proprietary messaging system not to be listening in at any time. Having a big red icon telling me I'm safe would be a big confidence boost, though obviously I'd be more confident if it was free software.

 

Are some of these things not simply artifacts of switching to a paid model?
I think only integration with the payment provider.
The GitHub README would do just as good a job for the Onboarding screens and website for most people.
For tech people only, when the audience is not a tech people, it could be product managers, sales people who don't know anything about Github. We wanted to have very nice website and very smooth/clear experience of using the app.
I have no confidence that my Mac has the microphone muted at any time.
It does not :) Mic is always turned on.
Having a big red icon telling me I'm safe would be a big confidence boost,
That what we do, and actually having the same for webcam also could be a good idea.

 

Webcam is easier. I have a sticker of a dinosaur on it my son gave me ;)

Do you have confidence in your workarounds though? I have a feeling it could not be trusted to be bulletproof from what you're describing. Maybe some other app turns it on without your app registering it.

I saw this the other day: project alias which is a physical solution for always-on devices but obviously that would be more difficult to make for a variety of different laptops.

Yeah, it would be difficult to work with a parasite on my laptop. Good idea though.

 

Hi Alex,
I've noticed you decided to host the app for download on your website, but didn't publish it on the App Store.
Will you skip the App Store completely or are you planning to publish there too?

 

Hi Johny,

Yes we published it on our own, however we signing the app and passing Apple notary service, since it will be required for app installation in the new macOS release.

We did not publish to App Store for few reasons:
1 - Fees are high
2 - No promo codes functionality
3 - We did not want to rely on Apple from perspective of App publication, since Apple does not like and could reject App because it duplicates existing functionality in their OS. And you could mute app or see the noise level through the settings.

 

Yes the fees are very high, but maybe it gets you more purchases because people search for stuff in the app store. I'm having the same dilemma about my app.

I'm interested to hear how you marketed your app, if you're looking for a topic for your next post :)

App Store from my perspective on macOS still does not work well and promote Apps. I don't remember when I last time searched something through it and the same for my friends. Mostly I'm searching in Google, then website of the app and only then if there is a link to app store I'm installing/buying through it.

Marketing will be the interesting part, will definitely write an article about it.

 

Did you see the news about Flutter : github.com/flutter/flutter/wiki/De... ?

Interesting news, even if am not sure to want to work on Google's language.

 

I have not, but it's very interesting. Having something which could be converted to a completely native code for macos,windows, linux would be very interesting.

For example it's possible to use Electron, but the size of the app and memory consumption will be terrible, and for small apps it's very sad.