If you have a mobile app you have probably heard about Apple’s rules released this Fall regarding mobile apps built using a platform or system such as Subsplash or Pushpay (eChurch). Apple in an attempt to reduce the number of garbage apps in their store has decided that such apps will no longer be allowed.
Both Pushpay and Subsplash have responded to this news by preparing a single new app which all churches will have their congregants install. Once opened the app will allow the individual to enter the name of their church and will pull up the respective churches’ content.
For the moment both Pushpay and Subsplash will allow existing stand-alone apps to remain as such, but I would expect that this will be a temporary solution which will be phased out sooner than anyone would like as maintaining the development of two systems will be a burden I doubt either will want to bear long-term.
So, my question is, how are you handling this? What are your plans? Will you keep your current stand-alone app as long as you can? Migrate to the new single app now? Go another route to ensure you get your own app in the app store?
I read over the actual Apple rules and my initial reaction was that Apple was trying to keep out the garbage and these rules might not specifically apply, but representatives I’ve spoken to from both Pushpay and Subsplash have indicated their companies have been talking with Apple about this and that Apple is not planning to allow these sorts of apps in the future.
More information is available on this TechCrunch article. I believe the intent is to eliminate app-builder apps entirely due to their tendency to be extremely low quality and poorly maintained. I know that’s been pretty consistent with my experience of Bluebridge apps.
I think a good part of the question should be do you really need an app or is a mobile friendly website a better option? Especially considering how many of these template apps are really just web views under the covers anyway.
We have both. For actual congregational engagement, the app gets FAR more use and is easier to explain to people less technically capable. This is a painful situation to be honest and a disappointing move.
I would imagine if you have an app that’s seeing good engagement and is in reasonable software condition (doesn’t crash most of the time, doesn’t fail to load content, doesn’t spin endlessly on load, doesn’t have loads of marketing push messages, etc.) that you’ll be alright for a while longer - but the writing is on the wall.
We seem to get better engagement with our app than our (mobile-friendly) website. I’m not sure why, though I’ve wanted for a while to do a little focus group with app users and ask them.
We just launched with Pushpay/Bluebridge/Echurch/whatever-they’re-calling-themselves-now about two months before the new rule was published. Needless to say we’re thrilled with the timing, with Apple, with Pushpay, just thrilled with everyone.
My suggestion to my boss was to transition to the consolidated app sooner rather than later given that Apple will eventually block updates to and/or unpublish the now non-compliant apps, and it’s par for the course with Apple that no advanced warning will be given. He wants to wait as long as possible so congregants don’t think we don’t have our act together rolling out another, different app less than six months after our initial roll out.
I think we both have valid points and we haven’t decided on timing yet, but we’re definitely planning on continuing with Pushpay in their consolidated app - it’s basically a wrapper around their existing app that handles the extra new tasks like searching for your church and pointing the app to the correct content database. It will use the same back-end as the current standalone apps.
There’s a few items Pushpay still need to work out before we’d be on board with the new platform. We definitely want them to do more testing - we’re happy to let other churches be the guinea pigs. And there are some branding issues - e.g. you can specify the app icon you want in the standalone apps, but to programatically change the app icon in iOS you need to bundle and list all the possible icons inside the app - not at all scalable. Losing the custom icon would be a major bummer, especially since we’re not thrilled with the default branding. Pushpay have suggested that we wait until they roll out a few new features that were already in the pipeline and then publicly spin it as an updated version with new features rather than a different app.
For those with a SubSplash app, a new “consolidated” app is available on the Apple app store. Search for “The Church App” and install to try it out. When you open it for the first time it asks you to choose your church. After that, it seems to work just like the standalone app, except a custom church logo does not display on the home screen icon or when the app first opens. I don’t know the deadline for moving from the standalone app to the consolidated app, but it looks like SubSplash is ready when that deadline comes up.
I personally don’t understand the need for a church app. Generally they offer just a subset of what’s already on the church website, but have more limitations of what can be displayed and linked to. A shortcut to a church website can be saved to the home screen with a nice icon, and after that is done it looks and works just like the app icon. True, you can’t send push notifications, but we have many other ways to communicate already. As far as engagement/usage, people will go where the content is. If you have an app and promote it, they will go there. If you don’t have an app and promote the website, they will go there.
The final details of the changes have been revealed.
4.2.6. Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences.
Another acceptable option for template providers is to create a single binary to host all client content in an aggregated or “picker” model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant, or as an event app with separate entries for each client event.
This basically means if you have a templated app, that’s fine but it needs to be published and signed by your Apple Developer account. This will cause some extra work, but doesn’t forbid you from using your templated app (and helps you prevent lock-in in the future if you want to change vendors). Kinda sucks that you’ll have to pay the $99 /year for a developer account, except that you probably won’t.
So now the question is… How do you guys feel about that?
I would actually prefer to have a templated app (with support from a dev company), but maintain some kind of control for our organization over it. Even if it costs $99/year for a dev account.
However, I am skeptical that the existing companies selling these ‘subcription w/ support’ apps (Subsplash, Pushpay, BlueBridge) would like that model. Are they really going to give us some kind of binary/code that we can walk with (and potentially reuse) easily?
This is super interesting. Love the discussion happening around this.
I get why churches want to have an app and if you are big enough, it’s probably a need at some point. App engagement is such a big deal. So is mobile web, in reality, we should be focusing on that also.
I don’t think churches should go out and try to build native apps because of this though. The expense, support, and maintenance tail on native development is something I think few should mess with.
I think companies will innovate and figure out some good ways to offer better 3rd party solutions once the dust settles and they’ve had some time to adapt.
I also think the consolidated app model will work great for lots of organizations. It makes sense. It’s easy to find. The stigma will wear off. I think there is some weird ego and hubris wrapped up in having your own specific app in the app store.
@sross I’d say it shouldn’t matter, because the backend is required for the app to keep working and the app developer controls that. On the other hand, I’d imagine that since the various app companies have now invested so much time and money and PR effort in the new consolidated app they won’t be very excited to continue supporting standalone apps. We’re going to reach out to Echurch within the next week or so to see how they’ve decided to respond to Apple’s change of heart.
@Cshurtz We looked seriously at contracting a mobile app developer nearby to build us a custom app, and between the cost of mangement and maintenance and the up front development, it was completely cost prohibitive to us. Not even remotely within the realm of possibility.
I agree that not everyone needs an app and that it’s probably much more sensible to focus on your website. And yet, we still seem to get much better engagement on our app than on our mobile-friendly website. Still puzzles me.
Wow, this wasn’t even on my radar. I’m so glad you posted this.
Our Communications department handles the app within our church, but I’ve forwarded the relevant information to them. I’m not sure if it was on their radar either.
Just had a talk with our echurch rep yesterday. She confirmed that echurch will support standalone apps. She mentioned that Apple told them it will waive the developer account fee for the first year. She also affirmed that all the new features they teased for the consolidated app will also be coming to the standalone app too.
