Rikki

The only app being tested right now is a 'white-label' app for this community. The multi-community test will come later. We're gradually expanding the number of testers, so sit tight 🙂

Whoops, you're right. Text isn't a 'child' in CSS, so actually I don't think there'd be a way to do this with CSS alone. Sorry for the confusion!

You could actually do this already - add this to your custom.css theme file: .ipsType_richText span.ipsEmoji:only-child { font-size: 48px; }

We anticipate it'll be available with v4.5, or shortly afterwards 🙂

Luckily, thanks to our work on the native app, we now have a services infrastructure that can register user devices and send notifications - when we feel the time is right. That's an example of the work we're doing on the app feeding back into the main product. You are obviously welcome to voice an opinion, but I feel like we're going in circles a bit. We've explained why we're going this route and why we don't feel PWA should be a sole focus right now, so repeating "but why?" in every reply won't get a different answer at this point.

My personal recommendation is use a password manager, preferably one that stores the encrypted passwords on your own storage (e.g. your own cloud account) rather than a central server. That way you can generate extremely good passwords and maintain a different one for every site without any hassle.

This part alone is enough reason for us to provide an app, I think. Many admins that offer TapaTalk have been itching for a first-party (or even a third-party) alternative. They view TapaTalk as a necessary evil, not something they're legitimately pleased to offer their users. We hope to be different in that regard. Regarding web vs. not web. If web apps on their own were perfect, there'd be no market for TapaTalk, for example - but as you say yourself, there clearly is. The lines are blurring though; the codebase we have for the native app can be transformed into a web app with a little effort. It is, after all, built on a framework originally designed for the web. We will be able to take what we learn from building a new native app, and apply that to the regular web view. Probably not in the 4.x line at this stage, but certainly in the 5.x+ lines. Some of the work may even be directly beneficial. For example, with the new API, we or third-party developers could build entirely new ways of using the Invision Community platform on the web. Finally, we know the app won't appeal to all communities, for various reasons. That's OK. The app won't stifle any potential PWA work (and as I said, it'll actually make it better), so those that don't want to use the app won't lose anything. Those that do will gain a new way of offering their community to users.

We have a fix ready and it should be in the next release 😊

Yes, but we don't do that right now. I just don't want to completely rule it out from ever happening, because doing that tends to bite us later 🙂 It's not something we have on the roadmap at the moment.

Yes, that's a fair comment. When I use TapaTalk I get much more of a 'platform' vibe from it, as if I'm using TapaTalk first and foremost, and the actual community is secondary to that. We've tried hard to do the reverse and make sure each community feels like it's separate from the others. Right now for example, there's no central login system, central activity feed or central notifications, no cross-promotion of communities and so on (though I can't say those things will never appear - I do think there's justification for some of them). Each community is entirely standalone once you tap into it from the directory.

As with other (currently) supported areas, Downloads will open in a webview inside the app. It's relatively seamless. Yes, you'll be able edit the language using the regular translation tools.

Blogs will certainly be supported too, but in terms of priority it would be lower than, say, Gallery which sees more use. On the plus side though, Blogs are also easier to support than Gallery, so there is that 🙂

Gallery and Clubs are both high on the priority list. Pages is tricky to do because people do so many custom things with it, whereas a native app needs its views built ahead of time. That said, I'd love to find a way of offering some pre-built views that you can choose for each database. It won't work for every site but it'd hopefully cover the common situations. There is a new GraphQL API that powers the app. While we're building it for the app, in theory any application would be able to use it.

Yes, that'll be a built in option 🙂You'll also be free to make your own banners/announcements/etc. of course too.

It actually compares pretty favorably to TapaTalk already in terms of features. It's important to note that all user handling is done by your community. We don't handle registrations, login or act as a middle-man. Once the user taps to enter your community, it's all handled by your IPS4 installation via a new API. The only exception to this is push notifications, which for technical reasons must route through our own service from your community. As a side effect of this, it means we aren't offering a global "Invision Account" type service right now. Users will need to register and log in to each community they wish to visit in the app. We hope to offer a premium option for users and/or communities later, but we also don't want to hoist ourselves with our own petard by ruling in or ruling out particular ideas at this early stage. We'll see what the reception to the app is once it's in users' hands and go from there.