Here is my opinion related to your situation: you probably already have a mindset about testing as being reactive (meaning is starts after something is built). It might help on the long term (with efforts done on short term) to change this and involve the testing team as soon as possible in your development effort. As they time will pass by this will reduce the number of bugs, the need for retesting and regression and thus in the end maybe more time for the testers.

Aside from this big change, here are more practical advices:

The Testing Team _can start_ as soon as they can execute the mobile app (either through a simulator/emulator or directly on the device).

In order to minimze the effort of the testing team here are some things that I think might help:

1. The purpose of the testing team should be: a) covering all functionalities and b) discover as much bugs as possible.

2. To be able to implement the first point, then the testing team should define a series of risks they want to cover. This can be done quick and efficient if they have two types of knowledge:

   (a) about what the application does (and here I think they can maximize what they learned from other platforms) 

   and 

   (b) about the types of bugs specific to the platform they are testing. 
   ​

With these in mind they can write a list of risks of what might go wrong in the app, even before starting the testing using the knowledge they have about the product features.

With this list and with an app ready to be installed on the device they can and should start testing.

I hould say two more things:

1) Optimising the testing effort by limiting different variables related to the testing process (ie. start as late as possible, doing it with few people ...) should be a decision always balanced by risks. I'm not saying you should not do it. But I am saying that when taking a decision one should assess what is there that one can risk in terms of probability and impact.

2) Testing is an activity that can be done also by development. So you can - and should based on many best practices - write unit testing as much as possible. Writing unit testing by development team lets the testing team focus more on exploration of functionalities and putting themselves in the shoes of the end-user and thus discovering what might go wrong from that perspective.

3) When constrained by time pressure one strategic focus of the testing team should be to cover more with less effort. It can be they should use more tools, learn more best practices, increase some skills that buy time (example: how fast they can type) or buy faster machines or decrease the amount of documentation written.

Hope this helps in some ways.

edit: formatting