Where this service fits
A release is a coordinated piece of work involving the app, its backend, store information and the people responsible for support. We help identify those dependencies and prepare the production build. The aim is to make the submitted experience match the product you have reviewed, including account flows and any environment-specific integrations.
Testing follows an agreed set of devices and user journeys. We check the important interactions, permissions and application states, and organise findings so fixes can be prioritised. Submission support can include build signing, configuration checks, listing assets and responses to review feedback. Store acceptance and review timing remain with the platform.
What the work can include
We agree the deliverables around your product and existing setup. A focused engagement can include the following work.
- Device matrix and release readiness review
- Agreed functional checks and issue tracking
- Production build and submission preparation
- Handover for updates and ongoing maintenance
Planning your project
Bring the current build, known issues, store accounts and release deadline. We identify dependencies such as legal copy, screenshots, reviewer access and backend readiness. A first release and an update to a live app have different risks, so the checklist should reflect the actual situation.
The estimate should identify the work, assumptions and responsibilities on both sides. We can shape a first phase around the highest-priority outcome, with additional work planned separately once the relevant decisions have been made.
Share your starting pointPrepare for real devices and a real release
Testing needs to reflect how mobile products are used. We agree a device and operating-system matrix, check the important flows and consider permissions, backgrounding, poor connectivity and expired sessions. Purchase-related work also needs attention to subscription status, restored access and the difference between the development and production environments.
Release preparation can include build configuration, signing, store-listing assets and submission support. Review decisions remain with the platform, so the schedule should allow room for feedback and any required changes. We also agree who maintains the app after launch and how future operating-system updates, dependency changes and product improvements will be handled.
How delivery works
Understand the work
We start with your users, business model and current constraints. Bring an idea, a running product or a workflow that causes friction. Together we identify what needs to change and what a useful first outcome looks like.
Shape a practical scope
We connect the user journey to the design, engineering and operational work it needs. Assumptions, dependencies and responsibilities are discussed early, so you can make informed decisions about the first release and the work that follows.
Build with visible progress
Designs, prototypes and working features give us something concrete to discuss. We review progress with you, resolve questions as they arise and test the important journeys. Changes to priorities are considered against the agreed scope.
Launch and keep improving
Release preparation includes the agreed testing, deployment and handover. We make support responsibilities clear and can continue as your product team, improving the experience as you learn from real use and plan the next release.
Coach Phil brings fitness goals, meals and workouts into a subscription app, with a separate admin workspace for managing the coaching experience. See both sides of the product.
Explore related workFrequently asked questions
Can you guarantee approval by a particular date?
No. We can prepare the submission and help address feedback, but review decisions and timing belong to the platform. The release plan should allow time for review and any changes that may be requested.
Can this be a focused engagement within our existing product?
Yes. We can scope this work around an existing product after reviewing the relevant design, code or operating setup. We identify the dependencies and agree what is included, who provides access and how the change will be reviewed. If another part of the product also needs work, we explain that before expanding the scope.