Suggestions for FastMail's mobile apps

[emailer84]

Hi Rob,

Really looking forward to this.
Any iOS screenshots to share?

Along with notifications through iOS, I'd really like the app to keep a user's login/password, so that they don't have to be entered each time.

Also, Extensions support, so that any app can email.

Keep us updated please.

[robn]

Originally Posted by emailer84

Any iOS screenshots to share?

Not exactly. If you load up the FastMail web client in Mobile Safari, then you've got a pretty good example of what it will look like. The main difference is that there's no browser chrome (location bar, navigation) - its just FastMail full-screen.

Everything else is behind-the-scenes platform integration stuff.

Along with notifications through iOS, I'd really like the app to keep a user's login/password, so that they don't have to be entered each time.

It won't store your username/password. Instead it will create a long-term session, exactly what the website does when you check "keep me logged in". So as long as you keep using the app, then your session will hang around forever.

This method is nice because it lets you sign out the mobile app through the "password & security" screen.

Also, Extensions support, so that any app can email.

Its definitely a good thing to do. I don't know if it will be in the iOS app in the first release, but we'll be constantly improving the apps much as we improve the web client.

[emailer84]

Originally Posted by robn

Not exactly. If you load up the FastMail web client in Mobile Safari, then you've got a pretty good example of what it will look like. The main difference is that there's no browser chrome (location bar, navigation) - its just FastMail full-screen.

Everything else is behind-the-scenes platform integration stuff.

OK thanks. This sounds quite promising.

It won't store your username/password. Instead it will create a long-term session, exactly what the website does when you check "keep me logged in". So as long as you keep using the app, then your session will hang around forever.

This method is nice because it lets you sign out the mobile app through the "password & security" screen.

OK, but does it share cookies/history with mobile Safari?
If for example, I were to clear mobile Safari's history, would the FM app lose its login status?

Its definitely a good thing to do. I don't know if it will be in the iOS app in the first release, but we'll be constantly improving the apps much as we improve the web client.

Looking forward to seeing this app.

[neilj]

Originally Posted by emailer84

OK, but does it share cookies/history with mobile Safari?
If for example, I were to clear mobile Safari's history, would the FM app lose its login status?

No, they're completely separate.

[emailer84]

Originally Posted by neilj

No, they're completely separate.

Good to know.
Thanks.

[Hlao-roo]

So no app for BlackBerry 10?

Seriously, though, I'd love one. My main complaint with the mobile Web interface is that the keyboard predictive text doesn't kick in when I'm in the compose field.

BlackBerry Hub is good enough for most everyday applications, but sometimes I miss the power of the Web UI.

[wakaba]

I have a minor request for the iOS mobile app.

In the current mobile interface, whenever I click on the reply or forward button for an email, it takes a couple of seconds for the reply screen to load (presumably because some communication is taking place with fastmail servers?). Is there any way to eliminate this waiting time in the mobile app (perhaps by doing any processing locally), so that replies can be instantaneous?

[randian]

One concern I have with the app just being a wrapper around the browser is the lack of calendar/contact integration with iOS/Android. Real native apps can solve that problem.

[robn]

Originally Posted by randian

One concern I have with the app just being a wrapper around the browser is the lack of calendar/contact integration with iOS/Android. Real native apps can solve that problem.

Wrapped apps can solve that problem too, if you want to

But yes, its something we're thinking and talking about quite a bit at the moment - just what does integration between the webapp and the platform look like? We haven't decided yet, and have no timelines. For the moment CalDAV/CardDAV sync is the way to go.

[randian]

Originally Posted by robn

Wrapped apps can solve that problem too, if you want to

That's neat. I thought it would have to be sandboxed like regular web pages are, since it was described as a wrapper around the regular mobile site. Mobile browsers don't let web pages read, alter, or delete your contacts or calendar info.

[robn]

Originally Posted by randian

That's neat. I thought it would have to be sandboxed like regular web pages are, since it was described as a wrapper around the regular mobile site. Mobile browsers don't let web pages read, alter, or delete your contacts or calendar info.

The way it works is that you write a regular native app, but instead of defining the UI with regular platform buttons, labels and other widgets, you embed a "WebView" component. That component is just the rendering & Javascript engine of the browser; there's no UI facilities like the location bar, tabs, bookmarks, etc. The native app has complete control of the facilities the browser can offer, and it can also expose additional services to pages/apps running inside the web view.

