How do we manage missing a missing skill ?

If the team can't meet the Definition of Done for the work being asked of them, then they should not agree to start the sprint. If they don't have the skills and/or the people then they have a duty not to commence. No-one can force that work onto a team.

If the Product Owner would find value in an iPhone-only release, and can manage that value without Android dependencies, then a different DoD may be negotiated for what is essentially a different component product. However a Development Team with only 2 members is too small for Scrum and so they may still reasonably refuse to commence sprinting.

- I know there shouldn't be defined roles in Scrum, but only one have the Android skill.

Of course there are. What you mean is: There are no titles for Development Team members other than Developer.
And the great thing about experience is: Now you know why.
Titles like "Android developer" encourage members to work on separate things rather than collaborate.
Collaboration causes skills to spread through the team which solves your problem of scarce skills.
For the moment I agree with Ian: The team cannot commit to deliver a done increment, if "done" includes things the team lacks the necessary skills for. In order to deliver the highest possible value while keeping transparency high, I would change the DoD accordingly, make it transparent to the organization that it has a dysfunction here and work with the team on this problem of scarce skills.
This means: Ask the team for ideas how to solve them.
When I have done this, they often had great ideas like pair programming, trainings etc.

Agree with Ian and Ludwig.

You've identified an impediment that needs to be made visible within the organization. This is a classic example of the limitations around specialization - use it!

I also see part of the issue around the definition of product (combining IPhone and Android), but based on your current set-up and limitations, it may be a constraint that you just need to deal with short-term.

You state that your DoD has "Released on both iPhone and Android". Who crafted the team's DoD? It just seems that this situation should have been foreseen, and the team should have been thinking of ways to mitigate it already.

It seems too that there could be possible stories that may not require releasing on both platforms (either IPhone or Andriod-specific functionality), so I'm uncertain why the DoD criteria is so restrictive.

And finally, I don't see why splitting your stories by destination platform (server, IPhone, Android) looks bad. What better way to promote much-needed cross-training and pair-programming than having your 3 developers working together on an story that targets only one platform?

That really helps, thanks Timothy, Ian and Ludwig. Glad you spent time writting for us.

So that's my first week with this team, the DoD, member's specialisation and lack of earlier forecast on the situation have been given to me as it is. I intend to fix that as good as I can. No one in the company would dare refusing to start the work, glad enough we are getting more Agile.

The solution we implemented today is to split the stories by destination platform, and change part of the DoD to be "Released on the platform mentionned in the story".
That make my backlog twice bigger, but it got accepted by PO.

Hopefully that will introduce cross-training, but it also can split my team as Android and iOs does not "have" to work on the same story anymore to reach the DoD.

I'm looking forward for my team to be more cross-trained, it might take a while considering my Android guy never touched a Mac ;)