njhaveri

On the Mac App Store, there isn't a practical way to charge for updates. You could release entirely new apps, but then upgrading is a pain for users, and you lose your ranking and reviews -- and it's difficult to charge an upgrade fee. You can gate-keep features with In-App-Purchases the way Agenda does, but then you're giving away bug fixes and polish on the app for free forever, and that's probably 80% of your development time. Plus, I would imagine the upgrade rate on that model is pretty low, since most users won't care about fringe features being added.

If you really want to offer perpetual licenses with paid updates, since you're a desktop app, you can roll your own licensing system and use FastSpring/Paddle/etc. It's a fair model, but it's a lot of work. It may be worth it depending on your audience - e.g. developers tend to care a lot about this stuff.

Selling this as a subscription is probably the best path if you can stomach the initial ire of users that don't like that model. Depending on your price point, you could consider a 4x-5x multiplier for a lifetime option if you want to try and keep some of them. Yes, you will lose some users that might have paid for a major version, but you'll probably make that up with the recurring revenue from less price-sensitive users.

Best of luck. I know this can be agonizing and there's no easy answer here.

Wow, I had no idea about this one! Thanks so much for this tip!

After the end of legacy G Suite was announced, I tried using iCloud+ to forward my personal domain to Gmail. However, because iCloud does not seem to support ARC for forwarding, Gmail was sending too much to Spam.

I tried many other mainstream forwarding options and settled on Pobox as the best overall option, and moved my personal domain over. It's working pretty well, flowing to my regular Gmail account and having aliases set up in Gmail.

Agreed, I think they'll just never increase the free storage again. Eventually, people will get tired of quarterly inbox cleanups and just pay for the extra storage, which is a win-win for them and avoids a serious PR crisis.

If you really want to host your own server for incoming mail, SES would probably be fine for SMTP and very cheap. With things set up correctly (SPF, DKIM), my personal experience with deliverability has been problem-free. However, I've seen others say they've still had issues because of the SES IPs. For double-checking the quality of your setup, mail-tester.com is handy.

If you want to migrate to a free consumer service (like a personal Gmail account and using aliases), a forwarding service that also provides SMTP is an option. I've been testing Pobox.com and it looks great ($20/yr for up to 20 addresses). I first tried using my registrar's forwarding service, and sending from aliased addresses via the Gmail SMTP Server, and had lots of trouble with deliverability, so I wouldn't recommend that.

I think there may be some confusion here. Reading the original tweets from @featherless, I don't see any intent to actually change the end-user design. For example:

> This evolution of how we approach design for Apple platforms has enabled us to marry the best of UIKit with the highlights of Google's design language.

I'm reading this to say that custom UI components will be replaced with UIKit components that will be customized to have Google's design language. But at a high level, the apps will continue to look the same as they currently do.

This is surprisingly sophisticated and loaded with features for a 1.0, congratulations on the release! I totally know what it's like to work on a productivity app for a long time before it feels like it meets the minimum bar for release, serious props for making it over the line. The smart summaries feature in particular looks really interesting.

While I confess that I'd also like the option to purchase a 1.0 license and then pay to upgrade to 2.0 later, I fully recognize that the App Store makes that sort of arrangement extremely awkward and difficult to achieve, and think you priced it more than fairly anyways.

Neat idea! Do you plan to notarize the binary?

From personal experience, notarization hasn't really caused any friction in my dev process for Mimestream. The upload + server response usually only takes about a minute. Yeah, it's another thing to learn, but the process is pretty well-integrated into Xcode, and if you're building via script then it seems well-supported?

On the other hand, code signing is perennially confusing, and I wish the documentation was better.

Haha, having worked on email clients, this gave me a good laugh. People use them in all sorts of different ways – part of what makes them tricky to build. Very clever customization though!

I get the general point of the article, but if I just lost the source code to the app I've worked on for years… It would take me a very, very long time to re-write everything. Sometimes, getting relatively straightforward code to actually work is hard and time consuming.

Finally!

Hopefully it will be based on the prefers-color-scheme media feature, instead of it being a setting to toggle…

I also really dislike that WWDC videos are now the de-facto documentation. It must be a lot of work to put them together – I wish they'd just write a doc instead. Would be way faster to read, search, etc. and could probably go into much greater depth.

As a developer of a native Mac email client, I sincerely hope that this is true. At least in the Apple ecosystem, there are new technologies like SwiftUI and Mac Catalyst that should make this easier, particularly for the army of iOS developers looking to bring apps to the Mac.

Before starting my app, I did briefly consider going the cross-platform route, and I realize that it's possible to build a decent app that way. But personally, I could always tell when I used one. Little things like swipe gestures and drag and drop didn't quite work right. The extra polish, consistency, and speed of going native is so nice for things you use all day every day. With the shift to remote work, people might notice this extra 5-10% of polish more than they did a year ago.

