Wenn beispielsweise die Zielgruppe des Unternehmens hauptsächlich aus Blackberry-Anwendern besteht, sollte eine Applikation für diese Zielgruppe, ihre Bedürfnisse und ihr Nutzungsverhalten entwickelt werden – ungeachtet der schwindenden Marktstellung. Eine beeindruckende Realisierung als Apple-I-OS-App wäre im Wortsinne für diesen Anwenderkreis nutzlos.
Wird dagegen kein Gerätetyp bevorzugt, ist zu überlegen, ob Plattformunabhängigkeit eine sinnvolle Designvorgabe sein kann. Dient eine App beispielsweise eher dem Nachschlagen von Informationen ist die Umsetzung als Web-App ein überlegenswerter Ansatz, wie es unter anderem Wikipedia vormacht.
Benötigen Apps dagegen mehr Zugriff auf Gerätefunktionen, sind hybride Apps ein alternativer Realisierungspfad, den unter anderem Facebook wählte.
Falls eine App wie die Metro-Group-Marathon-App allerdings auf einen mehrstündigen Dauereinsatz ausgelegt wird, bleibt nur der „native“ Weg. Denn mit Blick auf die Akkuleistung scheidet die Realisierung als Browser-App oder hybride App aus. Schließlich verlangt jede zusätzliche (Software-)Ebene ihr Quantum an Energie und Systemleistung.
Native Apps setzen direkt auf dem Betriebssystem der jeweiligen mobilen Geräte auf. Jede Plattform stellt hierzu unterschiedliche Entwicklungskits, Benutzeroberflächen und Programmiersprachen (Objective-C/C++ auf Apple-I-OS, Java auf Android und C# auf WP7, C++ oder Java-ME auf Symbian und Bada) bereit. Sollen mehrere Plattformen unterstützt werden, muss folglich für jede Plattform eine eigene native App realisiert werden. Sie sind wie ihre stationären Vorbilder mit HTML5, CSS und Javascript programmiert.