I have several (breaking) issues with the paid desktop version of the Sparrow.app. I've posted the most bothersome one on their support forums about two weeks ago: no reply at all. Nothing.
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.
I stopped using Sparrow due to a bug in their implementation of two-factor authentication for Gmail (it would always "forget" my app-specific password on startup). I got at least one (unhelpful) response to my support request(s) but the trail eventually went dead, with no resolution to the problem.
I'm not sure if it matters, but are you using a "regular" Gmail account or Google Apps for Your Domain? I'm doing the latter and still can't get it to stick (tried again this morning before posting). When I quit and restart Sparrow it cannot connect, and I have to reset the password before it will fetch my mail. Oh well!
I had severe issues too with the Mac app too, like lost email drafts. The problem is that email is difficult to handle. Sparrow does an excellent job with the UI and while that part was ready for a 1.0 release the email handling was not. It takes a lot of manual testing due to the way other email applications and servers abuses email standards. They released it to early for it to be labeled stable IMHO. The current release is decent though, but still found bugs and it has been a while since the latest update (they must have put all resources on the iPhone-app). Hopefully they haven't done the same mistakes with the iPhone-app. Looks great with my limited testing so far and I have replaced my main Mail-icon on my home screen.
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.
Same thing happened to me. To be fair though, I had issues with the app around a year ago and they promptly answered. It seems like they are a bit swamped with support issues now.
I can say from my experience so far with Buffer, that it is easy for this to get very hard to keep up with. Seems like they had similar great intentions like us to be amazing at support as well as build a fantastic product. We had a period where our support response time lagged as we reached a certain scale. We've since hired a freelancer for a few hours a day to help us and that's really transformed things to the point where we're better at support than we've ever been, and at the same time we can focus on what each of us in the rest of the team is good at. Whilst the freelancer does a lot, we dip into support every so often and have things assigned to us, so we're always in contact and understand customer problems, which I think is very important.
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.
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!
I find Sparrow for Mac much more pleasant than gmail or Mail.app. I’ve been on Sparrow’s beta build since the Sparrow beta started. I haven’t had any serious issues since version 1.0 was released, and I’ve received grateful replies to all of the minor issues I have emailed them about.
100% with you here - the latest version of Sparrow has some serious bugs that cause among other things, kernel panics. Previous versions have seen silently deleted messages, and other such nonsense. An email client should be, above all, reliable.
Sparrow has bugs that cause kernel panics? I've never seen this, but... I'd argue that if userspace programs can cause KPs, that's an OSX problem, not necessarily a Sparrow problem.
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)
I've also had a lot of problems, primarily that email subjects don't properly link to the body. Very confusing. I gave up on the app after a couple of updates.
I think the issue here is that it isn't really "push" they want to do. From what I can tell, they want to do is simply "run all the time so we can keep a connection open to receive new messages immediately". Which, to be fair, is pretty similar to what Apple does for their push notifications.
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.
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).
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.
Yeah: what we really want is a way to strictly limit Sparrow's permissions, so they can only see new mail as it is passed in, and maybe only just enough for something like push. However, that's really on Google's end to implement, and I'm not sure just how much interest they have in third party Gmail-specific mail clients.
Re push, I use an IMAP client called K-9 Mail on Android which has support for IMAP IDLE, which is basically the IMAP version of push. It keeps a constant connection open to my IMAP server and is immediately informed of any new mail. I have not noticed any reduction in battery performance since moving from 15 minute polls. I still get 1.5 to 2 days use out of it (HTC Desire Z).
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.
> I have not noticed any reduction in battery performance since moving from 15 minute polls.
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.
sure, K-9 Mail works fine and implements everything correctly. But what happens when you have 4 or 5 apps that start polling constantly for updates because they don't want to deal with push notifications? I think Apple opening up this functionality would be a mistake that's open for abuse by other developers.
I don't understand that page at all. It doesn't explain why the app was rejected or why they can't use the native iOS pushing. In fact, I'm quite unsure of what is unique about their use-case for push notifications that is different than... any other similar task in iOS.
The iOS push notification service works by having a remote server determine when a push notification needs to be displayed to the user. The only way for Sparrow to do this would be to store the gmail credentials of every user who uses their application on a server (instead of each individual users iPhone). This would obviously introduce a lot of security considerations that Sparrow don't want to have to deal with.
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.
When Apple announced the various background task "modes" available (push, call placing, audio recording/playing, task completion) I immediately noticed that one use case was missing, and that's something like cron/at. Just like Apple allows tasks to run for a few moments for completion, they could allow tasks to run at scheduled times or intervals for a very limited time span, and maybe limit the number of apps/triggers allowed.
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.
The point is not that it can't be done securely, it's that they don't want the hassle of being responsible for a large amount of sensitive information. By not storing the information in the first place they can guarantee that they won't be hacked and have their customers data stolen.
I was seriously shocked to see that the iPhone's native client leaked that bad. 2 questions:
1) Is it possible for an app to leak less?
2) Is the 'leakage' already commonly exploited by firms for specific means? (proving you saw something etc.)
My understanding (I don't have an iOS device) is that the standard iOS email client has remote images enabled by default, and if you turn that off, then it doesn't leak at all. I think all email clients should have the option to automatically load remote images, but that it should be disabled by default. The problem is, users don't understand that by clicking the "load remote images" button, it will be possible to track them, so they often don't understand its purpose.
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.
You are correct about iOS. On my iPhone 4 with iOS 5.1, with remote images enabled (by default) it leaks 17 out of 32 categories. With remote images disabled, it leaks 0 out of 32 categories.
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.
Interesting that it seems to loads remote Flash content. I wonder if you could do anything nefarious with that capability. I don't know Flash enough to comment.
Does it have an option to enable/disable automatic loading of remote images? If so, what is it set to by default? And does it still leak if you disable loading of remote images?
Such are the vagaries of being a large corporation -- your various departments' goals become increasingly at odds with one another. The Android team wants their platform to be successful. Part of that means not releasing top-tier applications for competing platforms. Gmail wants their service to be successful. Part of that means releasing top-tier applications for as many platforms as possible.
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
Why not? If Google gives me a crappy mail app on my iPhone I am definitely not switching to Android. On the other hand, if it is high quality I may actually be tempted to switch.
I've been a beta tester of their iPhone app for over a month now, and while the UI is stellar, I still haven't found it to be a replacement for Apple's Mail app because of Sparrow's lack of push.
I've been a beta tester for the last month or so as well and I can definitely say this has replaced Mail.app for me. I feel relieved not seeing the red notification bubble growing. It's been freeing and I've got a much better way of managing my emails now. I hope Apple comes around on notifications though so this app will be even more popular(already broken the top 25 paid apps here in Canada.)
Absolutely, but my point is that not having the option for the notifications is fine by me now that I've realized I can live without. I should have made that clearer though.
Unless Apple change his policy about Push (API) there is little Sparrow can do. Spaarrow is aware of this. They have a page dedicated to this Push problem:
There's something that they can do, it's written as the first option:
"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 like that they're being honest about this and are focussing on what they are good at. The request push option, useless as it may be with Apple in charge, might be just what is needed. As they already state, allowing an e-mail app into the app store in the first place is a step in the right direction. Why not try to prod Apple to take another one.
The problem is focusing on what they're good at leaves the user with only half a product.
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.
I'd say it's better to have half a product than to have a product that spills your e-mail credentials all over the web. It's not like they try to hide the shortcoming in their app, they are open about it. If you feel the lack of push is a dealbreaker then you can just not use or buy the app.
It might be better than that but it's not as good as the native mail app which doesn't have those issues, is the incumbent application for this sort of thing and is free and installed on all iPhones from the off.
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.
There is actually something _else_ they could do; run a service where you forward your email to an address on their end (with GMail's autoforward thing or whatever); they push notifications to you based on that. Of course, that would require server infrastructure, and there'd still be privacy concerns (though lesser ones, as they wouldn't have to _store_ anything).
Wow, this looks like a really good IMAP client for the phone. A major limitation of the built-in iOS Mail app is that it has no facility to combine sent/received mail into one conversation view (unlike Mail on the Mac).
Sparrow also features a nice polished UI, and is responsive.
I've tried a number of email clients on the iPhone. In the end, i nearly always end up reverting back to the default app. There's something about the simplicity of it that always brings me back. That said, the other apps were always slower fetching mail from gmail which never helps. The only app that i have found to be very good is the gmail for iPhone app, but i only use it occasionally when the default app cant find an email address from my gmail address book. I should really use the gmail app more. Its mostly good enough.
Either way, whichever app i settle with in the end, its going to be the one that is the quickest in operation.
This is nice, and the lack of push notifications can be seen as a feature – less distractions! One possible solution to that issue is to build a push notification server into the desktop version so they wouldn't have to store your credentials.
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.
Wouldn't that also delete the from my IMAP server (in my case, Gmail)? I'd also be worried about deleting the messages from my [All Mail] folder, which is what I have a real issue with (my inbox is rarely very large).
I'm becoming very irritated with Apple's behavior in the app store. While it's nothing new, I hate that they're restricting apps that compete with native apps.
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.
Apple's happy to let Sparrow use push. Sparrow didn't want to use push, they want to poll. Allowing that would be good for time-pressed or unskilled devs, but bad for users.
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...
Lack of push was a deal breaker for me. They argue they don't want to store the credentials on their servers, but at least with Gmail they don't need to as it supports OAuth. The only issue I can see is holding the IMAP IDLE connections open for thousands of users which can be a bi* and a half to get right. Although http://www.nuevasync.com/ guys have done it successfully.
They posted several icon drafts on Dribbble to gather feedback from the users, but it doesn't seem like they listened to the suggestions (or maybe they didn't have time to submit a new icon?).
I truly appreciate their caution in storing my personal information on their servers, but unfortunately it's just not practical to use until there is proper push. Hopefully Apple hears their pleas and allow it. This app looks gorgeous.
Just download and paid for the OSX app. It's really nice, love the unified inbox, pulls labels from gMail, and also you can create e-mail alias like (sales, support) and send from those alias. Highly recommended.
I wonder if they have plans to turn this into a universal app or if we will have to purchase another version for the iPad (not that I'm complaining about paying for a valuable product).
This app's really awesome. 2 small annoying things though, that I hope will be fixed later is:
› the freeze for a few seconds when I open the app (on an iPhone 4S)
› the lack of push
Would love to see a writeup on how to set up boxcar for as a replacement. Maybe Sparrow should implement their push notifications by just integrating with Boxcar and making it idiot proof.
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.
Due to how they implemented the "panels" interface, swiping left-to-right on a row will pull the entire panel, so they had to implement it as only right-to-left to expose the actions. Kinda annoying, but it was a design decision forced on them by another design decision they made.
Just quick question, since I lost a track of AppStore Developer's guides&rules: wasn't there a rule that an app that is copying functionality provided in iOS will not be approved? Was that changed? Aside of this email app, I dont see any music players for my iPod other than the native Apple app (I see plenty of opportunities for an upgrade).
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.