I previously read about what happened to you guys Re: Sidecar (my sympathies), so congrats on making this pivot to adding Windows support! This should be a huge market!

I'm curious – did you have to change the hardware dongle much, or is this mostly a software stack rewrite to support Windows?

I looked into it and it seems by invite only. I get it.

I've received an overwhelming amount of feedback asking for this, and I plan to add this functionality.

Would love to, but need Gmail API support. Please consider Starring (but don't comment +1): https://issuetracker.google.com/issues/109952618

Tokens are granted to the app running on your Mac, not a service. There's definitely no Mimestream-run service component with access tokens to your account.

One tip - on the Google OAuth sign-in page, you can inspect the URL's query component to see the redirectURL parameter, and you'll see where Google will send the token. In Mimestream's case, it is <long-custom-scheme>:/oauthredirect, which is a custom scheme registered with macOS by the app, so macOS shows you the "Do you want to allow this page to open Mimestream" prompt.

This being said, you are totally correct, when you use any closed-source app like this that you did not build yourself, you are placing trust in the developer, and you are wise to be cautious.

In my opinion, there are still several practical security/privacy downsides to apps that run intermediary services with access to (or copies of) your email: - A larger attack surface (the intermediary service) for an adversary to take advantage of, and one that is probably less hardened than Gmail - A larger bug surface, as the service could potentially accidentally expose your data to another user (and this sort of bug _has_ happened in the past to others). - Google probably has serious policies/systems in place for preventing a curious (or disgruntled) employee from reading your unencrypted email. Hopefully. That level of sophistication seems less guaranteed from a small company, and it's completely invisible to you as a user.

Right now, it's WYSIWYG HTML composing only. Got a ton of requests for plain text (and markdown) composing support, and I definitely plan on adding it, though it might take a few months at this point.

I've heard this requested a lot in the last 24h, will add this.

Thanks! You can disable this in System Preferences > Notifications > Mimestream > Badge app icon

#1 - oops, I filed a bug to fix this up. Thanks for pointing it out.

#2 is something I'm hearing more about... I'll plan on offering this in the future.

This is an HTTPS GET of https://mimestream.com/appcast.xml in order to check for the availability of beta software updates, using the Sparkle framework that is popular amongst Mac apps.

Thanks! I have been hearing the plugin feedback a lot lately, and I will be thinking about making a plugin API in the future.

This is a very fair concern, and I sympathize with it a lot. I have thought about this a fair bit, and thought about eventually turning this into a "source-available" model (but not yet, I'd at least like to be fully launched on both App Stores first and have some user-base). There are pros and cons to that. At the end of the day, if you install an app from the App Store, you place trust in the developer. App Store Review only goes so far (e.g. look at Epic sneaking in an alternate payment system). Even if I made source available, the typical user has no guarantee that it matches the binary they're installing from the App Store.

I've also thought about starting with an OAuth scope that allows all operations except permanently deleting email, and asking the user to re-authenticate and upgrade their scope the first time they try to permanently delete something. This is a little awkward from the user experience, though. Maybe burying this as a fallback mechanism during the onboarding flow is an option.

General reputation-building is probably the right place to start.

Oh no! A few people reported this crash today, I'll be fixing it hopefully tomorrow!

You can reset your cache by running these this in Terminal: rm ~/Library/Containers/com.mimestream.Mimestream/Data/Library/Application\ Support/Mimestream/Mimestream*

rm -rf ~/Library/Containers/com.mimestream.Mimestream/Data/Library/Application\ Support/Mimestream/Attachments

This is something I asked about a few years ago when it was first introduced, and the vague answer I got is that the warning exists because the Gmail API is not as optimized as IMAP for some common email client tasks. (Indeed, for better performance, I would like to switch a few tasks to use IMAP instead of the Gmail API someday).

Google did vet Mimestream as a general-purpose email client before approving API access, and on the paperwork for that process "general purpose email client" was the app category that I selected, so I'm hoping all will be OK, or else I will be really scrambling to implement new protocols :P

I am definitely interested in eventually supporting IMAP, JMAP, and Outlook in the long term. In the short term, the focus will be on making the Gmail support solid.

Search is a merge of server-side results and a very basic local search that right now only looks at From and Subject. If you're offline, you'll get the local search results.

When you're offline, you can view messages. However, only the most recent messages are cached in the account, and caching is run lazily with the background activity scheduler, which won't run if your device is under any kind of load and runs infrequently on battery. Overall, I eventually plan to offer a "days of mail" setting to make this more predictable.

You can also take actions on messages – marking them read, starring them, replying and sending new messages, etc. This is all architected to work while offline and replay when a connection becomes available. This design is necessary to make things seem snappy when the client is online.

Overall, I have not yet heavily tested the offline capabilities, and there is some work to do around the caching predictability story. If offline access is a very firm requirement, I would recommend a client designed around this model, like Mail.