I wanted to see if anyone could tell me if they were able to get the fee waived for Apple when setting up to deploy an app int he app store? Reading online, seems Apple will waive the fee for non-profits.
Anyone been successful in this? Can you share the details/steps/pros/cons?
Thanks!
-Robert
Code for Cary (NC)
I’ll look into this from the CfA side. It looks pretty straightforward to apply as an organization. Assuming they grant us a fee waiver, I imagine we could probably create you an account that isn’t subject to the fee.
Someone recently asked about this at OpenOakland too… I’d love to have this fee not be an impediment to your progress.
Should we talk about maintaining network-wide shared developer accounts for native mobile apps?
Losing access to developer accounts that mobile apps were published under by previous brigade members is a big source of headaches, as not having the logins or not having the signing keys can mean you can’t update or delist an app that was previously published
I think it would be a great idea if we had a national “CfA Brigade” developer account for Apple and Android and formed a small working group tasked with handling publishing apps and hanging on to credentials to provide continuity for future brigade leaders/members that may want to update or delist previously published apps
This sounds like a good idea to me.
However, at Code for BTV our approach is to never own the developer account that publishes something to the app store. Instead, we help the client establish an account, and when we finish, everything is on them. We often have keys to that account, of course, so we can publish on their behalf. But ultimately, the accounts we put stuff in the app stores from are not our own.
When you say “the client” are you talking about project-level partner orgs?
I like that approach for projects that have an intuitional owner, though I worry sometimes whether they have the capacity to be responsible custodians of technical credentials/services.
For brigades and projects though that are just a collection of brigade members, I feel like we’re failing our duty to our members if people are contributing to a project they see as community-owned where something vital to its operation like mobile dev accounts are personally owned/controlled by one of the other members. Not that there’s often any malicious intent behind it, but eventually life happens if no one technical is in position to extract credentials at the right time everyone’s work gets effectively locked up
Yeah - for us we don’t formally adopt and work on a project unless there is a community partner who effectively will own it at the end. We avoid doing projects that are just cool ideas the brigade has. Maybe if we were bigger there would be some ongoing projects that had no community client.
I agree with you that if you do have projects that are meant for a broad audience, they can’t have logistical bottlenecks built-in like being attached to a particular volunteer’s accounts. That’s bad…
Hey everyone, I sent the following reply to Robert via Email. I wanted to post it here as well for posterity:
Unfortunately, we are not able to offer Apple and Google Developer accounts under a common Code for America account at this time. This is for a couple reasons stemming from the fact that Apple/Google developer platforms are not designed to fit our decentralized use-case.
What I mean by that is that these platforms present to the user a single, validated, corporation name as the author of an application. For us that would be “Code for America” or “Code for America Labs” (our legal name). This is likely to be confusing to your users, who would expect to see the product being authored by your Brigade. Furthermore, it presents a concern that if/when a Code for America staff product team decides to publish an app, we would have everything lumped together (brigade projects + staff projects) which would present another potential source of confusion for users.
Do you know if you would be able to register a developer account under the name of your Brigade? We’d be happy to help make that happen from a legal standpoint as long as it ends up that the app publishing decisionmaking lives entirely within your brigade, and the user experience of downloading an app from your brigade makes it clear that the app is from your brigade and not CfA itself. Your Brigade should already have a Relationship Letter that designates your Brigade’s official relationship to Code for America, which should be a good start. Although, I’m not sure if it will be possible to claim the 501(c)3 discount in this case.
I should also say – I am not personally an expert with mobile app distribution platforms, so if there is another option here that I am missing, please do let me know.
This is mostly in reference to the idea of creating a Network-wide account, e.g. Chris’s idea above:
At this time, I don’t see the demand to set this up – very few Brigades publish native mobile apps. If this need emerges from Brigades, we can reconsider this of course!
From my own experience, it became common knowledge long ago that shipping a native app under a brigade is too big a pain to be worth it. Under this reality, demand would never get the chance arise.
It would be a leap of faith to assume that if we made it easier for brigades to ship native, they would do it more. If we’re contemplating shifting the core equation behind whether it’s a good idea or not for a brigade to ship native code though, nothing we see today is evidence of what we’ll see when such a mass of creativity as the brigade network gets a new lens
Let’s instead start from the question: if a brigade member was inspired to serve the mission via shipping a native experience, how should they do it?
Neither of these are workable for any brigades but maybe a couple around the bay. The situation makes it make no sense to consider native in civic tech, even though there is considerable creative energy and it’s a major way humans interface with technology. A native developer looking at how to contribute to their community via civic hacking would be right to conclude they couldn’t really be effective, they may never show up in the first place and gain the buy-in required to make demands
I see our core purpose as a network of brigades is creating spaces and pathways for technical creative expression that has an impact in our communities. So what would the best user experience we can imagine look like for the potential brigade member whose inspirations are in native mediums? How do we not utterly waste their time? Let’s start from there and then make what concessions we must around what’s most practical for now.
If there were to be a “CfA Brigade Network” developer account, how could that work?