From ticket to a build on your phone
Access and accounts come first
Before any code, we sort out ownership. The Apple Developer and Google Play accounts should belong to your company, with our developer invited as a team member. The same goes for Firebase and any analytics or crash reporting service. It takes a day or two and saves a painful transfer later. Your developer also needs the designs, API documentation or a staging API, and a list of the devices your customers really use.
Weeks one and two
For a new app, the first fortnight produces the project skeleton: architecture, theme, navigation, environment flavors and a build pipeline that can put an installable app on your phone. Then come the first real screens. For an existing app, the developer gets it building, upgrades what must be upgraded, reads the crash reports and tells you what state the code is in. In both cases you should have a test build in your hands by the end of week two, however plain it looks.
The weekly loop
Mobile work is easier to judge on a device than in a report. So the routine is simple. Tickets are agreed at the start of the week, and a new build reaches your testers through TestFlight and a Play testing track when there is something to try, with notes on what changed. You tap through it on your own phone and reply with comments or screen recordings. When the API is built by another team, the developer agrees the request and response shapes with them before coding and works against mock data until the endpoint is ready, which keeps both sides moving.
Testing and review
Business logic is covered by unit tests and important screens by widget tests. Before a release, the app is run on physical iOS and Android devices, covering slow networks, denied permissions and interrupted flows. Pull requests are reviewed by a second mobile developer or by your own engineers. For store releases a QA engineer from our team can run a regression pass if you want one.
Store submissions and judging fit
Review times and decisions belong to Apple and Google, so we never promise a launch date we do not control. What we can do is submit early, fill in the privacy and permission declarations accurately and answer reviewers quickly. As for fit: a good Flutter developer talks about edge cases unprompted, keeps build numbers and release notes tidy and gives you something new to tap on most weeks. For work beyond Flutter, our mobile app development pages cover the native options.