They can be (it's a non default but available checkbox on the CN interface) but they have to be very very carefully tested. Normal CentralNotice banners tend to end up being so large on the mobile system that they can be highly intrusive and it is difficult to do things like close the banner.

Hey Pine, The mobile apps do not display CentralNotice banners. The reason for this is because that the apps are not based on the MediaWiki technology stack at all so we don't get the integration for free, and there is no convenient API for CentralNotice which means it'd be a lot of work for us to integrate with it. And since we're still a very small team, building this API and hooking the apps into it isn't a priority right now. Thanks, Dan On 5 February 2015 at 13:48, Pine W <wiki.pine(a)gmail.com> wrote: -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

Hey Pine, Thanks for the questions. Sorry for my delay in responding, I've only just reached this point in my email backlog again (at 10pm on a Sunday, no less). My responses are in-line. On 5 February 2015 at 17:18, Pine W <wiki.pine(a)gmail.com> wrote: I think that's the wrong way of framing the question. Most companies with a mobile presence heavily prefer people to use their app instead of their mobile website. There are many reasons, such as: - *Responsiveness*: Apps are much easier to create compelling user experiences in than websites due to having native access to the hardware of the device, allowing for things like swipe gestures and parallax scrolling. - *Notifications*: Local and push notifications are powerful tools for driving repeat engagement, and that's what website developers care about! - *Reduced startup cost*: The user opens the app, and their login persists infinitely and easily and it can take them right back to where they were. This saves the user time. - *Monetisation*: Apps are easier to make money out of, because the user's payment credentials are often already saved so it reduces the user's overhead to spend. Some of these don't really apply to us; we're a non-profit, so maybe we're not interested in monetisation. But many othes, like responsiveness, do apply to us, but we're not really leveraging them right now.That's simply because we're entering really late into the mobile apps field, and our app isn't developed enough as a product for things like notifications to make total sense yet. But, notably, our app was also not very responsive at first, and now with lead images that responsiveness is increased... and our latest alpha build offers an even more compelling experience than that. We're making progress. :-) Then there are other factors which are particularly true for us, such as development speed: app development is a lot faster and easier than developing on the MediaWiki technology stack due to their self-contained nature. This lets us do readership experiments (like lead images) and learn much faster than we could on mobile web. And because the app has much smaller readership, making changes like this is nowhere near as disruptive as it would be if we did it on desktop or mobile web. So, in short, apps can do things that are practically impossible on mobile websites, and we want to leverage that. Mobile is very important for us. Both mobile web, and mobile apps. They serve different needs right now, both to us as an engineering organisation and also to our users (e.g. quick lookup on mobile web, and long reading on mobile apps). Yes! We had 2 engineers on Android and (approximately) 1.5 on iOS just over a month ago. Now we've had an internal transfer as well as hiring two more engineers, bringing us to 4 on iOS and 2 on Android. We're also hiring two more engineers to level out the platform inequality, and we're hoping to have them within a few months. That'll bring us to 4 iOS and 4 Android. Hopefully that answers your questions. I'm happy to answer any more that you might have! Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

I doubt that team will be growing soon; it grew a lot recently, going from 3 to 7 devs in the space of a few months or so. When a team grows so rapidly it needs time to find its feet afterwards. Tomasz is the mastermind behind the engineering team though, so I defer to him for comments on this.