Apple · App Store Review Guidelines
Read this before design starts, not just before submission. Account deletion, sign-in options and the minimum functionality an app must offer all affect your screens.
Open the guidelinesA software studio on City Road, London
Software that grows as one system
We design, build, publish and look after mobile apps and web platforms. Instead of separate deliverables, we treat every screen, service and release as one connected system.
Field notes
Problems usually start where parts meet
An app can look finished and still let people down. The sign-in service times out on a train. The content team cannot change a price without asking a developer. The store listing promises a feature the release does not have. None of these shows up in a screenshot. They happen where one part depends on another.
So before we design a screen, we map the whole system: who uses it, which data it relies on, which platforms it runs on and how each update reaches people. The map doesn't need to be big. It's usually one page that everyone involved, technical or not, can read and correct.
That page then shapes the plan. The data rules are written once and reused by the app, the website and the admin tools. Release work starts in the first week instead of at the end. The handover documents are planned from the start, so your own team can run the product when we step back.
Interactive diagram
Choose a part to see what it feeds
Each discipline we offer depends on the others. Select one to see what it covers and where to read more.
Discovery
A short, structured look at your goals, users, existing systems and constraints. You get a system sketch, a prioritised scope and a plain-language list of risks. Everything else starts from this.
How we workMobile apps
iOS and Android apps, usually built from one shared codebase, that follow the same data rules as your web platform so the two never disagree.
Mobile developmentWeb platforms
Websites, customer portals and web applications with content editing your team can use, measured performance and accessible markup.
Web developmentInterface design
Flows, wireframes, prototypes and a component library that designers and developers can both maintain.
UI/UX designPublishing
App Store and Google Play submissions, listings, privacy declarations and gradual rollouts, done alongside you rather than out of sight.
Publishing helpCare
Monitoring, updates and an agreed way to report faults after launch, so the product keeps working instead of slowly falling behind.
Support & careOur services
What we can take on, and what you receive
Mobile apps
iPhone and Android apps that work on poor signal, respect large text sizes and screen readers, and ask for permissions only when needed. We usually recommend one shared codebase, and we explain in writing when fully native code is worth the extra cost.
You receive source code in your own repository, test builds through TestFlight and Google Play testing, an architecture note and a handover session.
Web platforms
Public websites, customer portals, internal tools and the APIs that connect them. We choose well-documented technology over fashionable technology, and we tell you when a simple static site is enough.
You receive an accessible front end, content editing with a short guide, a hosting note and a redirect map for any migration.
Interface design
Research with real users, flows and wireframes that cover empty, loading and error states, clickable prototypes, and a component library so new screens stay consistent.
You receive a research summary, annotated wireframes, a prototype, design tokens and accessibility notes for each component.
Publishing help
Developer accounts in your organisation’s name, signing, store listings, privacy declarations, replies to reviewers and gradual rollouts. Available whether or not we built the app.
You receive a release checklist, listing copy, a privacy worksheet and a rollback plan.
Support & care
Monitoring, dependency updates, preparation for each year’s iOS and Android releases, and an agreed way to report faults during working hours.
You receive a written scope, a short monthly health note and planned time for fixes.
Project planner
Sketch your project in a minute
Tick what your product includes and choose how far along it is. The planner lists the workstreams it would probably need and what to gather before a first call. It all runs in your browser, and nothing is sent or stored.
How we work
The five stages of a project
- Listening
- A free conversation about your goals, users, deadlines and what already exists. We ask to see your current systems and any research you hold.
- Mapping
- A paid discovery that produces the system sketch, a prioritised backlog and a written estimate with the assumptions set out. The document is yours to take elsewhere.
- Growing
- Design and development in short cycles, each ending in a working build you can try. Decisions go into a shared log rather than relying on memory.
- Rooting
- Release preparation, store submission, monitoring set-up, and a handover session with written documentation.
- Tending
- Optional ongoing care, agreed in writing, during standard hours: Monday to Friday, 09:00–18:00 UK time.
From the field library
Three things worth reading before you commission software
GOV.UK · Accessibility requirements
A clear explanation of WCAG and accessibility statements. It is useful even if you are not a public body, because it sets out what “accessible” means in practice.
Read on GOV.UKICO · Guide to PECR
When a website or app needs consent before storing anything on a device. This is the reason our own site asks before it remembers your checklist ticks.
Read the ICO guideAfter launch
Someone still answers when something breaks
Operating systems update every year, libraries age, and real users find cases nobody tested. We offer three levels of care: Watching for stable products, Tending with reserved time for fixes, and Growing for products with a roadmap. Scope and response times are agreed in writing for each client.
Compare care levelsA good fault report includes
- What you were trying to do
- What happened instead, with the exact error wording
- Device, system and app or browser version
- Whether it happens every time
Please never send passwords or your customers’ personal data.
Questions
Asked before most first calls
Who owns the code and the accounts?
You do, from day one. We work in your repositories and in developer accounts in your organisation’s name, as invited team members.
Can you take over an app someone else built?
Yes. We start with a code and dependency review and a test build, then write a health report before suggesting whether to stabilise, refactor or rebuild.
How do estimates work?
Discovery produces a written estimate with ranges and assumptions. If the scope changes, we tell you in writing before doing the work, not afterwards on the invoice.
Do you publish client names or testimonials?
No. We discuss relevant previous work privately, where clients have agreed to it.
Do you offer out-of-hours cover?
Not as standard. Our hours are Monday to Friday, 09:00–18:00 UK time. Any other arrangement is agreed separately in writing.
Can we meet in person?
Yes, by appointment. Our correspondence address is 128 City Road, London, United Kingdom, EC1V 2NX.
A rough idea is enough to start. Tell us what you want to build.