The FastMail apps (Android and iPhone, they structurally the same) do exactly this. The native app configures the webview to have extra Javascript properties that help the mobile webapp know its running inside the native app and change its behaviour in a couple of subtle ways. They connect to the Google/Apple push channels (they're only available to native apps) and then pass the device token to the mobile webapp Javascript, which then submits it to FastMail servers so we can generate notifications. There's a few other things in there they do, mostly around preserving state across app restarts.

On Android, Chrome/Chromium is the only webview that performs well enough to run the mobile webapp. Unfortunately that only became available in Android in 4.4; earlier versions use an older, slower webview based on Webkit that makes the webapp pretty much unusable. To get around this, the Android app bundles a third-party Chromium-based webview called Crosswalk, which gets us great performance back to Android 4.0. I actually got an old Galaxy S, installed Cyanogen on it, and then the FastMail app, and its very usable there.

On iOS there's none of these problems - the system webview runs the FastMail mobile webapp great back to iOS 5, I believe.

So anyway, back to calendar and contacts integration. If we wanted to let the apps communicate with the platform calendar/contacts, the way to do it would be to build a "bridge" inside the native portion of the app that makes the system calendar/contacts facilities available to the mobile webapp via Javascript. Actually exposing this to Javascript isn't hard, its just writing some code. Its all the interactions that are complicated.

Most of what we're thinking about is how it plays with sync, and with third-party calendar/contact sync. Think about calendars. If you had your phone synced via CalDAV to FastMail, natively to Google, then you have a FastMail/Google CalDAV sync, then the mobile app is managing the FastMail server calendar, and talking to the local calendars, and suddenly you've got this very complicated set of interactions. Part of it is that its technically difficult to solve, and part of it is figuring out exactly what the purpose of the FastMail app is. Are we trying to be a calendar and contacts manager when your phone already has perfectly competent apps to do that?

These are difficult questions. We're talking about it a lot at the moment. We haven't yet decided what we're going to do, if we do anything at all. So for now the easiest thing to do is to treat the FastMail app is its own FastMail-specific world, and if you want to get your data from FastMail to your native platform database, you install/configure CalDAV/CardDAV sync.

[randian]

Originally Posted by robn

These are difficult questions. We're talking about it a lot at the moment. We haven't yet decided what we're going to do, if we do anything at all. So for now the easiest thing to do is to treat the FastMail app is its own FastMail-specific world, and if you want to get your data from FastMail to your native platform database, you install/configure CalDAV/CardDAV sync.

I see the problem. I think the other way would be nice too. If I have my contacts at Google or iCloud but not at Fastmail it would be nice if the Fastmail app could still use them, since the native mobile platform will obtain them via its standard sync service.

[robn]

Originally Posted by randian

I see the problem. I think the other way would be nice too. If I have my contacts at Google or iCloud but not at Fastmail it would be nice if the Fastmail app could still use them, since the native mobile platform will obtain them via its standard sync service.

I think that address autocomplete from the local contacts database as a convenience would be fairly easy to do and not complicate matters too much. But I don't think we'd expect to see these in the FastMail contacts view (until we figure out all the stuff mentioned above). I'll look into it further sometime. Its not a v1 feature

[ankupan]

Hi,

FM can outsource this thing. like https://www.nuevasync.com/

Even Rackspace and Luxsci also using them.

It will be better and user will not mind to pay for some extra $ for it too.

I am willing too

[WormholeLawyer]

Originally Posted by robn

Well you should never say never, but right now we've got no plans for one. Our browser stats show Windows Phone users as less than 2% of regular users to the mobile app. Of course that doesn't mean that there wouldn't be more users if we made an app available, but it does make it very hard to justify the time, particularly when no one on staff uses Windows Phone day-to-day. That makes dogfood testing very difficult!

As usual, if it becomes clear that there's demand for it then we'll consider it further.

Only problem with this is it won't be stored offline like a native app, right? I've never been a fan of web apps for that reason. I just wish iOS Mail.app worked more seamlessly with Fastmail, since Mail.app is way more integrated into the OS than any app could be. Like I wish you could set the from address to *@mydomain.com and it auto respond as whatever address the email was sent to, like you can do on the web app.

And Exchange or push notifications for regular Mail.app would be a dream. But I know these things won't come, just being wistful!