DigitableCourses
Portal settings
Русский
Show me around

Local and account-free. No account, no sign-up: whatever you type into the tools stays in this browser's localStorage and never reaches a server.

Our own counter records page opens and finishes: the address leaves, plus one tenth-of-the-text figure. No cookies, no outside trackers, your IP is not stored, Do Not Track is honoured. How to check that

The portal's own repository is not published, so we do not call it open source. What is open:

Digit flang Agent gate tools-core IT Tools Chat digitwm blender-mcp Hugging Face Licences

The portal lives on donations, paid consultations and requested write-ups, and on Workbench sales.

Support Order a write-up Workbench

There are no plans to make the courses paid.

Career

Mobile developer

Apps for iOS and Android: the platform, offline, background work, releases through the stores.

Roles and moves Self-assessment

Step 2 of 2 · Mobile developer

Which level inside the role?

Where people go from here: Frontend developer, Backend developer, Team lead, tech lead, engineering manager

Not sure — open the whole role card Pick another role

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Junior

Straight to the self-check

Compared with studying, the owner of the rules changes: what an application may do is decided by the platform, not by you.

Do now

  • I check my screen on rotation, on an incoming call and after the process has been killedThe state comes back instead of starting over.
  • I go through the screen on a bad connection and in aeroplane modeThe application explains that there is no connection and does not crash.
  • I build the layout for a large font and a small screenThe text is not cut off, and the buttons can be reached.
  • I work out where my branch merges and what will make it into the next buildI know which build my change will ship in without asking anyone.

Where next

Middle

Sideways out of the role

What this step asks of you

  • I understand the lifecycle of a screen and of the app on my platformI know what happens to my screen on rotation, on an incoming call and when the process is killed.
  • I build screens and navigation from a mockupThe layout survives a small screen, a large font and a long text.
  • I go to the network and handle the errors, not only the happy pathThe app does not crash in the underground and says clearly that there is no connection.
  • I work in a shared branch and understand the team's release cycleI know where my branch merges to and what will make it into the next build.

Common mistakes

  • Testing only on your own phone: people have older devices and another version of the system.
  • Treating the lifecycle of a screen as a detail: lost state is found by users and is hard to reproduce.
  • Pulling anything and everything into the application: size and start-up time cost more to fix later than not to add.

What to learn

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Middle

Straight to the self-check

The boundary of responsibility changes: a feature does not end at the screen — behind it are offline, background work and the review queue in the store.

Do now

  • I split the application into layers so that the logic can be checked without the interfaceA test for the logic runs without an emulator.
  • I write the rule for resolving sync conflicts before they happenA conflict ends in an outcome you can explain rather than in lost data.
  • I take a release through the store and rehearse the rollbackI know what to do about a bug in production while store review is still going on.
  • I bring background work down to what the platform allowsThe job runs with no hacks against the system.

Where next

Senior

Sideways out of the role

What this step asks of you

  • I lay the app out in layers, not in screensThe logic can be tested without launching the UI.
  • I build offline and synchronisation knowing that conflicts will happenI have a rule for resolving conflicts, not a hope that none will occur.
  • I work with background tasks and push notifications within the limits of the platformI understand why the system kills my background work, and I do not fight it with hacks.
  • I take a release through the store and can roll backI know what to do about a bug in production when review in the store takes a day.

Common mistakes

  • Fighting the limits of the platform with hacks: the next system update breaks them all at once.
  • Hoping that offline will somehow sync itself: the conflicts are found by your most active users.
  • Shipping a release with no rollback plan: the fix travels through store review rather than through a button.

What to learn

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Senior

Straight to the self-check

What you are risking changes: a released version cannot be recalled, and it stays on people's phones together with all of its mistakes.

Do now

  • I measure start-up, memory and battery on a weak device rather than on my ownThere are measurements before and after on a real phone.
  • I separate what we check automatically from what we check by hand, and explain whyThe list of manual checks is short and has reasons behind it.
  • I look at my own data through the eyes of whoever is holding the phoneThe application keeps no secrets that must not be shown.
  • I revisit the choice between native and cross-platform for my own teamI can name the price of the choice for us instead of arguing about frameworks in general.

Where next

Further on: a branching, not a rung

Sideways out of the role

What this step asks of you

  • I keep startup, memory and battery within limits I measured myselfI have the numbers before and after, taken on a real low-end device.
  • I protect data on a device that does not belong to meI do not keep secrets in the app, and I know that a client can always be cracked open.
  • I build testing that survives a zoo of devicesI know what we automate, what we deliberately check by hand, and why.
  • I choose native or cross-platform deliberatelyI can name the price of the choice for a specific team instead of arguing about frameworks in general.

Common mistakes

  • Keeping support for old versions on trust alone: people do not update, and the old client stays alive long after you stopped thinking about it.
  • Optimising by feel: without a measurement on a weak device the improvement goes unnoticed.
  • Arguing about frameworks instead of the problem: the choice is paid for by the team either way, not by the argument.

What to learn

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Further on: a branching, not a rung

Straight to the self-check

There is no rung upwards: from here the subject changes — other teams, the product or people — and each road leads its own distance away from the code.

Do now

  • I try the neighbouring job on my own task before changing rolesI have run a user interview or built the release pipeline, and I know whether it is for me.
  • I hand my shared module to a neighbouring team together with a path for upgradingIt is used by people I cannot give orders to.
  • I take the manual steps out of the release one at a timeThe list of manual operations before shipping has got shorter.
  • I teach the platform to somebody who came from the webThe person ships their first version themselves.

Where next

Not another step — a fork

Sideways out of the role

What this step asks of you

  • I build the shared foundation of the application that other teams useMy module has versions, a path for upgrading and real users inside the company.
  • I set up a release pipeline that works without meBuilding, signing and rolling out happen with no manual steps and do not wait for one person.
  • I judge the result of a feature by what people do, not by the number of versions shippedI can name what changed after the release and why it is not a coincidence.
  • I bring people from other platforms into mobile developmentPeople have grown next to me who had never shipped an application before.

Common mistakes

  • Treating management as the next rung: it is a different profession, and the release cycle makes it a particularly hard one here.
  • Building a shared module with no users: it turns into a personal project at the company's expense.
  • Keeping the magic of the release in your own head: your holiday stops the shipping.

What to learn

IT Tools source · GPL-3.0 Digitable Chat source · GPL-2.0-or-later Legal documents