Practical notes

06.1 Writing a bug report in 3 minutes

1. What you did: the steps that led to the problem, one per line.
2. What you expected and what actually happened.
3. Where: device, OS version, app version (usually in settings).
4. When: date and approximate Kyiv time — this helps find the crash in logs.
5. Does it repeat: always, sometimes, once.
6. A screenshot or screen recording, without passwords or others’ personal data.

06.2 The yearly OS update calendar

Apple and Google usually preview new OS versions in spring–summer and release in autumn. New store requirements for target SDK versions often take effect in the second half of the year.

Spring–summer

read beta release notes, list risks

Summer

build against beta SDK, fix warnings

Autumn

verify on final release, ship a compatible update

Winter

remove deprecated code, update dependencies

Exact dates are announced each year by Apple and Google — check their official developer pages.

06.3 A one-page brief template

• Who the app is for and the one job it does
• The three most important user journeys
• What already exists: mock-ups, code, accounts, APIs
• Constraints: dates, budget range, mandatory integrations
• How you will know the first release succeeded

06.4 Glossary of care

Dependency

a third-party code package the app relies on; needs regular updates

Build

a specific version of the app compiled from code at a point in time

Staged rollout

releasing an update to a share of users to spot problems early

Regression

a bug in something that used to work

Technical debt

deferred improvements that make change more expensive over time