A Citizen App for Municipalities, Built on the City Website

Reuse what the city already runs

Most municipalities already maintain the content a citizen app needs: news on the city website, online services and appointment booking in a service portal, a problem-reporting form, a waste collection calendar, an events listing and council information. A citizen app should bring these together on the phone, not duplicate them in a second system that editors must maintain.

• The website CMS remains the single source for news and pages.
• Online services open in the app with the same login as on the web.
• Third-party portals that offer their own app are linked, not rebuilt.
• Push notifications are the one genuinely new channel.

Push for local alerts, not life-safety warnings

Push is the main reason residents install a city app. Typical uses are road closures, water outages, waste collection reminders by district, and cancellations of public events. Let residents choose topics and areas, and define who in the administration may send which category.

Be clear about one limit: push delivery is not guaranteed, and phones may be muted or offline. National and regional warning systems remain the channel for emergencies. The city app complements them, for example by linking to official warnings and by covering local information those systems do not carry.

Accessibility is a requirement, not a feature

In the EU, the Web Accessibility Directive covers public-sector websites and mobile apps, with EN 301 549 and WCAG 2.1 level AA as the technical reference. In the US, the Department of Justice's ADA Title II rule sets WCAG 2.1 AA as the standard for state and local government web content and mobile apps. This is general information, not legal advice. In practice, check:

• The reused web pages already meet your accessibility target; the app inherits their strengths and weaknesses.
• Native parts such as navigation bars, splash and offline screens work with VoiceOver and TalkBack and respect system font sizes.
• Zoom is not disabled in the viewport settings.
• An accessibility statement covers the app, with a way to report barriers.

Procurement: what to secure in the tender

Public procurement rules differ by country and contract value. Independent of the procedure, these points belong in the requirements:

1. Publication in the municipality's own developer accounts, with the vendor working through assigned roles.
2. Handover of the full source code and build documentation, so another vendor can take over later.
3. Accessibility conformance and the obligation to fix reported barriers.
4. A data processing agreement, hosting location and a list of all third-party services, such as the push provider.
5. Maintenance terms for operating system and store policy updates, which Apple and Google change regularly.
6. Evidence of information security management, such as ISO 27001 certification.

Publishing under the municipality's own account

An app that carries a city's name and coat of arms should come from the city. Both stores scrutinize apps that appear to represent public authorities, and Apple rejects template-generated apps unless the content owner submits them. Register organization accounts in the municipality's name; Apple requires a D-U-N-S number and offers fee waivers for eligible government entities in some countries. Use a functional mailbox, not a staff member's address, so the accounts survive personnel changes.

How jocapps can help

WeSetupYourWebViewApp turns the city website or portal into store-ready iOS and Android apps within 72 hours, including full source code, which keeps the municipality independent. For tenders that require custom features, integrations and long-term SLAs, OnlineAppCreator is our B2B and B2G delivery team, ISO-certified in Germany. appsubmitter.io handles signing, CI/CD and submission directly in the municipality's own developer accounts, including help with rejections. On account setup, see Apple Developer accounts for organizations, or book a free 30-minute intro call.