Sparrow for iPhone
sparrowmailapp.com
sparrowmailapp.com
As a company that does epic UI, they should figure out that customer support is a form of user interface as well.
I'm not ready to give them any more money at this point.
We used UserVoice for a while and were responsive, then as we scaled we found it hard to keep up with, and ended up good at our email channel but bad at our UserVoice channel. Since then we've improved again and are generally good at all channels. With this experience in mind, I'd suggest reaching out through multiple channels if you want to get through to them. Try email and Twitter as well as the obvious channel.
I have two Buffer subscriptions, one for myself and one for a client and it has become a must use app.
Good work!
We have plans to make the iPhone app even more awesome (and also include more of the functionality of the web app) so stay tuned for that! Not sure if you have an iPad, but that's on the way too.
Fantastic to have you as a paying customer. Get in touch if you ever have any questions or suggestions!
Do you have a link to more info about this? I'm genuinely curious how that could happen. The only time I've ever seen OSX kernel panics was either due to faulty hardware or due to doing something silly (like messing with kernel extensions)
Sparrow for iOS is an insta-buy for me.
I had used emoji in some of my label names—all valid Unicode code points—and it broke Sparrow hard (to the point where even preferences would self-dismiss on clicking an icon). It took about six weeks to get to the point where the "unusual" Unicode characters were the problem.
It's a nice email client, but I don't find it that much better than the native gmail email interface that I use most of the time.
They have the email handy already.
Let's hope they get some traction petitioning for an acceptable method to send push notifications: https://news.ycombinator.com/item?id=3706993
However, allowing this would be a bad move. It'd mean that rather than once centralized connection that knows about the device's network state and can (at least try to) preserver battery life, you'd then have as many as one per each app, always open. (Once Sparrow does this, then why could any other app not?)
The real issue here is that, from their responses, it seems that Google doesn't have some sort of authentication method like that could be used to get access to just enough information to pass the push data to Apple — or, at least, not one (like OAuth) that doesn't need them to remotely store a username and password. If there was a way for them to get some sort of useless "token" to get the notifications themselves and pass them to Apple, I don't think the security issues would be anywhere near as severe (especially if it was an opt-in service). But I don't know if Google does that, and their responses don't seem encouraging that something like this would be possible.
Good point, that would be a much better solution. All they'd need is a web hook to let them know when there is new email for an account. They could use that to send a push notification with the correct badge count for unread messages.
That's what we should really be petitioning for.
If that database was unknowingly compromised there could be a lot of fallout. I think that's a much bigger concern than leaking passwords.
There's nothing inherently wrong with this on mobile devices. If Apple can't do it for iOS, that is a flaw in their design, or their thinking.
That's exactly the scenario we have with Android, and it's not a problem there...
Push should be less taxing on the battery, since you only really need to fire up the radio when new data is coming your way, save any overhead of ensuring the connection is still alive. Apple does the same for their notifications (and ActiveSync) for the same reasons.
> If Apple can't do it for iOS, that is a flaw in their design, or their thinking.
It's not really a flaw, just a different methodology that is reasonable given the design goals. If you want iOS to be like Android, why not just use Android? That's the beauty of competition – you are free to choose the best.
Alternatively, Apple provide an API that certain apps may use to regular check for updates by running code on the iPhone, but Apple are not allowing Sparrow to use this API.
This would cover many use cases, such as alarm clocks, calendar notifications, and various poll-based background checking like new email count, maybe even headers fetching, while retaining control of watt usage.
In the meantime, I suppose Sparrow could integrate with Prowl.
If anyone could help, that'd be awesome!
It is possible for an email app to not leak at all. All it has to do is not load remote content unless the user specifically requests it.
Yes, these tricks are commonly exploited. Most of the time, people just use a simple img tag pointing to a 1 pixel image, although recently there was some news about Facebook using the bgsound tag.
I don't know if law enforcement ever use these sort of techniques to try and track down suspects, but it wouldn't surprise me.
In contrast, Outlook for Mac 2011 leaks 2 out of 32 categories (audio and video) with remote images disabled. Mail.app 4.5 leaks 14 out of 32 categories with remote images disabled.
Do you intend to file bug reports for Outlook and Mail.app?
EDIT: I just asked somebody who has Mail.app version 5.2 to test with remote images disabled, and it didn't trigger any of the tests.
It's clear, here, that Google places Gmail below Android in their list of priorities. I'm curious about which one of those departments earns more money, though, and which one is more strategically important for the long-term success of Google.
John Siracusa explains this same scenario as it appears to be happening at Apple extremely well in this episode of his fantastic podcast: http://5by5.tv/hypercritical/8
"On our side: if Sparrow was to do Push today, we would have to store your credentials (login/password) on our servers to frequently poll your accounts, and send you notifications.
This is a responsibility we're not ready to take. As a startup focused on iOS/OS X development, we do not have the skills to secure your data on our servers and we do not want to put sensitive information at risk."
I've just downloaded the app and it's awesome from a UI perspective, but it's never going to be an option as my primary mail app in it's current form which means I really can't recommend it to anyone.
Yes Apple might change their policy on this but it seems unlikely, at least in the short term. I think their best hope would be a new mechanism that allows something like this in OS6 rather than Apple just going "OK" but pragmatically they need to be looking at what they can do rather than crossing their fingers and waiting for Apple.
But that's not really my point. My point is that petitioning Apple likely isn't a productive route for them to follow, they need to look at how they address this problem without relying on a third party who are unlikely to accommodate them.
Gmail has mechanisms for allowing access without you having to share you credentials with another organisation so it can be done. I get that it's not their core competence but if this is a market they want to be in, they might need to start expanding their skills base.
Sparrow also features a nice polished UI, and is responsive.
3-minutes-of-use verdict: GOOD
Either way, whichever app i settle with in the end, its going to be the one that is the quickest in operation.
One thing that keeps me from using Sparrow for OS X (or any other desktop client) is that they download every email, and I don't want to spare the 7 GB of hard drive space for something I don't need every day. Mail for iOS lets me choose to store only the last X messages on the device, but I haven't seen that option on any desktop client.
Sparrow? No push notifications for you. Dolphin? Here's an NC17 rating (wtf?) for you, and by the way-- no way to change the default browser.
I'd really like to see a reasonable explanation for both of these scenarios by Apple. My guess is the only reasonable explanation is that they want to restrict and "protect" the user experience for that critical functionality in a way that seems like an ornery chef who refuses to cook your steak medium well.
More condensed, it's a combination of Apple not wanting each app re-implementing push (or constant polling), Sparrow not willing to take on the responsibility of being able to access your email, and Google not providing low-privileges access for Sparrow to only be able to see the little amount of data that push needs.
Sparrow admittedly doesn't want to figure out how to do push securely. But look at the fantastic PushMail app (dopushmail.com) to see a beautiful push implementation. Apple's not blocking push.
// Too bad about dopushmail.com having to stop selling the app. That leaves an opportunity for someone...
Replacing swipe-to-delete on a message with back/pop: not so good.
It's really nicely done overall. Totally rethought from their desktop app.
And we'll have a blog post up at http://blog.boxcar.io here soon too. It's a bit easier than the above now, as you can just choose "Sparrow" from the list of Installed Clients to have it work.
I really hope this trend continues and we can see power user replacements for Safari and Calendar as well.